1.1 The Enduring Truth That Need Not Be
It is a sad truth that many system development programs fail to deliver a system to the customer with understandable evidence of system compliance with the content of program specifications. In order to be successful in doing so, the developer must begin early in the program to develop a good set of specifications in which the content has been derived through the application of an effective modeling method accomplished by people who know what they are doing. Then, the content of the specifications must be applied as the basis for design of the product. This same content of the specifications must also be used as the basis for the design of a verification process that produces evidence in a comprehensive series of verification task reports from which any reader will reach the same understanding of the degree of requirements compliance achieved. This is the third book on this subject the author has had published and it is the first time he has included the details about how to accomplish verification successfully and affordably, based on some recent program experiences in which a correction for the sad story became obvious to him but was not possible to achieve, because the driving specifications were not well-crafted by the customer and contractor and the remaining program budget, schedule, and customer goodwill were in insufficient supply to support correction of past errors. It should be said, however, that despite this past history the product system delivered was superb. The point of this book is that it is possible to deliver both a great product along with understandable verification evidence that truthfully reveals that the delivered product complies with the content of the program specifications.
The road to success is simple but it appears not to be easy to accomplish. In this book we will identify a simple prescription that any program can follow to succeed in system verification, but you must begin the prescription fairly early in the program and management must follow the plan through with determination and management skill.
1.2 Overview of This Chapter
This chapter collects in Section 1.3 general information about verification, intended to prepare the reader with background information that it is hoped will help the reader place the information provided in the other chapters in context. Section 1.4 continues the overview of the remaining chapters of the book.
We begin the introductory ideas in Section 1.3.1.1 with some fundamentals about the verification process definition, scope, and goals. In Section 1.3.1.2 we identify the customer relationship and the important role it plays in the verification process whether the sale is through a contract or a commercial sale. In Section 1.3.1.3 we emphasize the importance the words truth and integrity play in the verification process.
Section 1.3.1.4 correlates specific sets of specifications with particular verification classes and provides a checklist of specific actions that are necessary related to these specifications and classes. Section 1.3.1.5 discusses the partitioning of classes into product entities that focus our verification work, which is further partitioned into tasks of six kinds.
In Section 1.3.1.6 the meanings of two important words starting with the letter “v” are covered as these words are used in the book. Finally, a foundation of systems engineering is provided based on the limited capacity of the individual human mind relative to the amount of information that mankind has accumulated. This will lead to the importance of human communication to link the minds of several (maybe hundreds of) human beings who have each focused their knowledge capacity on a narrow field deeply. It will also show the need for people called system engineers. The management challenge is to form the equivalent of one great mind that has the capability to solve problems that no single person can possibly deal with successfully. Hopefully, this discussion will reveal to the reader why management is the most difficult task on a program and why all of us who are managed should do our best to support managers trying to do their best in a very difficult activity.
Section 1.3.1.7 offers ideas about attaching responsibility for the verification work to program personnel. This can be a complicated relationship on a program but the fundamentals are that one person should be identified as responsible for every verification task and these tasks should be managed through a well-defined management structure. A particular structure is offered but there are many reasonable ways to set this up on a program. Section 1.3.1.8 notes a need to assemble all of the parts of the verification process into an overall program plan that is further discussed in detail in Chapter 6.
Section 1.3.2 defines a system and provides an overview of the systems development process focused on the three fundamental phases of a program: (1) define the problem in a set of specifications; (2) solve the problem through synthesis of the requirements contained in the specifications in the three steps of design, procurement, and manufacture; and (3) determine the extent to which the resulting product complies with the content of the specifications. This book focuses on the third phase, verification. A fourth important area of interest is to provide good management across the complete program and within the enterprise across its active programs. The case is made for an enterprise possessing a single common process applied to all programs and covers four development environments within which an enterprise can apply this common process on programs: (1) waterfall, (2) V, (3) spiral, and (4) agile. In all cases the three-step development focus overlaid by good management is applied, being completed in the verification phase that actually extends throughout production, however long that may last. A program can continue far beyond its initial production phase of course, as in the case of the Boeing B-52 program, and very often parts of the four verification phases may have to be implemented relative to major modifications.
Section 1.3.2 also summarizes the work that should precede the synthesis and verification work to prepare a set of specifications deriving the content of those specifications through the application of a comprehensive modeling approach that the enterprise has prepared its engineers to employ. Four universal architecture description frameworks (UADF) are offered from which an enterprise can select to be applied on every program, no matter how it is determined that the problem should be solved through a design implemented in some combination of hardware, software, and people doing things. The reader is encouraged to consult the author’s book titled System Requirements Analysis, Elsevier, 2014 for full details on the methods summarized in this section.
Section 1.3.3 provides a description of the author’s preferred organizational structure that is assumed throughout the book, involving a matrix management structure. In this structure a set of functional departments, each specializing in a particular discipline, provides programs with the resources they need to accomplish planned work. The program organizational structures, each under a program manager, then organize these resources into cross-functional teams oriented around the product entities the program system will require.
Section 1.3.4 covers program phasing possibilities, describing three specific phasing concepts. The application of these phasing approaches tends to be fairly rigid in practice, and on some programs where it is very difficult to define the requirements comprehensively in a timely way program managers have applied what is called rapid prototyping or agile development in an attempt to speed up the process and avoid late recognition of serious problems, in some cases with success. Finally, the section covers three different program cases in terms of the number of systems delivered.