SYS 101: Fundamentals of Systems Engineering Introduction to Systems Engineering. Get the printer friendly version of the lesson here

Transcription

1 SYS 101: Fundamentals of Systems Engineering Introduction to Systems Engineering Introduction to Systems Engineering Get the printer friendly version of the lesson here

2 SYS 101: Fundamentals of Systems Engineering Overview Overview This topic provides an overview of the Introduction to Systems Engineering lesson.

3 SYS 101: Fundamentals of Systems Engineering Overview Overview The topics within this lesson lay the groundwork for understanding the DoD's Systems Engineering Technical Processes and Technical Management Processes as outlined in the Defense Acquisition Guidebook (DAG). In this lesson, divided into several topics, you will learn about: How Systems Engineering can be defined Technical and Technical Management Processes Roles played by Systems Engineering standards Technical Foundations: 'V' Models and their applications Essential Considerations: Planning and the role of the Systems Engineering Plan, Robustness, Open Systems and Evolutionary Acquisition Workplace Ethics Select NEXT to continue. Page 1 of 12

4 SYS 101: Fundamentals of Systems Engineering Overview Something to Ponder... The two stonecutters shown here were asked, 'What are you doing?' Select the photo of the stonecutters to view their two answers. Take a minute and ponder what these two widely differing responses actually mean, especially that of the second stonecutter. On the next screen you will be asked to evaluate views that others have had when asked to assess the response of the second stonecutter. Select NEXT to continue. Page 2 of 12

5 Two Stonecutters on the Job The first stonecutter said: "I am cutting this stone into blocks." The second stonecutter replied, "I am on a team that is building a monument."

6 SYS 101: Fundamentals of Systems Engineering Overview Response Assessment Do any of the following responses match what you believe is the best meaning of the second stonecutter's response? Select one of these statements. A. The second stonecutter is wasting time daydreaming. B. The second stonecutter is not paying attention to what is being done and thus, may cause errors in the work. C. The second stonecutter has the big picture, but that is not part of the stonecutter's job. D. The second stonecutter has a vision of the finished product and his contribution being made as part of a team. D. You have chosen the best response. The second stonecutter has a vision of the finished product and the contribution being made as part of a team. You are or will be a 'stonecutter' on an integrated product development team. Whatever your job is, it is akin to cutting a stone. Your stone may be part of the frame that holds the product together, or the name plate that identifies the product as a United States weapon, or the developer of equipment that will be used as ground support equipment for the operational product, or the manager responsible for monitoring a technical effort by a contractor. But whatever your stone, it is an important one, and it has an integral role in the overall system being developed. When you keep the end system in mind, you will be able to better identify interfaces, understand your role and work better with your team and other teams. Select Next to continue. Page 3 of 12

7 SYS 101: Fundamentals of Systems Engineering Overview Need for Product Vision Why have a vision of the final product? Perhaps the person in this picture can explain to you why product vision is essential! Unfortunately, such poorly implemented products are a common outcome when people with diverse skills work on a complex project but lack a common technical vision. The discipline of Systems Engineering plays a key role in helping to unify the technical vision of a product, to effectively manage all the diverse skills needed to develop modern defense systems and to help ensure that effective, supportable defense systems get fielded. Select NEXT to continue. Page 4 of 12

8 SYS 101: Fundamentals of Systems Engineering Overview The Essence of Systems Engineering Systems Engineering is a methodical, disciplined problem-solving approach used for the design, realization, technical management, operations and retirement of a system. A 'system' in this context is a collection of different elements, together producing results not obtainable by the individual elements alone. Elements: include people, hardware, software, facilities, policies and documents, all the things required to produce system-level results Results: include system-level qualities, properties, characteristics, functions, behavior and performance meeting a variety of different users' needs D Select NEXT to continue. Page 5 of 12

9 Long Description The V Model of the Iterative Approach shows how, in the Design phase, systemlevel design requirements lead to item-level design requirements and to completion of design requirements. The Fabricate (FAB), Integrate and Test phase is made up of components, assemblies, items and the system level.

10 SYS 101: Fundamentals of Systems Engineering Overview Integrative Nature of Systems Engineering Systems Engineering is holistic and integrative. It evaluates and balances the contributions of structural engineers, electrical engineers, software engineers, logistics engineers, reliability and safety engineers, power engineers, human factors engineers and many other technical disciplines to produce a coherent system whole. Systems Engineering seeks a safe and life cycle-balanced optimal design in the face of opposing technical interests and multiple, sometimes conflicting cost, schedule and performance constraints. Systems Engineering is hard work! It includes both technical and management aspects. Select NEXT to continue. Page 6 of 12

11 SYS 101: Fundamentals of Systems Engineering Overview Scope of Systems Engineering Systems Engineering is both a technical and management discipline. Systems Engineering is performed by multidisciplinary teams to engineer and integrate systems that help ensure DoD's products meet warfighters' needs. Systems Engineering encompasses the entire technical effort. It ties together all aspects of a project to ensure that individual parts, subsystems, support equipment and associated operational equipment effectively function together as intended in the operational environment. Systems Engineering is also a logical sequence of processes and activities. These transform operational needs into an optimal system-level configuration. Select NEXT to continue. Page 7 of 12

12 SYS 101: Fundamentals of Systems Engineering Overview Systems Engineers and Program Managers Systems Engineers and Program Managers are two important 'players' in the development and production of DoD systems. They perform differing but vital roles, which can be summarized as: Program Managers: Manage (i.e., plan, organize, direct, coordinate, control and approve) the activities of all aspects of a program as it proceeds through the phases of the Defense Acquisition Framework Systems Engineers: Integrate and balance the work of numerous engineering and technical disciplines from the initial system design to the production and fielding of the final product Frequently, senior Systems Engineers also perform key roles as the project's 'Technical Authority'. In these roles, they help ensure that technical rigor is maintained across all phases of development. Select NEXT to continue. Page 8 of 12

13 SYS 101: Fundamentals of Systems Engineering Overview Knowledge Review Which of the following statements about the scope of Systems Engineering is true? A. It helps to unify the technical vision of a product. B. It is a technical discipline. C. It encompasses the entire technical effort. D. It is comprised of a logical sequence of processes and activities. A, B, C, D. Correct! Systems Engineering is a broad-based, multi-faceted discipline. Properly applied, it is key to developing and fielding effective DoD systems. You ll learn more about it and its associated technical and management processes throughout the course! Select the NEXT button to continue. Page 9 of 12

14 SYS 101: Fundamentals of Systems Engineering Overview How Will You Use What You Learn? The many topics making up the lessons in this course cover the Technical Processes and the Technical Management Processes, as outlined in the Defense Acquisition Guidebook (DAG). These are the foundation processes for the DoD's approach to Systems Engineering. Depending on your current job role--dod in-house developer, member of a program IPT or involved in some other aspect of DoD technical engineering or program management--you'll find direct applicability for many of the parts of this course. Understandably, some DoD Acquisition Core careerists in their technical or program management oversight roles are primarily interested in Systems Engineering Technical Management Processes. However, in order to successfully use them to manage the outcomes of Technical Processes, one needs a good understanding of both. So both sets of processes are covered. Additionally, although the processes covered in this course are based on those in the DAG, your service or agency may supplement some of them with added procedures, regulations and instructions. You'll have to seek those out on your own. You'll learn that Systems Engineering is a vast field. Because only the core processes are covered here, a wide variety of additional, useful references are cited in Quick Reference. Check them out! Select NEXT to continue. Page 10 of 12

15 Technical Processes Technical Processes are used to design the system, subsystems, and components, including the supporting or enabling systems required to produce, support, operate or dispose of a system. These consist of Requirements Development, Logical Analysis, Design Solution, Implementation, Integration, Verification, Validation and Transition.

16 Technical Management Processes Technical Management Processes are used to manage the technical development of the system increments, including the supporting or enabling systems. These consist of Technical Planning, Requirements Management, Interface Management, Risk Management, Configuration Management, Technical Data Management, Technical Assessment and Decision Analysis.

17 SYS 101: Fundamentals of Systems Engineering Overview Performance Learning Model The Defense Acquisition University (DAU) is committed to supporting life-long learning. The AT&L Performance Learning Model (PLM) is used by the DAU and illustrated here. The PLM shows how the DAU supplements core acquisition certification training with other learning assets. You'll find these other learning assets useful on the job as well as throughout your career. More information about the DAU and its many learning assets is available here. Continuous Learning Modules (CLMs), Communities of Practice (CoPs), the AT&L Knowledge Sharing System (AKSS) and the Acquisition Community Connection (ACC) are important life-long learning components of the PLM. Details of these relating to Systems Engineering are provided as part of Quick References as well. Select NEXT to continue. D Page 11 of 12

18 Long Description Graphic of a temple labeled AT&L Performance Learning Model. The three pillars are labeled DAWIA Core Certification, Core Plus Development, and Executive & Leadership Support. The base is labeled Training Courses. The foundation contains Knowledge Sharing (AT&L Knowledge Sharing System, Acquisition Community Connection, and DAU Virtual Library); Continuous Learning (Continuous Learning Modules, Conferences and Symposiums); and Performance Support (Consulting, Rapid Deployment Training, Targeted Training).

19 Acknowledgements Many people played key roles in developing these course materials. Their assistance is appreciated. Additionally some portions of this course use materials from ANSI/EIA-632, Processes for Engineering a System as well as the NASA Systems Engineering Handbook. The assistance of the EIA and NASA in this regard is gratefully acknowledged. You have reached the end of this topic. To proceed, select the next topic in the Table of Contents. SYS 101: Fundamentals of Systems Engineering Overview Page 12 of 12

20 People Among others, these primarily included: Dr Jerry Lake, editor of ISO/IEC and editorial team member on several national and international Systems Engineering standards such as EIA 632, IEEE 1220, and ISO/IEC Dr. John Snoderly, DAU Program Director for Systems Engineering and former ( ) President of the International Council of Systems Engineers (INCOSE) Mr Bob Skalamera, Director OSD AT&L Defense Systems, Enterprise Development Col Warren Anderson, Deputy for Systems Engineering Plans and Policy, OUSD AT&L Defense Systems LtCol Andrew Batten, MOSA Program Office Dr Dave Brown DAU SYS 101 Course Manager (top-down design) Mr Bill Zimmerman DAU SYS 101 Course Manager (bottom-up product realization) Dr Joel Zamkoff, DAU Instructional Systems Designer Various course developers including private consultants: o o o Dr Sherwin Jacobson John Olmstead Michael Findley DAU Systems Engineering faculty course reviewers G. Kinsorp, Cosmetic Engineer

21 NASA Systems Engineering Handbook After much study and coordination, the NASA and the DoD, working in collaboration, developed and implemented essentially the same sets of Systems Engineering processes. NASA's Systems Engineering processes are described in their Handbook available here.

22 Acknowledged The following EIA diagrams are used in this course. Figures: 6.1.1, , 6.2, 6.2.1a, and G.1 from ANSI/EIA-632, Processes for Engineering a System, Copyright (1999) Government Electronics and Information Technology Association, a Sector of the Electronic Industries Alliance. All Rights Reserved. Reprinted by Permission.

23 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Description of Systems Engineering This topic defines Systems Engineering and outlines its scope.

24 Contents of Topic Approximate Length: 30 minutes SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Topic Description: The phases of the DoD Acquisition Framework essentially reflect an underlying engineering process. Bad engineering = bad products! Unless properly engineered, no affordable, effective product will ever reach the field. A wide variety of engineering disciplines have to be coordinated and properly utilized so that DoD systems are timely, effective and affordable. Systems Engineering helps ensure that that happens. This topic defines Systems Engineering, outlines its scope and gives examples of why Systems Engineering is challenging. Select NEXT to continue. Page 1 of 17

25 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Topic Learning Objectives Listed below are the objectives for this topic: State the DoD definition of Systems Engineering Summarize the scope of Systems Engineering activities Distinguish DoD and industry Systems Engineering roles List Systems Engineering challenges Select NEXT to continue. D Page 2 of 17

26 Long Description Flipchart with the following objectives: State the DoD definition of Systems Engineering Summarize the scope of Systems Engineering activities Distinguish DoD and industry Systems Engineering roles List Systems Engineering challenges

27 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Systems Engineering Viewpoints There are many ways to define 'Systems Engineering.' An internet search on the phrase 'Systems Engineering Definition' returns millions of hits! One way to put this into perspective is to consider that there are essentially four broadly-based 'views' of Systems Engineering. These are outlined below: Job View - Systems Engineering is what a person with the titled position of 'Systems Engineer' does and has as his/her job description, responsibility and/or role. Organizational View - Systems Engineering is what an organization named 'Systems Engineering' does and has as its responsibility and/or role. Problem-Solving View - Systems Engineering is a way of thinking about any complex technical problem. Multidisciplinary View - Systems Engineering is a multidisciplinary approach that defines the total technical effort needed to realize system products and sustain their life cycle services. The view upon which the Systems Engineering activities described in this course are based is the Multidisciplinary View. This viewpoint is also the basis for the definition of Systems Engineering as found in the DoD's Defense Acquisition Guidebook. Page 3 of 17

28 Role For example, a paper published in the International Council of Systems Engineers (INCOSE) 1996 Proceedings identified 12 different job roles, based on a variety of surveys that could be considered to constitute Systems Engineering. These job roles included: Requirements Owner; System Designer; System Analyst; Test Engineer; Logistics and Operations; System Integrator; Customer Interface; Technical Manager; Information Manager; Process Engineer; Coordinator; and miscellaneous Software Engineering roles.

29 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Defense Acquisition Guidebook Definition Systems Engineering is defined in the DoD's Defense Acquisition Guidebook as: Systems Engineering is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and total life cyclebalanced set of system, people and process solutions that satisfy customer needs. However, there is much more to Systems Engineering than just what is stated in this definition. Its scope is broad and can be described from a variety of perspectives including participants, total life cycle impact and the roles played by both industry and the DoD. Select NEXT to continue. Page 4 of 17

30 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Scope: DAG Viewpoint While the scope of Systems Engineering can be described in many ways, the DoD's Defense Acquisition Guidebook (DAG) broadly outlines it to include: Transforming needed operational capabilities into an integrated system design through concurrent consideration of all life cycle needs Integrating the technical efforts related to system and software development, manufacturing, verification, deployment, operations and support, disposal and user training for systems and their life cycle supporting products and services Developing credible and timely technical information to support the program management decision-making process Select NEXT to continue. Page 5 of 17

31 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Scope: Participants Systems Engineering permeates design, production, test and evaluation, and system support activities. In the DoD, Systems Engineering is typically implemented via Integrated Product and Process Development (IPPD). IPPD is performed by multidisciplinary teams, typically formally charted as Integrated Product Teams (IPTs). While the Program Office may have an assigned Chief Engineer or Lead Systems Engineer, many personnel from non-systems Engineering organizations or even from outside the program management structure also perform activities related to Systems Engineering. The defense system acquisition life cycle has as its purpose the creation of system products, including the technical support of those products throughout their service life. Accordingly, many program office and life cycle support personnel are participants in some way in the Systems Engineering effort. Page 6 of 17

32 Integrated Product and Process Development (IPPD) Integrated Product and Process Development (IPPD) is a management technique that simultaneously integrates all essential acquisition activities through the use of multidisciplinary teams to optimize design, manufacturing and supportability processes. IPPD facilitates meeting cost and performance objectives. One of the key IPPD tenets is multidisciplinary teamwork through Integrated Product Teams (IPTs).

33 Integrated Product Teams (IPTs) Integrated Product Teams (IPTs) are composed of representatives from appropriate functional disciplines working together to build successful programs, identify and resolve issues, and make sound and timely recommendations to facilitate decision-making.

34 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Scope: Total Life Cycle In the DoD, Total Life Cycle System Management (TLCSM) is the planning for and the management of the entire acquisition life cycle of a system. Systems Engineering, because it encompasses the entire technical effort, is a key TLCSM enabler. Costs to implement technical changes increase dramatically as a program moves further along the Defense Acquisition Framework. The greatest leverage exists in the early stages of development. Done then, analyses of TLCSM issues performed as part of Systems Engineering processes can reveal an optimum, life cyclebalanced design that prevents costly technical changes later. Systems Engineering is applied at the initial stages of program formulation. It provides the integrated technical basis for program plans and acquisition decisions; provides for requirements management, risk and design trade-offs; and integrates engineering, logistics, test and life cycle management efforts among all stakeholders. Select NEXT to continue. Page 7 of 17

35 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Scope: Industry and DoD Roles An additional key consideration related to the scope of Systems Engineering is to realize that different roles are played by industry (the developer) and the DoD (the acquirer). Both industry and the DoD have similar goals in product development and share key Systems Engineering processes. However the scope of their application is fundamentally different: The Acquirer: DoD program offices and agencies mainly use Systems Engineering processes and tools to manage development activities. The Developer: The defense industry mainly uses Systems Engineering processes and tools as part of their approach both to manage development, as well as to create products for the acquirer. For more information on the key role of the acquirer, click here. Select NEXT to continue. Page 8 of 17

36 Developer Although the 'developer' is cited here as reflective of the defense industry, in some situations, the DoD is both the 'acquirer' as well as the 'developer.' The same disciplined Systems Engineering processes apply, no matter what role is being filled!

37 The Key Role of the Acquirer Within the DoD, Systems Engineering is typically implemented through multidisciplinary teams of subject matter experts, often via an Integrated Product Team (IPT). The Systems Engineering IPT translates user-defined capabilities into operational system specifications consistent with cost, schedule and performance constraints. While the Program Office usually has a Chief Engineer or Lead Systems Engineer in charge of implementing Systems Engineering processes, personnel from non-systems Engineering organizations or from outside the program management structure may also perform key activities related to Systems Engineering. 'Front-end' Systems Engineering-like activities include defining architectures and capabilities and conducting functional analyses, etc. Planners and analysts usually complete many of these activities before a program is formally initiated within the Defense Acquisition Framework.

38 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering The Challenge: DoD Environment There are many attributes of defense systems that make the application of Systems Engineering challenging, on both the government and industry sides. Some of these challenges include: The need to quickly and costeffectively build interoperable, enterprise-wide, software-intensive systems to meet an ever-changing variety of threats while simultaneously integrating numerous existing DoD legacy systems Personnel turbulence, continuing defense industry consolidations, as well as the impact of the 'graying' of both the DoD's and industry's acquisition workforces Select NEXT to continue. Page 9 of 17

39 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering The Challenge: Complexity Another challenge is the complexity of DoD systems, which continues to grow at an increasing rate over time. The requirement to use good Systems Engineering practices by both government and industry will be even greater in the future as the DoD develops more complex Systems-of-Systems and increasingly moves toward net-centric operations. Select NEXT to continue. Page 10 of 17

40 Net-Centric Net-Centric DoD systems use service-oriented information processing, networks and data from the following perspectives: user functionality (capability to adaptively perform assigned operational roles with increasing use of system-provided intelligence/cognitive processes), interoperability (shared information and loosely coupled services) and enterprise management (net operations).

41 System-of-Systems (SoS) A SoS is a set or arrangement of interdependent systems that are related or connected to provide a given capability. The loss of any part of the system will generally significantly degrade the performance or capabilities of the whole.

42 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering The Challenge: Inadequate Technical Investment A final example of the challenge facing Systems Engineering is documented in various studies which looked at program success as a function of how much of the program resources were invested in technical management activities. As illustrated by the chart, programs that spent little on technical management had a higher probability of cost overruns than those programs that spent more. Unfortunately, a lot of programs fail to adequately invest in technical management. Failed, poorly-engineered, over-budget and inoperable systems are the likely results! Select NEXT to continue. Page 11 of 17

43 Adequately Invest Studies have been done that have attempted to quantify ideal investment levels. One study identified that the optimal Systems Engineering effort should be approximately 15-20% of the project development effort. But 3-8% or even less is typical on most projects. Other research has shown that effective use of Systems Engineering early in the life cycle can reduce project costs by over 20% and increase the likelihood of ontime delivery by 50%. Not a bad return-on-investment!

44 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Early-Phase Systems Engineering The challenge of inadequate technical investment was documented in a National Academy of Sciences study. This study found that many systems-level risks in interface and system complexity, requirements stability, technology maturity and software development as well as technical leadership could all be mitigated by sufficient investments in earlyphase Systems Engineering Systems Engineers must play an important role at the very start of a project. Effective Systems Engineering at the outset of a project plays a critical role in later project success. However, many DoD projects surveyed suffered from a lack of Systems Engineering focus and discipline at the outset. This results in sowing 'seeds of failure' related to cost, development time and performance risk. These significantly impact the program when discovered later. Select NEXT to continue. Page 12 of 17

45 Study This study is entitled 'Pre-Milestone A and Early-Phase Systems Engineering'. While performed for the US Air Force, its conclusions are relevant for all DoD programs. The study is available here.

46 Systemic Deficiencies Some examples of these seeds of failure are documented in the General Accountability Office s (GAO) assessment of DoD weapon system development. Many troubled programs are cited in this annual assessment required by Congress. SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering While there are many complex issues that contribute to program problems, systemic problems related to Systems Engineering identified by the GAO include: Requirements turbulence Poor requirements management Use of immature technologies Inadequate technical assessment Unstable/unproven product designs Premature entry into production Undisciplined software development Lack of Robust Systems Engineering The US defense industry has identified similar systemic Systems Engineering issues. Page 13 of 17

47 Technical Assessment A key part of the Technical Assessment process is the use of the results of Technical Design Reviews. Such reviews and the assessments that result from them are one of the keys to a knowledge-based acquisition process. A recent GAO survey of over 70 major DoD programs concluded that: The absence of a knowledge-based acquisition process steeped in disciplined Systems Engineering practices contributes greatly to DoD s poor acquisition outcomes. Systems Engineering is a process that translates customer wants into specific product features for which requisite technological, software, engineering and production capabilities can be identified.dod programs often do not conduct Systems Engineering in a timely fashion or in some cases, omit key Systems Engineering activities altogether.

48 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Challenges: Defense Industry Perspective A National Defense Industrial Association (NDIA) Task Force conducted an extensive study to identify those areas in DoD Systems Engineering requiring improvement. The NDIA Task Force identified five top Systems Engineering issues and challenges. Select the report cover to learn more about these Systems Engineering issues and challenges as viewed by the US defense industry. Select NEXT to continue. Page 14 of 17

49 Top Five SE Issues in Defense Industry - NDIA Task Force 1. Key Systems Engineering practices known to be effective are not consistently applied across all phases of the program life cycle. 2. Insufficient Systems Engineering is applied early in the program life cycle, compromising the foundation for initial requirements and architecture development. 3. Requirements are not always well-managed, including the effective translation from capabilities statements into executable requirements to achieve successful acquisition programs. 4. The quantity and quality of Systems Engineering expertise is insufficient to meet the demands of the government and the defense industry. 5. Collaborative environments, including SE tools, are inadequate to effectively execute SE at the joint capability, System-of-Systems (SoS) and system levels.

50 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Knowledge Review Which one of the following best summarizes how the DoD views Systems Engineering? Select the correct answer. A. Systems Engineering is what an organization named 'Systems Engineering' does and has as its responsibility and/or role. B. Systems Engineering is a multidisciplinary approach that defines the total technical effort needed to realize system products and sustain their life cycle C. Systems Engineering is a way of thinking about any technical problem. D. Systems Engineering is what a person with the titled position of 'Systems Engineer' does and has as his/her job description, responsibility and/or role. Great! The focus of this view is not on who does it, but on what is done to satify customer needs. This view is consistent with other well-respected references. Select Next to continue. Page 15 of 17

51 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Knowledge Review Key parts of the DoD's definition of Systems Engineering include all of the following except. A. Encompasses the entire technical effort B. Total life cycle-balanced set of solutions C. An interdisciplinary approach D. Performed only by defense contractors E. Involves system, people and process D.That s right! Systems Engineering is performed by both the DoD and its defense contractors, not just the latter alone! Select Next to continue. Page 16 of 17

52 Review of Objectives SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Systems Engineering: Is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and total life cyclebalanced set of system, people and process solutions that satisfy customer needs. The Scope of Systems Engineering: Includes transformation of needed operational capabilities into an integrated system design; integration of technical life cycle efforts; and development of technical information to support program management decisionmaking. Systems Engineering, because it encompasses the entire technical effort, is a key enabler of effective Total Life Cycle System Management (TLCSM). Challenges to Systems Engineering: Include growing system complexity; workforce turbulence; low technical management investment; inconsistent application of Systems Engineering; insufficient early use of Systems Engineering; and poor initial program formulation, insufficient tools and environments and inconsistent requirements management. You have reached the end of this topic. To proceed, select the exam for this topic in the Table of Contents. Page 17 of 17

53 SYS 101: Fundamentals of Systems Engineering Description of Systems Engineering Exam Description of Systems Engineering Exam

54 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Overview of Systems Engineering Processes This topic summarizes the various processes that comprise the DoD s approach to Systems Engineering.

55 Contents of Topic Approximate Length: 1 hour SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Topic Description: Systems Engineering is a process-oriented discipline. Technical Processes do the work of Systems Engineering while Technical Management Processes help to ensure the work gets done right. This topic summarizes the various Technical Processes and Technical Management Processes, as outlined in the DoD's Defense Acquisition Guidebook. These are the processes that can be used to accomplish Systems Engineering. Select NEXT to continue. Page 1 of 27

56 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Topic Learning Objectives Listed below are the learning objectives for this topic: Identify Systems Engineering Technical Processes Identify Systems Engineering Technical Management Processes Summarize the purpose of each of them Select NEXT to continue. D Page 2 of 27

57 Long Description Flipchart with the following objectives: Identify Systems Engineering Technical Processes Identify Systems Engineering Technical Management Processes Summarize the purpose of each of them

58 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Role of Standard Processes Standard processes offer a consistent and repeatable way for the acquirer and developer to communicate about various Systems Engineering activities. A process identifies 'what' has to be done but not the details of 'how' to do it. Standardized processes are essential for: Controlling the overall technical effort Designing systems solutions 'Realizing' products that make up the system 'Realization' is a formal term used to precisely quantify the desired end-state of Systems Engineering activities. A formal definition of 'realization' from a Systems Engineering perspective is shown here. D Page 3 of 27

59 Long Description A definition of the word 'Realization' is shown under a magnifying glass. It means the physical design solution is provided in a form suitable for meeting the applicable acquisition phase exit criteria, including verifying the product form is consistent with the design-to or build-to specifications, validating that the product form satisfies stakeholder expectations, and transitioning the product form to the next level up of the system structure or to the customer.

60 Process A process is a sequence of steps or activities performed for a given purpose. A process converts an input (such as requirements) to a desired output (such as defined work products) through a set of structured activities. To execute a process, it takes resources such as trained people, funds, facilities, equipment, tools and methods. Processes are constrained by various management and legal and regulatory directives and requirements.

61 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review The term 'realization' as used in Systems Engineering encompasses. A. Transitioning the product, ultimately to the customer B. Providing the physical design solution in an appropriate form C. Verifying and validating the product D. None of these responses is correct. A, B, C. Yes! Select Next to continue. Page 4 of 27

62 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Systems Engineering Processes The Defense Acquisition Guidebook (DAG) supplements the DoD's 5000-series of acquisition policies. The DAG is a collection of best practices and procedures applicable across all of the phases of the Defense Acquisition Framework. As outlined in the DAG, the DoD's Systems Engineering processes are comprised of categories consisting of: Technical Processes for designing systems Technical Processes for product realization Technical Management Processes Select the above entries to see a process listing for each of these categories. Select NEXT to continue. Page 5 of 27

63 Technical Processes for Designing Systems Requirements Development Logical Analysis Design Solution

64 Technical Processes for Product Realization Implementation Integration Verification Validation Transition

65 Technical Management Processes Technical Planning Requirements Management Interface Management Risk Management Configuration Management Technical Data Management Technical Assessment Decision Analysis

66 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Purposes of Technical Processes Technical Processes are used to design the products of a system, including the operational products and the supporting or enabling products required to produce, support, operate or dispose of a system. Technical Processes are also used to realize these system products. Select the Technical Processes for Designing Systems block for a summary description of these processes. Select the Technical Processes for Realizing System Products block for a summary description of these processes. Select NEXT to continue. D Page 6 of 27

67 Technical Processes for Designing Systems Requirements Development takes all inputs from users and stakeholders and translates these inputs into Technical Requirements. Logical Analysis improves understanding of the defined requirements and the relationships among the requirements (e.g., functional, behavioral, time-related). Design Solution translates the outputs of the Requirements Development and Logical Analysis processes into alternative design solutions and selects a final design solution (Solution-Specified Requirements).

68 Technical Processes for Realizing System Products Implementation makes, buys or reuses low-level system elements. Integration incorporates lower-level system elements into higher-level subsystems and systems. Verification confirms that a system element meets its design-to or build-to specifications. Validation confirms that a system element meets its Stakeholder Requirements. Transition moves the system element to the next stage of development, or for the end-item system, to the user.

69 Long Description The image shows three cubes. At the top is a cube labeled Technical Management Processes. Under this cube are cubes labeled Technical Processes for Designing Systems and Technical Processes for Realizing System Products. When the student clicks one of the bottom cubes, the following text displays: Technical Processes for Designing Systems Requirements Development takes all inputs from users and stakeholders and translates these inputs into Technical Requirements. Logical Analysis improves understanding of the defined requirements and the relationships among the requirements (e.g., functional, behavioral, time-related). Design Solution translates the outputs of the Requirements Development and Logical Analysis processes into alternative design solutions and selects a final design solution (Solution-Specified Requirements). Technical Processes for Realizing System Products Implementation makes, buys or reuses low-level system elements. Integration incorporates lower-level system elements into higher-level subsystems and systems. Verification confirms that a system element meets its design-to or build-to specifications. Validation confirms that a system element meets its Stakeholder Requirements. Transition moves the system element to the next stage of development, or for the end-item system, to the user.

70 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review Which of the following statements about the various Technical Processes used in Systems Engineering is correct? Select the best answer. A. They are used for designing systems and for product realization. B. They are used to manage the overall technical effort. C. 'Decision Analysis' is a key Technical Process. D. Different ones are used for different types of DoD systems. A. Correct! Select Next to continue. Page 7 of 27

71 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review Which of the following is not a Systems Engineering Technical Process used for system design and product realization? A. Design Solution Process B. Requirements Management Process C. Requirements Development Process D. Verification Process E. Transition Process B. Great! You realize that Requirements Management is a Technical Management Process, not a Technical Process. The latter are the ones used for system design and product realization. Select NEXT to continue. Page 8 of 27

72 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review Which of the following are Systems Engineering Technical Processes used for designing systems? A. Transition Process B. Requirements Development Process C. Logical Analysis Process D. Verification Process E. Design Solution Process F. Integration Process B, C, E. Great! You understand which processes are used for designing systems and which are used for realizing system products. Select Next to continue. Page 9 of 27

73 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review Which of the following are Systems Engineering Technical Processes used for realizing system products? A. Integration Process B. Verification Process C. Validation Process D. Design Solution Process E. Requirements Development Process F. Transition Process A, B, C, F. Yes! You understand which processes are used for realizing system products and which are used for designing systems. Select Next to continue. Page 10 of 27

74 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Purposes of Technical Management Processes Technical Management Processes are used to manage the development of system products, including supporting or enabling products. Technical Management Processes are used in tandem with Technical Processes. The latter do the work of Systems Engineering while the former ensure that the work gets done right. Select the Technical Management Processes block for a summary description of each process. Select NEXT to continue. Page 11 of 27

75 Technical Management Processes Technical Planning--Ensures the proper application of Systems Engineering processes. Requirements Management--Provides traceability, ultimately back to user-defined capabilities and needs. Interface Management--Ensures interface definition and compliance among the elements that compose the system as well as with other systems with which the system or system elements must interoperate. Risk Management--Examines the technical risks of deviating from the program plan. Configuration Management--Establishes and maintains consistency of a product's attributes with its requirements and product configuration information. Technical Data Management--Plans for, acquires, accesses, manages, protects and uses data of a technical nature to support the total life cycle of the system. Technical Assessment--Measures technical progress and the effectiveness of plans and requirements. Key Technical Assessment tools include: Earned Value Management (EVM), Technical Performance Measurement (TPM) and Technical Reviews. Decision Analysis--Provides the basis for evaluating and selecting technical alternatives when decisions need to be made.

76 SYS 101: Fundamentals of Systems Engineering `` Overview of Systems Engineering Processes Knowledge Review Which of the following statements about the various Technical Management Processes used in Systems Engineering is correct? A. They are used extensively in system design. B. Product 'realization' uses them to field a C. Design Solution is the most important of the D. They are key to managing the overall E. None of these responses is correct. D. Yes! You understand the key purpose of the various Technical Management Processes. Select Next to continue. Page 12 of 27

77 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review Each of the following is a Systems Engineering Technical Process used for designing systems except for. Select the correct answer. A. Requirements Development Process B. Logical Analysis Process C. Technical Planning Process D. Design Solution Process C. Great! You know the three technical processes for designing systems. Select Next to continue. Page 13 of 27

78 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review Each of the following is a Systems Engineering Technical Management Process except. A. Requirements Development Process B. Transition Process C. Decision Analysis Process D. Interface Management Process E. Technical Planning Process A,B. Right! Select Next to continue. Page 14 of 27

79 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review Which of the following best defines Requirements Management, one of the Systems Engineering Technical Management processes? Select the correct answer. A. It provides traceability, ultimately back to user-defined capabilities. B. It is used to plan for, acquire, access, manage, protect and use data of a technical nature. C. It is used to examine the technical risks of deviating from the program plan. D. It provides the basis for evaluating and selecting alternatives when decisions need to be made. A. That's correct! You know the definition of the Requirements Management Process. Select Next to continue. Page 15 of 27

80 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes The Big Picture I: Product Design Snapshot Let's look at a simplistic (you'll find out why later!) example of Systems Engineering Technical Processes in action, starting with the three Technical Processes used to design a system. These processes are: 1. Requirements Development Process: Requirements for DoD systems come from various diverse constituencies (generically categorized as Acquirer Requirements and Other Interested Party Requirements). Together these requirements comprise the set of Stakeholder Requirements, which also include Derived Requirements. These sets of requirements are ultimately transformed into Technical Requirements. The latter become the basis for the design. Key Measures of Effectiveness are also initially identified. 2. Logical Analysis Process: Technical Requirements are then analyzed in various ways to determine an optimal functional architecture. Interfaces are defined in more detail. Performance parameters are allocated. Important additional Technical Requirements (called Derived Technical Requirements) are identified. Work products are baselined. 3. Design Solution Process: Using the outcomes from the Requirements Development Process and the Logical Analysis Process, alternative design solutions are developed. More Derived Technical Requirements may be identified as well. These design solutions are evaluated to determine which are acceptable within cost, schedule and technical constraints. A design or a physical architecture is established. Outcomes of the Design Solution Process typically include a set of Solution-Specified Requirements, a key component of which is the System Specification. These requirements are baselined and become part of a Technical Data Package (TDP). 4. Select NEXT to continue. Page 16 of 27

81 Acquirer Requirements Acquirer Requirements may be in the form of requirement statements from a customer, user or operator; or be expressed as a set of assigned/allocated specifications developed previously.

82 Other Interested Party Requirements These types of requirements include those of parties who have some interest in the system, such as those providing life cycle support functions; OSD management or other government agencies; and laws, regulations, treaties, policies, etc. which may affect the program or project.

83 Stakeholder Requirements These are requirements that represent what stakeholders of a system need or expect of the system products. They are comprised of 'Acquirer Requirements' and 'Other Interested Party Requirements'.

84 Derived Requirements Derived Requirements are those that are not explicitly stated in the set of Stakeholder Requirements yet are required to satisfy one or more specific Stakeholder Requirements. Derived Requirements are generated based on an operational or technical analysis of a Stakeholder Requirement in order to clarify the requirement or make it achievable. For example: Stakeholder Requirement: A missile must have a fly-out distance of 2 kms and hit a target having a Radar Cross Section the size of a tennis ball. Derived Requirement: The missile shall be aimed within 2 degrees of the target so that the warhead terminal seeker can lock on and perform the terminal intercept.

85 Technical Requirements A Technical Requirement is derived from analysis of Stakeholder Requirements. It is expressed as a confirmed and quantitative 'shall' statement. The set of Technical Requirements are inputs to the Logical Analysis Process. Technical Requirements establish the basis for system development.

86 Measures of Effectiveness Measures of Effectiveness (MOEs) give definition to the operational capabilities essential to mission accomplishment. They represent the metrics by which satisfaction with products produced by the technical effort will be measured.

87 Functional Architecture This is an arrangement of functions and their sub-functions and interfaces (internal and external) that defines the execution sequencing, conditions for control or data flow, and the performance requirements to satisfy the requirements baseline.

88 Derived Technical Requirements These are technical requirements that are further refined from a primary source requirement or a higher-level derived requirement. Derived Technical Requirements are requirements that result from the analysis of Technical Requirements, which is done as part of the Logical Analysis Process or Design Solution Process.

89 Work Products A work product is any artifact--material or electronic--generated during the conduct of the activities and tasks of a process, including the desired outputs.

90 Physical Architecture This is a hierarchical arrangement of people, product and process solutions; their functional and performance requirements; their internal and external interfaces; and their physical constraints. It forms the basis for the design.

91 System Specification This is a type of program-unique specification that describes the requirements and how they will be verified for a combination of elements that must function together to produce the capabilities that fulfill a mission need, including hardware, equipment and software.

92 Solution-Specified Requirements These are the requirements that characterize and specify the functions and performance of the design solution. They are expressed in the System Specification, subsystem specifications, verification/validation criteria, various end product specifications and requirements for Enabling Products.

93 Technical Data Package (TDP) A Technical Data Package (TDP) provides a comprehensive description of a given system element. The TDP is used for the Implementation Process and is retained and placed under configuration management and baselined throughout the life of the product.

94 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes The Big Picture II: Product Realization Snapshot Realization now begins, using these Technical Processes: 4. Implementation Process: If subsystems do not need to be developed, then, using appropriate elements from the TDP, the product is made, bought or reused. This may involve hardware fabrication, manufacturing, software coding or purchase from outside sources. No matter what their source, some degree of low-level verification and validation is performed to make sure that 'good' products are implemented. Some supporting documentation may be developed. 5. Integration Process: At some point, implementation is completed. End product components are assembled and integrated. Prior to this, implemented components are verified and validated as appropriate so as to ensure that only 'good' products actually get assembled and integrated. 6. Verification Process: Using criteria established as part of the Design Solution Process and various plans, the end product is verified. This ensures that it conforms to its 'design-to' requirements and has been 'built right'. 7. Validation Process: Using criteria established as part of the Design Solution Process and various plans, the end product is validated. This ensures that it conforms to its Stakeholder Requirements and is the 'right product'. 8. Transition Process: The end product either: (1) moves up a level (e.g., from subsystem to system) in the physical architecture of the system for more development as needed; (2) it transitions to the next Defense Acquisition Framework phase; or (3) the End Product is delivered successfully to the user. Simple, eh? Wait! Not so fast... Page 17 of 27

95 Realization Realization is providing the physical design solution in a product form suitable for meeting the applicable acquisition phase exit criteria, including product verification and validation and transitioning the product to the next level up of the system structure or ultimately, to the customer.

96 Various Plans Key among these plans is the Test and Evaluation Master Plan (TEMP). The TEMP, one of the outcomes of the Technical Planning Process, provides top-level details of systems-level verification (Developmental Testing) and validation (Operational Testing). Specific test scenarios and scripts are provided elsewhere in more detailed test plans.

97 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Not So Fast...Fleas?? The Technical Process snapshots that we just provided, while correct from a big picture standpoint, are simplistic from several actual application perspectives: Non-Linear: The processes were depicted as occurring in a strict linear sequence. This is not typical. There is a high degree of healthy interaction among them, especially among the Design processes. This interaction is in the form of iteration (do it until you get it right!) and recursion (keep doing it at different levels in the system until you are done!). Entire DAF: The processes were depicted as occurring only in a later stage in the Defense Acquisition Framework (DAF). In actual practice, these Technical Processes will occur repeatedly during each acquisition phase, but with different types of realized products. Examples are illustrated on The Chart. Complex System Model: The processes were depicted as operating on a simple model structure. In practice, for non-trivial systems, the system structure consists of many layers and levels (e.g., subsystems, components, assemblies, etc.). Throughout this layered structure, multiple Technical Processes are being applied simultaneously. So...a lot of things are going on at the same time in different parts of the system structure. And these things are typically being done by many different organizations. Given this, it's all too easy to make chaos out of order! That is why Technical Management Processes are absolutely vital complements to the Technical Processes. Select NEXT to continue. Page 18 of 27

98 Layered Structure One humorous analogy related to this multiple layering of a system structure is reflected in this ditty by Augustus De Morgan. De Morgan was a nineteenth century English mathematician. In his book, A Budget of Paradoxes, he wrote: Great fleas have little fleas upon their backs to bite 'em, And little fleas have lesser fleas, and so ad infinitum, And the great fleas themselves, in turn, have greater fleas to go on, While these again have greater still, and greater still, and so on. A 'System Model' accommodates this sort of multiple levels of layering in a (much!) more formal way. More definition of a system model and discussions of its many uses are given in other topics.

99 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review What ordering of Technical Processes best completes this process list? Select the best order., Logical Analysis,, Implementation A. Transition, Validation B. Verification, Validation C. Requirements Development, Design Solution D. Requirements Management, Interface Management C. Right! This is the most likely order for the performance of these processes. Bear in mind that there will be a high degree of interaction among them! Select Next to continue. Page 19 of 27

100 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Knowledge Review What ordering of Technical Processes best completes this process list? Select the best order. A. Transition, Validation, Verification B. Validation, Verification, Transition C. Logical Analysis, Requirements Development, D. Implementation, Verification, Validation E. Verification, Validation, Transition E. Verification, Validation, Transition. Right! This is the most likely order for the performance of these bottom-up product realization processes. Select Next to continue. Page 20 of 27

101 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes The Big Picture III: Technical Control Processes Continuing our example, let's look at the application of the various Technical Management Processes. Five of these are generally referred to as Technical Control Processes. These are: 1. Requirements Management Process: Used heavily as the three design Technical Processes iterate and interact, it ensures that all of the generated Technical Requirements and Derived Requirements can ultimately be traced back to user-defined capabilities and needs. 2. Interface Management Process: Used to support the Logical Analysis Process (where many interfaces are defined) as well as the Integration Process. Interface Management ensures interface definition and compliance among system elements and for interoperability with other systems. 3. Risk Management Process: Is a core process which underlies all others. It identifies, analyzes, mitigates and tracks program technical risks. 4. Configuration Management Process: Ensures that baselines are established, controlled and kept consistent. Configuration Management is a key player with the Requirements Management, Interface Management and Technical Data Management Processes. 5. Technical Data Management Process: A wide variety of data and information is produced as outcomes of various process activities. Technical Data Management plans for it; acquires it; provides access to it; manages it; and protects data and information of a technical nature needed to support the total life cycle of a system. Select NEXT to continue. Page 21 of 27

102 Baselines Typically these include the following: Functional Baseline: Documentation describing system and subsystem functional characteristics and the verification required to demonstrate the achievement of those specified functional characteristics. Allocated Baseline: Documentation that designates the Configuration Items (CIs) making up a system, and then allocates the system function and performance requirements across the CIs (hence the term 'allocated baseline'). Product Baseline: The approved technical documentation which describes a system's Configuration Item during the production, fielding/deployment and operational support phases of its life cycle.

103 Data and Information The term 'data' as used in Technical Data Management includes technical data; computer software documentation; or representation of facts, numbers, or datum of any nature that can be communicated, stored and processed to form information required by a contract or agreement to be delivered, or accessed by, the Government. Information, on the other hand, is generally considered as processed data. The form of the processed data is dependent on the documentation, report, review formats or templates that are applicable. Of course, one needs wisdom to use either data or information most effectively. Unfortunately, that is not one of the by-products of Technical Data Management!

104 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes The Big Picture IV: Other Technical Management Processes The remaining Technical Management Processes are: 6. Technical Planning Process: This management process is the lynchpin of the entire Systems Engineering process and ultimately, initiates the overall effort. Various key plans, such as the Systems Engineering Plan (SEP) (which outlines expected activities by acquisition phase), the Test and Evaluation Master Plan (TEMP) and various other plans are key outcomes of the Technical Planning Process. 7. Technical Assessment Process: This process provides visibility to 'where we are' and 'where we are going' in terms of the application of Technical Processes. Key tools used in Technical Assessment include Technical Reviews, Earned Value Management (EVM) and Technical Performance Measurement (TPM). 8. Decision Analysis Process: This is a cross-cutting process that provides a rational, repeatable basis -- both formal and informal -- for evaluating and selecting alternatives when a decision must be made. It operates within the program's trade space. Select NEXT to continue. Page 22 of 27

105 Systems Engineering Plan (SEP) The SEP is a detailed formulation of actions that should guide all technical aspects of an acquisition program. The SEP is intended to be a roadmap that supports program management by defining comprehensive Systems Engineering activities, addressing both government and contractor technical activities and responsibilities. The SEP should incorporate known industry 'best practices' and be used by the Program Office to help frame contractual technical requirements. It is prepared for each phase of a Defense Acquisition Framework.

106 Test and Evaluation Master Plan (TEMP) The TEMP is an important document in that it contains the required type and amount of integrated test and evaluation events, along with their resource requirements. The TEMP focuses on the overall structure, major elements and objectives of the T&E program, and it must be consistent with the Systems Engineering Plan (SEP).

107 Other Plans A number of 'other plans' exist. Some of them frame the actual program's implementation of Technical Management Processes. For example: Interface Management Plan; Requirements Management Plan; Risk Management Plan; Configuration Management Plan; Data Management Plan, among others. Others are so-called specialty plans which include: Electromagnetic Compatibility/ Interference (EMC/EMI) Control Plan; Human Systems Integration (HSI) Plan; Producibility Plan; Safety Plan; Security Plan; Information Support Plan; Corrosion Prevention Plan, etc. Many of these plans are discussed in various sections of the Defense Acquisition Guidebook (DAG). In some cases, specific formats are suggested and in other cases, plan formats depend on local command policies and regulations. Some plans are required by statute, and details about them are provided via tabular format as enclosures to the DoD 5000-series of acquisition directives.

108 Technical Reviews Technical Reviews are an important oversight tool. They are used to review and evaluate the state of the system and the program, re-directing activity after the review if found necessary. Technical Reviews are key decision events used to measure technical progress and maturity in system development as well as to assess various programmatic issues.

109 Earned Value Management (EVM) Earned Value Management is a tool that allows visibility into contractual technical, cost, and schedule planning, performance, and progress. This visibility provides insight to contract performance, but also provides the necessary data points to statistically estimate probable completion costs. EVM helps to ensure that cost, schedule and technical aspects of the contract are truly integrated.

110 Technical Performance Measurement (TPM) This is the technique of predicting the future value of a key technical parameter of the higher-level end product under development, based on current assessments of products lower in the system structure. In the DoD, these key technical parameters are typically related in some way to Key Performance Parameters (KPPs).

111 Trade Space Trade Space is the set of program and system parameters, attributes and characteristics required to satisfy some aspect of system performance. Decision-makers define and refine the development system by making trade-offs with regard to cost, schedule, risk and performance---all of which fall within the 'trade space'.

112 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes The Systems Engineering Engine A way of depicting the interactions among Technical Processes and their controlling Technical Management Processes is shown here as the 'Systems Engineering Engine'. Technical Processes get applied recursively to each system element, from the top to the bottom. This continues until the lowest system products are defined to the point where they can be implemented (i.e., bought, built or reused) and realized. Meanwhile, Technical Management Processes are controlling all these Technical Processes and ensuring their effective application. Select NEXT to continue. D Page 23 of 27

113 Long Description The diagram shows two ovals: System Design Technical Processes indicates that requirements flow down from the level above and flow down to the level below. System Realization Technical Processes indicates that realized products flow up from the level below and flow up to the level above. Between the two ovals are the Technical Management Processes, which ensure the effective application of the Technical Processes.

114 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Activities, Tasks and Outcomes The 16 Defense Acquisition Guidebook (DAG) processes outlined previously are the foundations of the DoD's approach to Systems Engineering and technical management. These eight Technical Processes and eight Technical Management Processes are broken down into over 90 process-specific activities, each with associated expected outcomes. Each activity is further decomposed into more detailed sets of illustrative tasks. These illustrative tasks put the processspecific activity into perspective. They show one possible way the activity could be accomplished and its expected outcomes used. Select NEXT to continue. Page 24 of 27

115 Processes A process is a sequence of steps performed for a given purpose. A process converts an input (such as requirements) to a desired output (such as defined work products) through a set of structured activities. Executing a process takes resources such as trained people, funds, facilities, equipment, tools and methods. Processes are constrained by various management and legal and regulatory directives and requirements.

116 Process Activity Roadmap With all these activities, tasks and expected outcomes, one can get overwhelmed without some sort of a guide. Looking at them all from a macro- level, many of the activities and associated tasks making up a process follow a generic common-sense roadmap. The process activity roadmap generally will look like some variation of the following: SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes GET READY: Prepare to do the activity DO IT: Perform process activities ADJUST AND ANALYZE: As needed BASELINE: Baseline results in some manner CAPTURE: Update the program's technical management database While this simplifies things somewhat, there is still a lot going on and a lot that needs to go on, in Systems Engineering! This is why numerous studies and 'lessons learned' have shown that the levels of investment in program technical management are very good predictors of later overall program success. Hint! Select NEXT to continue. Page 25 of 27

117 Hint! The processes in this course follow those in Chapter 4 of the Defense Acquisition Guidebook (DAG) but with more detail. Because of this, you might want to get your own printed copy of Chapter 4 on which you can take personal notes as you go through the various lesson topics. If you want to do this, you can get a copy here.

118 Review of Objectives SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes There are eight Technical Processes that are used for designing and realizing systems. Systems Engineering Technical Processes for designing systems include: 1. Requirements Development: Translates stakeholder needs into Technical Requirements 2. Logical Analysis: Improves understanding of requirements and their relationships 3. Design Solution: Develops alternative design solutions and selects a final design (Solution-Specified Requirements) Systems Engineering Technical Processes for realizing systems products include: 1. Implementation: Creates (making, buying or reusing) low-level system elements 2. Integration: Incorporates lower-level system elements into higher-level ones 3. Verification: Confirms that system elements meet design-to or build-to specifications 4. Validation: Confirms that system elements meet Stakeholder Requirements 5. Transition: Moves a system element to the next development stage or, for the End Product, to the user Select NEXT to continue. Page 26 of 27

119 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Review of Objectives, Cont. Systems Engineering Technical Management Processes are used to control the application of the Technical Processes and to help ensure that they're effectively used. The eight Technical Management Processes are: 1. Technical Planning: Ensures the proper application of Systems Engineering processes 2. Requirements Management: Provides traceability of system and subsystem requirements, ultimately back to user-defined capabilities and needs 3. Interface Management: Ensures interface definition and compliance among system elements, including other systems 4. Risk Management: Examines the technical risk of deviating from program plans 5. Configuration Management: Establishes and maintains the consistency of a product's attributes with its requirements and configuration information 6. Technical Data Management: Plans for, acquires, accesses, manages, protects and uses data of a technical nature in order to support the total life cycle of a system 7. Technical Assessment: Measures technical progress and the effectiveness of plans and requirements 8. Decision Analysis: Provides the basis for evaluation and selection of technical alternatives when decisions need to be made You have reached the end of this topic. To proceed, select the exam for this topic in the Table of Contents. Page 27 of 27

120 SYS 101: Fundamentals of Systems Engineering Overview of Systems Engineering Processes Overview of Systems Engineering Processes Exam

121 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Role of Systems Engineering Standards This topic discusses the roles played by some of the most commonly used Systems Engineering standards.

122 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Contents of Topic Approximate Length: 30 minutes Topic Description: This topic presents an overview of current Systems Engineering standards, important roles they can play, and how they differ from capability maturity models. Select NEXT to continue. Page 1 of 13

123 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Topic Learning Objectives Listed below are the learning objectives for this topic: Describe the role of Systems Engineering standards Identify three key Systems Engineering standards Distinguish between standards and maturity models Select NEXT to continue. D Page 2 of 13

124 Long Description Flipchart with the following objectives: Describe the role of Systems Engineering standards Identify three key Systems Engineering standards Distinguish between standards and maturity models

125 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Role of Systems Engineering Standards A variety of standards and models exist that describe the processes and 'best practices' that can be used to accomplish Systems Engineering. These standards and models define various processes and establish common vocabularies between the acquirer and the developer. This helps to promote consistent and effective communications. Additionally, standards play key roles in the following areas: They provide a baseline of the 'what's' and 'why's'. This provides a basis for assessing and improving an organization's policies and procedures. They are used by developers to: o Establish and standardize internal processes o o o Direct usage by suppliers and subcontractors Assess internal and supplier capabilities Develop Systems Engineering technical plans They are used by acquirers to: o Understand the developer's Systems Engineering activities o Determine and assess developer capabilities They are used by countries. Standards provide an industry with a set of national practices. NOTE: DoD acquirers need to be familiar with standards that developers may use. This is so they can properly evaluate the developer's proposals relative to Systems Engineering submitted as part of the contracting process. However, the DoD does not generally contractually impose any particular SE standard on developers. Select NEXT to continue. Page 3 of 13

126 Developers Although the 'developer' is cited here as reflective of the defense industry, in some situations, the DoD is both the 'acquirer' and the 'developer'.

127 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Evolution of SE Standards For years the DoD had thousands of Military Standards (MIL-STDs) that were used to specify products and standardize processes. One of these was MIL-STD-499A, which until 1994 was the mandatory standard used for DoD Systems Engineering. DoD Acquisition Reform efforts in the mid-1990s ultimately eliminated nearly all unique DoD MIL-STDs, including MIL-STD-499A. It and its projected replacement, MIL-STD-499B, were canceled. After that cancellation, the Electronic Industry Alliance (EIA) and the Institute of Electrical and Electronics Engineering (IEEE), two US standardsmaking bodies, released interim Systems Engineering standards. These were commercial derivatives of MIL-STD-499B. Over time these interim standards evolved. Both organizations ultimately released final versions of their standards, which differed considerably from the interim ones. Select NEXT to continue. D Page 4 of 13

128 Differed Considerably The EIA standard evolved to a multiple process approach such as described in the Defense Acquisition Guidebook (DAG) and in this course. Although the IEEE standard retained a single Systems Engineering process approach, it added additional scope than was originally found in the interim standard.

129

130 Long Description Flowchart titled 'Heritage of SE Standards.' Flow begins with MIL-STD-499 to MIL- STD-499A to MIL-STD-499B (Not Released), which branches to both EIA/IS (Interim) and IEEE (Trial Use). EIA/IS (Interim) goes to ANSI-EIA-632. IEEE (Trial Use) goes to IEEE-1220.

131 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Current Key SE Standards EIA 632, Processes for Engineering a System and IEEE 1220, Standard for Application and Management of Systems Engineering Processes are two current US national Systems Engineering standards. An international Systems Engineering standard, recently adopted by the IEEE, exists as well. In 2002, the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) released an international standard, ISO/IEC Revised in 2008 to better accomodate software development, this standard is entitled Systems and Software Engineering - System Life Cycle Processes. In addition to the existing IEEE 1220, it has been adopted unchanged by the IEEE as another US standard. Whereas ANSI/EIA 632 and IEEE 1220 focus on process requirements, ISO/IEC focuses on application of processes across the life cycle. All of these standards have relevance to the application of Systems Engineering processes. D Page 5 of 13

132 Long Description Graphic titled 'Heritage of Systems Engineering Standards' with three columns: Government, Commercial, International. Under Government, MIL STD 499 flows to MIL STD 499A, which flows to MIL STD 499B. Under Commercial, EIA/IS 632 flows to EIA 632. IEEE Trial Use Std-1220 flows to IEEE Std There is also a box labeled IEEE Std Under International, there is one box, ISO An arrow runs from it to IEEE

133 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Scope of Systems Engineering Standards These Systems Engineering standards differ primarily in their depth and breadth of coverage. ISO/IEC (which is identical to IEEE Std 15288) has the greatest breadth (25 system life cycle processes including post-deployment ones) but the least depth of coverage. It is useful for top-level planning, primarily at the organizational level. This standard is designed to be used by an organization, a project within an organization, or an acquirer and a supplier via an appropriate agreement. EIA 632 defines the set of requirements for engineering a system. The processes in EIA 632 describe 'what to do' with respect to the processes for engineering a system. These are at the next level down from the ISO/IEC level of system life cycle processes. IEEE 1220 defines a Systems Engineering process. It gives the next level of detail below the process requirements described in EIA 632. The process is described more at the task or application level. IEEE 1220 has the greatest depth of coverage for its limited scope but the least breadth. EIA-632 falls between the other two standards. It is not necessarily a question of choosing just one standard for a program. Depending on the specific needs of a given program, all of these standards may be employed. The Systems Engineering processes outlined in the DoD's Defense Acquisition Guidebook (DAG) are derived in part from EIA 632. Select NEXT to continue. Page 6 of 13

134 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Knowledge Review Key commercial Systems Engineering standards include. A. EIA 632, IEEE 1220 and ISO/IEC B. MIL-STD 498, MIL-STD 499A and MIL-STD-499B C. MIL-STD 1521B D. MIL-HDBK 961, SE Standard Practices E. EIA 667, IEEE 1946 and ISO/IEC F. IEEE and DoD-STD 2167A A. Right! The others are either obsolete standards or fictitious ones! Select Next to continue. Page 7 of 13

135 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Role of Systems Engineering Standards True or False? The scope, breadth and life cycle applicability of the various Systems Engineering commercial standards such as EIA 632, IEEE 1220 and ISO/IEC are consistent. Select the correct answer. A. True B. False False. Correct! These commercial standards vary in both their depth and in their breadth of coverage of Systems Engineering processes. Select Next to continue. Page 8 of 13

136 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Standards vs. Capability Maturity Models Standards and Capability Maturity Models play mutually supportive roles in Systems Engineering. Both are important, but the role for each is different. The major distinction lies in their purposes. Standards provide a set of processes that, if performed by qualified persons using appropriate tools and methods, will provide a capability for effective and efficient engineering of systems, including their software components. Standards provide recommended processes to apply, describe expected tasks and outcomes, and describe how they all integrate to provide required inputs and outputs. Capability Maturity Models were originally developed for internal process improvement purposes. In that role, they can also be used to assess how well an organization's standard processes are defined, understood and followed. Properly understood, they can also give the acquirer insights into potential developer risks. Sponsored by industry and the DoD, the Capability Maturity Model, Integrated (CMMI ), which combines a number of disciplines such as Systems Engineering, Project Management, hardware/software development and IPPD processes into a 'constellation' of various unified models, is a commonly used maturity model. Both acquisition and development variants of the CMMI have been developed. Select NEXT to continue. Page 9 of 13

137 CMMI CMMI is registered in the U.S. Patent and Trademark Office by the Carnegie Mellon University.

138 Integrated Product and Process Development (IPPD) Integrated Product and Process Development (IPPD) is a management technique that simultaneously integrates all essential acquisition activities through the use of multidisciplinary teams to optimize design, manufacturing and supportability processes. IPPD facilitates meeting cost and performance objectives. One of the key IPPD tenets is multidisciplinary teamwork through Integrated Product Teams (IPTs).

139 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards CMMI Architecture CMMI models are made up of Process Areas. Process Areas are outlined in terms of goals, practices and work products. This outline provides evidence of effective process application but does not go into the details of how to do it. Because of this, the CMMI is not a prescriptive model. One way of viewing CMMI models is via a 'Staged Representation'. This features ratings on a maturity level scale from 1 to 5; each Process Area builds on those at lower levels. A 'Continuous Representation' form, where Process Areas are evaluated separately, is also used. This is felt to give greater insight into and more flexibility for process improvement. More information about CMMI models is available in the Quick References section. Select NEXT to continue. D Page 10 of 13

140 Process Areas A Process Area is a set of related practices satisfying a set of goals important for making improvements. Not surprisingly, many of the CMMI Process Areas relate directly to various DoD Systems Engineering Processes. CMMI Process Areas and their associated maturity levels included in the CMMI-Development model include: Causal Analysis and Resolution: Level 5 Configuration Management: Level 2 Decision Analysis and Resolution: Level 3 Integrated Project Management + IPPD: Level 3 Measurement and Analysis: Level 2 Organization Innovation and Deployment: Level 5 Organization Process Definition: Level 3 Organization Process Focus: Level 3 Organization Process Performance: Level 4 Organizational Training: Level 3 Product Integration: Level 3 Project Monitoring and Control: Level 2 Project Planning: Level 2 Process and Product Quality Assurance: Level 2 Quantitative Project Management: Level 4 Requirements Development: Level 3 Requirements Management: Level 2 Risk Management: Level 2 Supplier Agreement Management: Level 2 Technical Solution: Level 3 Validation: Level 3 Verification: Level 3

141 Long Description The graphic, tiltled 'CMMI Model Staged Representation,' is a drawing of a set of ascending stairs. The bottom stair is labeled 1. Initial. The second stair is labeled 2. Managed. The third stair is labeled 3. Defined. The fourth stair is labeled 4. Quantitatively Managed. The top stair is labeled 5. Optimizing. An ascending arrow indicates increasing maturity from the bottom stair (1) to the top stair (5).

142 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Knowledge Review Each of the following is a possible role for a Systems Engineering standard except. Select the correct answer. A. Acting as a baseline for process assessment B. Providing a basis for more effective communications C. Being mandated contractually for DoD projects D. Establishing and standardizing internal processes C. Correct! As part of the Acquisition Reform movement, which eliminated many D0D-unique MIL-SPECs, the DoD does not contractually impose specific Systems Engineering standards on defense contractors. All other choices are examples of key roles played by standards. Select Next to continue. Page 11 of 13

143 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Review of Objectives Roles of Systems Engineering Standards Systems Engineering Standards are used to: Provide a baseline for assessment Standardize internal processes Develop consistent engineering plans Gain insight into the developer's Systems Engineering practices Promote effective communications Standardize vocabularies Provide a consistent set of practices Select NEXT to continue. Page 12 of 13

144 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Review of Objectives, Cont. Key Current Standards Three commercial Systems Engineering standards exist. All have relevance to improving the practice of Systems Engineering by both acquirers and developers. These three standards are: ANSI/EIA 632: Processes for Engineering Systems IEEE 1220: Standard for Application and Management of Systems Engineering ISO/IEC 15288: Systems Engineering--System Life Cycle Processes Standards vs. Maturity Models Standards are by design useful for helping a project implement Systems Engineering. They provide a set of processes that, if performed by qualified persons using appropriate tools and methods, will provide a capability for effective and efficient engineering of systems. Maturity models (e.g., the CMMI) are by intent useful for determining the capability and/or maturity of an organization to perform Systems Engineering. A maturity model is used to assess, from an organizational perspective, how well processes have been established and instituted and how well they are being followed. You have reached the end of this topic. To proceed, select the exam for this topic in the Table of Contents. Page 13 of 13

145 SYS 101: Fundamentals of Systems Engineering Role of Systems Engineering Standards Exam Role of Systems Engineering Standards Exam Page X of Y

146 SYS 101: Fundamentals of Systems Engineering Technical Foundations Technical Foundations This topic presents key technical information that is the foundation for understanding how Systems Engineering Processes can be applied and used. Page X of Y

147 Contents of Topic Approximate Length: 1.5 hours SYS 101: Fundamentals of Systems Engineering Technical Foundations Topic Description: This topic consists of three interrelated parts that provide key technical foundations for understanding Systems Engineering processes and their application. These parts are: Part 1: Definition of a generic 'system model' Part 2: Illustration of uses of that model Part 3: Overview of Defense Acquisition Framework Systems Engineering life cycle activities Select NEXT to continue. Page 1 of 66

148 SYS 101: Fundamentals of Systems Engineering Technical Foundations Learning Objectives - Technical Foundations Listed below are the objectives for this topic: Define a 'system' Distinguish between an end product and an enabling product Identify uses of a generic system model Describe the Systems Engineering 'V' Model Explain recursion and iteration with respect to Systems Engineering List the order of the Technical Processes that are involved in 'top-down' design List the order of the Technical Processes that are involved in 'bottom-up' realization Define various types of specifications Identify Systems Engineering activities by defense acquisition phase Select NEXT to continue. D Page 2 of 66

149 Long Description A flipchart that lists the following objectives: Define a 'system' Distinguish between an end product and an enabling product Identify uses of a generic system model Describe the Systems Engineering 'V' Model Explain recursion and iteration with respect to Systems Engineering List the order of the Technical Processes that are involved in 'top-down' design List the order of the Technical Processes that are involved in 'bottom-up' realization Define various types of specifications Identify Systems Engineering activities by defense acquisition phase

150 SYS 101: Fundamentals of Systems Engineering Technical Foundations Background and Review Systems Engineering is all about 'engineering systems'. Everyone has an intuitive understanding of what a 'system' is and what 'engineering' encompasses. But to understand Systems Engineering Technical Processes and Technical Management Processes, more formal and precise definitions are needed. This includes development of an illustrative 'system model'. Such formality allows these processes to be described and applied in a consistent, repeatable way. Some key terms you should be familiar with before continuing are: realization, Technical Processes, Technical Management Processes, the Defense Acquisition Guidebook (DAG) and the Defense Acquisition Framework. Additionally, you should be familiar with the web-enabled version of 'The Chart', especially the capability to drill down in each acquisition phase. Click here to experiment with 'The Chart'. Select NEXT to continue. Page 3 of 66

151 Realization Realization is providing the physical design solution in a 'product' form suitable for meeting the applicable acquisition phase exit criteria, including product verification and validating and transitioning the product to the next level up of the system structure or to the customer.

152 Technical Processes These are used to design the system products (e.g., subsystems and components), including the operational/mission products and supporting or enabling systems required to produce, support, operate or dispose of system products.

153 Technical Management Processes These are used to manage the technical development of the system, including its supporting or enabling products.

154 Defense Acquisition Guidebook (DAG) The Defense Acquisition Guidebook is designed to complement acquisition policy documents by providing the acquisition workforce with discretionary 'best practices' that should be tailored to the needs of each program. Click here for a functional viewpoint of the scope of the DAG.

155 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Ambiguity Both within the DoD and the defense industry, a 'system' and its constituent parts are typically referred to in many different ways. Examples include: system, subsystem, system segment, system increment, system component, system element, system spiral, system end-item, configuration item, software item, hardware item, end product and enabling product, among others. This proliferation of terms is not unexpected: this is because numerous different DoD policies, handbooks and standards exist, many of which refer to a 'system' and its constituent composition differently, sometimes even within the same publication! However, modern defense systems consist literally of tens of thousands of different 'pieces.' To ensure consistency in describing and applying Systems Engineering Technical Processes and Technical Management Processes, a standard definition of a 'system' and a model of its constituent entities are needed. Select NEXT to continue. Page 4 of 66

156 SYS 101: Fundamentals of Systems Engineering Technical Foundations Key Questions The answer to "What is a system?" is fundamental to Systems Engineering in that the Technical Processes used for design are applied to the system to develop a system solution, regardless of its place in the overall system structure. Then product realization processes are applied to the defined solutions for each system's end products in order to to build the desired operational End Product that fulfills a desired capability. It is essential therefore that the 'right' system be engineered. The key questions are: "What is the right system?" and "What system model is appropriate to describe the right system?" Select NEXT to continue. Page 5 of 66

157 SYS 101: Fundamentals of Systems Engineering Technical Foundations Systems and System Models Because of differences in the way systems and system models can be defined, without consistent definitions, projects will have problems in uniform application of Systems Engineering processes. Three broad categories of system models include: 1. A generic dictionary type of definition that provides some insight but limited usefulness for actually engineering a particular system 2. A definition that considers the system as the operational entity 3. A model definition that encompasses both the operational products and their related enabling (life cycle support services) products Many definitions of a 'system' exist based on these categories. Select the bookcase to learn more about ways in which a 'system' can be characterized. Select NEXT to continue. Page 6 of 66

158 Long Description A book animates out of the bookcase, opens and displays the following text: 1. ANSI/EIA 632 An aggregation of end products and enabling products to achieve a given purpose. 2. IEEE 1220 A set or arrangement of elements and processes that are related and whose behavior satisfies customer/operational needs and provides for life cycle sustainment of the products. 3. ISO/IEC A combination of interacting elements organized to achieve one or more stated purposes. 4. United Kingdom Systems Engineering Handbook A homogeneous entity that exhibits predefined behavior in the real world and is composed of heterogeneous parts that do not individually exhibit that behavior and an integrated configuration of components and/or subsystems. 5. NASA Systems Engineering Handbook (1) combination of elements that function together to produce the capability to meet a need; (2) The end product (which performs operational functions) and enabling products (which provide life cycle supports services) that make up a system. 6. INCOSE An integrated set of elements to accomplish a defined objective.

159 SYS 101: Fundamentals of Systems Engineering Technical Foundations Definition of a System Review the definition of a 'system' shown in this graphic. There can be confusion as to just what the scope of a particular system entails and where its boundaries begin and end. This broad definition addresses this by explicitly defining the complete scope of all products needed to field an effective, usable and supportable system. The definition, based on ANSI/EIA 632, is the basis for the system model that is used in this course. It is also the basis for the DoD's Systems Engineering processes as described in the Defense Acquisition Guidebook (DAG). Select NEXT to continue. D Page 7 of 66

160 Long Description There is an image of a magnifying glass focused on the word 'System' and its definition: An aggregation of end products and enabling products to achieve a given purpose.

161 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model Constituents The notion behind this system model is that every system consists of: 1. One or more End Products that will perform the intended operational functions expected by the customer and be within the constraints set by other stakeholders 2. A set of Enabling Products that perform life cycle service functions required for the End Product to operate effectively Each End Product will have its unique and common set of Enabling Products that will enable the End Product to be designed, realized, deployed, operated, maintained and, when the End Product has finished its useful life, to be properly disposed. Enabling Products include training products that will enable the operators and maintainers of the operational End Products to perform their missions. Select NEXT to continue. D Page 8 of 66

162 Long Description Chart with System at the top and branching into End Products and Enabling Products. End Products perform operational functions and Enabling Products perform life cycle service functions.

163 SYS 101: Fundamentals of Systems Engineering Technical Foundations 'Product' Characterizations End Products and Enabling Products can be further characterized. End Product: o o o Defined by a customer need Performs the operational functions required by a customer Has '-ilities' designed in - Producibility, Testability, Trainability, Supportability, Disposability Enabling Product: o o o o o Defined as those products required to enable the End Product to be developed, produced, tested, deployed, utilized, supported and disposed of May need to be developed or may already exist and thus constrain the End Product Each End Product has its own set of Enabling Products Enabling Products are determined by End Product life cycle requirements Must be available to support End Product life cycle functions Select NEXT to continue. Page 9 of 66

164 Constrain For instance, the size and operation of nozzles and clamping devices used for air-to-air refueling have been standardized over many years within the Air Force and Navy tanker fleets. Existing aircraft use these nozzles and clamping designs. New aircraft must accommodate them as well. Similar considerations regarding so-called Ground Handling Equipment (GHE), used to service aircraft, may apply as well.

165 Examples of End Products An End Product can be: SYS 101: Fundamentals of Systems Engineering Technical Foundations 1. Self-contained in terms of its use and operations Examples: An aircraft, a tank, a submarine, a communications module or a satellite 2. Items that have no use outside a larger end product, but that are developed as an end product of a subsystem (lower-layer system building block) Examples: An engine or radio for an aircraft; a power train or braking system for a tank; switches or transducers for a communications module; a solar panel or transmitter for a satellite Select NEXT to continue. Page 10 of 66

166 SYS 101: Fundamentals of Systems Engineering Technical Foundations Examples of Enabling Products Enabling Products perform non-operational functions of the system. Some examples include: Development: Plans and schedules; engineering policies and procedures; automated tools, models, qualified engineering and management personnel Manufacturing: Policies and procedures; manufacturing facilities; jigs, special tools and equipment; production processes; manufacturing and procurement personnel Test: Test plans, policies and procedures; models and mockups; special tools and test equipment; test facilities and sites; simulation or analytical models; inspection procedures and test personnel An Enabling Product is illustrated here. Select NEXT to continue. Page 11 of 66

167 Enabling Product The F404-GE-400 engine, mounted on an engine test stand, is shown being tested by aviation maintenance personnel aboard the aircraft carrier, the USS George Washington. This test stand is an enabling product for both the engine end product as well as for the ultimate End Product, the F/A-18 Hornet jet fighter.

168 SYS 101: Fundamentals of Systems Engineering Technical Foundations Examples of Enabling Products, Cont. To continue with examples of generic of Enabling Products: Operations/Deployment: Plans, policies and procedures; packaging materials; storage facilities; special handling and transportation equipment; installation procedures; deployment instructions; and installation personnel Training/Utilization: Plans and schedules; simulators, training models; courses and materials; special training facilities and trainers Support: Policies and procedures; tools and repair equipment; support facilities and handling equipment; maintenance manuals; maintenance management systems; special diagnostic equipment; repair personnel Retirement: Plans, schedules and procedures; refurbishment facilities; disposal sites; equipment for disposal of spent products; disposal personnel Development of Enabling Products, if not already existing, is normally initiated only after their supported End Products are fully defined. Part of this definition, done as part of the Design Solution Process, results in the identification of the requirements for any needed Enabling Products. Select NEXT to continue. Page 12 of 66

169 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Which of the following statements about Enabling Products are correct? A. They perform the operational functions required by a customer. B. Except for minor differences, they are synonymous with End Products. C. They enable End Products to be realized and used. D. They may constrain the End Product in some way. E. None of these responses is correct. D. Yes! You understand some of the key differences between Enabling Products and End Products. Select Next to continue. Page 13 of 66

170 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Which of the following statements about End Products are correct? A. They have -ilities designed in. B. They enable Enabling Products to be realized and used. C. They perform the operational functions required by a customer. D. They are defined by customer need. E. All of these responses are correct. A, C, D. Yes! You understand the key differences between End Products and Enabling Products. Select Next to continue. Page 14 of 66

171 SYS 101: Fundamentals of Systems Engineering Technical Foundations End Product: Aircraft System Illustrated is an example of an End Product: an air vehicle with its typical subsystems and lower-level elements. Select NEXT to continue. D Page 15 of 66

172 Long Description The graphic is titled 'End Product'. It has an airplane in the middle and six bubbles around it. They are: Life Support Subsystem, Airframe Subsystem, Propulsion Subsystem, Weapons Subsystem, Flight Control Subsystem, and Navigation Subsystem. Navigation Subsystem branches out to Display Assembly and Global Positioning Receiver Assembly.

173 SYS 101: Fundamentals of Systems Engineering Technical Foundations Enabling Products: Aircraft System Shown here, these examples of Enabling Products for the air vehicle End Product encompass: Development Manufacturing Test Operations Support Retirement Note that some of these Enabling Products are facilities and equipment that can be seen as consisting of hardware and software. Also, notice that pilot training and flight planning software are included as well. Select NEXT to continue. D Page 16 of 66

174 Long Description Chart titled 'Enabling Products' with the following text boxes: Air Vehicle Development Products System Baselines System Interfaces Air Vehicle Manufacturing Products Plant Facilities Production Equipment Jigs and Fixtures Air Vehicle Test Products Test Facilities Test Plans Test Equipment Air Vehicle Operations Products Pilot Training Air Traffic Control Airport Facilities Flight Planning Air Vehicle Support Products Maintenance Refueling Equipment Nozzles Air Vehicle Retirement Products Resale Documents Disposal and Recycle

175 SYS 101: Fundamentals of Systems Engineering Technical Foundations Aircraft Generic System Model The aircraft End Product example can be translated into a hierarchical model. This hierarchical model, illustrated here, shows the relationships of the End Products and Enabling Products that were displayed in the previous two screens. Select NEXT to continue. D Page 17 of 66

176

177 Long Description Flowchart titled 'Model of Aircraft System.' Aircraft System consists of End Products and Enabling Products. The End Product is the Air Vehicle End Product, which consists of Airframe Subsystem, Propulsion Subsystem, Weapons Subsystem, Life Support Subsystems, Navigation Subsystem and Flight Control Subsystems. The Enabling Products are Development Enabling Products, Manufacturing and Test Enabling Products, Training Enabling Products, Maintenance Enabling Products and Other Enabling Products.

178 SYS 101: Fundamentals of Systems Engineering Technical Foundations Model of Aircraft Navigation Subsystem This aircraft system model can then be used to illustrate the relationships among elements of one of the subsystems. The Navigation Subsystem is modeled here. The Systems Engineering Technical Processes outlined in the Defense Acquisition Guidebook would be applied iteratively and recursively to these system model products to realize subsystem and system end products and enabling products needed to realize and sustain the desired system. Select NEXT to continue. D Page 18 of 66

179 Iteratively Iteratively refers to the continued application of a process to the same product or set of products to correct a discovered discrepancy or other variation from requirements.

180 Recursively Recursively refers to the repeated application of processes to design the next lower-layer system products or to realize upper-layer products within the system.

181

182 Long Description Flowchart titled 'Model of Aircraft System.' Aircraft System consists of End Products and Enabling Products. End Products consist of Air Vehicle End Product, which consist of Airframe Subsystem, Propulsion Subsystem, Weapons Subsystem, Life Support Subsystems, Navigation Subsystems and Flight Control Subsystems. Navigation Subsystems consist of Global Positioning Reference Subsystem, Display Subsystem, Radar Control Subsystem and Other Sensor Subsystems. Enabling Products consist of Development Enabling Products, Manufacturing & Test Enabling Products, Training Enabling Products, Maintenance Enabling Products and Other Enabling Products.

183 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Each of the following items could be an Enabling Product for an automobile except. Select the correct answer. A. Engine diagnostic system B. Disk brake adjustment tool C. Model repair manual D. Transmission Good job! The correct answer is D. The transmission is a subsystem of the drive train, which is part of the End Product (the automobile). All the other items are Enabling Products which are not actually part of an automobile End Product, but are nevertheless needed in some way for its effective use. Select Next to continue. Page 19 of 66

184 SYS 101: Fundamentals of Systems Engineering Technical Foundations Some Conventions Both 'end products' and 'enabling products' exist at various layers in the system structure. To distinguish them, the convention used in this course is to refer to them as follows: Rule 1: When referring to the realized products that are transitioned to the end user or to the next phase of the Defense Acquisition Framework, 'End Product' and 'Enabling Product' are capitalized. Rule 2: When referring to them generically as part of lower layers in the system structure, 'end product' and 'enabling product' are not capitalized. Rule 3: When in doubt, use Rule 1. Select NEXT to continue. Page 20 of 66

185 SYS 101: Fundamentals of Systems Engineering Technical Foundations Close-to-Home Example: System Model Let's illustrate this system model again, but now by using a much smaller, but close-to-home example...this course! This DAU online course consists of text and graphics on screens (pages). The screens are aggregated into topics, which make up lessons and in turn comprise this course. This particular course system model is established by DoD policy, an example of an Other Interested Party Requirement. End Products and Enabling Products exist at these different levels of this course structure. Select each product example below to learn more. Screen/Page Level Products Topic Level Products Lesson Level Products Course Level Products Select NEXT to continue. Page 21 of 66

186 Other Interested Party Requirement Other Interested Party Requirements include those of parties who have some interest in the system such as those providing life cycle support functions; OSD management or other government agencies; and laws, regulations, treaties, policies, etc., which may affect the program or project. The Advanced Distributed Learning (ADL) Initiative was formed as a developer and implementer of learning technologies across the Department of Defense. DAU on-line courses follow the structure established by ADL DoD-wide standards.

187 Screen/Page Level Products End Product: a screen comprised of text and any graphics included Enabling Products: subject-matter experts, course developers and instructional system designers; graphics artists; course software development environment; graphics tools; QA personnel; DAU course development standards and procedures

188 Topic Level Products End Product: topic consisting of screens with related subject matter Enabling Products: subject-matter experts, course developers; topic reviewers; course software integration environment; test procedures; topic-related Knowledge Reviews; QA personnel

189 Lesson Level Products End Product: lesson comprised of related topics Enabling Products: lesson exam test banks; exam grading software; lesson reviewers; Learning Management System (LMS) development and test environment; Key Terms file; Quick References file; course Configuration Management (CM) system

190 Course Level Products End Product: this course, composed of various lessons Enabling Products: Learning Management System (LMS) and IT infrastructure for course delivery; security software; DAU Help Desk personnel; DAU course instructors; course Help file; end-of-course survey software; course registration systems

191 System Model Uses SYS 101: Fundamentals of Systems Engineering Technical Foundations A system model allows for the uniform application of various Systems Engineering processes. For typically complex DoD systems, a system model's standardized nomenclature is key to facilitating communications and to helping ensure that all parts of the system are considered and addressed in a uniform way. Such a model can be used for: Planning and managing the Systems Engineering effort o o o o Identifying products to be engineered Assigning work packages Making cost estimates Assessing risks and opportunities Organizing IPTs and facilitating teamwork Orchestrating incremental reviews Defining and structuring specifications, including interfaces Creating system structure (level-by-level development and product realization) Identifying and developing enabling products Examples of these uses of a system model are provided on subsequent screens. Select NEXT to continue. Page 22 of 66

192 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Process Perspective The system model is the target of Systems Engineering Technical Processes. These are comprised of System Design Processes (Requirements Development, Logical Analysis and Design Solution) and Product Realization Processes (Implementation or Integration, Verification, Validation and Transition). Specifically: The three System Design Processes are initially used to fully define the system model in terms of Solution-Specified Requirements. The five Product Realization Processes are then used to generate (realize) the physical form of the end product consistent with its set of Solution-Specified Requirements. In conjunction with these Technical Processes, Systems Engineering Technical Management Processes are used for planning, assessing and controlling the technical effort used in designing the system and in realizing the End Product and its associated Enabling Products. Select NEXT to continue. D Page 23 of 66

193 Solution-Specified Requirements These are the requirements, specifications and/or other descriptive design documents that fully define system model elements (system, end product, subsystem and enabling product) at the completion of the application of the System Design Processes to that system model. They are expressed in System Specifications and Item Specifications.

194 Physical Form The physical form of an end product that is realized by application of the Product Realization Processes is dependent on the Defense Acquisition Framework phase in which the system model end product is realized and the phase exit criteria that must satisfied by the technical effort. In early phases of the Defense Acquisition Framework, the form may be digital as in a analytical report or simulation; a breadboard or brassboard; a scaled model or technology prototype. In later phases, the physical form may be in an engineering prototype or ultimately, the full scale, deployable product.

195

196 Long Description Chart titled 'Generic System Model.' System flows to End Product, which flows to Subsystems. System also flows to Development Enabling Products, Manufacturing & Test Enabling Products, Training Enabling Products, Maintenance Enabling Products and Other Enabling Products.

197 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Management Examples A system model identifies the products that need to be engineered or acquired to make up the 'system.' Such a model provides a structure for planning the Systems Engineering effort, for making cost estimates and for assigning work packages for each product in the model. The model also provides a uniform, consistent structure for identifying, analyzing and mitigating technical risks, as well as for understanding their interrelationships. The End Product illustrated by this system model is the main deliverable. It represents the product desired by the ultimate customer. Other product boxes (i.e., Enabling Products) will eventually be realized so that when available, they will make up the 'system.' The system and subsystems will also be described by appropriate Solution-Specified Requirements developed as outputs of top-down design processes. Select NEXT to continue. D Page 24 of 66

198 Work Packages A Work Package is a detailed, short-span task, identified by the performing contractor or an in-house IPT for accomplishing work required to complete a project. EIA Standard 748, Earned Value Management System, formally adopted by the DoD in 1999, defines a work package as: "A task or set of tasks performed within a cost control account."

199 End Product Defined by a customer need Performs the operational functions required by a customer Has '-ilities' designed in - Producibility, Testability, Trainability, Supportability, Disposability, etc.

200 Enabling Products Defined as those products required to enable the End Product to be developed, produced, tested, deployed, utilized, supported and disposed of May need to be developed or may already exist and thus constrain the End Product Each End Product has its own set of Enabling Products Enabling Products are determined by End Product life cycle requirements Must be available to support End Product life cycle functions

201 Realized Realization provides the physical design solution in a product form suitable for meeting the applicable acquisition phase exit criteria, including product verification and validating and transitioning the product to the next level up of the system structure or to the customer.

202

203 Long Description Chart titled 'Generic System Model.' System flows to End Product, which flows to Subsystems. System also flows to Development Enabling Products, Manufacturing & Test Enabling Products, Training Enabling Products, Maintenance Enabling Products and Other Enabling Products.

204 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Work Products One of the important work products resulting from system model definition is the set of requirements for the various Enabling Products which will be needed to provide life cycle support services to the End Product. Acquisition activities may mandate use of existing Enabling Products or in some cases, require development of unique products. If so, these Enabling Products will be developed, realized and managed using the same Systems Engineering Processes that were used for the supported End Product but now are applied to a separate system model for the appropriate Enabling Product(s). Examples of other work products that arise from defining the system model include: requirements baselines; configuration baselines; decision analysis recommendations and impacts; decisions made, including assumptions, technical plans, work packages, technical reports, effectiveness assessments and risk status. Some of these work products are delivered to the customer while others are interim products used mainly by the developer; but all of them should be appropriately captured and retained in a designated program or project technical data management database. Select NEXT to continue. Page 25 of 66

205 Work Products A work product is any artifact - material or electronic - generated during the conduct of the activities and tasks of a process, including the desired outputs.

206 Technical Data Management Database The program's technical management database, its adequacy and protection, among other areas, is a key aspect of Technical Data Management. One of the Systems Engineering Technical Management Processes, the Technical Data Management Process is the disciplined processes and systems used to plan for, acquire, access, manage, protect and use data of a technical nature to support the total life cycle of the system.

207 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Teamwork and IPTs In the DoD environment, where Integrated Product Teams (IPTs) and the use of Integrated Product and Process Development (IPPD) are key 'best practices,' the system model can also provide a basis for forming and assigning Core Teams and IPTs so that they operate most effectively. For example, the illustrated System Core Team would be responsible for initial planning to develop their system model and for assigning IPTs to the products at the second level of the model. An end product team could be the leaders from their respective subsystem teams. An enabling product team would include individuals representing their respective functional disciplines. This process continues, and a subsystem team could become the core team for the next lower-layer subsystem and its end and enabling products. Select NEXT to continue. D Page 26 of 66

208 Integrated Product and Process Development (IPPD) Integrated Product and Process Development (IPPD) is a management technique that simultaneously integrates all essential acquisition activities through the use of multidisciplinary teams to optimize design, manufacturing and supportability processes. IPPD facilitates meeting cost and performance objectives. One of the key IPPD tenets is multidisciplinary teamwork through Integrated Product Teams (IPTs).

209 System Core Team A System Core Team is usually composed of the project technical manager, along with members to be assigned to team lead positions on end product and associated process teams.

210

211 Long Description A flowchart titled, 'System Model Used for Assuring Teamwork.' System Core Team flows to End Product IPT, which then flows to two Subsystem Core Team boxes. System Core Team also flows to Development & Integration Product IPT, Production Product IPT, Test Product IPT, Operations Product IPT and Logistics Products IPT.

212 SYS 101: Fundamentals of Systems Engineering Technical Foundations Teamwork and IPTs Using a system model, each Integrated Product Team is given a product element to develop and performs required Systems Engineering activities. Using this approach, each model element can have a dedicated IPT assigned. This IPT will be able to deal with an unambiguously defined work package regarding what is to be accomplished. Each IPT is responsible for: Planning their work Making cost estimates related to their work and the product Doing the work described in the team's approved work package Identifying and managing the risks and opportunities associated with the development of the product, including interfaces with other products in the model Select NEXT to continue. D Page 27 of 66

213

214 Long Description A flowchart titled, 'System Model Used for Assuring Teamwork.' System Core Team flows to End Product IPT, which then flows to two Subsystem Core Team boxes. System Core Team also flows to Development & Integration Product IPT, Production Product IPT, Test Product IPT, Operations Product IPT and Logistics Products IPT.

215 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Incremental Reviews Another advantage of using a system model is its use for efficient structuring of various In-Progress Reviews (IPRs) that can be conducted in preparation for more formal major systems-level Technical Reviews. The graphic illustrates several generic examples of such reviews. Select the four boxes in the top row of the graphic to learn more about the ways in which these reviews can be used. Select NEXT to continue. D Page 28 of 66

216 Technical Reviews The Technical Management Process, Technical Assessment, measures technical progress and the effectiveness of plans and requirements. An important component of Technical Assessment is the use of Technical Reviews. Technical Reviews are an important oversight tool. They are used to review and evaluate the state of the system and the program, redirecting activity after the review, if found necessary. Technical Reviews are key decision events used to measure technical progress and maturity in system development as well as to assess various programmatic issues. Technical Reviews are summarized as part of Chapter 4 of the Defense Acquisition Guidebook (DAG). Additionally check out the DAU Continuous Learning Module (CLM) on Technical Reviews available here.

217 Subsystem Reviews This type review can be presented by the Subsystem IPT/Core Team for the purpose of giving the status of the subsystem development and its readiness to initiate development. The status of interface definitions, software development and any other critical or high-risk areas are special considerations of this type review.

218 Enabling Product Readiness Reviews The purpose is to demonstrate that the enabling product s requirements are defined and ready for initiating development, either by applying Systems Engineering Processes to the system model or by the acquisition of already available enabling products.

219 End Product Reviews Once the system model Subsystem and Enabling Product Reviews have been satisfactorily completed, End Product Reviews can be held. The purpose is to provide confirmation that the End Product has been adequately defined to approve initiation of development of Enabling Products and Subsystems system models.

220 System Review A formal system-level review (Technical Review) is typically associated with the top-level system model in the system structure or for an identified critical end product (e.g. engine, weapon, or computer) that makes up the system-level End Product (e.g. an aircraft, tank or satellite). These system-level reviews should be held after satisfactory completion of the relevant corresponding Technical Reviews at the subsystem level of the system model. These types of reviews should be called out in the program s Systems Engineering Plan (SEP). Examples include the Initial Technical Review (ITR); Alternative Systems Review (ASR); System Requirements Review (SRR); System Functional Review (SFR); Preliminary Design Review (PDR); Critical Design Review (CDR); Test Readiness Review (TRR); Production Readiness Review (PRR); System Verification Review (SVR); the In-Service Review (ISR); and audits such as the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA).

221 Long Description Flowchart titled 'System Model Used for Life Cycle Reviews.' Subsystem Reviews flows to Enabling Product Readiness Reviews, which then flows to End Product Reviews, which flows to System Review. System Review flows to End Product Review, which then flows to Subsystem Reviews. System Review also flows to Development and Integration Product Review, Production Product Review, Test Product Review, Operations Product Review and Logistics Products Review.

222

223 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Structuring Specifications An essential part of developing system models is the creation of various program-unique specifications (large programs may have thousands of these!), including related interface specifications. Program-unique specifications define requirements for each system model element, while interface specifications define interfaces between and among system model elements and external system products. Specification standards for the DoD are described in MIL-STD 961, Defense and Program-Unique Specifications Format and Content and include the following generic categories: System Specification Performance Specification Detail Specification Item Specification Software Specification More information about MIL-STD 961 is available via Quick References. Select NEXT to continue. Page 29 of 66

224 Program-Unique Specifications These describe a system, item (e.g., End Product), software program, process or material developed and produced (including repetitive production and spares purchase) for use within a specific program, or as part of a single system and for which there is judged to be little potential for use by other systems.

225 Interface Specifications These describe physical form and fit interfaces, human interfaces (human-to-machine and human-to-human), electronic interfaces, logical or functional interfaces, etc. among various elements of a system model or products external to the system model that interact or have a potential to interact with or impact each other. They may be defined via an Interface Control Document (ICD).

226 System Specification This is a type of program-unique specification that describes the requirements and verification of the requirements for a combination of elements that must function together to produce the capabilities required to fulfill a mission need, including hardware, equipment and software.

227 Performance Specification This is a specification that states requirements in terms of the required results with criteria for verifying compliance, but without stating the methods for achieving the required results. A Performance Specification defines the functional requirements for the item (e.g., End Product), how well it must perform that function, the environment in which it must operate and interface and interchangeability characteristics.

228 Detail Specification A Detail Specification specifies design requirements, such as materials to be used, how a requirement is to be achieved or how an item is to be fabricated or constructed.

229 Item Specification This is a type of program-unique specification that describes the form, fit and function and method for acceptance of end products (e.g., parts, components and other items that are elements of a system model).

230 Software Specification This is a type of program-unique specification that describes the requirement and its verification for the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission or reception of data or information.

231 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Development Consistency To simplify the development of a system and to make Systems Engineering Processes easier to apply, IPTs must operate the same way at each level of the system structure. Their operation should be consistent, regardless of whether they're developing the top-level system model or the lowest system model within the structure. Illustrated is the conceptual relationship between a higher system model and a set of lower system models--one for each subsystem of the higher system model. This abstraction makes it easier for team members to work consistently on any size system, at any level of the system structure or in any life cycle phase. The only differences expected are in the complexity of the product, the methods and tools used and the scope of the problems that must be solved. Select NEXT to continue. D Page 30 of 66

232

233 Long Description A flowchart titled, 'System Model Used for System Structure Development.' System flows to End Product, which also flows to Subsystems. System also flows to Development & Integration Products, Production Products, Test Products, Operations Products and Logistics Products.

234 SYS 101: Fundamentals of Systems Engineering Technical Foundations System Model: Enabling Products This approach also applies to Enabling Products. Each system model will have its own dedicated set of Enabling Products. Enabling products vary. For example, at the lowest layer such enabling products as jigs, fixtures, Computer Numeric Controlled (CNC) machine tool programs and software products such as compilers may be critical. At the ultimate End Product level, these Enabling Products are the one the users in the field will need to effectively use, maintain and support and dispose of the End Product. Enabling Products that require development (e.g., do not already exist) will have their own system structure developed using System Design Technical Processes. Select NEXT to continue. D Page 31 of 66

235 Enabling Products Defined as those products required to enable the end product to be developed, realized, tested, deployed, utilized, supported and retired May need to be developed or already exist and thus may constrain the end product Each end product has its own set of enabling products Enabling products are determined by end product life cycle requirements Must be available to support end product life cycle functions

236 Compilers A compiler is a complex software tool that translates computer programs (source code) into machine language that can be executed by a computer.

237

238 Long Description A graphic with three flowcharts titled, 'System Model Used for Enabling Product Development.' The first flowchart begins with System, which flows to End Product, which then flows to two Subsystems. System also flows to Development & Integration Products, Production Products, Test Products, Operations Products and Logistics Products. From Production Product, an arrow points to a new flowchart. Flowchart #2 begins with System, which flows to End Product, which then flows to two Subsystem boxes. System also flows to Development & Integration Products, Production Products, Test Products, Operations Products and Logistics Products. From Logistics Products in Flowchart #1, an arrow points to a new flowchart. Flowchart #3 begins with System, which flows to End Product, which then flows to two Subsystem boxes. System also flows to Development & Integration Products, Production Products, Test Products, Operations Products and Logistics Products.

239 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review A system model can be used to assist in. Select the correct answer. A. Orchestrating incremental reviews B. Structuring IPT team assignments C. Developing specifications D. All of the above. D. All of the above. That's correct! The generic system model is used for all of these functions. Select Next to continue. That is not correct. The correct answer is D. The generic system model is used for all of these functions. Select Next to continue. Page 32 of 66

240 SYS 101: Fundamentals of Systems Engineering Technical Foundations What is a Work Breakdown Structure? A Work Breakdown Structure (WBS) is a productoriented family tree composed of hardware, software, services, data and facilities. A 'program' WBS displays and defines the product(s) to be developed and/or produced by the program. It relates the elements of work to be accomplished to each other and to the End Product. The WBS is used to generate initial cost estimates and program plans and to support Contracting and Reporting. It can also be used to help create a program schedule. At one time, WBS formats and system structures were mandated within the DoD via a prescriptive Military Standard. That standard has been replaced by a Military Handbook (MIL-HDBK- 881A), which provides specific guidance on WBS usage. Within the DoD, a WBS is the most common way that a system model is formally documented. Select NEXT to continue. Page 33 of 66

241 SYS 101: Fundamentals of Systems Engineering Technical Foundations WBS: 'Program' vs. 'Contract' Linkage The Program WBS relates the elements of work to each other and to the End Product. In the DoD, the Program WBS is extended to a Contract WBS that defines the relationships between the elements of the program and corresponding elements of the contract work statement. The Contract WBS provides the reporting structure used for DoD contract management. Used in this way, the WBS becomes the common framework that consistently links program and technical planning, cost estimating, resource allocation, performance measurement, technical assessment and status reporting. Use of a WBS that follows MIL-HDBK-881A is required by DoD policies for such key programmatic items as the Contract Performance Report (CPR), Integrated Master Schedule (IMS) and Contractor Cost Data Report (CCDR). MIL-HDBK-881A also includes several appendices that illustrate WBSs for a variety of defense system categories. These provide an initial WBS that must be further tailored and extended to generate a complete, program-specific system model. Additionally, some agencies provide more explicit guidance on WBS structures to be used for their agency-specific products via regulations that supplement the WBS handbook. More information about the WBS as well as a WBS Continuous Learning Module (CLM) is available via Quick References. Select NEXT to continue. Page 34 of 66

242 Program WBS More formally, the Program WBS defines the program in terms of hierarchically related, product-oriented elements and includes 'other Government elements' (i.e., Program Office Operations, Manpower, Government Furnished Equipment (GFE) and Government Testing). Each element provides logical summary levels for assessing technical accomplishments, supporting the required event-based technical reviews and for measuring cost and schedule performance. [MIL-HDBK-881A].

243 Contract WBS More formally, the Contract WBS is the government-approved WBS for program reporting purposes and includes all product elements (hardware, software, data or services) which are the contractor's responsibility. It includes the contractor's discretionary extension to lower levels, in accordance with Government direction and the Contract Statement of Work (SOW). [MIL-HDBK-881A].

244 Contract Performance Report (CPR) The CPR provides contract cost and schedule performance data that is used to identify problems early in the contract and forecast future contract performance. The CPR is the primary means of documenting the ongoing communication between the contractor and the program manager to report cost and schedule trends to date and to permit assessment of their effect on future performance. A CPR (DD Form 2734) should be used on all cost or incentive contracts, subcontracts, intra-government work agreements and other agreements valued at or greater than $20 million.

245 Integrated Master Schedule (IMS) The IMS is a calendar-based schedule containing the networked, detailed tasks necessary to ensure successful program/contract execution. The IMS is traceable to the Integrated Master Plan (IMP), the Cntract Work Breakdown Structure (WBS), and the Statement of Work. The IMS is used to verify attainability of contract objectives, to evaluate progress toward meeting program objectives, and to integrate the program schedule activities with all related components. An IMS should be used on all cost or incentive contracts, subcontracts, intragovernment work agreements and other agreements valued at or greater than $20 million. The IMS is applicable to development, major modification, and Low-Rate Initial Production efforts; it is not typically applied to Full-Rate Production efforts. It is also not normally required for contracts valued at less than $20 million, contracts less than 12 months in duration, or Firm-Fixed Price contracts, regardless of dollar value.

246 Contractor Cost Data Report (CCDR) The CCDR is the primary means within the Department of Defense to systematically collect data on the development and production costs incurred by contractors in performing DoD acquisition program contracts. Additionally, existing CCDR data from historical programs is used to make parametric cost estimates for future acquisition programs. CCDR reporting is required by DoD policy for certain categories of programs having specific cost thresholds. The Defense Cost and Resource Center (DCARC) is the OSD office responsible for administering the CCDR system. Because of its sensitivity, access to CCDR data is restricted.

247 Defense System Categories The categories of defense systems documented in MIL-HDBK-881A include: Aircraft System: Applies to fixed or movable wing, rotary wing or compound wing manned air vehicles designed for powered or unpowered (i.e., glider) guided flight. Electronic/Automated Software System: Applies to electronic, automated or software system capability. Missile System: Applies to a missile in an operational environment which produces a destructive effect on selected targets or has the capability for launching space systems. Ordnance System: Applies to all munitions (nuclear, biological, chemical, psychological and pyrotechnic) and the means of launching or firing them. Sea System: Applies to surface and submersible ship platforms, systems, weapons and equipment required for performing naval tasks at sea. Space System: Applies to developing, delivering and maintaining mission payloads in specific orbit placement, operation and recovery of manned and unmanned space systems. Surface Vehicle System: Applies to navigation over the surface. Unmanned Air Vehicle: Applies to fixed or movable wing, rotary wing or compound wing unmanned air vehicles designed for powered or unpowered (glider) guided flight.

248 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Which of the following statements about a Work Breakdown Structure (WBS) is correct? A. It is a product-oriented family tree composed of hardware, software, services, data and facilities. B. It is used to consistently link program and contracting reporting activities. C. It is a distinct product not at all related to a system model. D. Use of the WBS is mandated by a prescriptive military standard. A, B. Correct! You understand some of the key characteristics of a WBS. Select Next to continue. Page 35 of 66

249 SYS 101: Fundamentals of Systems Engineering Technical Foundations An Engineering 'V' Model A system structure based on a hierarchy of system models provides the basis for both Top-Down System Design and Bottom-Up Product Realization. Concurrently with this Top-Down Design and Bottom-Up Realization, the Enabling Products for each system are being defined and developed or acquired so that they will be available when needed. When arranged in the fashion shown here, it is referred to as a 'V' Model for obvious reasons. Select NEXT to continue. Page 36 of 66

250 Top-Down System Design System Design Processes (Requirements Development, Logical Analysis and Design Solution) are applied to each system model in the system structure. Upper system models must be fully defined and appropriate Technical Reviews successfully completed in order to be able to start development of a lower-layer system model. This application of System Design Processes continues until all system model end products can be built (or coded), bought or reused/off-the-shelf and are ready for realization.

251 Bottom-Up Product Realization At the point when end products are ready for realization, Product Realization Processes (Implementation or Integration, Verification, Validation and Transition) are applied to each end product from the bottom up, realizing the design solution for that end product. An end product obtained from the Implementation Process is then verified, validated and transitioned for assembly and integration into its parent system model end product which in turn is verified, validated and transitioned. This sequence continues until the desired system-level End Product is realized. This sequence occurs in each of the Defense Acquisition Framework phases with the realized End Product used to provide information to satisfy necessary phase exit criteria and transitioned between phases. Ultimately, End Products are produced and transitioned to operational customers and end users.

252

253 SYS 101: Fundamentals of Systems Engineering Technical Foundations An Engineering 'V' Model, Cont. While technical processes along the 'V' are illustrated in a linear or serial sequence, it is important to understand that they do not necessarily have to start in the strict illustrative sequence depicted. But to be effective, they ultimately must finish in that order. A similar 'V' format, but with verification and validation linkages drawn between the legs of the 'V,' can be used to structure application of Systems Engineering processes in the context of the Defense Acquisition Framework. It is used to help ensure that required technical exit and entry criteria associated with each phase of the life cycle are met. Examples are available at 'The Chart'. Select NEXT to continue. Page 37 of 66

254

255 SYS 101: Fundamentals of Systems Engineering Technical Foundations The 'V' - Going Down! Illustrated here is a macro-view of generic outputs from Technical Process activities. The left side of the 'V' represents various design activities 'going down' the system V. Generated for each system model on the left side of the 'V' are: Sets of end product specifications and design descriptions Verification and Validation plans later used to determine realized product compliance with specifications (Verification) and Stakeholder Requirements (Validation) Initial specifications that become the flowdown requirements for the next lower system model development Select NEXT to continue. D Page 38 of 66

256

257 Long Description Chart titled 'The V - A Macro View.' The left side of the 'V' includes: Generate System- Level End Product Specification & Verification & Validation Plans, Generate Subsystem- Level End Product Specifications & Verification & Validation Plans, Generate Lower- Level End Product Specifications & Verification & Validation Plans, Generate Lowest- Level End Product Specifications & Verification & Validation Plans. The right side of the 'V' includes: Assemble & Integrate System-Level End Product & Verify & Validate, Assemble & Integrate Subsystem-Level End Products & Verify & Validate, Assemble & Integrate Next-Level Up End Products & Verify & Validate, Implement Lowest-Level End Products & Do Verification & Validation.

258 SYS 101: Fundamentals of Systems Engineering Technical Foundations The 'V' - Coming Up! Shown here, the right side of the 'V' represents various bottom-up Product Realization activities 'coming up' the system 'V' for each end product. Generated for each end product on the right side of the 'V' are: Implemented or assembled and integrated end products for the corresponding system model as per the left side of the "V" Product Verification results conducted according to the plan(s) generated during design of the end product Product Validation results conducted according to the plan(s) generated during design of the end product Realized products which are transitioned to the next layer of the model for assembly and integration or ultimately, for End Product use Select NEXT to continue. D Page 39 of 66

259

260 Long Description A chart titled 'The V - A Macro View.' The left side of the 'V' includes: Generate System-Level End Product Specification & Verification & Validation Plans, Generate Subsystem-Level End Product Specifications & Verification & Validation Plans, Generate Lower-Level End Product Specifications & Verification & Validation Plans, Generate Lowest-Level End Product Specifications & Verification & Validation Plans. The right side of the 'V' includes: Assemble & Integrate System-Level End Product & Verify & Validate, Assemble & Integrate Subsystem-Level End Products & Verify & Validate, Assemble & Integrate Next-Level Up End Products & Verify & Validate, Implement Lowest-Level End Products & Do Verification & Validation.

261 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Which of the following statements about the application of the Systems Engineering 'V' Model are correct? A. It addresses both End Products and Enabling Products. B. Verification and Validation Plans are generated as part of Bottom-Up Product Realization activities. C. It can be used to structure Systems Engineering activities within the context of the phases of the Defense Acquisition Framework. D. It generates specifications that are flowed down as requirements for lower system models. E. It generates realized End Products that ultimately get transitioned to the user. A, C, D, E. Great! All are correct except response B. Response B is incorrect because Verification and Validation plans are generated as part of the top-down development and are exercised during bottom-up product realization. Select NEXT to continue. Page 40 of 66

262 SYS 101: Fundamentals of Systems Engineering Technical Foundations The 'V': Top-Down Design In a Top-Down System Design, the same Systems Engineering Design Technical Processes (Requirements Development, Logical Analysis and Design Solution) are applied to each system model in the system structure. Feedback (iteration) can occur among the three System Design Processes being applied to any one system model. For example, Logical Analysis or Design Solution activities may discover technical problems not identified by a prior process. If so, prior processes may need to be reaccomplished, including possible reinvolvement of stakeholders. Feedback can also occur between a lower system model and its parent model. In some instances, System Design activities may uncover technical problems that will require resolution (e.g., clarification or modification of requirements, changes in system architecture, etc.) at an upper level system model. Select NEXT to continue. D Page 41 of 66

263

264 Long Description A flowchart titled 'Top Down System Design.' Top Down Design begins with Stakeholder Requirements, which flows to three boxes titled 'System End Products Definition,' which flow to Subsystem Detailed Designs.

265 SYS 101: Fundamentals of Systems Engineering Technical Foundations The 'V': Bottom-Up Realization Once the products of all system models have been fully defined, Bottom-Up End Product Realization can be initiated. This begins by applying the Implementation Process to buy, build, code or reuse end products. These implemented end products are verified against their design descriptions and specifications, validated against Stakeholder Requirements and then transitioned to the next higher system model for integration. End products from the Integration Process are successively integrated upward, verified and validated, transitioned to the next acquisition phase or transitioned ultimately as the End Product to the user. Select NEXT to continue. D Page 42 of 66

266 Realization Realization refers to providing the physical design solution in a product form suitable for meeting the applicable Defense Acquisition Framework phase exit criteria, including product verification and validating and transitioning the product to the next level up of the system structure or to the customer.

267

268 Long Description Flowchart titled, 'Bottom Up Realization.' Four processes flow to the other and are each labeled Realization Processes/Subsystem Detailed Designs.

269 SYS 101: Fundamentals of Systems Engineering Technical Foundations Systems Engineering and Recursion Recursion is the repeated application of the same Technical Processes to either: (1) successively lower system models within the system structure or (2) to end products at successively higher levels of the system structure. For example, on the right side of the graphic two system models with a parent-child (systemsubsystem) relationship are illustrated. Top-Down System Design Processes (i.e., Requirements Development, Logical Analysis and Design Solution) are first applied to the parent system model. Then, based on the flow-down of subsystem initial specifications to the child system model, the same set of three processes get applied to the child system model. This recursion occurs at each system model within the system structure. Select NEXT to continue. D Page 43 of 66

270

271 Long Description Chart titled 'Recursive Application of System Design Processes'. Requirements Development Process flows to Logical Analysis Process to Design Solution Process to Requirements Development Process to Logical Analysis Process to Design Solution Process.

272 SYS 101: Fundamentals of Systems Engineering Technical Foundations Systems Engineering and Iteration Iteration is the re-application of processes already applied to a system model based on feedback indicating a problem that needs resolution. On the right side of the illustrative graphic are two system models with a parent-child relationship. In this case, the three system design processes (i.e., Requirements Development, Logical Analysis and Design Solution) are first applied to the system model. As technical difficulties such as unacceptable risk, infeasible technology or a requirement conflict are discovered, these must be resolved via process reapplication. This must be done before finalizing the design solution of the end product and subsequently flowing down specifications for the subsystems at the layer below. Select NEXT to continue. D Page 44 of 66

273

274 Long Description Flowchart that begins with Requirements Development Process to Logical Analysis Process to Design Solution Process. These are iterative loops and are applied to System Model (Layer N). A second flow begins with Requirements Development Process to Logical Analysis Process to Design Solution Process. These are iterative loops and are applied to Subsystem System Model (Layer N+1).

275 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Which of the following statements is true? Select the correct answer. A. The design of systems should be accomplished from the bottom up so as to capture all components. B. Realization of system model end products should be accomplished from the bottom up so as to find and correct problems at the lowest possible level. C. Realization of a system should be from the top down so as to develop requirements in a logical order. D. None of the above is true. B. Good job! You know that systems should be realized from the bottom up to find and correct problems at the lowest possible level. Select Next to continue. Page 45 of 66

276 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review The Logical Analysis Technical Process has been completed on a portion of the XYZ system. However, an in-progress review of the work products indicated that many Technical Requirements were not adequately considered in development of the functional architecture. Consequently, a decision was made to redo Logical Analysis using these additional missing Technical Requirements. This is an example of. A. Process Recursion B. Process Iteration C. Both Process Recursion and Iteration C. Neither Process Recursion nor Iteration B. Correct! You understand a key aspect of process iteration, which is basically keep doing it until you get it right! Select NEXT to continue Page 46 of 66

277 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review The Design Solution Technical Process has nearly been completed on the XYZ system. As a result, Derived Technical Requirements were discovered that pertain to one of the XYZ proposed subsystems, Subsystem ABC. These have resulted in the initiation of the Requirements Development process for subsystem ABC. Meanwhile, Technical Process activities continue at the XYZ system level. This is an example of. A. Process Recursion B. Process Iteration C. Both Process Recursion and Iteration D. Process Incursion A. Correct! You understand a key aspect of process recursion, which is basically keep doing it until you re done! Select NEXT to continue Page 47 of 66

278 SYS 101: Fundamentals of Systems Engineering Technical Foundations Close-to-Home Example: Top-Down Design Let's return to our example (this course!) again. The earlier 'Close-to-Home' example discussed the DAU course system model. Now we illustrate some of the System Engineering processes that were used during its creation, starting with top-down design processes... Acquirer Requirements and Other Party Requirements were analyzed as course Stakeholder Requirements via the Requirements Development Process. Additional Derived Requirements were also identified. Technical Requirements were ultimately developed and became the basis for course design. The Logical Analysis Process evaluated several ways to partition the course technical requirements into various lessons. Learning objectives were allocated to lesson topics accordingly. Ultimately, a course architecture was selected, and a course allocated baseline established. Design Solution evaluated various designs for the physical architecture of the course. Several lesson prototypes were developed and evaluated to assist in choosing the final physical architecture. Requirements and various work products (e.g., course design documents) were developed and baselined as the Solution-Specified Requirements for the course. Select NEXT to continue. Page 48 of 66

279 System Model DAU online courses consist of lessons, which are aggregations of subject-matter related topics. In turn, topics are comprised of screens (pages), which consist of text and typically, graphics.

280 Acquirer Requirements Acquirer Requirements for DAU courses are established by the acquisition workforce Functional Advisor (FA). The FA is assisted by a Functional Integrated Product Team (FIPT) comprised of Service and agency career field representatives. Among other duties, the FIPT establishes career field competencies. For this course, 126 competencies were established as the course functional baseline.

281 Other Party Requirements Some of these included DoD-mandated standards for course structure; provisions for accessibility in accordance with Section 508 legislation; and Information Assurance and software security requirements, among others.

282 Derived Requirements Further analysis of the career field competencies revealed the need for several additional ones to adequately cover particular areas. These were submitted to the FIPT and re-baselined accordingly.

283 Allocated Baseline For this course, the allocated baseline is essentially the topic learning objectives for each lesson/topic. They are traceable to the functional baseline (career field competencies).

284 Technical Requirements These are traceable to the learning objectives for each topic that you see listed on the second screen throughout the course.

285 SYS 101: Fundamentals of Systems Engineering Technical Foundations Close-to-Home Example: Bottom-Up Realization Screens (pages) were implemented: text was developed, some graphics were reused and others were newly created. Screens were coded using a distance learning course development system (an enabling product). As part of implementation, screens were verified. Collections of screens were integrated into topics, verified again and then integrated into lessons and ultimately, a course. As part of the Verification Process, the course was verified via various Quality Assurance checks as well as an Instructor Pilot. As a result, necessary changes were made (i.e., the Requirements Development, Logical Analysis and Design Solution processes were iterated accordingly). The course and its work products were rebaselined. As part of the Validation Process, a Student Pilot was held to validate the course against workforce needs. Additional revisions were identified and made, and the final course product baseline (the course you are taking) was established. The course was transitioned from its development environment to the DAU Learning Management System (called ATLAS) and made available to the acquisition workforce. Voila! A course...multiply the above by about 10,000, and you have a typical DoD system. Nevertheless, this example illustrates that Systems Engineering Processes scale up and down quite easily. That is the whole point of consistent processes used in conjunction with a well-defined system model...they can be used at any point within the system structure for a wide variety of systems...from this lowly course to something as complex as an aircraft carrier or a theater-level command and control system! Select NEXT to continue. Page 49 of 66

286 SYS 101: Fundamentals of Systems Engineering Technical Foundations Defense Acquisition Framework The 5000-series of DoD publications specifies acquisition policies and procedures to be applied within the context of the Defense Acquisition Framework (DAF). DAF phase entry and exit criteria determine the maturity of the system under development and whether it is ready to proceed (or transition) to the next acquisition phase. Whatever technical work needs to be done is governed by acquisition phase criteria as well as the information needed by a Milestone Decision Authority (MDA) to make decisions on continued system development, use or retirement. The 'V' Model described previously is a good metaphor to understand and describe key Systems Engineering activities performed by both the 'acquirer' (the DoD) as well as the 'developer' (typically defense contractors) associated with each phase of the acquisition framework. Select NEXT to continue. D Page 50 of 66

287

288 Long Description A chart titled 'Defense Acquisition Management Framework.' From Technology Opportunities & User Needs, there are three arrows pointing to three triangles labeled A, B and C (Program Initiation). Under these triangles there are five boxes: Concept Refinement, Technology Development (Pre-Systems Acquisition), System Development & Demonstration, Production & Deployment (Systems Acquisition) and Operations & Support (Sustainment). At the bottom of the graphic there is a line labeled 'Relationship to Requirements Process.' There are three documents listed for this process: Initial Capabilities Document (ICD) (Formerly MNS), Capabilities Development Document (CDD) (Formerly part of ORD), Capabilities Production Document (CPD) (Formerly part of ORD). At the top right of the graphic is the following information: Process entry at Milestones A, B or C; Entrance criteria met before entering phase; Evolutionary Acquisition or Single Step to Full Capability; IOC: Initial Operational Capability; FOC: Full Operational Capability; FRP: Full Rate Production.

289 SYS 101: Fundamentals of Systems Engineering Technical Foundations The 'V' - DAF Viewpoint In early phases of the Defense Acquisition Framework (DAF), the work products describing the end products will be less detailed than would be expected later when End Product design solutions would be realized into actual production articles. Likewise, the end products implemented and assembled and integrated on the right side of the 'V' Model will take different forms. Select NEXT to continue. D Page 51 of 66

290

291 Long Description V-chart titled 'The V -- A Macro View.' The left side of the 'V' includes: Generate System-Level End Product Specification & Verification & Validation Plans, Generate Subsystem-Level End Product Specifications & Verification & Validation Plans, Generate Lower-Level End Product Specifications & Verification & Validation Plans, Generate Lowest-Level End Product Specifications & Verification & Validation Plans. The right side of the 'V' includes: Assemble & Integrate System-Level End Product & Verify & Validate, Assemble & Integrate Subsystem-Level End Products & Verify & Validate, Assemble & Integrate Next-Level Up End Products & Verify & Validate, Implement Lowest-Level End Products & Do Verification & Validation.

292 SYS 101: Fundamentals of Systems Engineering Technical Foundations The 'V' - DAF Viewpoint, Cont. For example, early life cycle stage end products may include analytical reports, simulation results, and feasibility studies based on analytical models, breadboards, brassboards, scaled physical models, or prototypes. During later life cycle stages, the end products would take the form of a final engineering prototype or a production representative article or ultimately, the deliverable End Product. While the realized products differ, it is important to understand that, independent of DAF phase, the same Systems Engineering processes are used throughout the life cycle. 'V' Model examples, tailored by acquisition phase, are summarized on subsequent screens. Select NEXT to continue. D Page 52 of 66

293 Breadboards A breadboard is an experimental device (or group of devices) used to determine feasibility and to develop technical data. Normally, it will be configured for laboratory use only to demonstrate the technical principles of immediate interest. It may not resemble the end item and is not intended for use as the projected end item.

294 Brassboards A brassboard is an experimental device (or group of devices) used to determine feasibility and to develop technical and operational data. Normally, it will be a model sufficiently hardened for use outside of laboratory environments to demonstrate the technical and operational principles of immediate interest. It may resemble the end item, but is not intended for use as the end item.

295 Prototypes Prototypes are originals or models on which a later system or item is formed or based.

296

297 Long Description V-chart titled 'The V -- A Macro View.' The left side of the 'V' includes: Generate System-Level End Product Specification & Verification & Validation Plans, Generate Subsystem-Level End Product Specifications & Verification & Validation Plans, Generate Lower-Level End Product Specifications & Verification & Validation Plans, Generate Lowest-Level End Product Specifications & Verification & Validation Plans. The right side of the 'V' includes: Assemble & Integrate System-Level End Product & Verify & Validate, Assemble & Integrate Subsystem-Level End Products & Verify & Validate, Assemble & Integrate Next-Level Up End Products & Verify & Validate, Implement Lowest-Level End Products & Do Verification & Validation.

298 SYS 101: Fundamentals of Systems Engineering Technical Foundations Overview: Concept Refinement During the Concept Refinement (CR) phase, activities are focused on trade studies to develop outputs (specifically a preliminary System Specification) to prepare for passage into the next phase. The System Specification describes the requirements and how they will be verified for a combination of elements to produce the capabilities required to fulfill a mission need. Additional outputs are identification of critical and enabling technology areas that require maturation efforts during the next phase, an overall technical risk assessment and an initial Systems Engineering Plan (SEP). Modeling and Simulation (M&S) will be used extensively during this phase. For a description of these activities, click here. To see these life cycle activities in the context of 'The Chart,' click here. Select NEXT to continue. D Page 53 of 66

299 Systems Engineering Plan (SEP) The Systems Engineering Plan (SEP) is a detailed formulation of actions that should guide all technical aspects of an acquisition program. Program Managers and project Lead/Chief Systems Engineers should establish the SEP early in program formulation and update it at each subsequent milestone. It is intended to be a living document, tailored to the program, and a roadmap that supports program management by defining comprehensive Systems Engineering activities, addressing both government and contractor technical activities and responsibilities. The SEP should incorporate known industry 'best practices' and be used by the Program Office to help frame contractual technical requirements. The SEP is updated for each acquisition phase.

300

301 Long Description A chart titled 'Concept Refinement Phase.' Boxes are labeled 'inputs' or 'outputs.' Inputs begins with ICD, AoA Plan, Exit Criteria, Alternative Maintenance & Logistics Concepts, Interpret User Needs, Analyze Operational Capabilities & Environmental Constraints, Develop Concept Performance & Constraints, Definition & Verification of Objectives, Decompose Concept Performance Into Functional Definition & Verification Objectives, Decompose Concept Functional Definition Into Concept Components & Assessment Objectives, Develop Component Concepts, i.e., Enabling Critical Technologies, Constraints & Cost/Risk Drivers. Then begins the outputs: Analyze/Assess Enabling/Critical Components Versus Capabilities, Analyze/Assess System Concept Versus Functional Capabilities, Assess/Analyze Concept & Verify System Concept's Performance, Analyze/Assess Concepts Versus Defined User Needs & Environmental Constraints. The final outputs are Preliminary System Specifications, T&E Strategy, SEP, Support & Maintenance, Concept & Technologies, Inputs to draft CDD, TDS, AoA, Cost/Manpower Estimate.

302 SYS 101: Fundamentals of Systems Engineering Technical Foundations Overview: Technology Development During the Technology Development (TD) phase, efforts focus on continued trade studies and analyses working toward a final System Specification, risk analysis of key and enabling technologies and risk assessments related to their maturation. Key outputs of this phase include such products as a final System Performance Specification, demonstration of technology maturity from analyses and test results, program technical risk assessment and a Test and Evaluation Master Plan (TEMP). For a description of these activities, click here. To see these life cycle activities in the context of 'The Chart,' click here. Select NEXT to continue. D Page 54 of 66

303 Test and Evaluation Master Plan (TEMP) The Test and Evaluation Master Plan (TEMP) is an important document in that it contains the required type and amount of test and evaluation events, along with their resource requirements. The TEMP focuses on the overall structure, major elements and objectives of the T&E program and must be consistent with the Systems Engineering Plan (SEP).

304

305 Long Description A chart titled 'Technology Development Phase.' Boxes are labeled 'inputs' or 'outputs.' Inputs begins with ICD & Draft CDD, Preferred System Concept, Exit Criteria, T&E Strategy, Support & Maintenance Concepts & Technologies, AoA, SEP, TDS, Interpret User Needs, Analyze Operational Capabilities & Environmental Constraints, Develop System Performance & Constraints Spec & Enabling Critical Tech Verification Plan, Develop Functional Definitions for Enabling Critical Technologies & Associated Verification Plan, Decompose Functional Definitions into Critical Component Definition & Tech Verification Plan, Develop System Concepts, i.e., Enabling Critical Technologies, update Constraints & Cost/Risk Drivers. Then begin the outputs: Demo Enabling Critical Technology Components Versus Plan, Demo System Functionality Versus Plan, Demo/Model Integrated System Versus Performance Spec, Demo & Validate System Concepts & Technology Maturity Versus Defined User Needs, System Performance Specifications, LFT&E Waiver Request, TEMP, SEP, PESHE, PPP, TRA, Validated System Support & Requirements, Footprint Reduction, Inputs to IBR, ISP, STA, CDD (Acquisition Strategy), Affordability Assessment and Cost/Manpower Estimates.

306 SYS 101: Fundamentals of Systems Engineering Technical Foundations Overview: System Development and Demonstration During the System Development and Demonstration (SDD) phase, both preliminary design and critical design activities occur. This culminates in products designed down to the lowest level of the system model. These products are implemented and tested and then assembled, integrated and ultimately tested back up to the top system model level. The outputs of this phase include not only the prime mission product (the End Product) such as a vehicle, aircraft or ship, but also the training, logistic support and other supporting Enabling Products needed to deploy, employ and operate the mission products. Outputs also include the manufacturing enabling products and procedures needed for limited and/or full-rate production as well as the initial Product Baseline. Select NEXT to continue. D Page 55 of 66

307 Product Baseline The Product Baseline is the approved technical documentation or work product (e.g., Technical Data Package, including specifications, drawings, software code, interface control documents, related materials) that describes a Configuration Item (CI) during the production, fielding/deployment and operational support phases of its life cycle.

308

309 Long Description Chart titled 'System Development & Demonstration Phase.' Inputs: System Performance Specification, Exit Criteria, Validated Sys Support & Maintenance Objectives & Requirements (APB, CDD, SEP, ISP, TEMP), Interpret User Needs, Refine System Performance Specs & Environmental Constraints, Develop System Functional Specs & System Verification Plan, Evolve Functional Performance Specs into CI Functional (Design to) Specs and CI Verification Plan, Evolve CI Functional Specs into Product (Build to) Specs and CI Verification Plan, Fabricate Assemble Code to 'build to' Documentation. Outputs: Individual CI Verification (DT&E), Integrated DT&E, LFT&E & EOAs Verify Performance Compliance to Specs, System DT&E, LFT&E OAs Verify System Functionality & Constraints Compliance to Specs, Combines DT&E/ OT&E/LFT&E, Demonstrate System to Specified User Needs & Environmental Constraints, Initial Product Baseline, Test Reports (TEMP), Elements of Product Support, Risk Assessment (SEP, TRA, PESHE), Inputs to CPD, STA, ISP (Cost/Manpower Est.).

310 SYS 101: Fundamentals of Systems Engineering Technical Foundations Overview: System Development and Demonstration, Cont. Key among SDD outputs are numerous program-unique specifications. Generic types of these are: Item Specifications Detail Specifications Other outputs include the initial production baseline, various risk and readiness assessments, product support assessments and test reports. A variety of Technical Reviews, performed as part of the Technical Assessment Process, occur during SDD. Among these reviews are the System Requirements Review (SRR), the System Functional Review (SFR), the Preliminary Design Review (PDR) and the Critical Design Review (CDR). For a description of these activities, click here. To see these life cycle activities in the context of 'The Chart,' click here. Select NEXT to continue. D Page 56 of 66

311 Item Specifications These describe the form, fit and function and method for acceptance of end products (parts, components and other items that are elements of a system model).

312 Detail Specifications These specify design requirements, such as materials to be used, how a requirement is to be achieved or how an item is to be fabricated or constructed.

313 Technical Assessment Process One of the Systems Engineering Technical Management Processes, the Technical Assessment Process measures technical process and the effectiveness of various technical plans and requirements and monitors progress against those plans.

314 System Requirements Review (SRR) The SRR is a multifunctional technical review to ensure that all system and performance requirements derived from the Capability Development Document are defined and consistent with cost (budget), schedule (program schedule), risk and system constraints. The SRR ensures consistency between the system requirements and the preferred system solution and available technologies.

315 System Functional Review (SFR) The SFR assesses the system functional requirements as captured in system specifications (functional baseline) and ensures that required system performance is fully decomposed and defined in the functional baseline. The SFR determines whether the system functional definition is fully decomposed to a low level, and whether to start preliminary design.

316 Preliminary Design Review (PDR) The PDR is a multidisciplinary technical review to ensure that the system under review can proceed into detailed design and can meet the stated performance requirements within cost (program budget), schedule (program schedule), risk and other system constraints. The PDR assesses the system preliminary design as captured in performance specifications for each Configuration Item in the system (allocated baseline), and ensures that each function in the functional baseline has been allocated to one or more system Configuration Items.

317 Critical Design Review (CDR) The CDR is a multidisciplinary technical review to ensure that the system under review can proceed into system fabrication, demonstration, and test; and can meet the stated performance requirements within cost (program budget), schedule (program schedule), risk and other system constraints. The CDR assesses the system final design as captured in product specifications for each configuration item in the system (product baseline), and ensures that each product in the product baseline has been captured in the detailed design documentation.

318

319 Long Description Chart titled 'System Development & Demonstration Phase.' Inputs: System Performance Specification, Exit Criteria, Validated Sys Support & Maintenance Objectives & Requirements (APB, CDD, SEP, ISP, TEMP), Interpret User Needs, Refine System Performance Specs & Environmental Constraints, Develop System Functional Specs & System Verification Plan, Evolve Functional Performance Specs into CI Functional (Design to) Specs and CI Verification Plan, Evolve CI Functional Specs into Product (Build to) Specs and CI Verification Plan, Fabricate Assemble Code to 'build to' Documentation. Outputs: Individual CI Verification (DT&E), Integrated DT&E, LFT&E & EOAs Verify Performance Compliance to Specs, System DT&E, LFT&E OAs Verify System Functionality & Constraints Compliance to Specs, Combines DT&E/ OT&E/LFT&E, Demonstrate System to Specified User Needs & Environmental Constraints, Initial Product Baseline, Test Reports (TEMP), Elements of Product Support, Risk Assessment (SEP, TRA, PESHE), Inputs to CPD, STA, ISP (Cost/Manpower Est.).

320 SYS 101: Fundamentals of Systems Engineering Technical Foundations Overview: Production and Deployment During the Production and Deployment (P&D) phase, Low-Rate Initial Production (LRIP) units are constructed using the processes and tools planned for final production. Early LRIP units are also used for final validation of the product in the form of Operational Test and Evaluation (OT&E) in the user environment. Activities also include ramp-up to full-rate production and delivery to, installation at and training of the first receiving organizations. This phase validates the manufacturing processes and confirms that End Products are being produced in accordance with the specified manufacturing processes. A final production baseline is established. For a description of these activities, click here. To see these life cycle activities in the context of 'The Chart,' click here. Select NEXT to continue. D Page 57 of 66

321

322 Long Description Chart titled 'Production and Deployment Phase.' Under OTR, Independent IOT&E has an arrow that points to BLRIP Report to Congress. Full-up System Level LFT&E has an arrow that points to LFTE Report to Congress. There is also JITC Interoperability Certification Testing and J-6 Interoperability & Supportability Validation. At the bottom of the chart is Inputs/Outputs flow. Inputs: Test Recruits, Exit Criteria, APB, CPD, SEP, TEMP, Product Support Package, Analyze Deficiencies to Determine Corrective Actions, Modify Configuration (Hardware/Software/Specs) to Correct Deficiencies, Verify & Validate Production Configuration, Production Baseline, Test Reports, TEMP, PESHE, SEP, Input to Cost/Manpower Est.

323 SYS 101: Fundamentals of Systems Engineering Technical Foundations Overview: Operations and Support Once deployed, the End Products must be supported until disposal. Activities in the Operations and Support (O&S) phase include monitoring service use data to determine and correct any problems with the End Products. Systems Engineering-related outputs from this phase include recommendations for modifications and engineering changes in response to discovered problems, safety issues, obsolescence, changes in threat or mission or technology refreshment. Support of disposal or retirement activities may also be needed if there have been changes in environmental laws and/or a need to modify the disposal Enabling Products and/or procedures. For a description of these activities, click here. To see these life cycle activities in the context of 'The Chart,' click here. Select NEXT to continue. D Page 58 of 66

324

325 Long Description Flowchart titled 'Operations and Support Phase.' Inputs: Service Use Data, User Feedback, Failure Reports, Discrepancy Reports, SEP, Monitor and Collect All Service Use Data, Analyze Data to Determine Root Cause, Determine System Risk/Hazard Severity, Develop Corrective Action. Outputs: Integrate & Test Corrective Action, Assess Risk of Improved System, Implement and Field, Input to CDD for Next Increment, Modifications/Upgrades to Fielded Systems, SEP.

326 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Efforts are focused on continued trade studies working toward a final system specification and maturation of key technologies during the phase. Select the correct answer. A. Technology Development B. Concept Refinement C. System Development and Demonstration D. Operations and Support A. Great! You know some of the characteristics of the Technology Development phase. Select Next to continue. Page 59 of 66

327 SYS 101: Fundamentals of Systems Engineering Technical Foundations Knowledge Review Which phase has outputs that include validation of the manufacturing processes and confirmation that End Products are being manufactured in accordance with the specified manufacturing processes? Select the correct answer. A. Production and Deployment B. Operations and Support C. Concept Refinement D. System Development and Demonstration A. Great. You know some of the outputs of the Production and Deployment phase. Select Next to continue. Page 60 of 66

328 Process Useability SYS 101: Fundamentals of Systems Engineering Technical Foundations The use of Systems Engineering processes adds value to acquisition projects, whether they are complex, large developments or small, simple ones. But the application of Systems Engineering processes is not limited to these types of situations. The processes can also be applied in 'novel' ways. In this context, Systems Engineering can be thought of as a set of disciplined and coherent management techniques useful whenever a technical problem needs to be solved. An example of such a novel application of Systems Engineering processes is shown in this illustration. An ongoing effort has been underway to revitalize DoD Modeling and Simulation (M&S). The cornerstone of the project was the development of a DoD Acquisition M&S Master Plan. The illustration demonstrates how the Systems Engineering process was tailored by the plan developers to ensure the master plan was developed in a disciplined way traceable to the DoD's top-level requirements. Select NEXT to continue. D Page 61 of 66

329

330 Long Description The flowchart is titled 'Systems Engineering Process Applied to DoD M&S Master Plan Development'. Diagonally down the left side, DoD M&S Strategic Vision feeds into Derived Needs and CONOPS. Once reviewed, these, along with Studies, feed into Evaluate Findings and Define Framework. Once reviewed, this feeds into Specified Needed Actions. Once reviewed, this feeds into Publish C&CC Business Plan: Framework, Business Process and Metrics. The flowchart begins upward on the right side with Implement: Project Proposals, Influence Policy; Shape Other Activities. This feeds into Deliverables Evaluation, then Integration, then Impact Validation. The result is the DoD M&S Master Plan. A line labeled Measures of Effectiveness runs between the boxes, Derived Needs and CONOPS and Impact Validation. A line labeled Allocated Functions and Interfaces runs between the boxes Evaluate Findings and Define Framework and Integration. A line labeled Measures of Performance runs between the boxes Specify Needed Actions and Deliverables Evaluation. An arrow spans upward on the left side of the flowchart. It is labeled Feedback and Traceability.

331 SYS 101: Fundamentals of Systems Engineering Technical Foundations Review of Objectives System: An aggregation of End Products and Enabling Products that achieves a given purpose Products: A 'system' consists of a wide variety and large number of different products. Categories of such products include: End Products, which actually perform the intended operational functions of the system Enabling Products, which are those products that must be available to enable the End Product to be developed and supported over its life cycle Realization: For each end product design solution, provides a product in a form suitable for meeting the applicable Defense Acquisition Framework phase exit criteria, including verification and validation and transitioning the product to the parent system model for integration into another end product or to the customer. Select NEXT to continue. Page 62 of 66

332 SYS 101: Fundamentals of Systems Engineering Technical Foundations Review of Objectives, Cont. Role of Systems Models: In order to unambiguously describe various Systems Engineering processes and activities as well as provide a framework for their application, a system model is used. Such models are useful for: Planning and managing the Systems Engineering effort o o o o Identifying products to be engineered Assigning work packages Making cost estimates Assessing risks and opportunities Organizing IPTs and facilitating teamwork Orchestrating incremental Technical Reviews Defining and structuring specifications, including interfaces Creating system structure (level-by-level development and product realization) Enabling product identification and development Work Breakdown Structure (WBS): Is a product-oriented family tree composed of hardware, software, services, data and facilities. MIL-HDBK-881A provides details on use of a WBS to include illustrative WBSs for a variety of defense system categories. Within the DoD, a WBS is the most common way that a system model is formally documented. Select NEXT to continue. Page 63 of 66

333 Review of Objectives, Cont. SYS 101: Fundamentals of Systems Engineering Technical Foundations Iteration and Recursion: Are key concepts in the application of Systems Engineering processes Iteration: The re-application of processes already applied to a system model based on feedback indicating a problem that needs resolution Recursion: The repeated application of the same Technical Processes to either successively lower system models within the system structure or to end products at successively higher levels 'V' Model: Is a structure based on a hierarchy of layered systems models which provides the basis for Top-Down System Design and Bottom-Up Product Realization Top-Down System Design: System Design Processes are applied to each 'system model' of the system structure. Upper system models must be fully defined and appropriate Technical Reviews successfully completed in order to be able to start development of a lower system model. This application of System Design Processes continues until all system model end products can be built (or coded), bought, or reused/off-the-shelf and are ready for realization. Bottom-Up Product Realization: At the point when end products are ready for realization, Product Realization Processes are applied from the bottom up to realize the design solution for that end product. An end product obtained from the Implementation Process is then verified, validated and transitioned for assembly and integration into its parent system model end product which in turn is verified, validated and transitioned. This sequence continues until the desired system-level End Product is realized. Select NEXT to continue. Page 64 of 66

334 SYS 101: Fundamentals of Systems Engineering Technical Foundations Review of Objectives, Cont. Specifications: A key part of Systems Engineering involves the development and management of various specifications. The system model aids in understanding which products and their interfaces need to have specifications as outputs of the System Design Processes. MIL-STD 961, Defense and Program-Unique Specification Format and Content, is the DoD specification standard. It defines generic categories of specifications as: System Specification, Performance Specification, Detail Specification, Item Specification and Software Specification. Defense Acquisition Framework: The 5000-series of DoD publications specifies acquisition policies and processes to be applied within the context of the Defense Acquisition Framework (DAF). DAF phase entry and exit criteria are used for determining the maturity of the system under development and whether it is ready to proceed (or transition) to the next acquisition phase. The 'V' Model can be used to structure Systems Engineering activities by DAF life cycle phase. Outputs from each phase are used to develop information as to continued system development, production and deployment, use or retirement. Select NEXT to continue. Page 65 of 66

335 Review of Objectives, Cont. SYS 101: Fundamentals of Systems Engineering Technical Foundations Summary of key Systems Engineering activities by defense acquisition phase include: Concept Refinement (CR) Phase: Is focused on trade studies to develop key outputs (e.g., preliminary System Specification) for passage into the next phase. Technology Development (TD) Phase: Continued trade studies and analyses working toward a final System Specification, risk analysis of key and enabling technologies, and risk assessments related to their maturation. System Development and Demonstration (SDD) Phase: Preliminary design and critical design activities, which culminate in an intial Product Baseline. Products are implemented, integrated and verified to that baseline in actual products. Production and Deployment (P&D) Phase: Low-Rate Initial Production (LRIP) units are constructed using the processes and tools planned for final production. LRIP units are also used for initial product validation. Activities also include ramp-up to full-rate production and delivery to the first receiving organizations. Operations and Support (O&S) Phase: Includes monitoring of service use data to determine and correct any problems with the End Products being used. Support of disposal or retirement activities may also be needed. You have reached the end of this topic. To proceed, select the exam for this topic in the Table of Contents. Page 66 of 66

336 SYS 101: Fundamentals of Systems Engineering Technical Foundations Exam Technical Foundations Exam Page X of Y

337 SYS 101: Fundamentals of Systems Engineering Essential Considerations Essential Considerations This topic discusses key DoD policies and some of the various 'best practices' that are essential to the effective use of Systems Engineering in the DoD.

338 Contents of Topic Approximate Length: 30 minutes SYS 101: Fundamentals of Systems Engineering Essential Considerations Topic Description: A variety of essential design and implementation considerations, based on 'best practices' and DoD policies, influence system development. They must be considered in the application of Systems Engineering processes. Some of these considerations are outlined in this topic. They include: the Systems Engineering Plan; Robust Systems Engineering; Modular Open System Architectures; Evolutionary Acquisition; and Ethics. Others, including 'Important Design Considerations,' are discussed in the Defense Acquisition Guidebook (DAG) and also are available via Quick References. Select NEXT to continue. Page 1 of 23

339 SYS 101: Fundamentals of Systems Engineering Essential Considerations Topic Learning Objectives Listed below are the objectives for this topic: Summarize the role of a Systems Engineering Plan Describe Robust Systems Engineering Explain Modular Open Systems Architectures Summarize uses of Modeling & Simulation Outline how Evolutionary Acquisition is used Recognize ethical issues Select NEXT to continue. D Page 2 of 23

340 Long Description Flipchart with the following objectives: Summarize the role of the Systems Engineering Plan Describe Robust Systems Engineering Explain Modular Open Systems Architectures Summarize uses of Modeling & Simulation Outline how Evolutionary Acquisition is used Recognize ethical issues

341 SYS 101: Fundamentals of Systems Engineering Essential Considerations Role of the Systems Engineering Plan Effective Systems Engineering is critical to the successful development of defense systems. Within the DoD, a variety of initiatives have been implemented to increase overall Systems Engineering capabilities and instill more discipline into the conduct of Systems Engineering. One of these initiatives is the use of a Systems Engineering Plan (SEP) by all programs. The emphasis is not so much on the format or existence of a SEP, but on the actual thinking, captured in the SEP, about how Systems Engineering will be effectively employed. A SEP is prepared by the Program Management Office and is one of the expected outcomes of the Technical Planning Process. While the developer typically will produce a much more technically detailed plan, sometimes called a Systems Engineering Management Plan (SEMP), the SEP is a distinct government product. Ultimately the SEP, as it evolves, should be reflective of the contractor's proposed processes as well. Select NEXT to continue. Page 3 of 23

342 Developer Although the 'developer' as cited here is reflective of industry, in some situations the DoD is both the 'acquirer' and the 'developer'. The same Systems Engineering processes apply, including the importance of a SEP, no matter what role is being filled!

343 Systems Engineering Planning The initial Systems Engineering Plan (SEP) is prepared early in the acquisition life cycle. The SEP must be updated periodically, at least for each new phase of development or within phases, if needed. The level of fidelity and emphasis in the SEP will naturally evolve and be aligned more closely to the developer s more detailed processes as the program progresses. Program SEPs are formally assessed during milestone reviews. The SEP should include assignment of responsibilities to specific organizations. This allows for early identification of adequate capabilities and skill sets that will be needed to accomplish effective Systems Engineering for the program. Once developed, the SEP must be used, including used to help frame contractual requirements. The Program Office should carefully monitor SEP execution and adjust as necessary. SYS 101: Fundamentals of Systems Engineering Essential Considerations More detailed information about the SEP and other Systems Engineering policies and initiatives is available in the Quick References section. Select NEXT to continue. Page 4 of 23

344 Formally Assessed Key assessment areas evaluated at milestone reviews include the SEP's completeness in addressing the following areas: What are the technical issues? Who has responsibility and authority for managing the technical issues? What processes and tools will be used to address the technical issues? How will those processes be managed and controlled? How is that technical effort linked to the overall management of the program?

345 SYS 101: Fundamentals of Systems Engineering Essential Considerations Contracting for Systems Engineering Part of effective Systems Engineering includes motivating contractors to perform better Systems Engineering as well as making appropriate levels of technical management investments. Contracting considerations include: Formally evaluating Systems Engineering during the source selection process Assessing a contractor's Systems Engineering past performance and demonstrated process maturity level as part of source selection considerations Using various contract types (e.g., incentive or award fees) to promote Robust Systems Engineering Additionally, the government s SEP should be included as part of each Request for Proposal (RFP). More information about contracting appears in the Quick References section. Select NEXT to continue. Page 5 of 23

346 Knowledge Review True or False? SYS 101: Fundamentals of Systems Engineering Essential Considerations The Systems Engineering Plan is first required at program initiation at Milestone B. Select the correct answer. A. True B. False B. Great job! The Systems Engineering Plan is first required at Milestone A. Select Next to continue. Page 6 of 23

347 SYS 101: Fundamentals of Systems Engineering Essential Considerations Rules for Robust Flying An insight as to what is meant by the term 'Robust Systems Engineering' is to consider analogies to the following humorous (but true!) "Rules for Robust Flying" found posted anonymously in a aircraft squadron ready room: Regarding flying near the edges of the flight envelope: 1. Try to stay in the middle of the air. 2. Do not go near the edges of it. 3. The edges of the air can be recognized by the appearance of ground, buildings, sea, trees and interstellar space. It is much more difficult to fly there. Using this analogy, a key step to effective use of Robust Systems Engineering is understanding the 'flight envelope' of the system being developed. Select NEXT to continue. Page 7 of 23

348 SYS 101: Fundamentals of Systems Engineering Essential Considerations What is Robust Systems Engineering? Robust Systems Engineering is the use of disciplined Systems Engineering processes in conjunction with robust product design. Robust Systems Engineering should be used when developing designs for systems that have critical operational performance envelopes---a characteristic of most DoD systems. A robust design is a flexible and adaptable one that is tolerant of end product failure points and/or operating conditions. In robust design, errant excursions outside the operating 'flight envelope' of an end product do not necessarily result in catastrophic consequences. During system design, failure modes and limits of end products are predicted. The resultant design solution should ensure that adequate margins of error for safety and survivability become an inherent part of product design. Select NEXT to continue. Page 8 of 23

349 Failure Modes and Limits An example of such a limit would be the predicted point and conditions of end product mechanical failure. A robust design would include a sensitivity analysis to ensure that catastrophic consequences do not occur within a suitable margin of error at that predicted point and for those conditions.

350 SYS 101: Fundamentals of Systems Engineering Essential Considerations Robust Design Architectures Robust Systems Engineering also helps to generate flexible and adaptable designs. This is particularly important for DoD systems. Many of these systems have extremely long service lives, yet must continue to be effective as technology and threats change around them. Use of Modular Open System Architectures--- key to flexible and adaptable designs---is another characteristic of robust Systems Engineering. Modular design and use of Open System Architectures potentially allow for straightforward replacement of critical modules in response to changing threats, new technology or technology obsolescence, or for different mission profiles. Select NEXT to continue. Page 9 of 23

351 SYS 101: Fundamentals of Systems Engineering Essential Considerations Modular Design Modular designs offer the potential for allowing critical end products to be replaced with different ones, ones that have equivalent interfaces but which have improved or better functionality. Over time, this allows for more flexible and timely product upgrades. Modular designs can also help to minimize total life cycle support costs. A necessary pre-condition to enabling a modular design is ensuring that like functions are appropriately grouped together (partitioned) as part of the Logical Analysis Process activities in creating a functional architecture. Such a functional partitioning is driven by technical considerations of maximizing cohesion while attempting to minimize coupling. Later on, these functional groupings are then synthesized into modular design elements during the Design Solution Process. Ideally, these modules should have single entry/exit points that are separately testable. Interfaces are also defined during Logical Analysis and refined in Design Solution. Some of these interfaces will be of particular interest and so identified as Key Interfaces. Modular designs, along with the identification of Key Interfaces, are prerequisites for effective use of 'Open System Architectures.' Select NEXT to continue. Page 10 of 23

352 Logical Analysis Process One of the Systems Engineering Technical Processes, the Logical Analysis Process yields sets of logical solutions that improve understanding of requirements and their relationships. Using these logical solutions, performance parameters and constraints are allocated, and Derived Technical Requirements to be used for the system design are defined.

353 Functional Architecture This is an arrangement of functions and their subfunctions and interfaces (internal and external) that defines the execution sequencing, conditions for control or data flow and the performance requirements to satisfy the requirements baseline.

354 Cohesion Cohesion is a measure of the degree of encapsulation of only similar functions within a module.

355 Coupling Coupling is a measure of the number of dependent interfaces among entities.

356 Design Solution Process One of the Systems Engineering Technical Processes, the Design Solution Process is used to transform the outputs of the Logical Analysis Process into a set of design solutions that are described by specifications and other design configuration descriptions.

357 Key Interfaces A DoD-unique term, the DoD defines a Key Interface as a common boundary of 'interest' shared between system modules. Key Interfaces are those that provide access to critical data, information, materiel or services; and/or are of high interest due to rapid technological change, a high rate of failure, or costliness of connected modules; or are important from an interoperability or net-centric standpoint. Some Key Interfaces are candidates for implementation via Open Systems.

358 SYS 101: Fundamentals of Systems Engineering Essential Considerations What is an Open System Architecture? An Open System Architecture (OSA) is appropriate for some module interfaces. An OSA uses commercial or non-proprietary (i.e., open system) standards for selected Key Interfaces. Potentially, this allows multiple vendors to implement different modules which may be totally different internally, but which externally function equivalently in their parent system End Product. The DoD defines an Open System as one which: Is based around a modular design, and Uses widely supported and consensus-based ('open') standards for its key interfaces, and Successfully verifies and validates the openness of these interfaces The use of Open System standards for Key Interfaces may imply that a variety of open system commercial products with adequate capabilities and performance are available. Because of a wider customer base, these 'open' products may in many instances be cheaper and more supportable than equivalent custom-designed ones. Select NEXT to continue. Page 11 of 23

359 Standards The DoD Architecture Framework (DoDAF) is mandated for use within the DoD. The DoDAF is used to formally document a program's operational, system and technical architectures via a series of highly-formatted 'views'. One of the technical architecture 'views' (TV-1) is a profile of those technical standards, implementation conventions, standards options, rules and criteria that will be used for a system. An extensive collection of DoD endorsed IT-related standards (many of them are open standards) has been created for programs to consider using. Those that are appropriate are incorporated into that program's technical architecture. Previously documented in the Joint Technical Architecture (JTA), this collection of standards is now part of the online Defense Information Standards Repository System (DISRonline). More information about the DoDAF and the DISRonline is available in Quick References.

360 Open Systems and MOSA Other advantages of Open System designs are that they: SYS 101: Fundamentals of Systems Engineering Essential Considerations Better adapt to evolving requirements and threats Promote easier technology transition Facilitate system integration efforts Contribute to a 'robust' design Reduce development time and life cycle costs Enhance interoperability, reuse and supportability Provide better access to cutting-edge technologies Mitigate technology obsolescence and single-supplier risks The DoD's Modular Open System Approach (MOSA) is a business and technical strategy that can facilitate effective Open System usage. More information about MOSA is available in Quick References. Select NEXT to continue. Page 12 of 23

361 SYS 101: Fundamentals of Systems Engineering Essential Considerations Knowledge Review Which of the following statements about Robust Systems Engineering and Open Systems are correct? A. Key aspects of Robust Systems Engineering include robust design and use of Modular Open System Architectures. B. Enablers for effective use of Open System Architectures are a modular design and the identification of Key Interfaces. C. The DoD has mandated the use of open systems standards for all external system interfaces. D. The Logical Analysis Process and the Design Solution Process play important roles in modular design. E. Considerations for effective functional partitioning include maximizing coupling and minimizing cohesion. A, B, D. That s right! Select Next to continue. Page 13 of 23

362 SYS 101: Fundamentals of Systems Engineering Essential Considerations Modeling and Simulation (M&S) A model is a 'physical,' mathematical or logical representation of an system entity, phenomenon, process or end product. A simulation is the manipulation of that model. Modeling and Simulation (M&S) can be effective Systems Engineering tools across the life cycle. It is not uncommon for hundreds of different M&S assets to be used on a major program. Some examples of M&S usage include: Using M&S to explore concept alternatives, reliability, availability, maintainability, transportability, human-machine interfaces and estimate life cycle sustainment costs Using modeling environments provided by Systems Engineering tools, Computer-Aided Design (CAD), etc. to better manage complexity, increase design quality and improve productivity Helping to answer questions about the probability of meeting requirements for system performance Selective use as part of the verification and possibly, the validation processes During production, using M&S to make the manufacturing process more efficient Predicting maintenance and repair levels anticipated during system operation Within such M&S broad usage categories, programs should specifically define the planned use of M&S. The SEP is a key place where the M&S strategy should be outlined. Select NEXT to continue. Page 14 of 23

363 SYS 101: Fundamentals of Systems Engineering Essential Considerations Acquisition Approaches Acquisition approaches, chosen by the acquirer and formally documented in the system's overall Acquisition Strategy, determine how a total system (hardware, software, people and facilities) is 'put together'. The Acquisition Approach is the foundation for systems planning. Three generic types of acquisition approaches commonly used for DoD systems include: Grand Design: Sometimes referred to as a 'Once-Through,' 'Linear-Sequential' or 'Single-Step to Full Capability' strategy, this is the acquisition, development and deployment of the total functional capability of the system in a single, sometimes very massive effort. This approach is not generally recommended! Incremental: This is a phased approach that builds a system in pre-planned increments. Provisions for interfaces and accessibility are integrated into the system design. It is sometimes referred to as 'Pre-Planned Product Improvement, P3I'. Evolutionary Acquisition (EA): This approach builds and fields core portions of a system, selectively evolving it through phased upgrades. Evolutionary Acquisition, originally developed for software-intensive systems, is the preferred DoD strategy for system development, whenever it is appropriate. Select NEXT to continue. Page 15 of 23

364 Acquisition Strategy The Acquisition Strategy is the business and technical management approach designed to achieve program objectives within the resource constraints that are imposed. It is the framework for planning, directing, contracting for and managing a program. It provides a master schedule for research, development, test, production, fielding, modification, post-production management and other activities (including the acquisition approach) essential for program success. The acquisition strategy is the overarching basis for formulating functional plans and strategies (e.g., Test and Evaluation Master Plan (TEMP), Acquisition Plan (AP), competition, Systems Engineering Plan (SEP), various Design Considerations, etc.).

365 SYS 101: Fundamentals of Systems Engineering Essential Considerations Evolutionary Acquisition Evolutionary Acquisition, the preferred approach for all DoD projects where appropriate, is particularly suited for the software-intensive and IT-dominated Systems-of-Systems prevalent in the DoD today. Evolutionary Acquisition is a strategy in which: An initial core capability is fielded. A modular, open and robust system architecture is used. The fielded core capability is expanded based on user feedback. The expansion typically results in successively more capable blocks or increments. Provisions in the system's Modular Open System Architecture are made so that subsequent, timely upgrades can be made as requirements evolve. Select NEXT to continue. D Page 16 of 23

366 Systems-of-Systems (SoS) A SoS is a set or arrangement of interdependent systems that are related or connected together to provide a given capability. The loss of any part of the system will generally significantly degrade the performance or capabilities of the whole.

367

368 Long Description A diagram titled 'Evolutionary Acquisition versus Linear-Sequential Acquisition.' The linear-sequential acquisition process consists of Requirements, Design, Code & Unit Test, Integrate & Deploy and Support. The Evolutionary Acquisition process consists of Requirements Development, Experimentation, Risk Reduction, Market Analysis, etc. There are three small charts (Incr 1, Incr 2, Incr 3) that read: Design, Code & Unit Test, Integrate & Deploy. They all flow to Support.

369 SYS 101: Fundamentals of Systems Engineering Essential Considerations Knowledge Review Which of the following describe Evolutionary Acquisition? A. It is the acquisition, development and deployment of the total functional capability of a system in a single effort. B. Its success depends on the use of a modular, open and robust system architecture. C. It builds and fields core portions of a system by selectively evolving it through phased upgrades. D. It is particularly suited for software-intensive and IT-dominated systems. B, C, D. Great! You know some of the key characteristics of Evolutionary Acquisition. Select Next to continue. Page 17 of 23

370 SYS 101: Fundamentals of Systems Engineering Essential Considerations Knowledge Review Which of the following is characteristic of Open Systems Architectures (OSAs)? Select the correct answer. A. They are not related to 'robust' system design. B. They make it difficult to accommodate future system changes. C. They facilitate technology and software upgrades over a system's life. D. They use proprietary standards for security enhancement. C. Correct! Because they use non-proprietary interfaces, Open Systems can facilitate technology upgrades. Select Next to continue. Page 18 of 23

371 SYS 101: Fundamentals of Systems Engineering Essential Considerations What are 'Ethics?' 'Ethics' is related to morality, but the two terms are not synonymous. Ethics: The rules or standards governing the conduct of a person or the conduct of the members of a profession Morality: Concern with the distinction between good and evil or right and wrong; right or good conduct Morality can't be legislated and is considered an individual issue. Ethics, on the other hand, can be legislated and can apply to groups. Federal government employees are required to follow the ethical standards promulgated by the Office of Government Ethics. These standards are grounded in public laws as well as those specified via organizational regulations, directives and orders. Select NEXT to continue. Page 19 of 23

372 Executive Order This Presidential Executive Order establishes the framework for ethical conduct by all government employees. Key points include: SYS 101: Fundamentals of Systems Engineering Essential Considerations Avoiding financial conflicts impacting duty performance Not using information for private financial gain Prohibition on solicitation for financial gain Not using public office for financial gain Avoiding inappropriate outside employment Good faith discharge of financial obligations Adhering to equal opportunity laws Disclosing waste, fraud, abuse and corruption to appropriate authorities Avoiding the appearance of non-ethical behavior The complete text of this Executive Order can be accessed via the Quick References section. Page 20 of 23

373 SYS 101: Fundamentals of Systems Engineering Essential Considerations Ethics Resources A Continuous Learning Module (CLM) on Ethics, which is part of the required training for all DoD acquisition workforce employees, is available. For details on the registration process for this module, click here. The U.S. Office of Government Ethics (OGE) web site contains a variety of resources related to the ethics requirements for government employees. Finally, the International Council on Systems Engineering (INCOSE), a not-for-profit international body promoting the application of an interdisciplinary approach and means to enable the realization of successful systems, has developed a suggested code of ethics for engineering professionals. It is well worth reading. Both OGE and INCOSE ethics resources can be accessed via the Quick References section. Select NEXT to continue. Page 21 of 23

374 Ethics Training Registration To register for the Ethics training module, visit the DAU Continuous Learning Center at and follow the directions and links provided in the 'Register' section.

375 SYS 101: Fundamentals of Systems Engineering Essential Considerations Review of Objectives Essential considerations that affect the conduct of Systems Engineering within a DoD program include: Systems Engineering Plan (SEP): A detailed formulation of actions that should guide all technical aspects of an acquisition program. It is established early in the program and updated at each subsequent milestone and as needed. It is a living document, tailored to the program, and a roadmap that supports program management. Robust Systems Engineering: Refers to the use of a disciplined Systems Engineering approach in conjunction with a robust product design. A 'robust design' is one that: o o o Encompasses design and process flexibility which can rapidly and affordably accommodate change Is tolerant of end product failure points and/or operating conditions Employs modular architectures with open systems standards used for selected Key Interfaces A Model is a 'physical,' mathematical or logical representation of an system entity, phenomenon, process or end product. A Simulation is the manipulation of that model. Modeling and Simulation (M&S) can be an effective Systems Engineering tool across the life cycle. Its usage should be outlined in the program s Systems Engineering Plan. Select NEXT to continue. Page 22 of 23

376 SYS 101: Fundamentals of Systems Engineering Essential Considerations Review of Objectives, Cont. Open Systems Architectures: Use technical interface standards based on non-proprietary, 'open' standards that are widely used, consensus-based, published and maintained by recognized industry standards organizations. The Modular Open Systems Approach (MOSA) is a DoD business and technical strategy for fostering effective use of open systems. Evolutionary Acquisition: A type of acquisition approach used at the system level that builds and fields core portions of a system by selectively evolving it through phased upgrades. It is the preferred DoD strategy for software-intensive system developments, especially for network-centric or information-based systems. It should also be used for other types of systems whenever appropriate. The flexibility inherent in Modular Open System Architectures facilitates effective use of Evolutionary Acquisition. Ethics: Ethical behavior and conduct is required for all DoD employees. Presidential Executive Order established the framework for ethical conduct of all government employees. The U.S. Office of Government Ethics (OGE) contains references on specific laws and regulations related to ethical behavior. You have reached the end of this topic. To proceed, select the exam for this topic in the Table of Contents. Page 23 of 23

377 SYS 101: Fundamentals of Systems Engineering Essential Considerations Exam Essential Considerations Exam

378 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Summary - Introduction to Systems Engineering This lesson summarizes the Introduction to Systems Engineering lesson.

379 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Recap of Lesson The topics that were covered in this lesson included: How Systems Engineering can be described DoD Systems Engineering processes Roles played by Systems Engineering standards Technical Foundations: 'V' Models and their applications Considerations related to the role of the Systems Engineering Plan, Robustness, Open Systems, the role of Modeling & Simulation (M&S), Evolutionary Acquisition and Workplace Ethics Select NEXT to continue. Page 1 of 13

380 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Description of Systems Engineering There are many ways to describe the discipline of Systems Engineering. Systems Engineering, as defined in the DoD Defense Acquisition Guidebook, is: Systems Engineering is an interdisciplinary approach encompassing the entire technical effort to evolve and verify an integrated and total life cycle-balanced set of system, people and process solutions that satisfy customer needs. In the DoD, Systems Engineering is typically implemented via Integrated Product and Process Development (IPPD). IPPD is done by multidisciplinary teams of subject-matter experts, typically formally charted as Integrated Product Teams (IPTs). Because the cost to implement system changes increases dramatically as a program matures, Systems Engineering can have great impacts on Total Life Cycle Systems Management (TLCSM). Thorough analyses of TLCSM issues, done as part of the Systems Engineering effort, can reveal an optimum, life cycle-balanced design that prevents costly technical changes later. Select NEXT to continue. Page 2 of 13

381 Definition of a System A system consists of: SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering 1. One or more 'End Products' that will perform the intended operational functions expected by the customer and within constraints set by other stakeholders 2. A set of 'Enabling Products' that perform life cycle service functions Each End Product will have its unique and common set of Enabling Products that will enable the End Product to be designed, realized, deployed, operated, maintained and, when the End Product has completed its useful life, to be properly disposed. Select NEXT to continue. Page 3 of 13

382 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Systems Engineering Processes Systems Engineering processes outlined in the Defense Acquisition Guidebook (DAG) consist of: Technical Processes: These processes are used to design the system products, including the operational/mission products and supporting or enabling products required to produce, support, operate or dispose of system products. Technical Processes include those for: o o Top-Down Design: Requirements Development; Logical Analysis; and Design Solution Bottom-Up Product Realization: Implementation; Integration; Verification; Validation; and Transition Technical Management Processes: These processes are used to manage the technical development of the system, including its supporting or enabling products. These Technical Management Processes are: Technical Planning; Requirements Management; Interface Management; Risk Management; Configuration Management; Technical Data Management; Technical Assessment; and Decision Analysis. Select NEXT to continue. Page 4 of 13

383 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Systems Engineering Standards At one time MIL-STD-499A was the DoD's sole Systems Engineering standard. As part of the DoD Acquisition Reform movement, it (along with numerous other DoD-unique standards) was canceled. Relevant commercial Systems Engineering standards include: EIA 632, Processes for Engineering Systems IEEE 1220, Standard for Application and Management of Systems Engineering ISO/IEC (identical to IEEE 15288): Systems and Software Engineering--Life Cycle Processes All these standards have relevance to various parts of the Systems Engineering process and are selectively used, depending on a project's needs. DoD Systems Engineering processes are derived in part from EIA 632. Select NEXT to continue. Page 5 of 13

384 Role of the 'System Model' Existence of a comprehensive system model is critical. Such a model allows for the uniform application of various Systems Engineering processes and can be used to facilitate: SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Planning and managing the Systems Engineering effort by: o o o o Identifying products to be engineered Assigning work packages Making cost estimates Assessing risks and opportunities Organizing IPTs and facilitating team work Orchestrating incremental Technical Reviews Defining and structuring specifications, including interfaces Creating system structure Enabling product identification and development Within the DoD, a Work Breakdown Structure (WBS) is commonly used to formally document the system model. MIL-HDBK-881A provides detailed guidance. D Page 6 of 13

385 Long Description Flowchart titled 'Generic System Model.' System flows to End Product, Development & Integration Products, Production Products, Test Products, Operations Products, Logistics Products. End Product flows to two Subsystem boxes.

386 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Engineering 'V' Model A system structure based on a hierarchy of layered system models provides the basis for both Top-Down System Design and Bottom-Up Product Realization. When arranged in the fashion shown here, it is referred to as a 'V' Model for obvious reasons. A similar 'V' format can be used to structure key Systems Engineering processes in the context of the Defense Acquisition Framework. Used in this manner, the 'V' model helps to ensure that required technical exit and entry criteria associated with each phase of the life cycle are met. Select NEXT to continue. Page 7 of 13

387

388 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Systems Engineering Plan (SEP) A Systems Engineering Plan (SEP) is a detailed formulation of actions that should guide all technical aspects of an acquisition program. The SEP is a living document, tailored to the program, and is a technical roadmap that supports program management and serves as the basis for helping to frame the program's contractual technical requirements. The government Program Office creates the SEP. The initial SEP should be created early in the acqusition life cycle. The level of fidelity and emphasis in the SEP will evolve as the program progresses. SEPs must be updated and submitted as part of each milestone review over the life of the system. Select NEXT to continue. Page 8 of 13

389 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Robust Systems Engineering Robust Systems Engineering is the use of a disciplined Systems Engineering process in conjunction with a robust product design. A 'robust design' is one that encompasses design and process flexibility. This allows for the rapid and affordable accommodation of change over the system life cycle and is tolerant of end product failure points. One of the keys to robust design is use of a modular approach and of Open System Architectures where appropriate. Open System Architectures use technical interface standards based on non-proprietary, 'open' standards that are widely used, consensus-based, and published and maintained by recognized industry standards organizations. Selected Key Interfaces in a system should use these where appropriate. The Modular Open Systems Approach (MOSA) is the DoD business and technical strategy for fostering effective use of open systems. Select NEXT to continue. Page 9 of 13

390 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Modeling and Simulation (M&S) A model is a 'physical,' mathematical or logical representation of an system entity, phenomenon, process or end product. A simulation is the manipulation of that model. Modeling and Simulation (M&S) can be an effective Systems Engineering tool across the life cycle. It is not uncommon for hundreds of different M&S assets to be used on a major program. Some examples of M&S usage include: Using M&S to explore concept alternatives, reliability, availability, maintainability, transportability, human-machine interfaces and estimate life cycle sustainment costs Using modeling environments provided by Systems Engineering tools, Computer-Aided Design (CAD), etc. to better manage complexity, increase design quality and improve productivity Helping to answer questions about the probability of meeting system performance requirements Selective use as part of the Verification and possibly, the Validation Processes During production, using M&S to make the manufacturing process more efficient Predicting maintenance and repair levels anticipated during system operation Within such M&S broad usage categories, programs should specifically define planned use of M&S. The SEP is a key place where the M&S strategy should be outlined. Select NEXT to continue. Page 10 of 13

391 SYS 101: Fundamentals of Systems Engineering Summary - Introduction to Systems Engineering Evolutionary Acquisition Evolutionary Acquisition is a type of acquisition approach used at the system level. It builds and fields core portions of a system, selectively evolving it through phased upgrades based on user feedback. It is the preferred DoD strategy for system development, where appropriate. The flexibility inherent in Modular Open System Architectures facilitates effective use of Evolutionary Acquisition. Select NEXT to continue. D Page 11 of 13

392