Managing the systems lifecycle: systems engineering competencies and approaches

1. Managing the systems lifecycle: systems engineering competencies and approaches Professor Michael Henshaw Loughborough University, UK

2. Content • Competency in Systems Engineering • System lifecycles • Standards • ISO15288 the systems engineering lifecycle standard

3. Systems Thinking for Energy Negative Behavioural Change Example from Geoff Robinson, of Atkins, Keynote at ieeeSoSE 2010 Bio Fuels for cars CO2 Food shortages Increase Bio Fuel Production Processing De -forestation Systems Thinking: Understand complex problems Explore wider set of options

4. INCOSE Competency Framework Systems Thinking Systems concepts Super system capability issues Enterprise and technology environment Holistic Lifecycle View Determine and manage stakeholder requirements Systems design Architectural design Concept generation Design for... Functional analysis Interface management Maintain design integrity Modelling and simulation Select preferred solution System robustness Systems integration and verification Validation Transition to operation Systems Engineering Management Concurrent engineering Enterprise integration Integration of specialisms Lifecycle process definition Planning, monitoring and controlling

5. Typical stages of lifecycle management Initiation Planning & Design Execution Monitoring & Control Closing

6. Holistic lifecycle view • Whole life costs • Maintaining performance, safety, security, etc. • Retaining knowledge of the system • Upgrades • Risks over time • Disposal Image: Hunt Emerson

7. A System • Definition of a system • A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. • The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. ......... (Rechtin, 2000). INCOSE definition (first part) Image: AP

8. Systems Engineering and the Systems Life Cycle Standard Required by 1. Systems Eng. and systems thinking 1. Standards Mindset and approach for 2. System Life cycles Is an appropriate Enables mgt of Applies std. Defines ISO15288 -scope -structure -use 3. System of interest 5. Tailoring Requires Constrains illustrates 7. Limitations 6. Case studies

9. Standards - why they are important The need for standards and Systems Engineering

10. Standards: Benefits and Applicability • Benefits • Safety • Interoperability • Quality • Upgradeability • Applicability • Business • Trade • Technical • Engineering • Finance • Etc.

11. Application to project phases SAE DIN BSI Manufacture ASME IEC ASTM Design Operation ISO ISO ITU API – Application Programming Interface Construction ASME - American Society of Mechanical Engineers ASTM – American Society for the Testing of Materials API ASME BSI - British Standards Institution DIN - Deutsches Institut für Normung eV IEC - International Electrotechnical Commission ISO - International Standards Organization From ‘Why Standards are Important’, IHS Whitepaper, www.ihs.com ITU – International Telecommunications Union SAE - Society of Automotive Engineers

12. Compliance • Regulation • A regulation is a legal requirement and compliance is, therefore, compulsory. A regulation is usually developed by Government and specifies what must be done, but without specifying how it must be done. • Code • A code is a standard (developed by an appropriate body) and adopted by a Government entity. Compliance is compulsory. • Standard • A specification of best practice developed by experts and based on consensus. It is recognised by an appropriate standards development organisation. Compliance is voluntary. Based on ‘Why Standards are Important’, IHS Whitepaper, www.ihs.com

13. Part 4 – ISO 15288 Origin of ISO 15288 Application and characteristics of the standard Basic content of the standard

14. Origin of ISO 15288 Emerging Standards Systems context 1960 Space systems Military and civilian std. in US Increasing complexity 1970 Std. In EU Complex manufacture 1980 Software Software std. 1990 2000 ISO 15288 (2002) 2010 ISO 15288 (2008)

15. Characteristics of 15288 (1) • Product/service • Although described as applicable to service systems, the language and approach is strongly product based • Description • Standard is a comprehensive list of processes for life cycle management, but none is specified in detail • Cannot be used without tailoring • High-tech. Organisations recognise the standard, but don’t usually seek rigid compliance

16. Characteristics of 15288 (2) • Uses • As an outline framework from which organisation engineering and project management processes may be derived • As a checking procedure for extant processes • Level of compliance can indicate areas for process improvement • Compliance is seen as meritorious, but not essential

17. Significant INCOSE Publications based on 15288 • INCOSE Handbook • INCOSE 2010 systems engineering handbook, version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2 • INCOSE UK Systems Engineering Competency Framework • INCOSE UK 2010

18. Application • Enterprise Enduring General across all projects Organisation Long term Single project Project Enterprise Short term Tailoring General/high level – slowly changing Procedures : Processes Consistency Processes Specific/detailed – as & when required

19. Generic Lifecycle • A system progresses through specific stages during its life • In reality stages overlap • Enabling systems are required at each stage • All stages should be considered at design time and lifecycle features incorporated Utilisation stage Concept stage Development stage Production stage Retirement stage Support stage

20. ISO 15288 Content Project Processes Technical Processes Agreement Processes Acquisition Stakeholder Req. Definition Project Planning Supply Project Assessment & Control Req. Analysis Architecture Design Decision Mgt Organizational Project-Enabling Processes Implementation Risk Mgt Integration Life Cycle Model Mgt Configuration Mgt Verification Transition Infrastructure Mgt Information Mgt Validation Project Portfolio Mgt Measurement Operation Human Resource Mgt Maintenance System Life Cycle Processes Disposal Quality Mgt Based on ISO/IEC, 2008 figure 4

21. Agreement Processes • Provides symmetric processes for supplier and customer • Supply process • Acquisition process • Largely concerned with commercial matters • Not necessarily executed by engineers • Covers selection of or as supplier, acceptance criteria of product/service, financial arrangements

22. Organizational Project-Enabling Processes • Processes put underlying plan and resources in place • Selection/creation of appropriate life cycle model provides underlying assumption for whole project • E.g. CADMID underpins all UK defence acquisitions • Creation and maintenance of appropriate infrastructure for project • Note that different organizations have different definitions of infrastructure (buildings, communication channels, computer networks, ...) • Business decisions about portfolio of projects (sub-projects) • Skills and human resources planned • Quality procedures for project • Note that these will often be defined at the organization level, rather than at the individual project level

23. Project Processes • Mostly concerned with project management • Considerable overlap between systems engineering and project management • Need to be consistent with standard project managment processes of the organization • Standard distinguishes between Project management and project support • Management: planning and assessment/control • Support: decision, risk, information, measurement, and configuration control

24. Technical Processes • Focused on classic Systems Engineering aspects • Vee-model • Stakeholder analysis and Requirements • Design (architecture) • Implementation and Integration • Verification, Transition, and Validation • Operation, Maintenance • Disposal

25. (Typical) Vee-Model Concept of Operation Operation & maintenance Verification and Validation Requirements Validation Architecture Systems Verification Project test & integration Project Definition Detailed Design Test, and verification Integration Implementation Time

26. (Typical) Vee-Model + 15288 Technical Processes Disposal Maintenance Concept of Operation Operation & maintenance Stakeholder Req. Definition Operation Verification and Validation Requirements Requirements analysis Validation Validation Transition Verification Architecture Design Architecture Systems Verification Project test & integration Project Definition Detailed Design Test, and verification Integration Integration Implementation Implementation Time

27. Use • To some extent, ISO 15288 represents the collation of good practice • Organisations that develop complex systems may have procedures and processes that follow 15288 implicitly • Compliance may be advised but rarely (never?) compulsory

28. Limitations: SoS Properties - Emergence Desirable/ predicted Desirable/ unpredicted Undesirable/ unpredicted Desirable properties are designed to emerge Systems Subsystems Components Emergence is a phenomenon ascribable to the whole system and not to any of its individual parts. Some maintain it is only applied to something that has not been predicted, others that it may be either planned or unexpected Traditional systems engineering; well understood subsystems etc.; V&V Systems of systems engineering; incomplete knowledge of interactions, complexity, strong emergence

29. Managing and Engineering Members of the SoS owners’ club have partial knowledge and influence Need to engineer for compliance (interoperability) Standards Manage own system (part) through control Manage other parts of SoS through influence, protective measures, collaboration, … (not at all) If systems thinking tells us that we should make our systems behave in certain ways to maximise benefit, why don’t we do it? From the single-system community’s perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an (sic) SoS seen as a net gain from the viewpoint of single-system stakeholders. George Rebovich, Jr., 2009

30. Traditional SE versus SoSE SoS Table 1. SE versus SoSE From Neaga Henshaw and Yue, 2009

31. Limitations of the Standard What worked in the past will not always work in the future.

32. Systems Engineering • New publication available: • Guide to the Systems Engineering Body of Knowledge (SEBoK) at http://www.sebokwiki.org

33. Back-up slides

34. Example of use • Large defence related organisation has recently carried out a skills audit using the INCOSE Competency Framework • This provides health check for systems engineering skills and marketing information for use with clients