End of stage wrap up

The end of a stage provides an opportunity to make course corrections and learn from the experience of the stage. Increasingly accurate estimates can be made as the project progresses, laying the groundwork for planning that will be done at the beginning of the next stage. Project experience to date should be recorded in a software project log so that it can be used by future projects.

Staged delivery is a flexible delivery approach, and a staged delivery plan can be executed with either of two general bents:

• The stages can be deterministic, which means that they mainly provide a means of delivering the most important software functionality earlier than would be possible with an all-at-once approach.
• The content of the stages can be redefined at the end of each  stage, which means that the stages deliver the most important functionality early but also provide an opportunity to change course at the end of each stage.

A projects new hope.

Hold an omnibus change board meeting

The time just after a release is a natural time to consider proposed feature changes en masse. The whole project team topically works hard to achieve its software release, and spending a day or two considering a proposed changes can provide a welcome change of pace. Project members shouldn’t be subjected to a continuous barrage of feature change request. If the number of times changes are considered is not limited, project members can find themselves evaluating change impacts every few days or so, and those bits of work add up to a huge distraction.

Recalibrate estimates

The end of a stage is a good time to review the project’s actual schedule performance against its planned schedule performance and revise the project estimates in the first place by considering these questions.

• Is the project scope still about the same as it was estimated by originally? if not, the estimate should be adjusted for the improved understanding of the project scope.
• Has the feature set been changed?
• Has the required level of performance, robustness or fit and finish changed?
• Has the development team been as productive as expected?
• Were necessary tasks omitted for the estimates? The estimates should be revised to account for these factors, too.

It isn’t wrong to underestimate the project size or overestimate the project team’s productivity early in the project; it’s wrong not to find and correct those estimation mistakes later in the project.

Projects time, price, and effort are different if we started making a cheese cake and close after they changed their minds to make a weeding cake.

Evaluate performance against the project plan.

Keep sure that the team is following the plan, and keep track of their advance to the current goal to make sure everybody keeps with the plan. This books approach makes it easy to follow the plan. Since the information is public, the plans are credible, humane and up to date.

Stick to the plan, if the plan is impossible to follow, replan. A sure way to lose control of the project is to abandon the original plan without putting a new plan in its place.

Archive project media

The archive is for the young and inexperience to look with fascination and the old and savvy the have at hand.

At the end of each stage, the environment used to create the software should be archived. Organizations often need to be able to recreate an old version of their software, which can be an impossible task of old versions of project components are unavailable.

The project should archive at least the following:

• Copies of the release package, including CDs, printed documentation, collateral material, and packaging.
• Source code.
• Database or data files released with the software.
• Data files used to create the software.
• Custom tools developed for use on the project.
• Commercial libraries.
• Graphic resources, video resources, sound resources, and other resources contained in the software.
• Source text files for help files and other documentation.
• Build scripts.
• Test scripts.
• Test data.

 

Closure.

At the very end of the stage delivery we must also update the projects log, which is a valuable material for future projects.

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Software release

Finally we approach the release state for the software, after all of the hard work the team did we deserve to release quality product. Since we are using the staged delivering approach we need to make sure that every stage of the project is in a releasable state, this is a hard work for the programmers, since much of the work must be making the project in to a useful release state the main activity relies on polishing the code and eliminating most of the bugs.

“We avoid releasing a software product in this state”. – Project team developer maybe.

When to release

The answer must teeter on the line between releasing poor quality software early and releasing high quality software late. Severe methods can help you base the answers to this questions on a firmer footing than the instinctive guesses.

Defect counts.

By comparing the number of defect code this week with the past week you can know how close is the project to completion. If the number of defects this week exceeds the number of defects resolved this week then the software still has miles to go.

Statistics on effort per defect.

The data on time required to fix defects categorized by type of defect will provide a basis for estimating remaining defect correction work for this and future projects.

Defect density prediction.

One of the easiest to judge whether a program is ready to release is to measure its defect density. The number of defects per line of code. The more historical project data you have the more confidence you can be in the prerelease defect density targets.

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

System testing

System testing is conducted in parallel with construction or a half step behind. It exercises the system from end to end, exposing defects that are the corrected by developers. Testers support developers by ensuring that the system’s quality remains high enough to support the integration of new code.

Philosophy

Test often becomes the critical-path activity on a software project because no une plans for it until the software is mostly complete. Without adequate preparation, ramping up testing activities quickly enough to fully test the software is impossible.

Although in this book’s approach system testing is developed right along with the software, the quality assurance role it plays is less dramatic that it is on a project that defer quality assurance until the end of the project.

System testing should test the entire scope of a system. Test cases should be designed to assure that each requirement is implemented and each line of code is executing without errors.

Strategic quality assurance

System testing can be sued not just to fix specific defects but take strategic action to improve the quality of the software. Commonly, about 80 percent of a system’s errors will be found in about 20 percent of its routines. Several software engineering studies have found that these routines contribute a disproportionate share of the total cost to a system.

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Team.

Working as a team

A project is not accomplished by only one person and in this chapter we focus in the many individuals that are directly related to the development of code, that is the working project team. The idea of the pragmatic programmer behind the pragmatic project is about to make the team a pragmatic team, by expanding the universe of action of pragmatism we now have a functional unit of people willing to cooperate for the sake of good programming.

As your project gets under way, we need to move away from issues of individual philosophy and coding to talk about larger, project-sized issues. We aren’t going to go into specifics of project management, but we will talk about a handful of critical areas that can make or break any project.

As soon as you have more than one person working on a project, you need to  establish some ground rules and delegate parts of the project accordingly. In Pragmatic Teams, we’ll show how to do this while honoring the pragmatic  philosophy.

When working on a team you must look up at the team while looking for broken windows, make your code clean and good to avoid this, and keep the communication about what is happening with the project in a pragmatic team people are looking for a meeting to keep in touch communication with the team is very important and helps to take more important decisions.

Testing

Testing is by no means an easy task, there is quality to be maintained and many things to keep in consideration when doing this, the testing is the part of the project where we look forward to the quality guide lines and go outside to look up defects in the code.

We need testing because programmers are unable to create bug free software.

There are several major types of software testing that you need to perform:

• Unit testing
• Integration testing
• Validation and verification
• Resource exhaustion, errors and recovery
• Performance testing
• Usability testing

Apollo program software minutes before deployment

Comment your code.

Pragmatic Programmers embrace documentation as an integral part of the overall development process. Writing documentation can be made easier by not duplicating effort or wasting time, and by keeping documentation close at hand—in the code itself, if possible.

There are basically two kinds of documentation produced for a project: internal and external. Internal documentation includes source code comments, design and test documents, and so on. External documentation is anything shipped or published to the outside world, such as user manuals. But regardless of the intended audience, or the role of the writer (developer or technical writer), all documentation is a mirror of the code. If there’s a discrepancy, the code is what matters—for better or worse.

Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can’t be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded, and so on.

Great expectations.

Going back to the expectations of the client and the characteristics of the project, the users want something that can solve all of their needs and we as developers want to deliver but sometimes we deliver more than is required be weary of that.

In reality, the success of a project is measured by how well it meets the expectations of its users. A project that falls below their expectations is deemed a failure, no matter how good the deliverable is in absolute terms. However, like the parent of the child expecting the cheap doll, go too far and you’ll be a failure, too.

 

Give what the client desires.

 

Bibliography

Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15 (2000).