406 APPENDIX B REGULATORY BODIES AND STANDARDS ORGANIZATIONS The regulatory and standards bodies identified next are three of the most influential in the project solution space: Electronics Industries Alliance (EIA). International Organization for Standardization (ISO). U.S. Department of Defense (DoD). The EIA is theprimary industry association representing the U.S. electronics community and its sixtrade associations. The EIA has an affiliate relationship with the Internet Security Alliance, a collaborative effort with the SEI’s CERT Coordination Center (CERT/CC). Two standards have a broad and continuing influence on the solution space. EIA 632 standard and the International Or- ganization for Standardization (ISO) 15288 standard, while compli- mentary with different roles and details, have greatest impact when combined. The ISO is a worldwide, nongovernmental federation of national standards bodies established in 1947. ISO 9000 is the in- ternationally recognized standard and reference for quality man- agement in business-to-business dealings. The ISO standards that most directly affect the project solution space include: • ISO 15288 System Engineering—System Life Cycle processes. • ISO12207SoftwareEngineering—SoftwareLifeCycleprocesses. • ISO/IEC TR 15504—Software process assessment (published in 1998): A series of nine standards covering the capability model, performing assessments, assessor competency, and pro- cess improvement. Historically, the U.S. Department of Defense (DoD) has been directly involved in the solution space with standards such as Mil Std 498/499 and DoD 2167A/7935A. In more recent years, DoD in- fluence has shifted to acquisition policy, such as requiring contrac- tors to be rated at a specified CMMI level and/or conformance with DoD 5000 management principles and requirements generation. The DoD acquisition processes and procedures are directed and guided by three key documents: 1. DoD Directive (DoDD) 5000.1, 2. DoD Instruction (DoDI) 5000.2, and 3. Defense Acquisition Guidebook (DAG). cott_z02bappb.qxd 7/1/05 3:46 PM Page 406 APPENDIX B 407 The Defense Acquisition System Directive (DoDD 5000.1) identifies management principles for all DoD programs. The De- fense Acquisition System Instruction (DoDI 5000.2) establishes a management framework for translating needs and technology oppor- tunities into acquisition programs/systems. The Defense Acquisition Guidebook (DAG) is non-mandatory and provides guidance on pro- cedures for operation of the acquisition system and is based on an integrated management framework formed by three primary deci- sion support systems: the Requirements Generation System, the De- fense Acquisition System, and the Planning, Programming, and Budget System (PPBS). DoDI 5000.2 states that “Evolutionary acquisition is the pre- ferred DoD strategy for rapid acquisition of mature technology for the user. An evolutionary approach delivers capability in incre- ments, recognizing, up front, the need for future capability im- provements. The objective is to balance needs and available capability with resources, and to put capability into the hands of the user quickly. The success of the strategy depends on consistent and continuous definition of requirements, and the maturation of tech- nologies that lead to disciplined development and production of sys- tems that provide increasing capability towards a materiel concept.” In the DoD vernacular, “evolutionary” is an acquisition strategy that defines, develops, produces or acquires, and fields an initial hardware or software increment (called a phase or block) of opera- tional capability. Evolutionary acquisition is based on technologies demonstrated in relevant environments, time-phased requirements, and demonstrated capabilities for deploying manufacturing or soft- ware. Evolutionary acquisition provides capabilities to the users in increments. The capability is improved over time as technology ma- tures and the users gain experience with the systems. The first in- crement can be provided in less time than the “final” capability. Each increment will meet a useful capability specified by the user; however, the first increment may represent only 60 percent to 80 percent (or less) of the desired final capability. Each increment is verified and validated to ensure that the user receives the needed capability. The two basic evolutionary approaches are referred to as Spiral Development and Incremental Development, an unfortunate and confusing choice of terms since the well-known Spiral Model is applicable to both. In the DoD Spiral Development, the “end- state requirements are not known at program initiation.” The final functionality cannot be defined at the beginning of the program, and each increment of capability is defined by the matura tion of cott_z02bappb.qxd 7/1/05 3:46 PM Page 407 408 APPENDIX B the technologies matched with the evolving needs of the user. In the case of Incremental Development, the final functionality can be defined at the beginning of the program, with the content of each increment determined by the maturation of key technologies. The DoD Spiral Development closely corresponds to our Incre- mental/Evolutionary Method (with multiple deliveries) defined in Chapter 19, which may be modeled using the Spiral, but depending on other characteristics of the project, may best be modeled with the Waterfall or Vee. The DoD Incremental Development closely corresponds to our Incremental/Linear Method, which again, can be represented by any or all of the defined models. cott_z02bappb.qxd 7/1/05 3:46 PM Page 408 409 Appendix C The Role of Unified Modeling Language™ in Systems Engineering James Chism, Chairman, INCOSE Object Oriented Systems Engineering Methodology (OOSEM) Working Group L arge complex systems must be structured in a way that enables scalability, security, and robust execution under stressful condi- tions, and their architecture must be defined and communicated clearly enough so that they can be built and maintained. A well- de signed architecture benefits any program, not just the largest ones. Large applications are mentioned first because structure is a way of dealing with complexity, so the benefits of structure (and of modeling and design) compound as application size grows large. The OMG’s Unified Modeling Language™ (UML®) helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements. 1 That’s great for software engineers, but does it help with systems engineering? To develop any complex system requires a team of engineers working at the system level to analyze the needs of the stakeholders, cott_z03bappc.qxd 7/1/05 3:46 PM Page 409 410 APPENDIX C define all the requirements, devise the best concept from several al- ternatives and architect the system to the component level. The sys- tem team must also provide to the designers all of the models and visualizations that describe the architecture down to the lowest de- composed level. David Oliver in his book Engineering Complex Sys- tems with Models and Objects 2 states: “These descriptions must be provided in the representations, terminology, and notations used by the different design disciplines. They must be unambiguous, com- plete and mutually consistent such that the components will inte- grate to provide the desired emergent behavior of the system.” So how does one use UML that was originally designed primarily for software personnel to help the systems engineer? UML is a graphical language for modeling software systems and it was adopted as V1.1 by the Object Management Group (OMG) in 1997. Since then UML has become a de facto standard of the soft- ware community and the language has continued to improve through V2.0 as of 2004. It is a robust language with built-in extension mecha- nisms capable of addressing many needs. UML is supported by the OMG that has a well-defined technology adoption process and broad user representation that should assist in future development of the language. So how does this help the systems engineer and what is wrong with the current structured approach to systems engineering? First, there are many systems being developed that use the Ob- ject Oriented (OO) approach for software development. As such, the current structured approach to systems sngineering poses a definite communication blockage between the SE and the software developers due to the visualizations used by the traditional ap- proach. Basically, there is the lack of a common notation, seman- tics, and terminology as well as a definite tool incompatibility. This gap needs to be bridged to take full advantage of the OO approach and make full use of UML. So in addition to the structure language (UML), you need a systems engineering method consistent with that language and additional systems engineering notation to be effective. In November 2000, the INCOSE Object Oriented Systems En- gineering Methodology (OOSEM) Working Group was established to help further evolve the methodology. The working group is spon- sored by the INCOSE Chesapeake Chapter and led by Jim Chism. The OOSEM working group goals are to: •Evolve the object-oriented systems engineering methodology. •Establish requirements and proposed solutions for extending UML to support systems engineering modeling. cott_z03bappc.qxd 7/1/05 3:46 PM Page 410 APPENDIX C 411 •Develop education materials to train systems engineers in the OO systems engineering method. OOSEM includes the following development activities: •Analyze needs. •Define system requirements. •Define logical architecture. •Synthesize candidate allocated architectures. • Optimize and evaluate alternatives. •Validate and verify the system. These activities are consistent with the typical systems engi- neering Vee Model and process that can be recursively and itera- tively applied at each level of the system hierarchy. Fundamental tenets of systems engineering, such as disciplined management processes (i.e., risk, configuration management, planning, and mea- surement) and the use of multidisciplinary teams, must be applied to support each of these activities to be effective. OOSEM utilizes a model-based approach to represent the various artifacts generated by these activities as opposed to a document- dri ven approach with traditional systems engineering. As such, it en- ables the systems engineer to apply a very disciplined approach to the specification, design, and verification of the system, and ensures con- sistency between the requirements, design, and verification artifacts that are understood by the OO software developer. The added rigor of the model-based approach helps to analyze the system and surface technical issues early and communicate the issues in a precise man- ner. The modeling artifacts can also be refined and reused in other applications to support product line and evolutionary development approaches. However, the OOSEM Working Group as well as others determined that even UML 2.0 did not contain sufficient robustness to encompass the needs of systems engineering to support analysis, requirements, specification, design, and verification of complex sys- tems. As a result, in addition to the features of OOSEM, Sandy Friedenthal and others are working with the OMG and INCOSE to develop a Systems Engineering Modeling Language (SysML) to en- hance the use of UML by Systems Engineers. So what is SysML? “SysML will customize UML 2 to support the specification, analysis, design, verification, and validation of complex systems that may include hardware, software, data, personnel, proce- dures, and facilities” according to the SysML partners (OMG doc #ad/03-11-02). That effort began on September 13, 2001, with a meeting of an OMG chartered group called the Systems Engineering cott_z03bappc.qxd 7/1/05 3:46 PM Page 411 412 APPENDIX C Domain Special Interest Group (SE DSIG). The goals of that group were to: •Provide a standard SE modeling language to specify, design, and verify complex systems, •Facilitate integration of systems, software, and other engineer- ing disciplines, and •Promote rigor in the transfer of information between disciplines and tools. 3 In addition to the following UML 2.0 diagrams: activity dia- gram, assembly diagram, class diagram, behavior diagram, structure diagram, object diagram, package diagram, sequence diagram, state machine diagram, timing diagram, use case diagram; the SysML partners are recommending the addition of the following diagram types: parametric diagram and requirements diagram. The activity diagram and the assembly diagram will require extension to enhance their use for systems engineering. The design approach for SysML is to reuse a subset of UML and create extensions as necessary to sup- port the specific requirements of the UML based on the SE RFP. “The parametric diagram provides a mechanism for integrating engineering analysis, such as performance and reliability analysis, with other SysML models. It also provides an effective mechanism to identify critical performance parameters and their relationships to other parameters, which can be tracked throughout the system life cycle.” 4 In addition to these SysML attributes that will be added, new features of UML 2.0 will include parts, ports, and components that will allow an added capability to recursively decompose systems into their constituent components as well as to decompose behaviors in the activity and sequence diagrams. It is expected that SysML will be formally adopted by OMG in 2005. How does OOSEM enhance the UML role for Systems Engi- neering? As an example, we have chosen the topic “Analyze Needs,” since this initiates the systems engineering effort on a project. We then provide a comparison table of the traditional representations to the OOSEM visualizations used (UML diagrams). ANALYZE NEEDS This activity characterizes the problem space by defining the as-is systems and enterprise, their current deficiencies and potential im- cott_z03bappc.qxd 7/1/05 3:46 PM Page 412 APPENDIX C 413 provement areas, and the to-be enterprise model, mission/enterprise use cases, and associated mission requirements. An enterprise model depicts an overall enterprise and its con- stituent systems, as well as the enterprise actors (entities external to the enterprise). The constituent systems include the system to be developed or modified as well as other systems that support the en- terprise. The as-is enterprise is analyzed to determine its limitations using causal analysis techniques. The to-be enterprise model is established based on proposed changes to the as-is enterprise to address the deficiencies. The mission objectives for the enter- prise/mission are used as a basis for deriving top-level mission use cases. The use cases and mission scenarios capture the key function- ality for the enterprise. Measures of effectiveness are identified to support the enterprise/mission objectives, and used as a basis for trade-off and analysis. Analyze Needs OOSEM Visualization Used Traditional SE Representation As-is operational depiction As-is users As-is enterprise model As-is scenarios As-is system requirements As-is system design Causal analysis Reuse candidates To-be operational depiction Mission needs statement, concept of operations To-be enterprise model (operational, full life cycle) Mission scenarios OV-1; system threads; work flows System use cases Functional flow decomposition, business scenarios; work flows Mission time line Mission time line Mission parametric and Mission analysis via simulation and trade-off analysis mission scenarios. Trade-off analysis Requirements traceability Requirements traceability to original matrix (RTM) documents with decomposition typically done in requirements tool (DOORS, CORE, POPKIN, etc.) cott_z03bappc.qxd 7/1/05 3:46 PM Page 413 414 APPENDIX C OTHER AREAS OF SYSML APPLICATION In addition to the SE process “Analyze Needs,” there are five other areas that have been elaborated. Space restrictions limit us to listing the SE process areas covered in SysML: •Analyze needs (covered earlier). •Define system requirements. •Define logical architecture. •Synthesize candidate allocated architectures. • Optimize and evaluate alternatives. •Verify and validate the system. SUMMARY The OOSEM approach combines traditional systems engineering ap- proaches with object-oriented techniques and the application of the UML modeling language. It is not a pure OO method as used by the software community, but is a hybrid between structured and OO techniques. Some of the features that have been incorporated into OOSEM to enhance traditional systems engineering methodologies: •Use of UML and OO concepts for a model-based approach. •Use of enterprise model to support specification of mission re- quirements and constraints. •Use of causal analysis techniques to determine limitations of as- is enterprise and system. •Elaborated context diagram for capturing black box system re- quirements. •Control function for specifying control requirements. •Store requirements specified at the system level. •Requirements variation analysis. •Logical decomposition and logical architecture versus func- tional decomposition. •Formalizing the use of partitioning criteria for developing the architecture. •Verification system development approach. While the role of UML enhances the discipline with semantics and a modeling language it is necessary but not sufficient. The OOSEM approach, the use of SysML and the upgraded tools that need to include all of these methods and languages will make the ap- proach sufficient. As a result the role of UML becomes the founda- tion of a structured and disciplined approach to systems engineering modeling. cott_z03bappc.qxd 7/1/05 3:46 PM Page 414 415 Appendix D A Summary of the Eight Phase Estimating Process Ray Kile, Chief Systems Engineer for The Center for Systems Management and developer of the REVIC parametric cost estimating model. T he Eight Phase Estimating Process (Kile, 1987) was developed initially to provide structure to a training course for organiza- tions desiring to use the REVIC model, but it soon proved far more useful as a means of elaborating the risk inherent in a cost estimate. Subsequently, the Eight Phase Estimating Process provided a num- ber of key practices that are currently documented in the CMMI. PHASE 1: THE DESIGN BASELINE PHASE AND WORK BREAKDOWN STRUCTURE The Design Baseline Phase starts as soon as the systems engineers, or equivalent, have determined a candidate architecture and design for the proposed system. The requirements have been gathered and allocated to the components within the candidate architecture and a complete Work Breakdown Structure (WBS) has been developed for the project. The output product from the Design Baseline Phase is a table or listing of the components along with the required function- ality of each and the WBS. The products from this phase should be reviewed by the appropriate level of management and placed under configuration control. cott_z04bappd.qxd 7/1/05 3:47 PM Page 415 [...]... Schilling, and Katherine A Edward, Dynamic Project Management (New York: Wiley, 1988) CHAPTER 12 1 Project Management Institute Practice Standard for Work Breakdown Structures (Philadelphia, PA: Project Management Institute, 2000) 2 Sunny Baker and Kim Baker, The Complete Idiot’s Guide to Project Management (New York: Alpha Books, Simon & Schuster Macmillian, 1998), pp 97 100 CHAPTER 13 1 J March and Z... configuration management process improvement template, 395 controlling, 267, 268 lessons learned as, 42 roles, 120–121, 359–360 Aspects of the project cycle, 99 102 See also Project cycle (one of five essentials) budget, 30, 31, 99, 101 102 , 115–116 business, 30–31, 99 101 , 115–116 as layers, 30 technical: development tactics, 116 –119 modeling, 104 108 periods and, 99 systems engineering and, 102 104 technology... Object-Oriented Analysis and Design and Iterative Development, 3rd ed (Upper Saddle River, NJ: Prentice Hall, 2005) 13 David Oliver, Timothy P Kelliher, and James G Keegan Jr., Engineering Complex Systems with Models and Objects (New York: McGraw-Hill, 1997) 14 Sanford A Friedenthal and Cris Kobryn, “Extending UML to Support a Systems Modeling Language,” INCOSE Symposium Paper (2003) 438 NOTES CHAPTER 10 1 Henry... their tools, training, and personnel However, the size of the product to be developed will have a definite impact on the environment for several reasons First the organization’s ability to handpick personnel and staff a project with experts and highly experienced personnel is far easier for a small project requiring only 5 to 10 personnel than for a large project needing 50 to 100 or more personnel... satisfied Systems Modeling Language (SysML) A generalpurpose notational language for specifying, describing, and visualizing complex systems SysML builds on UML Vee model (Dual) A system development model authored by Dr Kevin Forsberg and Hal Mooz to illustrate integrated architecture and entity solution development technical aspect of the project cycle The technical management approach to achieving the project. .. up-front systems engineering time required to perform system level requirements analysis If this work is to be included in the project, we must add the effort and duration required to the model’s estimates Also, many models were calibrated from government projects that had a large amount of documentation Our project may not require that much documentation and we will have to reduce the effort (and duration)... “Managerial Perspectives on Risk and Risk Taking,” Management Sci- 2 3 4 5 6 7 8 9 10 11 12 ence, vol 33, no 11 (November 1987), pp 13–17 Rita Mulcahy, Risk Management: Tricks of the Trade for Project Managers (Minneapolis: RMC Publications, 2003), p 68 Tom Kendrick, Identifying and Managing Project Risk (New York: AMACOM, 2003) Rita Mulcahy, Risk Management: Tricks of the Trade for Project Managers (Minneapolis:... Publishing Co., 1991) Rita Mulcahy, Risk Management: Tricks of the Trade for Project Managers (Minneapolis: RMC Publications, 2003), p 68 Jon Krakauer, Into Thin Air (New York: Doubleday Dell, 1997) Kevin Forsberg and Hal Mooz, “Risk and Opportunity Management and the Project Cycle,” Proceedings of the National Council for System Engineering Symposium (July 1995) Ben R Rich and Leo Janos, Skunk Works (Boston:... Peter F Drucker, People and Performance: The Best of Peter Drucker on Management (New York: Harper & Row, 1977) 3 Suzanne K Bishop, “Cross-Functional Project Teams in Functionally Aligned Organizations,” Project Management Journal (Sylva, NC: Project Management Institute, September 1999), pp 6 –12 4 Deborah S Kezsbom, Donald Schilling, and Katherine A Edward, Dynamic Project Management (New York: Wiley,... we must capture the rationale for the changes and maintain a document trail for subsequent analysis PHASE 5: THE PROJECT ESTIMATE PHASE All parametric models and estimating methodologies come with specific assumptions about both what development life cycle phases APPENDIX D (e.g., design, code, verification) and types of activities (e.g., systems engineering, project management, testing) are included . design, and verify complex systems, •Facilitate integration of systems, software, and other engineer- ing disciplines, and •Promote rigor in the transfer of information between disciplines and tools. 3 In. personnel and staff a project with experts and highly expe- rienced personnel is far easier for a small project requiring only 5 to 10 personnel than for a large project needing 50 to 100 or more per- sonnel the project estimate and the project budget. Management should carefully consider the risks and ensure that ap- propriate risk planning and mitigation are included in the project s plans and