Dual Vee Model
Encyclopedia
The Dual Vee Model builds on the V-Model to cleanly depict the complexity
associated with designing and developing system
s. 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.
Waterfall Model
The Waterfall Model breaks up the development process into development phases. The name implies that design decisions flow from the requirements, implementation decisions flow from the design, etc. 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." etc.
The Vee Model can be expanded in several ways to meet system requirements. It can include the seven INCOSE
layers of system complexity (i.e. system, element, subsystem, assembly, subassembly, component, and part). It can include decomposition, definition, integration, and verification. It may also include user/stakeholder participation, opportunity and risk management, and problem resolution.
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 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 the 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, so too 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 (which is in-process validation), and downward for opportunity and risk management, as shown in the following figure.
The left leg off-Vee core investigations center around what concept is best and what architecture is best for that concept. For example, commercial products usually face the dilemma as to whether batteries should be standard, unique, replaceable, or not. Downward off-Vee core investigations and analysis can facilitate determining the most desirable approach that would then be baselined on the Vee core if the 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 live with 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 deliberate. 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.
At each elaboration, there is a direct correlation between activities on the left and right legs of the Entity Vee. Again this is deliberate. The method of verification to be used on the right Vee leg must be defined as requirements are developed on the left, otherwise requirements might be created that could not be verified. For example “user friendly” is a valid requirement, but it is unverifiable. Instead, 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 verification requirements and methods are known and planned for at the design-to decision gate, commonly called Preliminary Design Review (PDR). Draft verification procedures based on the verification requirements, verification plan, and proposed entity design should be available at the build-to and code-to decision gate, commonly called Critical Design Review (CDR). This reduces the chances that verification as specified cannot in fact be performed.
The vertical dimension of the Entity Vee is baseline elaboration at the selected architecture level and the core of the Entity Vee represents entity baseline elaboration progression. Also included (similar to the Architecture Vee) are the activities associated with opportunity and risk management, pursued downward and off-core to the level of detail necessary for issue evaluation and resolution. For example, laboratory test of a computer chip or of software code may be necessary to confirm technical feasibility. Unlike the commonly held view of the Waterfall Model, there is no prohibition against doing exploratory design and analysis at any point in the project cycle to investigate or prove performance or feasibility. Unlike the Spiral Model, the Vee opportunity and risk investigations may be performed either in series or in parallel with the on-core development work, rather than being conducted sequentially and prior to 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 the two concepts could be modeled with selection based on response time versus cost. Customer confirmation could then provide valuable in-process validation of the preferred approach.
In the right leg, downward off-core investigations are applied to resolve assembly and verification anomalies. This may require descending to design errors, a cold solder joint, 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 conducted on 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.
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 consistent with decomposition to the lowest configuration item level (LCI). This sequence ensures that there is 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, will perform as expected, and will meet user requirements.
Complexity
In general usage, complexity tends to be used to characterize something with many parts in intricate arrangement. The study of these complex linkages is the main goal of complex systems theory. In science there are at this time a number of approaches to characterizing complexity, many of which are...
associated with designing and developing system
System
System is a set of interacting or interdependent components forming an integrated whole....
s. In systems engineering
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...
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.
Waterfall ModelWaterfall modelThe waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.The waterfall...
The Waterfall Model breaks up the development process into development phases. The name implies that design decisions flow from the requirements, implementation decisions flow from the design, etc. 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." etc.Vee Model
The Vee Model organizes development phases into levels of complexity with the most complex item on top and least complex item on bottom (a.k.a. Lowest Configuration Item). This places the requirements at the beginning next to the product's operation at the end, and the design next to verification. This makes sense because when developer delivers a product to the customer, the customer may ask, "Why should I accept this product?" and the developer should answer, "Because it meets your (the customer's) requirements." The requirements are connect to the operation. When performing 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 that was built matches the design." Verification is connected to the design.The Vee Model can be expanded in several ways to meet system requirements. It can include the seven INCOSE
International Council on Systems Engineering
The International Council on Systems Engineering is a non-profit membership organization dedicated to the advancement of systems engineering and to raise the professional stature of systems engineers.- Overview :...
layers of system complexity (i.e. system, element, subsystem, assembly, subassembly, component, and part). It can include decomposition, definition, integration, and verification. It may also include user/stakeholder participation, opportunity and risk management, and problem resolution.
Dual Vee Model
The Dual Vee Model builds on 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 the 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, so too 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 (which is in-process validation), and downward for opportunity and risk management, as shown in the following figure.
The left leg off-Vee core investigations center around what concept is best and what architecture is best for that concept. For example, commercial products usually face the dilemma as to whether batteries should be standard, unique, replaceable, or not. Downward off-Vee core investigations and analysis can facilitate determining the most desirable approach that would then be baselined on the Vee core if the 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 live with 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 deliberate. 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 which describes 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 and on to design-to specifications and fully detailed build-to artifacts. The right Vee leg represents the sequence of entity assembly and performance assurance on 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. Again this is deliberate. The method of verification to be used on the right Vee leg must be defined as requirements are developed on the left, otherwise requirements might be created that could not be verified. For example “user friendly” is a valid requirement, but it is unverifiable. Instead, 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 verification requirements and methods are known and planned for at the design-to decision gate, commonly called Preliminary Design Review (PDR). Draft verification procedures based on the verification requirements, verification plan, and proposed entity design should be available at the build-to and code-to decision gate, commonly called Critical Design Review (CDR). This reduces the chances that verification as specified cannot in fact be performed.
The vertical dimension of the Entity Vee is baseline elaboration at the selected architecture level and the core of the Entity Vee represents entity baseline elaboration progression. Also included (similar to the Architecture Vee) are the activities associated with opportunity and risk management, pursued downward and off-core to the level of detail necessary for issue evaluation and resolution. For example, laboratory test of a computer chip or of software code may be necessary to confirm technical feasibility. Unlike the commonly held view of the Waterfall Model, there is no prohibition against doing exploratory design and analysis at any point in the project cycle to investigate or prove performance or feasibility. Unlike the Spiral Model, the Vee opportunity and risk investigations may be performed either in series or in parallel with the on-core development work, rather than being conducted sequentially and prior to 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 the two concepts could be modeled with selection based on response time versus cost. Customer confirmation could then provide valuable in-process validation of the preferred approach.
In the right leg, downward off-core investigations are applied to resolve assembly and verification anomalies. This may require descending to design errors, a cold solder joint, 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 conducted on 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
To evolve user needs into a system that satisfies those needs 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 of 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 phasingFor 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 consistent with decomposition to the lowest configuration item level (LCI). This sequence ensures that there is 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, will perform as expected, and will meet user requirements.