Presentation is loading. Please wait.

Presentation is loading. Please wait.

INCOSE UK Spring Symposium 2001 PGR Systems Engineering - In Retrospect and In Prospect Peter Robson Systems Engineering Consultant.

Similar presentations


Presentation on theme: "INCOSE UK Spring Symposium 2001 PGR Systems Engineering - In Retrospect and In Prospect Peter Robson Systems Engineering Consultant."— Presentation transcript:

1 INCOSE UK Spring Symposium 2001 PGR Systems Engineering - In Retrospect and In Prospect Peter Robson Systems Engineering Consultant

2 INCOSE UK Spring Symposium 2001 PGR Overview of Paper Introduction Generic Systems Engineering Systems Engineering Maturity –Performance –Methodology –Focus –Life Cycle In Retrospect In Prospect Conclusions

3 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR Thesis “Complementary systems engineering capabilities are needed within and between the various enterprises in the supply chain, in particular between customers and suppliers”

6 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR Structure based on SE Maturity Model based on Brian Mar’s “Systems Engineering Maturity Model” NCOSE 1993

9 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR Requirements and Options

25 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR SE Maturity of UK Industry

29 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR In Prospect Overview Barriers to SE excellence SE research objectives Management of SE research projects/programmes Barriers in a SE research programme Conclusions

31 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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 INCOSE UK Spring Symposium 2001 PGR 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.”


Download ppt "INCOSE UK Spring Symposium 2001 PGR Systems Engineering - In Retrospect and In Prospect Peter Robson Systems Engineering Consultant."

Similar presentations


Ads by Google