Download The Method Framework for Engineering System Architectures   Easily In PDF Format For Free.

PREFACE:

One of the biggest sources of pain in system development is “system integration and test.” This is  frequently  where  projects  sailing  along  with  all-green  progress  reports  and  Earned  Value Management System status summaries start to see these indicators increasingly turn to yellow and then to red. 

Projects that were thought to be 80 percent complete may be found to still have another 120 percent to go, increasing the relative costs of integration and test from 20 percent of the total to 120/200 = 60 percent of the total.

 Managers often look at this 60 percent figure and say, “We need to find a way to speed up integration and test,” and invest in test tools to make testing go faster. But this is not the root cause of the cost escalation. That happened a lot earlier in the definition and validation (or more often the lack of these) of the system’s architecture.

 Components that were supposed to fit together did not. Unsuspected features in commercial off-the-shelf (COTS) products were found to be incompatible, with no way to fix them and little vendor interest in doing anything about the problems. Nominal-case  tests  worked  beautifully  but  the  more  frequent  off-nominal  cases  led  to  system failures. Readiness tests for safety and security certification were unacceptable. Defect fixes caused regression tests to fail due to unanticipated side effects. 

Required response times were impossible to meet. And award fees for on-time delivery and expected career promotions faded away. Suppose, however, that you could do most of this integration before you bought or developed the components. An increasing number of projects have been able to do this. 

Some good examples are the Boeing 777 aircraft, which developed and validated a digital version of the aircraft before committing to its production, and the TRW CCPDS-R command and control system, well documented in Walker Royce’s book, Software Project Management. 

These and other successful projects concurrently engineered their system’s architecture along with its concept of operations, requirements, life-cycle plans, and prototypes or early working versions of its high-risk elements. And they also concurrently prepared for and developed the evidence that if the system were developed to the given architecture, it would support the operational concept, satisfy the requirements, and be buildable within the budgets and schedules in the plans.

 Further, they checked the consistency of the interfaces of the elements so that if the developers complied with the interface specifications, the developed elements would plug-and-play together (well, almost). Thus, the managers proceeding into development had much more than a set of blueprints and software architecture diagrams upon which to base their decision to proceed.

 They had strong technical  evidence  of  the  feasibility  of  the  specifications  and  plans,  and  often  a  business  case showing that the costs to be invested in the system would provide a positive return on investment (ROI).

 The costs of doing all this up-front work are higher, but as we show for software-intensive systems in an upcoming paper in the INCOSE journal Systems Engineering(B. Boehm, R. Valerdi,and  E.  Honour,  “The  ROI  of  Systems  Engineering:  Some  Quantitative  Results  for  SoftwareIntensive Systems,” 2008), the ROI is generally quite positive and becomes increasingly large as the systems become increasingly large.

 For example, consider a software-intensive system with one million equivalent source lines of code, on which the time spent in systems engineering for the project before proceeding into development increases from 5 to 25 percent of the nominal project duration. 

Based on the Constructive Cost Model (COCOMO II) calibration to 161 project data points, an additional 13.5 percent of the nominal project budget will be invested in the project in doing so, but 41.4 percent of the budget will be saved by avoiding rework due to weak architecting and risk resolution, for a return on investment of over 2:1. This book, The Method Framework for Engineering System Architectures (MFESA), is the first book of a new generation of books that will provide guidelines for how to develop systems in this way.

 The book strongly emphasizes, as have others, that there is no one-size-fits-all set of architecting guidelines and representations. But this book breaks new ground (while being practical and useful) by providing an architectural framework that can be tailored to a project’s particular situation.

 It provides a ten-task process (in which steps can be performed concurrently) that enables one to evaluate a project’s architectural options with respect to its situation; to synthesize a solution; to verify and validate its feasibility; and to elaborate it into a solid build-to (or acquire-to) set of architectural representations. The ten tasks are formulated as reusable and tailorable method components, and are described in Chapters 6 through 15in the book.