PPI Articles & Presentations

Welcome to the PPI Articles & Presentations. Sign up to access premium content including participation in the contents section, newsletters, special offers and more.

The Wedge Model™

Share

Share on linkedin
Share on facebook
Share on twitter
Share on email

DESCRIPTION OF THE WEDGE MODEL™


Abstract

The Vee Model, first defined by Rook in 1986, has served well as a depiction of design of non-trivial systems through physical levels of solution description on the left-hand side of the Vee, and physical realization of system elements, together with their integration to create higher physical level system elements, on the right-hand side of the Vee. The Vee model has commonly shown verification of system elements on the right-hand side, against requirements for each element on the left. Whilst valuable, this depiction is a very limited representation of the reality of development of non-trivial systems. The Wedge ModelTM extends the basic Vee model to incorporate verification and validation of requirements, design, system elements and system, within a multiple-build development strategy.

Description

The Wedge Model™ is a derivative of the well-known Vee Model (Rook, 1986). The Wedge Model™ shows the products of design on the left-hand side of the wedge, and system integration on the right-hand side, with verification (is the work product correct with respect to the inputs used to create it – usually “meets requirements”?) and validation (does the work product correspond to the need for the work product?) superimposed. Colloquially, verification is – have we done the job right, and validation is – have we done the right job?

The Wedge Model™ shows multiple builds in the third dimension – a second time axis with time coming out of the page towards the reader. Thus, the face of the Wedge represents the last build (version, release, etc.) in each case. All of the verification and validation concerns on the face are replicated back onto the earlier builds. Note that not all potential verifications and validations will be carried out on all of the products associated with all of the builds. It is an engineering management role to decide which of the products will be subject to verification and validation, and to what degree.

A description of the model follows. Verification is shown in red. Validation is shown in blue. The subjects of verification and validation are at the arrow tails. The references for verification and validation are at the arrow heads.

 

The “Vee” model is sometimes misunderstood to be a development model, and a time-sequential Waterfall development model at that. This is not the case. The original “Vee” represents the end products on the design and build sides of the “Vee”, but says almost nothing about how the developer got there. The Wedge Model™ adds some of the story as to how the developer got there, but only insofar as intermediate design artifacts and corresponding intermediate builds. There are time trends, but no strict time axes, even for incremental and evolutionary builds. These could be sequential or partly concurrent on each side of the Wedge. The timing dependencies are finishing, not starting or doing (we have to have finished building the engine before we can finish building the propulsion system).

A “Project System” invariably appears at Level 2 in the Wedge Model™. The Project System has system elements, and lower physical level system elements, and lower again, and again, down to, for example, individual test procedures and emails. Each subject to the same principles verification and validation principles and relationships.

Conclusion

The Wedge Model™ provides a comprehensive representation of the end products and intermediate products within the development of larger, more complex systems, together with the superimposition of the subjects of verification and validation, the references for verification and validation, and representative methods of verification and validation, within both single build and multiple build development strategies for the system itself and for each developmental system element.

References

Forsberg, K., and Mooz, H. “The relationship of systems engineering to the project cycle”. Engineering Management Journal Vol. 4, No. 3, 1992, pp. 36-43.

Rook, Paul. “Controlling Software Projects” in Software Engineering Journal (Vol 1, No 1, pp. 7-10, January 1986, ISSN 0268-6961.

Share

Share on linkedin
Share on facebook
Share on twitter
Share on email

Published By

Systems engineering thought leader, consultant, trainer and coach, impacting people's lives on six continents.
Published 7 months ago

LEAVE A COMMENT

Comments

Share on activity feed

Powered by WP LinkPress

 

2105_PPI-WEB_Ad-template

Make 2021 a year of learning improvement

PPI 's 2021 full course schedule is now live. Click here and register your interest today!

PPI_Logo_Symbol_Only.png

FREE Monthly SE Industry News?

More news for you

Scroll to Top