Systems Engineering - In Retrospect and In Prospect

1. Systems Engineering - In Retrospect and In Prospect Peter Robson Systems Engineering Consultant

2. Overview of Paper • Introduction • Generic Systems Engineering • Systems Engineering Maturity • Performance • Methodology • Focus • Life Cycle • In Retrospect • In Prospect • Conclusions

3. Disclaimers • My views only! • Examples come primarily from defence background • but read across / translate to other sectors • Examples are mostly end customer – prime supplier • but don’t forget that prime suppliers are customers down the supply chain • Not an analysis of thirty years of systems theory • but subjective identification of key issues

4. Introduction • Resurgence of national interest in systems engineering during the last decade • DTI’s Foresight Systems Engineering Working Party • MOD’s initiative on ‘Smart’ Procurement’ • Importance of systems engineering to other sectors of industry • Signs that the resurgence has not taken sufficient root • Systems engineering is a shared interest throughout the whole supply-and-use chain for a project or product

5. Thesis “Complementary systems engineering capabilities are needed within and between the various enterprises in the supply chain, in particular between customers and suppliers”

6. Generic Systems Engineering • What is a System? • “A system is an interacting combination of elements, viewed in relation to function” • the human element • emergent properties • What is Systems Engineering? • “Systems engineering is the art and science of creating complex systems” (Hitchins) • Discovery, a specialist type that involves significant analysis, particularly of the problem space (Sheard) • Program Systems Engineering, a co-ordination or generalist type that emphasises the solution space and technical and human interfaces (Sheard) • Approach, a process type that can (and should) be performed by any engineer(Sheard)

7. Generic Systems Engineering • The Human Foundation of Systems Engineering • Propositions about Humans and Problems • Propositions about Knowledge • Propositions about Systems Engineering • Systems Hierarchies Constituents of a system Systems engineering hierarchy

8. Structure based on SE Maturity Model based on Brian Mar’s “Systems Engineering Maturity Model”NCOSE 1993

9. Performance Have we just promised to provide SE (Level 1) or have we demonstrated it (Level 2) or have we made it repeatable (Level 3) or have we already improved our (repeatable) systems engineering process (Level 4)?

10. The Best of Cost-Plus :The heady days of Ptarmigan • Succinct top-level User requirement • Strong MOD/SRDE/Industry team built-up through earlier studies and demonstrator activities • Green-field approach to management and technical processes (top-down) • Time to think first then act • Trade-offs ‘round the table’ - an integrated project team! • How do we recapture the best of this?

11. The Worst of Fixed-Price • The requirement is assumed complete and fixed • Implementation defined as part of the requirement • Lip-service paid to whole-life costs • Jump off the cliff if you want to win • Don’t bother to explain the potential problems and how they’ve been allowed for in the price • The customer won’t be impressed, he’s looking for someone that doesn’t have problems • Sort it out after you’ve won • You’re bound to make a loss reworking and retesting • The customer will slag you off because of late delivery • Next time, someone else can jump!

12. Becoming Smarter? • Match the chosen procurement approach to the feasibility of the systems engineering involved • A cry for “faster, cheaper, better” in accordance with the principles of systems engineering is unlikely to be successful unless complemented by other changes • Recognise precedented ‘project systems’ should be delivering the ‘unprecedented systems’ • Complete the bridges between • systems engineering and project management • customer and supplier • Customers must have a full systems engineering capability • education and training in SE process, methods and tools

13. Laws & Principles • Foresight SEWP Report • Build the right system • Build the system right • EIA/IS 632 Standard • The right things should be done • The right things should be done at the right time • The right things should be done by the right people • The right things should be done right the first time • Simple, even trivial, statements but often forgotten and difficult to achieve

14. Methodology Do we think SE is just documents (Level 1) or about producing a self-consistent set of requirements, functions and architectures (Level 2) or are we able to simulate our systems dynamically before trying to build them (Level 3) or have we done all this and have now optimised our approach (Level 4)?

15. Methodology • Level 1 - documents, documents and more documents • Level 2 - process together with recognition that SE is about ‘joined up information’ • base on needs  design  analysis not requirements  analysis  design • ‘process’ not ‘lifecycle’ • but more than ‘process’, more than ‘information’ - emphasis on design or architecting • systems engineering plans • systems engineering tools • ‘tribalism’ becomes more visible • Level 3 - dynamic interactions between system elements • discover emergent properties sooner! • Becoming smarter - does concurrency help? • handle increased concurrency in the ‘project production system’ with care!

16. Focus Are we doing SE on our products only for those customers that have demanded it (Level 1) or do we apply SE to the process as well but again only at customer demand (Level 2) or are we mature enough to apply SE to all our products because we believe in SE as a contractor (Level 3) or do we apply it to our processes as well (Level 4)?

17. Focus • Dimension reflects a contractor’s motivation or enlightened self-interest • Focus metric is defined as two state pairs • is systems engineering driven by the customer or the producer (contractor)? • is systems engineering used to develop the product or the process? • Level 1 harks back to the days when the contract would stipulate the applicable standards • Relates to the role of systems engineering standards and maturity models

18. External standards - just what are they for? • Provide an external and believable reference • rather like a consultant, only impersonal and cheaper! • Level the playing field for procurers and suppliers • Capture of best practice • Avoid inappropriate practice • e.g. misapplication of software-based systems approaches to levels of systems well above software • Establish a common language • eliminate the need for the SE Babel Fish! • Aid to the conduct of Program Systems Engineering • not so useful for mandating that “the fundamental concepts of generic systems engineering shall be followed”

19. Key Issues for SE Standards • Essence of SE v detailed systematic engineering • Needs  Design  Analysis rather than Requirements  Analysis  Design? • Process v Life Cycles? • Synthesis v Decomposition? • Hard (Products) or Hard  Soft (Services)? • SE component of SW standards? • Project management - in or out? • Humans - in or out? • Software engineering - in or out?

20. Capability Maturity Models - do they help? • EIA 731 SECM • can really help an organisation assess its capability to carry out systems engineering • not a standard for systems engineering, or for a systems engineering process • encourages systematic engineering in a more capable way • EIA 731 status and intended use

21. EIA 731 status and intended use “This Interim Standard is intended solely to be used for self-development, self-improvement, and self-appraisal. Organizations should not apply this Interim Standard to suppliers as a means of source selection or as a means of qualification to be a supplier.” EIA 731 Part 1 Section 2.3

22. Capability Maturity Models - do they help? • EIA 731 SECM • can really help an organisation assess its capability to carry out systems engineering • not a standard for systems engineering, or for a systems engineering process • encourages systematic engineering in a more capable way • EIA 731 status and intended use • but customers using SECM in source selection to help give confidence in the outcome of a resultant contract • Pursuit of ‘Focus maturity’ • mixture of self-assessment and third-party assessment on an annual cycle • Customers need to apply SECM to themselves • SE is not done only by suppliers • SE is a critical capability for customers who want their projects to succeed

23. The tyranny of requirements • The apparent inability of customers to ‘focus’ on the wider aspects of systems engineering is a major cause of project failure • Customers must aspire to more than ‘systematic requirements engineering’ • even though this contains much good practice • e.g. establish a minimal and abstracted set of project requirements, fully traceable and verifiable and which do not constrain the creativity of both customer and supplier • Over-emphasis on functional requirements at the expense of non-functional requirements • desired ‘emergent properties’ often relate to NFRs

24. Requirements and Options

25. The tyranny of requirements- quote from a past INCOSE President “If someone is trying to contract for a system, and they can properly identify all the necessary ‘requirements’, then it makes sense to do so. The preference then usually becomes: “meet the requirements, and pick the lowest cost.” But the reality is, in every complex system I've seen, “most ‘requirements’ aren't.” Given the right combination, nearly any ‘requirement’ will be relaxed to obtain some other gain. The real preferences are hidden behind the ‘requirements’ in some operational analysis space. This is the ‘real’ reason behind the recent Acquisition Reform initiatives to contract based on performance specifications - but even these initiatives don't go far enough. As soon as someone lists a set of ‘requirements’ without indicating what makes one system better than another, they've lost the information for comparison.” Eric Honour

26. Life Cycle Do we apply SE only during the concept phase of projects (Level 1) or throughout the development phase (Level 2) or throughout production and delivery (Level 3) or does SE form the basis for all project activities, including operation, modification and decommissioning (Level 4)?

27. Life Cycle • Lifecycles are well appreciated • but the ordering of the four levels of maturity is telling • Processes associated with all stages of the lifecycle are active throughout the lifecycle • Stakeholders associated with all stages of the lifecycle need to be active throughout the lifecycle as well • Sponsor, User, Procurer, Technical Adviser, Supplier, Operator, Maintainer, …. • Exclusion of suppliers during the formative work on a project significantly increases the risk to the project

28. SE Maturity of UK Industry

29. The ‘People Problem’ • Common factor many problems is ‘people’ rather than technical issues • particularly true for Program Systems Engineering • SE is not the responsibility of a single ‘tribe’ of Systems Engineers within industry • Project management must use SE principles to design projects • Software engineers (and other engineering disciplines) must adopt a SE approach, which complements that on the overall project • Customers must carry out SE activities in cooperation with their suppliers • So – what are the prospects for Systems Engineering?

30. In Prospect • Overview • Barriers to SE excellence • SE research objectives • Management of SE research projects/programmes • Barriers in a SE research programme • Conclusions

31. In Prospect - Overview • SE has had many major successes • but it clear that much remains to be done • What are its prospects for the coming decade? • What aspects need to be tackled? • The ‘SERF’ Report • Boardman, J, Tully, C & Rose, M; ‘Systems Engineering: A Research Framework’; Report published by De Montfort University, 1997 • Update of personal input to the study

32. Barriers to SE excellence • Lack of understanding of the potential of SE within industry • Ill-considered systems procurements • Poor conceptual understanding of SE • i.e. regarded only as a engineering specialisation, domain by domain • Lack of training, both on and off job • Lack of recognised qualifications • Reluctance to apply SE to other than deliverable engineering projects • i.e. not to project or business processes or to service-providing systems • Too close association of SE with software engineering • leading to demarcation issues which give impression that SE only applies to computer-based systems • Over-reliance on SECM and (potentially) CMMI models for SE capability improvement • Over-specialisation in UK educational system (leading to fragmentation of engineering disciplines)

33. Barriers to SE excellence • Lack of understanding of the potential of SE within industry • Ill-considered systems procurements • Poor conceptual understanding of SE • Lack of training, both on and off job • Lack of recognised qualifications • Reluctance to apply SE to other than deliverable engineering projects • Too close association of SE with software engineering • Over-reliance on SECM and (potentially) CMMI models for SE capability improvement • Over-specialisation in UK educational system (leading to fragmentation of engineering disciplines) The ‘People Problem’ is very apparent in the above list. For systems engineering to take its proper place in the future, these barriers need to be removed or steps taken to overcome them.

34. Systems Engineering Research Objectives • Generic system architectures for complex systems • Taxonomies for systems • Approaches to requirements elicitation and subsequent cost/benefit analysis to facilitate trade-offs • Generic SE process with per-domain interpretations • Techniques for information-based SE • e.g. to allow greater abstraction than process-based SE • Interaction of SE with project management • Application of SE to project design • i.e. to the system for producing the system • Methods for system behavioural and performance modelling • SE tool integration & interfacing • Assessment of quality of a system design and appropriate metrics • SE processes tailored to evolving systems and to ‘systems of systems’ rather than just to unprecedented systems • SE applied to human aspects of systems and to human organisations in general

35. Systems Engineering Research Objectives • Generic system architectures for complex systems • Taxonomies for systems • Approaches to requirements elicitation and subsequent cost/benefit analysis to facilitate trade-offs • Generic SE process with per-domain interpretations • Techniques for information-based SE • Interaction of SE with project management • Application of SE to project design • Methods for system behavioural and performance modelling • SE tool integration & interfacing • Assessment of quality of a system design and appropriate metrics • SE processes tailored to evolving systems and to ‘systems of systems’ rather than just to unprecedented systems • SE applied to human aspects of systems and to human organisations in general Work on many topics is on-going; no claims for originality! The need for more work on and a better understanding of ‘soft’ systems engineering is apparent, together with techniques to facilitate ‘read across’ from one application domain to another.

36. Management of SE research projects/ programmes • National Systems Engineering Research Agenda supported by Government, Academia and Industry (not tied to specific engineering disciplines or domains) • Evolution of INCOSE UK Chapter into THE recognised body for Systems Engineering (not tied to specific engineering disciplines or domains • Network of excellence for systems engineering, provided in association with INCOSE The DTI’s System Integration Initiative was a major achievement of the Foresight work but it has not been adequately consolidated by the Systems Engineering National Advisory Committee or networks of excellence.

37. Barriers in a systems engineering research programme • Emphasis on discipline boundaries in academia and engineering institutions • Lack of formally trained and industrially experienced academic staff • Unwillingness/inability of industry to release experienced SE staff to help overcome academia's shortfalls • INCOSE UK Chapter may not be able to evolve beyond group of "enthusiasts“ • hence be unable to exercise influence over the national agenda These barriers need to be tackled to assure the future of systems engineering.

38. Conclusions “In some ways, the whole paper is a conclusion, or rather an interim conclusion. Perhaps the point that stands out above all others is the extent of the ‘People Problem’; this is far more likely to hold back the advancement of systems engineering than a lack of systems theory.”