AY2024 TRI2 4608 - Lesson 2 (10th January 2025) - Systems Engineering PDF
Document Details
![SparklingCottonPlant4257](https://quizgecko.com/images/avatars/avatar-18.webp)
Uploaded by SparklingCottonPlant4257
Singapore Institute of Technology (SIT)
2025
Ng Bor Kiat
Tags
Summary
This document provides a lecture on Large Scale Systems (LSS) and Systems Engineering (SE) for a university course. It covers the definition, characteristics, and challenges of LSS, along with examples and various approaches to managing them. Information on domain analysis and key processes are also included.
Full Transcript
SIT Internal SEM 4608 Tri-2 AY2024/2025 Large Scale Systems Associate Professor Ng Bor Kiat Lesson 2 (10th Jan 2025) SIT Internal Scope: 1. LSS Broad Overview 2. Domain Analysis Information 3. Systems Engineering Processes (1) – Chapter 1 to 3 of INCOSE SE Hand...
SIT Internal SEM 4608 Tri-2 AY2024/2025 Large Scale Systems Associate Professor Ng Bor Kiat Lesson 2 (10th Jan 2025) SIT Internal Scope: 1. LSS Broad Overview 2. Domain Analysis Information 3. Systems Engineering Processes (1) – Chapter 1 to 3 of INCOSE SE Hand Book 4. Discussion SIT Internal Definition of Large Scale System (LSS) Large Scale Systems: - Complex systems involving a high degree of interconnection, numerous components, and often require coordination across multiple layers. - Designed to handle significant amounts of data, resources, or operations. SIT Internal Characteristics of Large Scale Systems Key Characteristics: - Size and complexity: Large number of components or users. - Scalability: Potential to handle increasing loads or demands. - Distributed nature: Often spread across multiple locations or platforms. - - High throughput: Capable of processing or operating with vast amounts of data and information. - Robustness: Can be designed to remain functional (partially or total) even with failures or faults. SIT Internal Examples of Large Scale Systems Examples include: Systems supporting data and information transactions: - Cloud computing infrastructure: Managing vast amounts of data and user requests. - Global financial networks: Systems supporting transactions and real-time trading across the world. - Telecommunications networks: Managing billions of connections, calls, and data exchanges. - Social media platforms: Managing millions of users and real-time content updates. SIT Internal Examples of Large Scale Systems Other examples include installations and services:: - Supply chain management systems: Coordinating global logistics, inventory, and distributions. - Infrastructural systems: Global ware-housing, transport facilities, military installations, data centers etc. - National level public services: Healthcare, education, defence, energy, food, water, environment and transport etc. SIT Internal Challenges in Large Scale Systems - Managing complexity and uncertainty: Integrating and optimising across multiple components. - Fault tolerance and reliability: Ensuring continued performance despite failures. - Performance and latency: Maintaining fast response times under heavy load. - Communication and ownership: Keeping clear and continuous communication with stakeholders. SIT Internal The Key Approaches to Designing and Managing Large Scale Systems Detailed requirements analysis and planning: - Defined user needs, performance goals, and scalability requirements. - Identified constraints like budget, time, and technology stack. - Continued integrated end-to-end life cycle planning. Robust systems design and project management: - Systems-of-systems rigours and clearly defined KPIs. - Modularity, flexibility, reliability, availability, maintainability, safety and scalability in design. - Systematic and structured verification and validation process. - Comprehensive project management, testing and acceptance criteria. SIT Internal Internal Scope: 1. LSS Broad Overview 2. Domain Analysis Information 3. Systems Engineering Processes (1) – Chapter 1 to 3 of INCOSE SE Hand Book 4. Discussion SIT Internal Domain Analysis Information Domain Analysis During domain analysis, a systems engineer learns background information about the general field of business or technology in which the system is to be utilized. Enough information must be gathered to understand the problem to be solved and to make good decisions throughout the system lifecycle. Some domains may be very broad (e.g.: Sea Port Operations, Land Transportation, Airline Reservations, Medical Diagnosis … etc.) while others are narrower (e.g.: Building of Drones, Manufacturing of Paint, Scheduling Meetings … etc.). People who work in a domain and who have a deep knowledge of it (or part of it), are called “Domain Experts”. To perform domain analysis, information from whatever sources that are available are gathered. These sources include the domain experts; any books about the domain; any existing system and its documentation … etc. SIT Internal Information Items A summary of the information found during domain analysis can be structured with the following information items: A) Introduction: Name the domain, and give the motivation for performing the analysis. The motivation normally relates to solving a particular problem by developing or extending a system. B) Glossary: Describe the meanings of all terms used in the domain that are not part of everyday language or have special meanings. A systems engineer must master this terminology to communicate with customers and users. (note: The terminology will appear in the user interface of the system as well as the documentation for the system). C) General Knowledge about theDomain: Summarise important facts or rules that are widely known by the domain experts and which would normally be learned as part of their education. Such knowledge includes scientific principles, business processes, techniques, and how any technology works. (note: This is an excellent place to use diagrams and point the reader to details readily accessible).. SIT Internal Information Items (Contd) D) Customers and Users: Describe who will or might buy the system, and in what industrial sectors they operate. Also, describe the other people who work in the domain, even peripherally. Mention their background and attitude as well as how they fit into the organization chart, and relate to each other. These people may become users. E) The Environment: Describe the equipment and systems used. The new system or extensions will have to work in the context of this environment. F)Tasks and Procedures Currently Performed: Make a list of what the various people do as they go about their work. It is important to understand both the procedures people are supposed to follow as well as the shortcuts they tend to take. (note 1: For example, if people are supposed to enter certain information on a form, but rarely do this suggest this information is not useful). (note 2: Tasks listed in this section may be candidates for automation). SIT Internal Information Items (Contd) G)COTS Systems: Describe what Commercial Off-the-Shelf systems that are available to assist the users and customers, including system that is already in use. Discuss their advantages and disadvantages. This information suggests ideas for requirements, and highlights mistakes to avoid. H)Similarities across Domains and Organisations: Understanding what is generic versus what is specific will facilitate the creation of system that might be more reusable or more widely marketable. Determine what distinguishes this domain and the customer’s organization from others, as well as what they have in common. (note 1: Do not duplicate excessive amount of detailed information). (note 2: It is a waste of effort to duplicate the original source of material, summarise the information and point to the detailed sources). SIT Internal Elaboration No serious project should be undertaken without a sound domain analysis. A good knowledge of the domain of application considerably increases the chances of success. Many of the most successful systems have been developed by people who were actively working in the domain before they became systems engineers – such people have a better feel for what is really needed. Once systems engineers have a good grasp of the domain, they can move on to requirements analysis, which includes defining the problem to be solved and what system will be created to solve it. However, domain analysis should never really end: systems engineers have the responsibility to continue improving their understanding as development proceeds. An extension to the system added for a subsequent release will often merit a domain analysis of its own sub-domain. SIT Internal Example 1 Developing a new and better telephone response and dispatch system for medical emergencies. The system will be used by operators and paramedics who respond to calls to the emergency number 995. A. Introduction: The domain is “Medical Emergency Dispatch”. The motivation for the domain analysis is to develop a new system that would improve upon existing systems. Qualities that are valued in such systems include accurate guidance to the paramedics, fast response time, flexibility, and above all, saving lives. B. Glossary: Much of the special terminology for this domain will be medical in nature, but there will also be terminology related to communications equipment, emergency vehicles and rescure equipment. SIT Internal Example 1 (Contd) C.General Knowledge about the Domain: Obtain statistics about the calls received and the types of cases handled; this will help determine the level of performance the system must achieve. Other examples of information to learn include: What are the different categories of emergency situations, and how is each handled? Note 1: How are addresses described (it is critically important that no mistake is made when communication an address to an ambulance driver)? Note 2: How do dispatchers decide whether police, fire-fighters or other special services should also be dispatched? D.Customers and Users: In this domain everyone, including operators, drivers, paramedics and doctors in hospitals, has a clearly defined role. Understand the knowledge they posses and what they need to learn during the process of handling an emergency. Some users may oppose to the introduction of any new software -- they might have developed considerable skill with the existing methods, and fear a new system will render their skills redundant, or even put them out of a job. Knowing this fact actions can then be taken to address their concerns and thus avoid any political problems. SIT Internal Example 1 (Contd) E. Tasks and Procedures currently performed: The procedures that are currently used by dispatchers and paramedics will help decide the functions to be implemented. These procedures are normally very well defined so that they can be followed without any decision-making delay even in a major crisis. Examples of procedures include: How decisions are made about which ambulance to dispatch to which address. Note 1: How dispatchers of ambulance drivers decide upon a route, especially when traffic is heavy or blocked. Note2: How priorities are established in a disaster, when there are not enough ambulances; how communications are established among the dispatcher, the paramedics and doctors in hospitals. Note 3: How records of each call are logged. The study of these procedures will help identify what aspects can be improved and how the software will become an asset to the customer. Any standards that may exist can be highlighted, so the system can conform to them. SIT Internal Example 1 (Contd) F.Competing Software: It may be discovered that there is widely-used and well- respected emergency management system on the market. It may be the case that there is little chance of economically developing something that would be as good. In such a case, it would be advisable to propose the use of widely-used system. On the other hand, the market may be under-developed, with many opportunities for a product like the system to be developed to excel. With extra effort, a generic system can be developed, rather that a custom product and can be sold to many different municipalities. G.Similarities across Domains and Organisations: The task of dispatching ambulance could be generalised as the problem of allocating the closest resource to a customer. Considerations may be given to the development for this aspect of the program. SIT Internal Internal Scope: 1. LSS Broad Overview 2. Domain Analysis Information 3. Systems Engineering Processes (1) – Chapter 1 to 3 of INCOSE SE Hand Book 4. Discussion SIT Internal Objective of INCOSE (International Council on Systems Engineering) Handbook SEH: SYSTEMS ENGINEERING HANDBOOK To describe key process activities A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES performed by Systems Engineers. Descriptions in SEH: Show what each SE process activity entails in the context of designing for required performance and life cycle considerations. FOUR T H E D I T I O N Source: Systems Engineering Handbook INCOSE –TP- 2003-002-04(2015) SIT Internal History of Systems Engineering Handbook (SEH) SIT Internal INCOSE Systems Engineering Handbook (SEH) Chapter 1. Systems Engineering Handbook Scope 2. Systems Engineering Overview 3. Generic Life Cycle Stages 4. Technical processes 5. Technical Management Processes 6. Agreement Processes 7. Organisational Project-enabling Processes 8. Tailoring Process and Application of Systems Engineering 9. Cross-cutting Systems Engineering Methods 10. Specialty Engineering Activities SIT Internal Objectives of Systems Engineering Handbook (SEH) Objective of INCOSE (International Council on Systems Engineering) SEH: –to describe key process activities performed by Systems Engineers. Descriptions in SEH: –show what each SE process activity entails in the context of designing for required performance and life cycle considerations. SIT Internal Contents Purpose [1.1] Application [1.2] Contents [1.3] Format [1.4] Definitions of Frequently Used Terms [1.5] SIT Internal Purpose of SEH Defines the discipline and practice of Systems Engineering (SE) for students and practicing professionals. Provides an authoritative reference to understand the SE discipline in terms of content and practice. SIT Internal Application (1) SEH is consistent with ISO/IEC/IEEE 15288:2015, Systems and Software Engineering—System Life Cycle Processes (15288). Ensure its usefulness across a wide range of application domains: – Man-made systems & products – Businesses – Services ISO / IEC / IEEE 15288 provides generic top-level process description and requirements. SEH further elaborates on the practices and activities necessary to execute the processes. SIT Internal Application (2) Guide to the Systems Engineering Body of Knowledge (SEBoK, 2014) : - SEH is also consistent with SEBoK to the extent practicable. -provides more detailed coverage of the related topics described in SEH. - includes a current and vetted set of references. SIT Internal Contents of SEH (1) Chapter 1: Systems Engineering Handbook Scope –defines the purpose and scope of SEH. Chapter 2: Systems Engineering Overview –provides an overview of the goals and value of using SE throughout the system life cycle. Chapter 3: Generic Life Cycle Stages –describes an informative life cycle model with six stages: concept, development, production, utilization, support, and retirement. SIT Internal Problem & Solution Space Life Cycle Stages Concept Development Production Utilization Support Retirement SIT Internal Contents of SEH (2) ISO/IEC/IEEE 15288 identifies 4 process groups to support SE: –Chapter 4: Technical Processes –Chapter 5: Technical Management Processes –Chapter 6: Agreement Processes –Chapter 7: Organizational Project Enabling Processes SIT Internal Contents of SEH (3) Chapter 8: Tailoring Process and Application of Systems Engineering: –Information on how to adapt and scale the SE processes and how to apply those processes in various applications. –Not every process will apply universally. –Careful selection from the material is recommended. SIT Internal Contents of SEH (4) Chapter 9: Cross-Cutting Systems Engineering Methods -Provides insights into methods that can apply across all processes, reflecting various aspects of the iterative and recursive nature of SE. Chapter 10: Specialty Engineering Activities –Include practical information so systems engineers can understand and appreciate the importance of various specialty engineering topics. SIT Internal Contents of SEH (5) Appendix A: References – List of references. Appendix B: Acronyms – List of acronyms. Appendix C: Terms and Definitions – Glossary of SE terms and definitions. Appendix D: N2 Diagram of Systems Engineering Processes – Shows where dependencies exist in the form of shared inputs or outputs. Appendix E: Input/Output Descriptions – A master list of all inputs/outputs identified for each SE process. SIT Internal Notes: Before applying this handbook in a given organization or project, it is recommended that the tailoring guidelines in Chapter 8 be used to remove conflicts with existing policies, procedures, and standards already in use within an organization. Processes and activities in this handbook do not supersede any international, national, or local laws or regulations. SIT Internal Format SIT Internal Input-Process-Output (IPO) Diagram Represent “a” way that the SE processes can be performed, but not necessarily “the” way that they must be performed. To understand a given process – need to study the complete information provided in the combination of diagrams and text and not rely solely on the diagrams. SIT Internal Structure for Process Descriptions (1) Process Overview Purpose - Purpose statements from ISO/IEC/IEEE 15288 are included verbatim for each process. Description Inputs/Outputs –Listed by name within the respective IPO diagrams with which they are associated. –Complete list of all inputs and outputs with their respective descriptions appears in Appendix E. SIT Internal Structure for Process Descriptions (2) Process Activities titles of the process activities listed in each section are consistent with ISO/IEC/IEEE 15288. –In some cases, additional items have been included to provide summary- level information regarding industry best practices and evolutions in the application of SE processes. Process Elaboration - SE processes produce “results” that are often captured in “documents” rather than producing “documents” simply because they are identified as outputs. SIT Internal Controls and Enablers Govern all processes. Not repeated in the IPO diagrams or in the list of inputs associated with each process description. Descriptions of each control and enabler are provided in Appendix E. SIT Internal Controls (1) Applicable Laws and Regulations –International, national, or local laws or regulations. Standards –This handbook and relevant industry, country, military, acquirer, and other specifications and standards. –Includes new knowledge from industry sponsored knowledge networks. Agreements –Agreements from all applicable life cycle processes, including acquisition agreements and supply agreements. SIT Internal Controls (2) Project Direction - Organizational direction to the project. - Include sustainment of projects meeting assessment criteria and redirection or termination of projects not meeting assessment criteria. Project Control Requests - Internal project directives based on action required due to deviations from the project plan. - New directions are communicated to both project team and customer, when appropriate. - If assessments are associated with a decision gate, a decision to proceed, or notto proceed, is taken. SIT Internal Enablers (1) Organization Policies, Procedures & Standards (Assets) - Items related to the organization’s standard set of life cycle processes. - Include guidelines and reporting mechanisms. - Organisation process guidelines in the form of organization policies, procedures, and assets for applying the system life cycle processes and adapting them to meet the needs of individual projects (e.g., templates, checklists, forms). - Includes defining responsibilities, accountability, and authority for all SE processes within the organization. SIT Internal Enablers (2) Project Infrastructure – Resources and services that support a project. –Project-level facilities, personnel, and resources for hardware fabrication, software development, system implementation and integration, verification, validation, etc. SIT Internal Enablers (3) Knowledge Management System – Maintained knowledge management system. – Project suitability assessment results for application of existing knowledge. – Lessons learned from execution of the organizational SE processes on projects. –Include mechanisms to easily identify and access the assets and to determine the level of applicability for the project considering its use. – Can be used by any life cycle process. SIT Internal Definition of Terms One of the systems engineer’s first and most important responsibilities on a project is to establish nomenclature and terminology that support clear, unambiguous communication and definition of the system and its elements, functions, operations, and associated processes. Some reference examples are as shown below: –ISO/IEC/IEEE 15288 –ISO/IEC/IEEE 24765, Systems and Software Engineering—Vocabulary (2010) –SE VOCAB (2013) SIT Internal INCOSE Systems Engineering Handbook (SEH) Chapter 1. Systems Engineering Handbook Scope 2. Systems Engineering Overview 3. Generic Life Cycle Stages 4. Technical processes 5. Technical Management Processes 6. Agreement Processes 7. Organisational Project-enabling Processes 8. Tailoring Process and Application of Systems Engineering 9. Cross-cutting Systems Engineering Methods 10. Specialty Engineering Activities SIT Internal ISO/IEC/IEEE 15288 (Systems Life Cycle Processes) SIT Internal Generic Life Cycle Stages, Purposes and Decisions SIT Internal System Life Cycle Stages Comparisons of Life Cycle Models SIT Internal Contents Introduction [3.1] Life Cycle Characteristics [3.2] Life Cycle Stages [3.3] Life Cycle Approaches [3.4] What Is Best for Your Organization, Project, or Team? [3.5] Introduction to Case Studies [3.6] SIT Internal INTRODUCTION Life Cycle (1) o series of stages through which a system or manufactured product passes. o encompass development, production, utilization, and support stages and provides early focus on the retirement stage when decommissioning and disposal of the system will occur – environmental issues. o needs for each of the subsequent stages must be considered during the earlier stages; – especially during the concept and development stages in order to make the appropriate trade-off decisions to accommodate the needs of later stages in an affordable and effective manner. SIT Internal INTRODUCTION Life Cycle (2) o SE tasks are usually concentrated at the beginning of the life cycle – but both industry and government organizations recognize the need for SE throughout the systems’ life span, often to modify or change a system product or service after it enters production or is placed in operation – consequently, SE is an important part of all life cycle stages – e.g., during the utilization and support stages, SE executes performance analysis, interface monitoring, failure analysis, logistics analysis, tracking, management, etc. that is essential to ongoing operation and support of the system SIT Internal INTRODUCTION Role of Systems Engineer o encompasses the entire life cycle for the SOI o orchestrate the development of a solution from requirements definition through design, build, integration, verification, operations, and ultimately system retirement o assuring that domain experts are properly involved o ensure that all advantageous opportunities are pursued o identify and mitigate significant risks o works closely with the Project Manager in tailoring the generic life cycle, including key decision gates, to meet the needs of their specific project SIT Internal INTRODUCTION Purpose of Defining the System Life Cycle o to establish a framework for meeting the stakeholders’ needs in an orderly and efficient manner for the whole life cycle o usually done by defining life cycle stages and using decision gates to determine readiness to move from one stage to the next o skipping stages and eliminating “time‐consuming” decision gates can greatly increase the risks (schedule, cost and performance) and may adversely affect the technical development as well by reducing the level of the SE effort SIT Internal LIFE CYCLE CHARACTERISTICS Decision/Control Gates (1) o represent major decision points in the system life cycle o an approval event in the project cycle, sufficiently important to be defined and included in the schedule by the Project Manager, executive management, or the customer o entry and exit criteria are established for each gate at the time they are included into the project management baseline o ensure that new activities are not pursued until the previously scheduled activities, on which new activities depend, are satisfactorily completed and placed under configuration control SIT Internal LIFE CYCLE CHARACTHERISTICS Decision/Control Gates (2) o proceeding beyond the decision gate before the project is ready entails risk – project manager may decide to accept that risk, as is done, for instance, with long‐lead item procurement o often called “milestones” or “reviews” – all decision gates are both reviews and milestones – however, not all reviews and milestones are decision gates SIT Internal LIFE CYCLE CHARACTERISTICS Decision/Control Gates (3) o Decision Gates address the following questions: – Does the project deliverable still satisfy the business case? – Is it affordable? – Can it be delivered when needed? o project business case issues are important decision criteria influencing concept selection, and they should be updated and evaluated at every decision gate: – market demand – affordability – realistic schedules SIT Internal LIFE CYCLE CHARACTERISTICS Decision/Control Gates (4) o inadequate checks along the way can set up subsequent failures— usually a major factor in cost overruns and delays o Primary Objectives of Decision Gates – Ensure that the elaboration of the business and technical baselines are acceptable and will lead to satisfactory verification and validation (V&V) – Ensure that the next step is achievable and the risk of proceeding is acceptable – Continue to foster buyer and seller teamwork – Synchronize project activities SIT Internal LIFE CYCLE CHARACTERISTICS Decision/Control Gates (5) o there are at least two decision gates in any project: – authority to proceed – final acceptance of the project deliverable o project team needs to decide which life cycle stages are appropriate for their project and which decision gates beyond the basic two are needed o each decision gate must have a beneficial purpose SIT Internal LIFE CYCLE CHARACTERISTICS Decision/Control Gates (6) o in agile development, frequent interaction with stakeholders may minimize, but not eliminate, the need for decision gates – consequences of conducting a superficial review, omitting a critical discipline, or skipping a decision gate are usually long term and costly SIT Internal LIFE CYCLE CHARACTERISTICS Decision Gate Descriptions o Purpose and Scope of the Decision Gate o Entry and Exit Criteria o Host and Chairperson o Attendees o Location o Agenda and How the Decision Gate is to be Conducted o Evidence to be Evaluated o Actions Resulting from the Decision Gate o Method of Closing the Review, including timing for resolution of open action items SIT Internal LIFE CYCLE CHARACTERISTICS Decision Gate Approval o follows review by qualified experts and involved stakeholders o based on hard evidence of compliance to the criteria of the review o balancing the formality and frequency of decision gates is seen as acritical success factor for all SE process areas o on large or lengthy projects, decisions and their rationale are maintained using an Information Management process o upon successful completion of a decision gate, some artifacts (e.g., documents, models, or other products of a project life cycle stage) have been approved as the basis upon which future work must build o these artifacts are placed under configuration management SIT Internal LIFE CYCLE CHARACTERISTICS Decision Gate Approval o follows review by qualified experts and involved stakeholders o based on hard evidence of compliance to the criteria of there view o balancing the formality and frequency of decision gates is seen as acritical success factor for all SE process areas o on large or lengthy projects, decisions and their rationale are maintained using an Information Management process o upon successful completion of a decision gate, some artifacts (e.g., documents, models, or other products of a project life cycle stage) have been approved as the basis upon which future work must build o these artifacts are placed under configuration management SIT Internal LIFE CYCLE STAGES ISO/IEC/IEEE 15288 o 5.4.1—A system progresses through its life cycle as the result of actions, performed and managed by people in organizations, using processes for execution of these actions. a system “progresses” through a common set of life cycle stages where it is conceived, developed, produced, utilized, supported, and retired SIT Internal LIFE CYCLE STAGES SIT Internal LIFE CYCLE STAGES SIT Internal LIFE CYCLE STAGES - stages can overlap - utilization and support stages can run in parallel -outcome possibilities are the same for all decision gates although the stages in Table 3.1 are listed as independent, non‐overlapping, and serial, the activities constituting these stages can be in practice interdependent, overlapping, and concurrent SIT Internal LIFE CYCLE STAGES - discussion of system life cycle stages does not imply that the project should follow a predetermined set of activities or processes unless they add value toward achieving the final goal - serial time progression is not inherently part of a life cycle model (stages do not necessarily occur serially one after another in time sequence) SIT Internal LIFE CYCLE STAGES when reference is made to an earlier, prior, next, subsequent, or later stage, this type of model must be kept in mind to avoid confusion by inferring serial time sequencing subsequent chapters of SEH will define processes and activities to meet the objectives of these life cycle stages because of the iterative nature of SE, specific processes are not aligned to individual life cycle stages the entire set of SE processes is considered and applied at each stage of life cycle development as appropriate to the scope and complexity of the project SIT Internal LIFE CYCLE STAGES o Figure 3.3 compares the generic life cycle stages to other life cycle viewpoints o the concept stage is aligned with the study period for commercial projects and with the pre‐system acquisition and the project planning period in the US Departments of Defense and Energy, respectively o typical decision gates are presented in the bottom line SIT Internal LIFE CYCLE STAGES Concept Stage (1) begins with some recognition of a need for new or modified SOI process begins with interactions and studies to understand o potential new organizational capabilities, o opportunities, or o stakeholder needs o rather than beginning with “requirements” or “user requirements” a great deal of creative SE is done in this stage work done properly in early stages of the life cycle will avoid recalls and rework in later stages many industries employ an exploratory research activity in the concept stage SIT Internal LIFE CYCLE STAGES Exploratory Research (1) study new ideas or enabling technologies and capabilities, which then mature into the initiation of a new project for the SOI Systems Engineer leading these studies is likely to follow a new idea into the concept selection ‐ as project champion identifies the enabling technologies key activities o clearly define the problem space o characterize the solution space o identify business or mission requirements and stakeholder needs o avoiding any design work, provide an estimate of the cost and schedule for the full‐scale development SIT Internal LIFE CYCLE STAGES Exploratory Research (2) incomplete SE in this stage can lead to poor cost and schedule projections, as well as poor understanding of technical alternatives, resulting in poor trades among the alternatives o e.g., the Mars Science Laboratory Rover, scheduled for launch in 2009, had to be “delayed because of technical glitches.” This resulted in missing the launch window, causing a 2‐year delay and a 35% cost growth over the approved development costs. Program critics, however, claimed a 400% cost growth based on the early concept studies, and they threatened the project with cancellation as a result (Achenbach, 2009) SIT Internal LIFE CYCLE STAGES Preliminary Concept and Enabling Technologies (1) o critical to create and explore a high‐level preliminary concept to whatever depth is necessary to: – identify technological risks – assess the technology readiness level (TRL) of the project – generate early cost and schedule projections for the project if it moves ahead o focus is on studying potential technologies and determining the state of what is possible and what is not SIT Internal LIFE CYCLE STAGES Preliminary Concept and Enabling Technologies (2) o project may be an outgrowth of R&D – no connection to user‐ supported needs o preliminary concept and enabling technologies need to be identified early and issues arising from the studies need to be addressed during the development stage o challenges in developing alternate concepts – tendency to build on what has worked well in the past without considering true alternatives – missing opportunities to make dramatic improvements o preliminary concept is not put under configuration control SIT Internal LIFE CYCLE STAGES Preliminary Concept and Enabling Technologies (3) o key output from exploratory research – a clearer understanding of the business/mission requirements and the stakeholder needs – an assessment of the technology’s readiness to move to the next stage – a rough estimate of the project cost and schedule requirements and technical feasibility to first article delivery o preliminary concept is a starting point, not an end point, as the project moves into the concept selection activity of the concept stage SIT Internal LIFE CYCLE STAGES Concept Selection (1) second activity of the concept stage a refinement and broadening of the studies, experiments, and engineering models pursued during the exploratory research activity SIT Internal LIFE CYCLE STAGES Concept Selection (2) Operational Concept (OpsCon) Effort o identify, clarify, and document the stakeholders’ conceptual operation of the system across the different stages of use and the environments it is to be used in o include any changes caused by changes in the manufacture processes or materials, changes in interface standards, or new feature enhancements being added that can drive various aspects of concept selection of the system SIT Internal LIFE CYCLE STAGES Concept Selection (3) team begins in‐depth studies that evaluate multiple candidate concepts and eventually provide a substantiated justification for the system concept that is selected as part of this evaluation, mock‐ups may be built (for hardware) or coded (for software), engineering models and simulations may be executed, and prototypes of critical elements may be built and tested o engineering models and prototypes of critical elements are essential to: – verify the feasibility of concepts – aid the understanding of stakeholder needs – explore architectural trade‐offs – explore risks and opportunities SIT Internal LIFE CYCLE STAGES Concept Selection (4) o studies expand the risk and opportunity evaluation to include – affordability assessment – environmental impact – failure modes – hazard analysis – technical obsolescence – system disposal SIT Internal LIFE CYCLE STAGES Concept Selection (5) o issues related to integration and verification must also be explored for each alternate system concept – these can be discriminators in system selection o Systems Engineer facilitates these analyses by coordinating the activities of engineers from many disciplines o key objectives are to provide confidence that the business case is sound and the proposed solutions are achievable SIT Internal LIFE CYCLE STAGES Concept Selection (6) The concept stage may include system and key system element‐level concept and architecture definition and integration, verification, and validation (IV&V) planning o early validation efforts align requirements with stakeholder expectations o system capabilities specified by the stakeholders will be met by the combination of system elements – problems identified for individual system element‐level concepts should be addressed early to minimize the risk that they fall short of the required functionality or performance when the elements are finally designed and verified SIT Internal LIFE CYCLE STAGES Concept Selection (7) Many projects are driven by eager project champions who want “to get on with it.” They succumb to the temptation to cut short the concept stage, and they use exaggerated projections to support starting development without adequate understanding of the challenges involved. Many commissions reviewing failed systems after the fact have identified insufficient or superficial study in the concept stage as a root cause of failure. SIT Internal LIFE CYCLE STAGES Development Stage (1) defines and realizes a SOI that meets its stakeholder requirements and can be produced, utilized, supported, and retired begins with the outputs of the concept stage primary output of this stage is the SOI other outputs can include (ISO/IEC TR 24748‐1, 2010): o a SOI prototype o enabling system requirements (or the enabling systems themselves) o system documentation o cost estimates for future stages SIT Internal LIFE CYCLE STAGES Development Stage (2) business and mission needs, along with stakeholder requirements, are refined into system requirements system requirements are used to create a system architecture and design concept from the previous stage is refined to ensure all system and stakeholder requirements are satisfied requirements for production, training, and support facilities are defined SIT Internal LIFE CYCLE STAGES Development Stage (3) enabling systems’ requirements and constraints are considered and incorporated into the design system analyses are performed to achieve system balance and to optimize the design for key parameters one of the key activities of the development stage is to specify, analyze, architect, and design the system so that the system elements and their interfaces are understood and specified hardware and software elements are fabricated and coded operator interfaces are specified, tested, and evaluated during the development stage SIT Internal LIFE CYCLE STAGES Development Stage (4) operator and maintainer procedures and training are developed and delivered to ensure humans can interface with the SOI feedback is obtained from both external and internal stakeholders through a series of technical reviews and decision gates projects that are not showing acceptable progress may be redirected or even terminated detailed planning and execution of IV&V activities o planning for these activities needs to take place early to ensure that adequate facilities and other resources are available when needed SIT Internal LIFE CYCLE STAGES Production Stage (1) stage where the system is produced or manufactured product modifications may be required to: o resolve production problems o reduce production costs o enhance product or system capabilities any of these may influence system requirements and may require system reverification or revalidation all such changes require SE assessment before changes are approved SIT Internal LIFE CYCLE STAGES Utilization Stage stage where the system is operated in its intended environment to deliver its intended services may be concurrently with Support Stage SIT Internal LIFE CYCLE STAGES Support Stage stage where the system is provided services that enable continued operation modifications may be proposed to o resolve supportability problems o reduce operational costs o extend the life of a system changes require SE assessment to avoid loss of system capabilities while under operation SIT Internal LIFE CYCLE STAGES Retirement Stage stage where the system and its related services are removed from operation SE activities primarily focused on ensuring that disposal requirements are satisfied planning for retirement is part of the system definition during the concept stage o experience has repeatedly demonstrated the consequences when system retirement is not considered from the outset o many countries have changed their laws to hold the developer of a SOI accountable for proper end‐of‐life disposal of the system SIT Internal LIFE CYCLE APPROACHES Life Cycle Models Waterfall (Royce, 1970), Spiral (Boehm, 1986), Vee (Forsberg and Mooz, 1991) useful in defining the start, stop, and process activities appropriate to the life cycle stages graphical representations of life cycle stages tend to be linear, but this hides the true incremental, iterative, and recursive nature of the underlying processes approaches that follow imply full freedom to choose a development model and are not restricted to sequential methods SIT Internal LIFE CYCLE APPROACHES Iteration and Recursion (1) system definition is often viewed as a linear, sequential, single pass through the processes however, valuable information and insight need to be exchanged between the processes, in order to ensure a good system definition that effectively and efficiently meets the mission or business needs application of iteration and recursion to the life cycle processes with the appropriate feedback loops helps to ensure communication that accounts for ongoing learning and decisions facilitates the incorporation of learning from further analysis and process application as the technical solution evolves SIT Internal LIFE CYCLE APPROACHES - Iteration and Recursion SIT Internal LIFE CYCLE APPROACHES Iteration (1) o repeated application of and interaction between two or more processes at a given level in the system structure or hierarchy o is needed to – accommodate stakeholder decisions and evolving understanding – account for architectural decisions/constraints – resolve trades for affordability, adaptability, feasibility, resilience, etc. SIT Internal LIFE CYCLE APPROACHES Iteration (2) o figure only shows a subset of the life cycle technical processes, there can be iteration between any of the processes, e.g., – there is often iteration between system requirements definition and architecture definition ‐ there is a concurrent application of the processes with iteration between them, where the evolving system requirements help to shape the architecture through identified constraints and functional and quality requirements – architecture trades, in turn, may identify requirements that are not feasible, driving further requirements analysis with trades that change some requirements – likewise, the design definition could identify the need to reconsider decisions and trades in the requirements definition or architecture definition processes – any of these can invoke additional application of the system analysis and decision management processes SIT Internal LIFE CYCLE APPROACHES Recursion o repeated application of and interaction of processes at successive levels in the system structure o technical processes are expected to be recursively applied for each successive level of the system structure until the level is reached where the decision is made to make, buy, or reuse a system element o during the recursive application of the processes, the outputs at one level become inputs for the next successive level (below for system definition, above for system realization – vee model) SIT Internal LIFE CYCLE APPROACHES Sequential Methods (1) provide an underlying framework to provide discipline to the lifecycle processes for projects that need to coordinate large teams of people working in multiple companies characterized by a systematic approach that adheres to specified processes as the system moves through a series of representations from requirements through design to finished product specific attention is given to the: o completeness of documentation o traceability from requirements o verification of each representation after the fact SIT Internal LIFE CYCLE APPROACHES Sequential Methods (2) strengths o predictability o stability o repeatability o high assurance process improvement focuses on increasing process capability through standardization, measurement, and control methods rely on the “master plans” to anchor their processes and provide project‐wide communication historical data is usually carefully collected and maintained as inputs to future planning to make projections more accurate SIT Internal LIFE CYCLE APPROACHES Sequential Methods (3) safety‐critical products (e.g. Therac‐25) can only meet modern certification standards by following a thorough, documented set of plans and specifications o such standards mandate strict adherence to process and specified documentation to achieve safety or security unprecedented projects or projects with a high rate of unforeseeable change, poor predictability, and lack of stability often degrade project may incur significant cost trying to keep documentation and plans up to date SIT Internal Vee Model (1) introduced in Forsberg and Mooz (1991), described in Forsberg et al. (2005) a sequential method used to visualize various key areas for SE focus, particularly during the concept and development stages highlights o the need for continuous validation with the stakeholders o the need to define verification plans during requirements development o the importance of continuous risk and opportunity assessment provides a useful illustration of the SE activities during the life cycle stages SIT Internal LIFE CYCLE APPROACHES SIT Internal LIFE CYCLE APPROACHES Vee Model (2) time and system maturity proceed from left to right core of the Vee o products that have been placed under configuration control o depicts the evolving baseline from stakeholder requirements agreement to identification of a system concept to definition of elements that will comprise the final system with time moving to the right, the evolving baseline defines the left side of the core of the Vee, as shown in the shaded portion of Figure 3.7 SIT Internal LIFE CYCLE APPROACHES SIT Internal LIFE CYCLE APPROACHES Vee Model (3) time and maturity move from the left to the right across the diagram, as shown in Figure 3.7 at any instant of time, the development team then can move their perspective only along the vertical arrow, from the highest level of the system requirements down to the lowest level of detail SIT Internal LIFE CYCLE APPROACHES Vee Model (4) Off‐Core Opportunity and Risk Management Investigation and Action o going downward o address development options to provide assurance that the baseline performance being considered can indeed be achieved o initiate alternate concept studies at the lower levels of detail to determine the best approach o these downward off‐core investigations and development efforts are entirely under control of the development team SIT Internal LIFE CYCLE APPROACHES Vee Model (5) Off‐Core Stakeholder Discussion and Approvals (in process validation) o going upward o ensure that the proposed baselines are acceptable to management, customer, user, and other stakeholders o changes to enhance system performance or to reduce risk or cost are welcome for consideration, but these must go through formal change control, since others outside the development team may be building on previously defined and released design decisions SIT Internal LIFE CYCLE APPROACHES SIT Internal LIFE CYCLE APPROACHES Vee Model (6) as entities are implemented, verified, and integrated, the right side of the core of the Vee is executed Figure 3.8 illustrates the evolving baseline as system elements are integrated and verified all iterations in the Vee are performed on the vertical “time now” line upward Iterations involve the stakeholders and are the in‐process validation activities that ensure that the proposed baselines are acceptable downward Iterations involve off‐core opportunity and risk management investigations and actions SIT Internal LIFE CYCLE APPROACHES Vee Model (7) – In each stage of the system life cycle, the SE processes iterate to ensure that a concept or design is feasible and that the stakeholders remain supportive of the solution as it evolves. SIT Internal REFERENCES INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition. Edited by David D. Walden, Garry J. Roedler, Kevin J. Forsberg, R. Douglas Hamelin and Thomas M. Shortell. © 2015 John Wiley & Sons, Inc. Published 2015 by John Wiley & Sons, Inc. reference section of SEH SIT Internal Internal Scope: 1. Domain Analysis Information 2. LSS Broad Overview 3. Systems Engineering Processes (1) – Chapter 1 to 3 of INCOSE SE Hand Book 4. Discussion SIT Internal QUESTIONS?