|
|
Line 1: |
Line 1: |
− | The starting point of engineering any [[System of Interest (SoI) (glossary)|system-of-interest]] (SoI) is understanding the socio-economic and technological context in which potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. [[Mission Analysis (glossary)|Mission analysis]] (MA) is often performed iteratively with [[Stakeholder Needs and Requirements|stakeholder needs and requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment.
| + | {{Term|Lean Systems Engineering (LSE) (glossary)|Lean Systems Engineering (LSE)}} is the application of lean thinking (Womack 2003) to systems engineering (SE) and related aspects of enterprise and project management. LSE is an approach that is applicable throughout the system {{Term|Life Cycle (glossary)|life cycle}}. The goal of LSE is to deliver the best life-cycle value for technically complex systems with minimal waste. Lean engineering is relevant to all of the traditional SE technical processes (see [[Concept Definition|concept definition]], [[System Definition|system definition]], [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], etc.). Lean engineering also interacts with and utilizes many of the [[Systems Engineering and Specialty Engineering|specialty engineering disciplines]] discussed in [[Related Disciplines|Part 6]]. |
| | | |
− | MA is part of the larger set of [[Concept Definition|concept definition]] activities - the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the (SoI) is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements|stakeholder needs and requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.
| + | ==Lean Systems Engineering== |
| + | SE is an established, sound practice, but not always delivered effectively. Most programs are burdened with some form of waste such as: poor coordination, unstable requirements, quality problems, delays, rework, or management frustration. Recent U.S. Government Accountability Office (GAO), National Aeronautics and Space Association (NASA), and Massachusetts Institute of Technology (MIT) studies of government programs document major budget and schedule overruns and a significant amount of waste in government programs - some reaching seventy percent of charged time. This waste represents a productivity reserve in programs and major opportunities to improve program efficiency. |
| | | |
− | == Purpose and Definition ==
| + | LSE is the application of lean thinking to systems engineering and related aspects of enterprise and project management. SE is focused on the discipline that enables development of complex technical systems. Lean thinking is a holistic paradigm that focuses on delivering maximum value to the customer and minimizing wasteful practices. It has been successfully applied in manufacturing, aircraft depots, administration, supply chain management, healthcare, and product development, which includes engineering. LSE is the area of synergy between lean thinking and SE, which aims to deliver the best life-cycle value for technically complex systems with minimal waste. LSE does not mean less SE. It means more and better SE with higher responsibility, authority, and accountability (RAA), leading to better, waste-free workflow with increased mission assurance. Under the LSE philosophy, mission assurance is non-negotiable and any task which is legitimately required for success must be included; however, it should be well-planned and executed with minimal waste. |
− | The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportunities and solutions that can be applied to any organization that evolves its strategy for its business objectives.
| |
| | | |
− | MA, in some domains called [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context, together with the proposed enterprise [[Concept of Operations (ConOps) (glossary)|concept of operations]] (ConOps) and operational scenarios. The primary products of MA are the revised ConOps of the enterprise, the [[Operational Concept (glossary)|operational concept]], the [[Operational Scenario (glossary)|operational scenarios]] for the mission, and the context in which the solution will exist.
| + | ===Lean Principles=== |
| + | Oppenheim (2011) describes the six lean principles for product development (PD) as follows: |
| + | #'''Capture the ''value'' defined by the customer.''' One cannot over-emphasize the importance of capturing task or program value (requirements, CONOPS, etc.) with precision, clarity, and completeness before resource expenditures ramp up to avoid unnecessary rework. |
| + | #''' ''Map the value stream (plan the program)'' and eliminate waste.''' Map all end-to-end linked tasks, control/decision nodes, and the interconnecting information flows necessary to realize customer value. During the mapping process, eliminate all non-value-added activities, and enable the remaining activities to flow (without rework, backflow or stopping). The term ''information flow'' refers to the packets of information (knowledge) created by different tasks and flowing to other tasks for subsequent value adding, such as: design, analysis, test, review, decision, or integration. Each task adds value if it increases the level of useful information and reduces risk in the context of delivering customer value. |
| + | #'''''Flow'' the work through planned and streamlined value-adding steps and processes, without stopping or idle time, unplanned rework, or backflow.''' To optimize flow, one should plan for maximum concurrency of tasks, up to near capacity of an enterprise. Legitimate engineering iterations are frequently needed in PD, but they tend to be time consuming and expensive if they extend across disciplines. Lean PD encourages efficient methodology of ''fail early - fail often'' through rapid architecting and discovery techniques during early design phases. Lean flow also makes every effort to use techniques that prevent lengthy iterations, such as design frontloading, trade space explorations, set designs, modular designs, legacy knowledge, and large margins. Where detailed cross-functional iterations are indeed necessary, lean flow optimizes iteration loops for overall value. |
| + | #'''Let customers ''pull'' value.''' In PD, the pull principle has two important meanings: (1) the inclusion of any task in a program must be justified by a specific need from an internal or external customer and coordinated with them, and (2) the task should be completed when the customer needs the output. Excessively early completion leads to “shelf life obsolescence” including possible loss of human memory or changed requirements and late completion leads to schedule slips. This is the reason that every task owner or engineer needs to be in close communication with their internal customers to fully understand their needs and expectations and to coordinate their work. |
| + | #'''Pursue ''perfection'' of all processes.''' Global competition requires continuous improvements of processes and products. Yet, no organization can afford to spend resources improving everything all the time. Systems engineers must make a distinction between processes and process outputs. Perfecting and refining the ''work output'' in a given task must be bounded by the overall value proposition (system or mission success, program budget and schedule) which define when an output is "good enough." In contrast, engineering and other ''processes'' must be continuously improved for competitive reasons. |
| + | #'''''Respect'' for people.''' A lean enterprise is an organization that recognizes that its people are the most important resource. In a lean enterprise, people are not afraid to identify problems and imperfections honestly and openly in real time, brainstorm about root causes and corrective actions without fear, or plan effective solutions together by consensus to prevent a problem from occurring again. |
| | | |
− | MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.
| + | ==Lean Enablers for Systems == |
| + | In 2009, the International Council on Systems Engineering's (INCOSE's) Lean SE Working Group (LSE WG) released an online product entitled ''Lean Enablers for Systems Engineering (LEfSE)''. It is a collection of practices and recommendations formulated as “dos” and “don’ts” of SE, based on lean thinking. The practices cover a large spectrum of SE and other relevant enterprise management practices, with a general focus on improving the program value and stakeholder satisfaction and reduce waste, delays, cost overruns, and frustrations. LEfSE are grouped under the six lean principles outlined above. The LEfSE are not intended to become a mandatory practice but should be used as a checklist of good practices. LEfSE do not replace the traditional SE; instead, they amend it with lean thinking. |
| | | |
− | ==Principles and Concepts==
| + | LEfSE were developed by fourteen experienced INCOSE practitioners, some recognized leaders in lean and SE from industry, academia, and governments (such as the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. They collected best practices from the many companies, added collective tacit knowledge, wisdom, and experience of the LSE WG members, and inserted best practices from lean research and literature. The product has been evaluated by surveys and comparisons with the recent programmatic recommendations by GAO and NASA. |
− | ===Mission Analysis and Concept of Operations===
| |
− | MA and the ConOps are broadly used in defense and aerospace organizations to analyze and define how a system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed; they take into account the strategic, operational, and tactical aspects of the identified scenarios.
| |
| | | |
− | In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering (SE) leaders interact with enterprise leaders and operations analysts to understand
| + | Oppenheim (2011) includes a comprehensive explanation of the enablers, as well as the history of LSE, the development process of LEfSE, industrial examples, and other material. Oppenheim, Murman, and Secor (2011) provide a scholarly article about LEfSE. A short summary was also published by Oppenheim in 2009. |
− | *the enterprise ConOps and future mission, business, and operational (MBO) objectives;
| |
− | *the characterization of the operational concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and
| |
− | *how specific missions or operations are currently conducted and what gaps exist in those areas.
| |
| | | |
− | They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (NDIA 2010).
| + | ==References== |
− | | |
− | <blockquote>''The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems.'' (ISO/IEC 2011) </blockquote>
| |
− | | |
− | These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (ESA 2008).
| |
− | | |
− | In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:
| |
− | | |
− | <blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia Contributors, 2012)</blockquote>
| |
− | | |
− | Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level ConOps and the system level operational concepts, [[Function (glossary) |functions]], etc. For more explanations about the ConOps and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).
| |
− | | |
− | ===Mission Analysis as Part of Enterprise Strategy Development===
| |
− | Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions.
| |
− | | |
− | [[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|'''Figure 1. Enterprise Strategy and Concept Development (Roedler 2012).''' Used with permission of Garry Roedler.]]
| |
− | | |
− | As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine readiness to achieve future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a strengths, weaknesses, opportunities, and threats (SWOT) analysis may be performed. As the problem space is defined, the stakeholder needs are defined and transformed into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.
| |
− | | |
− | ==Process Approach==
| |
− | ===Activities of the Process===
| |
− | It is necessary to perform the following major activities and tasks during this process:
| |
− | #Review and understand the enterprise mission, vision, and ConOps.
| |
− | #Identify and define any gaps and opportunities related to future evolution of the strategy:
| |
− | ##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.
| |
− | ##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well. For the technological considerations, an appropriate architectural framework representation, such as DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.
| |
− | ##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution.
| |
− | #Examine and evaluate the solution space.
| |
− | ##Identify the main stakeholders (customers, users, administrations, regulations, etc.).
| |
− | ##Identify high level operational modes or states, or potential use cases.
| |
− | ##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.
| |
− | #Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.
| |
− | #Define basic operational concept or market strategy, and/or business models.
| |
− | ##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.
| |
− | ##Collect and enrich needs, expectations, scenarios, and constraints.
| |
− | ##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.
| |
− | #Evaluate the set of alternatives and select the best alternative.
| |
− | ##Perform a trade study of the alternatives to discriminate between the alternatives.
| |
− | #Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.
| |
− | | |
− | ===Mission Analysis Artifacts===
| |
− | | |
− | This process may create several artifacts, such as
| |
− | *recommendations for revisions to the enterprise ConOps;
| |
− | *preliminary operational concept document or inputs;
| |
− | *mission analysis and definition reports;
| |
− | *system analysis artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);
| |
− | *trade study results (alternatives analysis); and
| |
− | *market study/analysis reports.
| |
− | | |
− | ===Methods and Modeling Techniques===
| |
− | | |
− | MA uses several techniques, such as
| |
− |
| |
− | *use case analysis;
| |
− | *operational analysis;
| |
− | *functional analysis;
| |
− | *technical documentation review;
| |
− | *trade studies;
| |
− | *modeling;
| |
− | *simulation;
| |
− | *prototyping;
| |
− | *workshops, interviews, and questionnaires;
| |
− | *market competitive assessments;
| |
− | *benchmarking; and
| |
− | *organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).
| |
− | | |
− | ==Practical Considerations==
| |
− | Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1.
| |
− | | |
− | <center>
| |
− | {|
| |
− | |+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)
| |
− | !Pitfall
| |
− | !Description
| |
− | |-
| |
− | |Wrong level of system addressed
| |
− | |When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.
| |
− | |-
| |
− | |Operational modes or scenarios missing
| |
− | |In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.
| |
− | |}
| |
− | </center>
| |
− | | |
− | | |
− | Proven practices with mission analysis and marketing analysis are presented in Table 2.
| |
− | | |
− | <center>
| |
− | {|
| |
− | |+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)
| |
− | !Practice
| |
− | !Description
| |
− | |-
| |
− | |Models of operational scenarios
| |
− | |Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).
| |
− | |-
| |
− | |Models of the context
| |
− | |Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).
| |
− | |}
| |
− | </center>
| |
− | | |
− | ==References== | |
| | | |
| ===Works Cited=== | | ===Works Cited=== |
− | ESA. 2008. ''Mission Analysis: Towards a European Harmonization.'' Paris, France: European Space Agency. Accessed August 29, 2012. Available at: http://www.esa.int/esapub/bulletin/bulletin134/bul134b_schoenmaekers.pdf.
| + | Lean Systems Engineering Working Group. 2009. "Lean Enablers for Systems Engineering." Accessed 13 January 2016 at http://www.lean-systems-engineering.org/wp-content/uploads/2012/07/Lean-Enablers-for-SE-Version-1_03-.pdf. |
| | | |
− | Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”
| + | Lean Systems Engineering Working Group. 2009. "Quick Reference Guide Lean Enablers for Systems Engineering." Accessed 13 January 2016 at http://www.lean-systems-engineering.org/wp-content/uploads/2012/07/LEfSE-Quick-Reference-Guide-8-pages.pdf. |
| | | |
− | IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.
| + | Oppenheim, B.W. 2009. "Process Replication: Lean Enablers for Systems Engineering." ''CrossTalk, The Journal of Defense Software Engineering.'' July/August 2009. |
| | | |
− | ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011
| + | Oppenheim, B.W. 2011. ''Lean for Systems Engineering, with Lean Enablers for Systems Engineering''. Hoboken, NJ, USA: Wiley. |
| | | |
− | ISO/IEC/IEEE. 2008. ''Systems and Software Engineering - System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
| + | Oppenheim, B.W., E.M. Murman, and D. Secor. 2011. "Lean Enablers for Systems Engineering." ''Journal of Systems Engineering.'' 1(14). |
| | | |
− | ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Requirements Engineering''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.
| + | Womack, J.P. 2003. ''Lean Thinking.'' Columbus, OH, USA: Free Press. |
− | | |
− | Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008
| |
− | | |
− | Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.
| |
− | | |
− | NDIA. 2010. “Mission Analysis Committee Charter”. Website of the National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee. Accessed August 29, 2012. Available at: http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Mission%20Analysis%20Committee%20Charter.pdf.
| |
− | | |
− | Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.
| |
− | | |
− | Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).
| |
| | | |
| ===Primary References=== | | ===Primary References=== |
− | ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).
| + | Lean Systems Engineering Working Group. 2009. "[[INCOSE Lean Enablers for Systems Engineering|Lean Enablers for Systems Engineering]]." Accessed 13 January 2016 at<nowiki/>http://www.lean-systems-engineering.org/wp-content/uploads/2012/07/Lean-Enablers-for-SE-Version-1_03-.pdf. |
− | | |
− | ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].
| |
− | | |
− | INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
| |
| | | |
− | Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.
| + | Oppenheim, B., E. Murman, and D. Sekor. 2010. "[[Lean Enablers for Systems Engineering]]." Systems Engineering. 14(1). Accessed 13 January 2016. Available at http://www.lean-systems-engineering.org/wp-content/uploads/2012/07/LEfSE-JSE-compressed.pdf. |
| | | |
| ===Additional References=== | | ===Additional References=== |
− | Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993).
| + | Lean Enterprise Institute. 2009. "Principles of Lean." Accessed 1 March 2012 at http://www.lean.org/WhatsLean/Principles.cfm. |
| | | |
− | Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.
| |
− |
| |
− | IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.
| |
− |
| |
− | Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.
| |
− |
| |
− | Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984).
| |
− |
| |
− | Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309.
| |
− |
| |
− | Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.
| |
− |
| |
− | MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].
| |
− |
| |
− | MITRE. 2011. "Requirements Engineering." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/requirements_engineering/]].
| |
− |
| |
− | MITRE. 2011. "Stakeholder Assessment and Management." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/stakeholder_assessment_management.html]].
| |
| ---- | | ---- |
− | <center>[[Concept Definition|< Previous Article]] | [[Concept Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center> | + | <center>[[Integration of Process and Product Models|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[Concept Definition|Next Article >]]</center> |
− | | |
| | | |
| + | <center>'''SEBoK v. 2.0, released 1 June 2019'''</center> |
| | | |
− | [[Category: Part 3]][[Category:Topic]] | + | [[Category:Part 3]] |
− | [[Category:Concept Definition]] | + | [[Category:Topic]] |
− | {{DISQUS}}
| + | [[Category:Life Cycle Models]] |
Lean Systems Engineering (LSE)Lean Systems Engineering (LSE) is the application of lean thinking (Womack 2003) to systems engineering (SE) and related aspects of enterprise and project management. LSE is an approach that is applicable throughout the system life cyclelife cycle. The goal of LSE is to deliver the best life-cycle value for technically complex systems with minimal waste. Lean engineering is relevant to all of the traditional SE technical processes (see concept definition, system definition, system realization, system deployment and use, etc.). Lean engineering also interacts with and utilizes many of the specialty engineering disciplines discussed in Part 6.
Lean Systems Engineering
SE is an established, sound practice, but not always delivered effectively. Most programs are burdened with some form of waste such as: poor coordination, unstable requirements, quality problems, delays, rework, or management frustration. Recent U.S. Government Accountability Office (GAO), National Aeronautics and Space Association (NASA), and Massachusetts Institute of Technology (MIT) studies of government programs document major budget and schedule overruns and a significant amount of waste in government programs - some reaching seventy percent of charged time. This waste represents a productivity reserve in programs and major opportunities to improve program efficiency.
LSE is the application of lean thinking to systems engineering and related aspects of enterprise and project management. SE is focused on the discipline that enables development of complex technical systems. Lean thinking is a holistic paradigm that focuses on delivering maximum value to the customer and minimizing wasteful practices. It has been successfully applied in manufacturing, aircraft depots, administration, supply chain management, healthcare, and product development, which includes engineering. LSE is the area of synergy between lean thinking and SE, which aims to deliver the best life-cycle value for technically complex systems with minimal waste. LSE does not mean less SE. It means more and better SE with higher responsibility, authority, and accountability (RAA), leading to better, waste-free workflow with increased mission assurance. Under the LSE philosophy, mission assurance is non-negotiable and any task which is legitimately required for success must be included; however, it should be well-planned and executed with minimal waste.
Lean Principles
Oppenheim (2011) describes the six lean principles for product development (PD) as follows:
- Capture the value defined by the customer. One cannot over-emphasize the importance of capturing task or program value (requirements, CONOPS, etc.) with precision, clarity, and completeness before resource expenditures ramp up to avoid unnecessary rework.
- Map the value stream (plan the program) and eliminate waste. Map all end-to-end linked tasks, control/decision nodes, and the interconnecting information flows necessary to realize customer value. During the mapping process, eliminate all non-value-added activities, and enable the remaining activities to flow (without rework, backflow or stopping). The term information flow refers to the packets of information (knowledge) created by different tasks and flowing to other tasks for subsequent value adding, such as: design, analysis, test, review, decision, or integration. Each task adds value if it increases the level of useful information and reduces risk in the context of delivering customer value.
- Flow the work through planned and streamlined value-adding steps and processes, without stopping or idle time, unplanned rework, or backflow. To optimize flow, one should plan for maximum concurrency of tasks, up to near capacity of an enterprise. Legitimate engineering iterations are frequently needed in PD, but they tend to be time consuming and expensive if they extend across disciplines. Lean PD encourages efficient methodology of fail early - fail often through rapid architecting and discovery techniques during early design phases. Lean flow also makes every effort to use techniques that prevent lengthy iterations, such as design frontloading, trade space explorations, set designs, modular designs, legacy knowledge, and large margins. Where detailed cross-functional iterations are indeed necessary, lean flow optimizes iteration loops for overall value.
- Let customers pull value. In PD, the pull principle has two important meanings: (1) the inclusion of any task in a program must be justified by a specific need from an internal or external customer and coordinated with them, and (2) the task should be completed when the customer needs the output. Excessively early completion leads to “shelf life obsolescence” including possible loss of human memory or changed requirements and late completion leads to schedule slips. This is the reason that every task owner or engineer needs to be in close communication with their internal customers to fully understand their needs and expectations and to coordinate their work.
- Pursue perfection of all processes. Global competition requires continuous improvements of processes and products. Yet, no organization can afford to spend resources improving everything all the time. Systems engineers must make a distinction between processes and process outputs. Perfecting and refining the work output in a given task must be bounded by the overall value proposition (system or mission success, program budget and schedule) which define when an output is "good enough." In contrast, engineering and other processes must be continuously improved for competitive reasons.
- Respect for people. A lean enterprise is an organization that recognizes that its people are the most important resource. In a lean enterprise, people are not afraid to identify problems and imperfections honestly and openly in real time, brainstorm about root causes and corrective actions without fear, or plan effective solutions together by consensus to prevent a problem from occurring again.
Lean Enablers for Systems
In 2009, the International Council on Systems Engineering's (INCOSE's) Lean SE Working Group (LSE WG) released an online product entitled Lean Enablers for Systems Engineering (LEfSE). It is a collection of practices and recommendations formulated as “dos” and “don’ts” of SE, based on lean thinking. The practices cover a large spectrum of SE and other relevant enterprise management practices, with a general focus on improving the program value and stakeholder satisfaction and reduce waste, delays, cost overruns, and frustrations. LEfSE are grouped under the six lean principles outlined above. The LEfSE are not intended to become a mandatory practice but should be used as a checklist of good practices. LEfSE do not replace the traditional SE; instead, they amend it with lean thinking.
LEfSE were developed by fourteen experienced INCOSE practitioners, some recognized leaders in lean and SE from industry, academia, and governments (such as the U.S., United Kingdom, and Israel), with cooperation from the 160-member international LSE WG. They collected best practices from the many companies, added collective tacit knowledge, wisdom, and experience of the LSE WG members, and inserted best practices from lean research and literature. The product has been evaluated by surveys and comparisons with the recent programmatic recommendations by GAO and NASA.
Oppenheim (2011) includes a comprehensive explanation of the enablers, as well as the history of LSE, the development process of LEfSE, industrial examples, and other material. Oppenheim, Murman, and Secor (2011) provide a scholarly article about LEfSE. A short summary was also published by Oppenheim in 2009.
References
Works Cited
Lean Systems Engineering Working Group. 2009. "Lean Enablers for Systems Engineering." Accessed 13 January 2016 at http://www.lean-systems-engineering.org/wp-content/uploads/2012/07/Lean-Enablers-for-SE-Version-1_03-.pdf.
Lean Systems Engineering Working Group. 2009. "Quick Reference Guide Lean Enablers for Systems Engineering." Accessed 13 January 2016 at http://www.lean-systems-engineering.org/wp-content/uploads/2012/07/LEfSE-Quick-Reference-Guide-8-pages.pdf.
Oppenheim, B.W. 2009. "Process Replication: Lean Enablers for Systems Engineering." CrossTalk, The Journal of Defense Software Engineering. July/August 2009.
Oppenheim, B.W. 2011. Lean for Systems Engineering, with Lean Enablers for Systems Engineering. Hoboken, NJ, USA: Wiley.
Oppenheim, B.W., E.M. Murman, and D. Secor. 2011. "Lean Enablers for Systems Engineering." Journal of Systems Engineering. 1(14).
Womack, J.P. 2003. Lean Thinking. Columbus, OH, USA: Free Press.
Primary References
Lean Systems Engineering Working Group. 2009. "Lean Enablers for Systems Engineering." Accessed 13 January 2016 athttp://www.lean-systems-engineering.org/wp-content/uploads/2012/07/Lean-Enablers-for-SE-Version-1_03-.pdf.
Oppenheim, B., E. Murman, and D. Sekor. 2010. "Lean Enablers for Systems Engineering." Systems Engineering. 14(1). Accessed 13 January 2016. Available at http://www.lean-systems-engineering.org/wp-content/uploads/2012/07/LEfSE-JSE-compressed.pdf.
Additional References
Lean Enterprise Institute. 2009. "Principles of Lean." Accessed 1 March 2012 at http://www.lean.org/WhatsLean/Principles.cfm.
< Previous Article | Parent Article | Next Article >
SEBoK v. 2.0, released 1 June 2019