Decades of experience and research had led to an industry standard methodology for efficient software development methodology for both hardware and software. Development is divided into phases where specific goals are defined. When the decisions makers agree that the goals for a phase have been met, development continues to the next phase. This document will focus on the software version of this development methodology.

Phases in the Software Lifecycle are:

1. Requirements
2. External Design
3. Internal Design
4. Implementation
5. Unit Test/Integration
6. System Test/Release
7. Maintenance

In the following diagram, the area under the curve represents the relative amount of work in each phase.

The cost of resolving problems grows exponentially with each succeeding phase. For example, if a software defect, that could have been found during unit test, is not found until the product is released, it is very costly to make the change and re-release the product. Further, if a requirement is not found until system test, then portions of the entire lifecycle must be redone.

Phase Review Team

To facilitate the workings of the phase review process, a phase review team is established. This team is typically composed of a chairman represent executive management and members for various functional areas:

• marketing

• engineering

• manufacturing, if applicable

• quality assurance

• sales

• customer support and training

This team meets regularly to review the process towards the goals of each phase. A document is produced for each development phase. The Phase Review Team signs an approval coversheet upon completion of each phase.

Requirement Phase

Definition

The Requirements Phase includes the definition of the requirements for the product. Marketing typically drives the generation of the requirements. Ideas for possible features may be presented by engineering which are then evaluated by various marketing techniques to determine market needs, to test response by potential customers, and to determine priorities. Requirements for features are documented, but care is taken not to describe possible implementations only requirements for features. Requirements include:

• features
• definition of potential customers and target markets
• cost and price
• performance
• safety
• regulatory factors
• documentation and training needs

Phase Review and Signoff

Once all of the requirements are documented and agreed upon, the Phase Review Team signs the approval coversheet.

External Design Phase

Definition

The External Design Phase includes the design of a product or suite of products that meet the requirements. The external design includes:

• definition of user interfaces both command line and graphical
• features visible by users such screens and reports
• external interfaces to other programs or systems
• high level architecture showing dependency on external components such as operating systems, web browsers, etc.
• models for databases and lists of procedures for accessing the tables within the database
• response to cost, price, performance, safety, and regulatory requirements.

Engineering typically drives the external design with iterative feedback from marketing and the other functional areas.

Phase Review and Signoff

Once the external design and any amendments of the requirements are documented and agreed upon, the Phase Review Team signs the approval coversheet.

Internal Design Phase

Definition

The Internal Design Phase includes the design of implementation details that are not visible to external users. These implementation details include:

• internal architecture of program modules
• definitions for inter-module interfaces
• lists of key data structures and methods or functions associated with each module

Phase Review and Signoff

Once the internal design and any amendments of the external design are documented and agreed upon, the Phase Review Team signs the approval coversheet.

Implementation Phase

Definition

The Implementation Phase includes the following:

• coding in one or more programming languages
• implementation of each inter-module interface
• implementation of key data structures and methods or functions associated with each module

Phase Review and Signoff

Once the implementation of a module is complete a code review is held. When all modules specified in the Internal Design document have passed code review, the Phase Review Team signs the implementation phase completion approval form.

Unit Test and Integration Phase

Definition

The Unit Test and Integration Phase includes the following:

• testing each module in a standalone environment (typically by its developer)
• integration of previously tested modules (typically by the developers of those modules or an integration team)

During this phase problems with the implementation of individual modules are found and fixed and inter-module interfaces are tested.

NOTE: This phase traditionally has been underestimated by developers and schedulers and typically takes one third of the amount of calendar time spent on the previous phases.

Phase Review and Signoff

When all modules have been unit tested and integrated, the Phase Review Team signs the unit test and integration phase completion approval form.

System Test and Release Phase

Definition

The System Test and Release Phase includes the following:

• functionally testing the system as a whole
• performance and stress testing
• testing documentation against product as implemented
• testing on multiple platforms and configuration
• labeling source code with release information
• producing final versions and securely archiving product components

During this phase problems are found, fixed if critical, and re-tested. This phase may also include a limited release to beta testers or earlier adoption customers to ensure the product is ready for general release.

Quality Assurance drives this phase and typically uses problem report statistics to determine quality, stability, and reliability of the product. Typically a QA Plan document defines the criteria for release of a product.

Phase Review and Signoff

When the product has been thoroughly tested and the release criteria have been meet, the Phase Review Team signs the system test and release approval form.

Maintenance Phase

Definition

The Maintenance Phase includes the following:

• installation of the product
• customer support
• tracking of defects found in the product
• fixing defects in the released software
• releasing bug fix patches or bug fix releases
• gathering customer feedback for inclusion into future version or new products

Customer service, sales, marketing, engineering and QA share responsibilities during this phase. Typically a dedicated group of more junior engineers are assigned maintenance programming tasks, allowing them to learn the architecture and improve their skills and allowing the senior engineers and architects to be free to develop new products.

Phase Review and Signoff

When a product is discontinued or replaced by a new version of the product, the Phase Review Team ensures that customers are migrated forward and defect repairs and lessons learned are passed on to future products.

Typically there is no formal signoff of this

Rapid Prototyping

The recent availability of various rapid prototyping techniques can be a valuable asset in reducing product development cycle times. Marketing may develop a rapid prototype to test ideas to understand requirements, customer preferences, and priorities. Engineering may develop rapid prototypes to better understand architectural issues and to better communicate external designs.

It is important however to realize that a prototype is a prototype and not a product. Shipping prototypes that have not been fully designed, engineered and tested can be very costly.

Phase Overlap

As a practical matter, not all tasks for a given phase signoff will be completed at the exact same time. Those workers who have meet there goals cannot always help in the remaining tasks required for phase completion and it is reasonable for them to work ahead on the next phase. However, they should realize that requirements or interfaces may change and that they may have to revisit their work to maintain compatibility.

Also it is important for product testing and quality assurance to begin in parallel with implementation. Test automation can be a very important tool to developers who are unit testing their recently coded modules.

JAD Sessions

While the team is working to understand and document requirements and external designs, it is often beneficial to have experts from the various functional areas meet regularly to review previous work, discuss new facets of the problem and possible solutions. These Joint Application Development (JAD) sessions are extremely productive and lead to high quality products.

Conclusion

Using a sound development methodology ensures that software products are developed, in a timely, predictable manner, to meet market needs. Problems are found as early as possible in the product’s lifecycle and the cost to resolve problems are reduced.