22.5 GUIDING PRINCIPLES In summary, the preceding discussions provide the basis with which to establish guiding principles that govern the implementation of a system capability. Principle 22.1 Every operational capability has a System Capability Construct that models the capability’s action-based operations, tasks, and external interactions. Principle 22.2 Every operational capability requires an external trigger—a cue or a stimulus— to initiate its outcome-based processing. Principle 22.3 Every operational capability, as an integrated system, consists of three sequen- tial phase-based actions: 1. Pre-mission phase—initialization. 2. Mission phase—application-based performance. 3. Post-mission phase—analysis and deactivation. Principle 22.4 Every capability requires consideration of HOW exceptions to NORMAL and ABNORMAL operations will be handled. Principle 22.5 On completion of tasking, every capability should report notification of suc- cessful completion. 22.6 SUMMARY This chapter introduced the System Capability Construct and discussed its application to systems. Our dis- cussion covered the construct’s operations and control flows, and equated its structure to real world examples. We also emphasized the importance of the construct as a graphical checklist for specifying capability require- ments statements in terms of WHAT must be accomplished and HOW WELL without specifying HOW the requirement was to be implemented. GENERAL EXERCISES 1. Answer each of the What You Should Learn from This Chapter questions identified in the Introduction. 2. Refer to the list of systems identified in Chapter 2. Based on a selection from the preceding chapter’s General Exercises or a new system selection, apply your knowledge derived from this chapter’s topical discussions. If you were the designer of a specific capability, using Figure 22.1 as a guide, (a) Describe the set of tasks the capability should perform. (b) How would you handle exceptions? (c) How are outcome based results of the capability reported? In what format and media? (d) Translate each of the capability tasks into a set of operational capability requirements. General Exercises 239 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com ORGANIZATIONAL CENTRIC EXERCISES 1. Contact a program within your organization. Interview SEs concerning how they define and implement a capability. (a) How do their designers accommodate the various operations or tasks of the System Capability Construct? (b) Without making them aware of this chapter’s discussions or Figure 22.1, have they synthesized this concept on their own or just unconsciously do things ad hoc based on lessons learned from experience? (c) Present your findings and observations. 240 Chapter 22 The Anatomy of a System Capability Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 23 System Analysis Synthesis Throughout Part I we sequenced through topical series of chapters that provide an analytical per- spective into HOW to THINK about, organize, and characterize systems. These discussions provide the foundation for Part II System Design and Development Practices, which enable us to translate an abstract System Performance Specification (SPS) into a physical system that can be verified and validated as meeting the User’s needs. So, HOW did Part I System Analysis Concepts provide this foundation? 23.1 SYNTHESIZING PART I ON SYSTEM ANALYSIS CONCEPTS Part I concepts were embodied in several key themes that systems analysts and SEs need to under- stand when developing a new system, product, or service. 1. WHAT are the boundary conditions and constraints imposed by the User on a system, product, or service in terms of missions within a prescribed OPERATING ENVIRONMENT? 2. Given the set of boundary conditions and constraints, HOW does the User envision deploy- ing, operating, and supporting the system, product, or service to perform its missions within specific time limitations, if applicable? 3. Given the deployment, operation, support, and time constraints planned for the system, product, or service, WHAT is the set of outcome-based behaviors and responses required of the system to accomplish its missions? 4. Given the set of outcome-based behaviors and responses required of the system to accom- plish its mission, HOW is the deliverable system, product, or service to be physically imple- mented to perform those missions and demonstrate? To better understand HOW Part I’s topical series and chapters supported these themes, let’s briefly explore each one. Theme 1: The User’s Mission Boundary conditions and constraints for most systems are established by the organization that owns or acquires the system, product, or service to accomplish missions with one or more outcome-based performance objectives. The following chapters provide a topical foundation for understanding organizational boundary conditions and constraints. System Analysis, Design, and Development, by Charles S. Wasson Copyright © 2006 by John Wiley & Sons, Inc. 241 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 13: Organizational Roles, Missions, and System Applications Chapter 14: Understanding the System’s Problem, Opportunity, and Solution Spaces Chapter 15: System Interactions with Its OPERATING ENVIRONMENT Chapter 16: System Mission Analysis Theme 2: Deployment, Operations, and Support of the System Once the organization’s vision, boundary conditions, and constraints are understood, we addressed HOW the User envisions deploying, operating, and supporting the system to perform its missions. The following chapters provide a topical foundation for understanding HOW systems, products, or services are deployed, operated, and supported. Chapter 17: System Use Cases and Scenarios Chapter 18: System Operations Model Chapter 19: System Phases, Modes, and States of Operation Theme 3: System Behavior in Its OPERATING ENVIRONMENT Given the deployment, operation, support, and time constraints planned for the system, product, or service, we need to identify the set of outcome-based behaviors and responses required of the system to accomplish its missions. The following chapters provide a topical foundation for under- standing HOW systems, products, or services are expected to behave and interact with their OPER- ATING ENVIRONMENT. Chapter 20: Modeling System and Support Operations Chapter 21: System Operational Capability Derivation and Allocation Chapter 22: The Anatomy of a System Capability Theme 4: Physical Implementation of the System Based on an understanding of outcome-based behaviors and responses required of the system to accomplish its mission, the question is: HOW do we physically implement a system, product, or service to perform those missions? The following chapters provide a topical foundation for under- standing HOW systems, products, or services are physically implemented. Chapter 8: The Architecture of Systems Chapter 9: System Levels of Abstraction and Semantics Chapter 10: System of Interest (SOI) Architecture Chapter 11: Operating Environment Architecture Chapter 12: System Interfaces By inspection, these themes range from the abstract concepts to the physical implementation; this is not coincidence. This progression is intended to show HOW SEs evolve a system design solu- tion from abstract vision to physical realization. After examining this list, you may ask: Why did we choose to talk about system architectures early in an order that puts it last in this list? For instructional purposes, system architectures rep- resent the physical world most people can relate to. As such, architectures provide the frame of ref- erence for semantics that are key to understanding Chapters 13–22. 242 Chapter 23 System Analysis Synthesis Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 23.2 INTRODUCING THE FOUR DOMAINS OF SOLUTION DEVELOPMENT If we simplify and reduce these thematic groupings, we find that they represent four classes or domains of solutions that characterize HOW a system, product, or service is designed and devel- oped, the subject of Part II. Table 23.1 illustrates the mapping between the Part I’s systems analy- sis concepts themes and the four domain solutions. There are several key points to be made about the mapping. First, observe that objectives 1 and 2 employ the User as the “operative” term; Objectives 3 and 4 do not. Does this mean the User is “out of the loop”? Absolutely not! Table 23.1 communicates that the User, Acquirer, and System Developer have rationalized and expressed WHAT is required. Given that direction, the system development contract imposes boundary conditions and constraints on developing the system. This communicates to the System Developer “Go THINK about this problem and TELL us about your proposed solution in terms of its operations, behaviors, and cost-effective implementation.” Since Table 23.1 represents how a system evolves, User involvement occurs explicitly and implicitly throughout all of the themes. Remember, if the User had the capabilities and resources available, such as expertise, tools, and facilities to satisfy Objectives 3–4, they would have already inde- pendently developed the system. Second, if: 1) a SYSTEM has four domains of solutions and 2) the SYSTEM, by definition, is composed of integrated sets of components working synergistically to achieve an objective greater that the individual component objectives, deductive reasoning leads to a statement that each of the components ALSO has four domains of solutions, all LINKED, both vertically and horizontally. The four themes provide a framework for “bridging the gap” between a User’s abstract vision and the physical realization of the system, product, or service. Thus, each theme builds on decisions established by its predecessor and expands the level of detail of the evolving system design solution as illustrated at the left side of in Figure 23.1. This allows us to make several observations: 23.2 Introducing the Four Domains of Solution Development 243 Table 23.1 Linking Part I System Analysis Concepts themes into Part II System Design and Development Practices semantics ID Part I Thematic Objectives Domain Solutions 23.1 Objective 1—WHAT are the boundary conditions and constraints imposed Requirements by the User on a system, product, or service in terms of missions within a Domain Solution prescribed OPERATING ENVIRONMENT? 23.2 Objective 2—Given the set of boundary conditions and constraints, HOW Operations Domain does the User envision deploying, operating, and supporting the system, Solution product, or service to perform its missions within specific time limitations, if applicable? 23.3 Objective 3—Given the deployment, operation, support, and time constraints Behavioral Domain planned for the system, product, or service, WHAT is the set of outcome- Solution based behaviors and responses required of the system to accomplish its missions? 23.4 Objective 4—Given the set of outcome-based behaviors and responses Physical Domain required of the system to accomplish its mission, HOW is the deliverable Solution system, product, or service to be physically implemented to perform those missions and demonstrate? Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com • The mission (i.e., the opportunity/problem space) forms the basis for the User to establish the Requirements Domain Solution (i.e., the solution space). • The Requirements Domain Solution forms the basis for developing and maturing the Oper- ations Domain Solution. • The evolving Operations Domain Solution forms the basis for developing and maturing the Behavioral Domain Solution. • The evolving Behavioral Domain Solution forms the basis for developing and maturing the Physical Domain Solution based on physical components and technologies available. From a workflow perspective, the design and development of the system solution evolves and matures from the abstract to the physical over time. However, the workflow progression consists of numerous feedback loops to preceding solutions as System Analysts and SEs mature the solu- tions and reconcile critical operational and technical issues (COIs/CTIs). As a result, we symbol- ize the system solution domains as shown at the right side of Figure 23.1. 23.3 SYSTEM DOMAIN SOLUTION SEQUENCING Figure 23.2 provides a way to better understand how the system domain solutions evolve over time. As shown, the Requirements Domain Solution is initiated first, either in the form of a contract System Performance Specification (SPS) or a System Developer’s item development specification. Here is how the sequencing occurs: • When the Requirements Domain Solution is understood and reaches a level of maturity suf- ficient to develop concepts of operation, initiate the Operations Domain Solution. • When the Operations Domain Solution reaches a level of maturity sufficient to define relationships and interactions among system capabilities, initiate the Behavioral Domain Solution. 244 Chapter 23 System Analysis Synthesis The Mission Operations Domain Solution Requirements Domain Solution Behavioral Domain Solution Physical Domain Solution Level of Detail Elaborated Expansion 1 2 3 4 A bstract P hysical Physical Domain Solution Behavioral Domain Solution Reqmts. Domain Solution Operations Domain Solution 1 2 3 4 ExitEntry Figure 23.1 Development and Evolution of a SYSTEM’s/Entity’s Solution Domains Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com • When the Behavioral Domain Solution reaches a level of maturity sufficient to allocate the behavioral capabilities to physical components, initiate the Physical Domain Solution. • Once initiated, the Requirements, Operations, Behavioral, and Physical Domain Solutions evolve concurrently, mature, and stabilize. 23.4 SUMMARY In this chapter we synthesized our discussions in Part I on system analysis concepts and established the foun- dation for Part II on system design and development. The introduction of the Requirements, Operations, Behavioral, and Physical Solution Domains, coupled with chapter references in each domain, encapsulate the key system analysis concepts that enable us to THINK about, communicate, analyze, and organize systems, products, and services for design and development. With this foundation in place, we are now ready to proceed to Part II System Design and Development Practices. 23.4 Summary 245 Entry/Exit Physical Domain Solu tion Physical Domain Solution4 Physical Domain Soluti on Behavioral Domain Soluti on Reqmts. Domain Soluti on Operations Domain Soluti on 1 23 4 Level of Detail For each entity at every level of abstraction Requirements Domain Solution Requirements Domain Solution1 Operations Domain Solution Operations Domain Solution2 3 Behavioral Domain Solution Time Figure 23.2 System Solution Domain Time-Based Implementation Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Part II Systems Design and Development Practices EXECUTIVE SUMMARY Part II, System Design and Development Practices, builds on the foundation established in Part I System Analysis Concepts and consists of 34 chapters organized into six series of practices. The six series consist of: • System Development Strategies Practices • System Specification Practices • System Design and Development Practices • Decision Support Practices • System Verification and Validation Practices • System Deployment, Operations, and Support Practices As an introductory overview, let’s explore a brief synopsis of each of these practices. System Development Strategy Practices Successful system development requires establishing an insightful strategy and supporting work- flow that employs proven practices to enable a program to efficiently progress from contract award to system delivery and acceptance. The System Development Strategy Practices, which consists of Chapter 24–27, provide insights for establishing a program strategy. Our discussions describe how a program employs verification and validation concepts intro- duced in Part I to create a workflow that translates multi-level specifications into a physical design solution that leads to delivery of systems, products, or services. We explore various development methods such as the waterfall approach, incremental development, evolutionary development, and spiral development. We also dispel a myth that V & V are only performed after a system has been integrated and tested; V & V are performed continuously from contract award through system deliv- ery and acceptance. Given an understanding of System Development Strategy Practices, we introduce the corner- stone for system design and development via the System Specification Practices. System Specification Practices System design and development begins with the derivation and development of system specifica- tions and requirements that bound the User’s solution space subject to technology, cost, schedule, System Analysis, Design, and Development, by Charles S. Wasson Copyright © 2006 by John Wiley & Sons, Inc. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 248 Part II Systems Design and Development Practices support, and risk constraints. The System Specification Series, which consist of Chapters 28–33, explore what a specification is; types of specifications; how specifications are analyzed and devel- oped; and how specification requirements are analyzed, derived, developed, and reviewed. The System Specification Practices provide the cornerstone for our next topical discussion, System Design and Development Practices. System Design and Development Practices The design and development of a system requires that the developers establish an in-depth under- standing of WHAT the user is attempting to accomplish and select a solution from a set of viable candidates based on decision factors such as technical, technology, support, cost, schedule, and risk. The System Design and Development Practices series consists of Chapters 34–46 and cover a diverse range of system design and development practices. Our discussions include: understanding the operational utility, suitability, effectiveness, and availability requirements; formulation of domain solutions; selection of a system architecture; configuration identification; system interface design; standards and conventions; and design and development documentation. The System Design and Development Practices require timely data to support informed deci- sion making that the RIGHT system solution is selected. This brings us to our next topic, Decision Support Practices, which provide the data. Decision Support Practices The design and development of integrated sets of system elements requires analytical support to provide data and ensure that the system design balances technical, technology, support, cost, sched- ule, and risk considerations. The Decision Support Practices series, which consist of Chapters 47–52, provide mechanisms that range from analyzes to prototypes and demonstrations to provide timely data and recommendations. Our discussions address analyses; statistical variation influences on system design; system per- formance budgets and margins; system reliability, availability, and maintainability; system model- ing and simulation; and trade study analysis of alternatives. System design and development requires on-going integrity assessments to ensure that the system is being designed correctly and will satisfy the user’s operational need(s). This brings us to our next topic, Verification and Validation Practices, which enable us to assess the integrity of the evolving system design solution. Verification and Validation Practices System design and development requires answering two key questions: 1) Is the system being designed and developed RIGHT—in accordance with the contract requirements and 2) Does the system satisfy the user’s operational needs? The Verification and Validation Practices series, which consist of Chapters 53 through 55, enable the system users, acquirer, and developers to answer these questions from contract award through system delivery and acceptance. Our discussions explore what verification and validation are; describe the importance of tech- nical reviews to verify and validate the evolving and maturing system design solution; and address how system integration, test, and evaluation plays a key role in performing V & V. We introduce verification methods such as inspection/examination, analysis, test, and demonstration that are available for verifying compliance to specification requirements. Once a system is verified, validated, and delivered for final acceptance, the user is ready to employ the system to perform organizational missions. This brings us to our next topic, System Deployment, Operations, and Support Practices. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]...Simpo PDF Merge and Split Unregistered Version - and Development Practices 249 Part II Systems Design http://www.simpopdf.com System Deployment, Operations, and Support Practices People often believe that SE and analysis end with system delivery and acceptance by the user; SE continues throughout the operational life of the system, product, or service The System Deployment, Operations, and Support Practices. .. the right system 24. 7 SUMMARY During our discussion of the system development workflow strategy we introduced the system development phase processes The System Development Phase processes include: 1 2 3 4 5 System Design Component Procurement and Development System Integration, Test, and Evaluation (SITE) Authenticate System Baseline Operational Test, and Evaluation (OT&E) Based on the System Development. .. Simpo PDF 24 System Development Workflow Strategy 256 Chapter Merge and Split Unregistered Version - http://www.simpopdf.com System/ Product Life Cycle System Definition Phase System Procurement Phase 1 System Production Phase System Operations & Support Phase System Disposal Phase System Development Phase 7 Technical Management Process 2 3 Systems Design Process Highly Iterative Component Procurement & Development. .. understanding of how the SE process should be implemented and how to manage its implementation System Analysis, Design, and Development, by Charles S Wasson Copyright © 2006 by John Wiley & Sons, Inc 251 Simpo PDF 24 System Development Workflow Strategy 252 Chapter Merge and Split Unregistered Version - http://www.simpopdf.com What You Should Learn from This Chapter 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15... the workflow steps in system development? What is the verification and validation (V&V) strategy for system development? How does the V&V strategy relate to the system development workflow? Why is the V and V strategy important? What is the Developmental Configuration? When does the Developmental Configuration start and end? What is a first article system? What is developmental test and evaluation (DT&E)?... progression 24. 4 APPLYING V&V TO THE SYSTEM DEVELOPMENT WORKFLOW So far we have introduced the System Development Phase processes and described the sequential workflow Each of these processes enables the System Developer to accomplish specific objectives such as: 1 Select and mature a design from a set of viable candidate solutions based on an analysis of alternatives Simpo PDF 24 System Development. .. deficiencies, and the like Following OT&E (20), the ITA prepares an assessment and recommendations Author’s Note 24. 3 Although the System Development contract (6) may be complete, the User performs system verification and validation activities continuously throughout the System Development and system Operations and Support (O&S) phases of the system product life cycle V&V activities expand to encompass... (SPS) Since the System Development Phase focuses on development of the system, product, or service, testing throughout SVT is referred to as Developmental Test and Evaluation (DT&E) Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 24. 4 Applying V&V to the System Development Workflow 257 When the first article system( s) of the Developmental Configuration has been verified as meeting... strategy of system development, the question is: HOW do we implement it? This brings us to our next topic, Implementing the system development phase 24. 3 IMPLEMENTING THE SYSTEM DEVELOPMENT PHASE The workflow during the system development phase consists of five sequential workflow processes as illustrated in Figure 24. 2 The processes consist of: 1 System Design Process 2 Component Procurement and Development. .. Audit(PCA) 14 System Verification Procedures 19 10 Design Requirements Design Verification 12 Verification Procedures 15 System Verification Verified & Validated System (18) Not Shown Authenticate System Baselines Process System Delivery Process Install & C.O System Process · · · 16 Figure 24. 3 Development Process Context System Verification and Validation Concept 2 3 4 5 Procure, fabricate, code, and test . discussion, System Design and Development Practices. System Design and Development Practices The design and development of a system requires that the developers establish an in-depth under- standing. Development Strategy Practices, we introduce the corner- stone for system design and development via the System Specification Practices. System Specification Practices System design and development begins. of 34 chapters organized into six series of practices. The six series consist of: • System Development Strategies Practices • System Specification Practices • System Design and Development Practices •