Dual Vee Model
| Software development |
|---|
| Core activities |
| Paradigms and models |
| Methodologies and frameworks |
| Supporting disciplines |
| Practices |
| Tools |
| Standards and Bodies of Knowledge |
| Glossaries |
The Dual Vee Model builds on the V-model to clearly depict the complexity associated with designing and developing systems.[1][2][3] In systems engineering, it defines a uniform procedure for product or project development. The model depicts concurrent development of a system's architecture as one Vee, with each entity of that architecture as another Vee that intersects the architecture Vee. This clearly shows interactions and sequences in developing a complex system and a system of systems.
Background
Waterfall model
The Waterfall model[4] breaks down the development process into development phases. The name implies that design decisions flow from the requirements, implementation decisions flow from the design, and so on. On a large project, many different people only work on each part. So a designer may ask, "What am I trying to design?", and the response would be, "You're trying to design something that will satisfy the product requirements." The builder may ask, "What am I trying to build?", and the response would be, "You're trying to build what was designed.", and so on.
Vee model
The Vee Model[6][7][8][9][10] organizes development phases into levels of complexity, with the most complex item at the top and the least complex at the bottom (also known as the lowest configuration item). This places requirements at the beginning, adjacent to the product's operation at the end, and design next to verification. This makes sense because when a developer delivers a product to a customer, the customer may ask, "Why should I accept this product?", and the developer should answer, "Because it meets your requirements." Requirements are connected to operation. During product testing, the test engineer may ask, "What tests should I conduct?", and the designer should answer, "You should conduct tests to show the product matches the design." Verification is connected to design.
The Vee model can be expanded to meet system requirements. It can include the seven INCOSE layers of system complexity (system, element, subsystem, assembly, subassembly, component, and part). It can also include decomposition, definition, integration, and verification. It may also include user/stakeholder participation, opportunity and risk management, and problem resolution. Waterfall modules are also included in the triple V module.
Dual vee model
The dual vee model extends the vee model to manage a system of systems. An architecture vee manages the system, and entity Vees branch off the architecture Vee to manage sub-systems.
For example, GPS includes a constellation of satellites, a ground control network, and millions of users worldwide. Each satellite, ground control center, and GPS receiver is a complex system that could be managed by a separate Entity Vee. Development of a satellite can affect the design, manufacturing, or cost of receivers. Similarly, development of a receiver can affect design, manufacturing, or cost of satellites. So everything must be integrated into a system of systems that are developed within a larger Architecture Vee.
The architecture vee
When developing complicated systems, a system engineer must manage a system baseline configuration from start to finish. The baseline can include design documents, user manuals, the product itself, and should answer every "What?", "Why?", and "Who?" for a system's architecture. At each development phase, there will be changes to the system, which will change the baseline.
The core of the vee is the evolving architecture baseline, from initial requirements to a delivered system. The Architecture Vee produces the what, why, and who (which entity level) is responsible for a system's architecture.
Downward off-vee core investigations (figure – below) facilitate gaining knowledge to justify architecture baseline decisions made on the Vee core. Upward off-core communication with customers and users facilitates in-process validation, keeping stakeholders abreast of and committed to the evolving baseline. Note that in all Vee representations, time and maturity move from left to right. Just as we cannot move backward in time, one cannot move from right to left in the Vee model representation. Iteration is essential in system development, and all iteration is done vertically off-core, upward to users and customers (in-process validation), and downward for opportunity and risk management, as shown in the following figure.
The left leg off-vee core investigations focus on what concept is best and what architecture is best for that concept. For example, commercial products often face the dilemma of whether batteries should be standard, unique, replaceable, or not. Downward off-Vee core investigations and analysis can help determine the most desirable approach, which would then be baselined on the Vee core if stakeholders agree. Similar investigations can prove the viability and technical feasibility of candidate concepts.
Right leg off-vee core downward investigations (figure – below) are directed at investigating integration anomalies to determine their root cause and to correct them. Upward communication with stakeholders determines if they can accept the as-integrated and as-verified performance.
At each decomposition level, there is a direct correlation between activities on the left and right sides of the Vee. This is intentional. For example, the method of integration, verification, and validation to be used on the right must be determined on the left as concepts are defined at each decomposition level. This minimizes the chances that concepts are conceived in a way that cannot be carried out.
The entity vee model
The entity vee illustrates the entity development and realization process, describing how each entity will be obtained (development, purchase, reuse, etc.). An entity vee (figure – below) exists for every entity of the architecture, from the system down to the lowest configuration items (LCIs), such as computer software units or hardware components. All activities within an Entity Vee reside at the same architecture level (System, Subsystem, LCI). The left Vee leg represents entity definition elaboration, from very sketchy user requirements, through concept determination to design-to specifications and fully detailed build-to artifacts. The right Vee leg represents the sequence of entity assembly and performance assurance, through verification and validation of the entity.
At each elaboration, there is a direct correlation between activities on the left and right legs of the Entity Vee. This is intentional. The method of verification to be used on the right must be defined as requirements are developed on the left; otherwise, requirements might be created that cannot be verified. For example, "user-friendly" is a valid requirement, but it is unverifiable. A requirement that a computer screen display have "no more than five lines of 14-point text" defines one user's view of "user-friendly" in measurable terms. Verification plans should be baselined to ensure that verification requirements and methods are known and planned for at the design-to decision gate (Preliminary Design Review – PDR). Draft verification procedures, based on verification requirements, verification plan, and proposed entity design, should be available at the build-to and code-to decision gate (Critical Design Review – CDR). This reduces the chances that specified verification cannot be performed.
The vertical dimension of the entity vee represents baseline elaboration at the selected architecture level. The core of the entity vee represents the progression of entity baseline elaboration. Also included (similar to the architecture vee) are activities associated with opportunity and risk management, pursued downward and off-core to the level of detail needed for issue evaluation and resolution. For example, laboratory testing of a computer chip or software code may be necessary to confirm technical feasibility. Contrary to the common view of the Waterfall Model, there is no prohibition against exploratory design and analysis at any point in the project cycle to investigate or prove performance or feasibility. Unlike the spiral model, vee opportunity and risk investigations may be performed either in series or in parallel with on-core development work, rather than sequentially before the design development process. Hardware and software requirements-understanding models or technical feasibility models are encouraged early in the project cycle to pursue opportunities, such as new technologies, and to reduce risk. For instance, to evaluate a concept of a manual override versus full automation, technical feasibility of both concepts could be modeled with selection based on response time versus cost. Customer confirmation can provide valuable in-process validation of the preferred approach.
In the right leg, downward off-core investigations are used to resolve assembly and verification anomalies. This may involve investigating design errors, cold solder joints, or operator error, and the like. Upward off-core user interactions obtain user and customer confirmation or rejection of the realized performance. Note that in the entity Vee, these interactions address individual entity solutions and not the integration of the architecture, which is handled by the architecture vee. At any level of decomposition, the customer of an entity is the manager of the next higher level of decomposition. For example, the power subsystem manager is the customer of the battery and is responsible for battery validation.
Dual vees: intersecting architecture and entity vees
Evolving user needs into a system that satisfies them requires a best-value solution for every entity of the architecture. This can be visualized by positioning entity vees orthogonal to the architecture vee, as shown in the figure below. For each entity of the Architecture Vee, there is a corresponding Entity Vee that addresses the entity development and realization. For example, the Architecture Vee in the figure below contains two subsystems, hence there are two Entity Vees to represent the concurrent development of those two subsystems.
Phasing of decision gates
Architecture entities are developed and integrated into the system architecture in a phased sequence consistent with systems engineering best practices. The figure below provides a three-dimensional view of Design-to and Build-to Decision Gate phasing
For simplicity of illustration, only one entity vee is shown intersecting the architecture vee at each decomposition level. Note that the design-to sequence is top-down, starting at the system level and proceeding consistently with decomposition to the lowest configuration item level (LCI). This sequence ensures proper top-down requirements flowdown and traceability.
When build-to and code-to artifacts, including draft verification procedures, are ready for baselining, the build-to decision gate sequence is conducted bottom-up to prove the feasibility of building or coding the designs. The decision gate also confirms that, if the solution is built according to the build-to artifacts, the required performance will be achieved. This sequence ensures that, if the entity designs satisfy their design-to requirements, the entities will integrate into the next higher-level entity, perform as expected, and meet user requirements.
References
- ↑ "Systems Engineering for Intelligent Transportation Systems" (PDF). US Dept. of Transportation. p. 10. Retrieved 2007-06-09.
- ↑ Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management, 3rd edition, John Wiley and Sons, New York, NY, 2005. Pages 108–116, 242–248, 341–360.
- ↑ International Council on Systems Engineering (INCOSE), Systems Engineering Handbook Version 3.1, August 2007, pages 3.3 to 3.8
- ↑ Winston W, Royce (August 1970), the Development of Large Software Systems, Proceedings, IEEE WESCON, pp. 1–9. Reprinted in tutorial: Thayer, R. H., ed. (1988), Software Engineering Project Management, Washington, D.C: IEEE Computer Society Press,
- ↑ Clarus Concept of Operations. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
- ↑ Forsberg, Kevin; Mooz, Harold (October 1991), The Relationship of System Engineering to the Project Cycle (PDF), Chattanooga, Tennessee: Proceedings of the National Council for Systems Engineering (NCOSE) Conference, pp. 57–65, archived from the original (PDF) on 27 February 2009.
- ↑ Forsberg, Kevin; Mooz, Harold (July 1995), Application of the Vee to Incremental and Evolutionary Development (PDF), St. Louis, MO: Proceedings of the National Council for Systems Engineering (NCOSE) Conference, pp. 801–808.
- ↑ Mooz, Harold; Forsberg, Kevin (August 1997), Visualizing System Engineering and Project Management as an Integrated Process (PDF), Los Angeles, CA: Proceedings of the International Council for Systems Engineering (INCOSE) Conference, pp. 569–576.
- ↑ Mooz, Harold; Forsberg, Kevin (July 2001), A Visual Explanation of Development Methods and Strategies Including the Waterfall, Spiral, Vee, Vee+, Vee++ Models (PDF), Melbourne, Australia: Proceedings of the International Council for Systems Engineering (INCOSE) Conference.
- ↑ Forsberg, Kevin; Mooz, H., Cotterman, H. (2005), Visualizing Project Management, Third Edition, New York, NY: J. Wiley & Sons, Inc.CS1 maint: Multiple names: authors list (link)
This article "Dual Vee Model" is from Wikipedia. The list of its authors can be seen in its historical. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
