Search Results for:

The Waterfall, Spiral, and Vee models are reminder models that guide us to less perilous paths when developing solutions to problems. Dr. Royce’s Waterfall (Royce 1970) provides an orderly approach to software development. Dr. Boehm’s Spiral (Boehm 1988) provides emphasis on solving known software risks before proceeding with Royce’s Waterfall. The Forsberg/Mooz Vee Model (Forsberg 1991) embraces full systems development by including details of integration, verification, and validation and opportunity and risk management in the symmetry of the Vee development sequence. However, all of these single solution development models fail to address the necessary concurrent development of a system’s architecture with the entities of that architecture.

While the original Vee-Model allowed for off-core concurrent engineering, the Dual Vee moves those off-core activities into core processes. In discussing the shortcomings of the Waterfall variants, they said:

“All of these popular development models, while quite accurate in their contributions to solution development, fail to adequately address the real life challenges of concurrently developing the system’s architecture while at the same time creating the architecture entities that are in various stages of their development especially when COTS, NDI and new development are all part of the architecture. Since our original Vee model did not clearly provide this aspect we have developed the Dual Vee…”

The Dual Vee Model recognizes two types of system development maturation in an Architecture Vee and an Entity Vee. The system architecture is defined as a “complement of entities that are to be realized at all architecture levels.” Entity development is “the creation of each entity within the architecture complement.” These two Vee models represent separate but concurrent paths that intersect at various points along the development life cycle culminating in system realization.

In concluding their paper, Forsberg and Mooz said, “Development of systems and system of systems requires the concurrent development of complex architectures and the entities of those architectures. A model has been needed to depict the required multi aspect decisions required to ensure correct and progressive development of both architecture and entity baselines. The Dual Vee Model offers the features of concurrent development, in parallel opportunity and risk management, integration, verification and validation planning, and anomaly resolution. It is a comprehensive reminder model that can remind us of our industry’s best practices, if we allow it to.”

Both Forsberg and Mooz are involved in the aerospace industry. At the time of the document, Forsberg had 27 years of experience in Applied Research, System Engineering, Program, and Proposal Management, followed by seven years of successful consulting to both government and industry. He received the NASA Public Service Medal for his contributions to the Space Shuttle program. Mooz had 22 years of experience in System Engineering and Program Management, followed by ten years of successful consulting to government and industry. Mooz has won and successfully managed highly reliable, sophisticated satellite programs from inception to operations. It’s a fascinating coincidence that both the German and US V-Models were parented by the aerospace industry.

Forsberg and Mooz believe their Vee-Model addresses the system engineering deficiencies of Linear Waterfall, Modified Waterfall and DOD-STD-2167A, the immediate successor to DOD-STD-2167. They mention Boehm’s Spiral Model in their paper and say, “While Boehm’s spiral representation (Exhibit 4) achieves his objective, the system engineering role is still obscured.” The “(Exhibit 4)” in the quote refers to an image of Boehm’s model reproduced in their document.

As all the other models we’ve discussed thus far, the Vee-Model is Waterfall based with notable exceptions. They said, “In our approach, the technical aspect of the project cycle is envisioned as a “Vee,” starting with User needs on the upper left and ending with a User-validated system on the upper right.” Notice the deliberate use of the word “user” implying end users are involved in all aspects of the development cycle.

The model recognizes the changeability of requirements and provides for the establishment of six baselines: User Requirements Baseline, Concept Baseline, System Performance Baseline, “Design-To” Baseline, “Build-To” Baseline and “As-Built” Baseline. The process is iterative and allows for incremental development and concurrent engineering within any phase until that phase’s stage review. After a stage review successfully completes, a new phase is initiated and the old phase is not revisited as in the Waterfall design. Major emphasis is placed on Verification and Validation activities, risk identification and risk reduction modeling. Verification and validation mean that all requirements are testable and agreed to by the stakeholders. We’ll discuss verification and validation in detail in the requirements chapters.

The Forsberg and Mooz Vee-Model consists of nine phases:

• Understand user requirements, develop system concept and validation plan
• Develop system performance specification and system verification plan
• Expand system performance specification into CI “Design-to” specifications and CI verification plan
• Evolve “Design-to” specifications into “Build-to” documentation and inspection plan
• Fabricate, assemble and code to “Build-to” documentation
• Inspect to “Build-to” documentation
• Assemble CIs and perform CI verification to CI “Design-to” specifications
• Integrate system and perform system verification to performance specification
• Demonstrate and validate system to user validation plan

Much of the risk analysis and concurrent systems engineering occur in “off-core” activities. Forsberg and Mooz said, “While technical feasibility decisions are made in the off-core activities only decisions at the core-level are put under Configuration Management at the various Control Gates. Off-core activities, analyses, and models are performed to substantiate the core decisions and to ensure that risks have been mitigated or determined to be acceptable.”