- The Capability Maturity Model for Software
- Requirements Analysis and Definition
- Validation and Testing
- Production Acceptance
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Requirements Analysis and Definition
This is where every software project starts. Requirements serve many purposes for a software development project. For starters, requirements define what the software is supposed to do. The software requirements serve as the basis for all the future design, coding, and testing that will be done on the project. Typically, requirements start out as high-level general statements about the software's functionality as perceived by the users of the software. Requirements are further defined through performance, look and feel, and other criteria. Each top-level requirement is assigned to one or more subsystems within an application. Subsystem-level requirements are further refined and allocated to individual modules. As this process points out, requirements definition is not just a process that takes place at the start of a development project, but an ongoing process. This is especially true when a spiral development model is used. The ability to manage the definition and tracking of requirements is a key process area required of level 2 organizations by the SW-CMM.
System Architecture and Design
The system design stage is where the software architect plays a crucial role. The architect takes the output from the requirements stage, which states what the software is supposed to do, and defines how it should do it. This is a crucial stage for any software project because even the best programmers will have trouble implementing a poor design.
Test Plan Design
Designing your software test plan is really part of system design, but we've decided to break this out into a separate stage because it's so often overlooked. Many great software designs end in unsuccessful projects because no one thought about how the system would be tested.
Implementation
During the implementation or coding stage of a software development project, software engineers complete detailed level designs and write code. One of the key processes that level 3 organizations complete during the implementation stage is peer review. During a peer review, a group of developers meet to review a software module, including the code under development, the detailed design, and the requirements of the module. To someone who isn't a software developer, getting a half-dozen people in a room to review, line by line, hundreds of lines of code in a software module may seem like a large waste of time. In reality, however, code reviews are one of the common processes followed by successful software development organizations of all kinds. Here's the outline for a sample code review:
Attendees: We typically try to have four to eight code reviewers (peers of the developer) from the same or related application development teams. The developer's manager attends, if possible. We typically try to involve a system architect or senior developer as a facilitator for the code review.
Ground rules: We have found that these ground rules are essential to making a code review productive. We always review the ground rules at the start of each code review.
No grading. The purpose of the code review is not to grade or otherwise measure the performance of a developer, but to identify and resolve any issues while the code is still under development. Unless this is perfectly understood and practiced, we often find a developer's peers are unwilling to raise issues with code in front of a manager or more senior developer for fear of having a negative impact on the developer. This dilutes the entire value of the code review.
No incomplete phrases. During the review, incomplete phrases are typically well understood by all given their context. However, two weeks later, a developer will typically not be able to understand the meaning of an incomplete phrase noted in the meeting minutes. When everyone speaks and writes in complete sentences, it makes follow-up on the review much simpler.
Majority rules. Everyone must agree up front that when issues are raised, they will be discussed until everyone is in agreement. This is a peer review by developers working on the same or closely related applications. If there are any questions as to the validity of the design or of a code segment, this is the time to resolve it. If there is not 100% agreement, then those in the minority must ultimately side with the majority view if they can't sway others to their case.
Stay intellectually committed. It takes a lot of effort to follow the code of another developer line by line. However, everyone in the code review is making a major investment in the review for the benefit of the entire team. Everyone needs to be 100% committed to the review process and not duck what they perceive as issues.
Requirements review: The developer presents the requirements that have been allocated to the module.
Design review: The developer presents the detailed design of the module. Visual aids used include flowcharts, UML diagrams, call graph trees, class hierarchies, and user interface components.
Code review: At this point, the facilitator takes over and walks everyone through the code. This frees the developer to concentrate on listening to and documenting comments made by the reviewers.
Summary: The facilitator summarizes the findings of the code review. If necessary, specific design modifications are determined. If major design changes are required, a follow-up code review will always be conducted. If only minor code changes are identified, no follow-up review is required in most cases.