Seven systems engineering myths and the corresponding realities

1,937 views

Published on

Published in: Engineering, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,937
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
69
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Seven systems engineering myths and the corresponding realities

  1. 1. Seven systems engineeringmyths and the corresponding realities Joseph E. Kasser Visiting Associate Professor Temasek Defence Systems Institute National University of Singapore Email joseph.kasser@incose.org Copyright Joseph Kasser 2010 1
  2. 2. Topics The state of systems engineering 2010 Seven systems engineering myths Copyright Joseph Kasser 2010 2
  3. 3. Systems engineering  Means whatever the speaker intends  Subjective, no anchor points  Endless pronouncements of positions  Overlaps with other ways of doing things  Management, design, problem solving, OR  Confusing information in text books  Opinions of authors (mine included)  Poorly practiced  Defects in paradigm  Promises big things  Reports of successes and failures  Snake oil salesmen?INCOSE Fellows Briefing on SEBoK, July 2009 Copyright Joseph Kasser 2010 3
  4. 4. State of Systems Engineering at INCOSE IS Academic Forum 2009 Electrical engineering before Ohm’s law was postulated Electrical engineering before Maxwell’s equations were stated  engineers built motors by winding coils but had no theory upon which to predict the behaviour of the motor before powering it up for the first time Chemistry before the periodic table of elements was discovered Medicine in the 1800’s  before medical science provided a theory of why some medications work and why some don’t Copyright Joseph Kasser 2010 4
  5. 5. The discipline Systems engineering is in its early stages. A discipline in these stages is characterized by  debates based on subjective opinions  participants talking past each other  a lack of listening  contradictory and confusing information  a number of myths Copyright Joseph Kasser 2010 5
  6. 6. Seven systems engineering myths Myth 1: There are Standards for systems engineering Myth 2: The “V” model of the systems engineering process Myth 3: Follow the systems engineering process and all will be well Myth 4: Complexity needs new tools and techniques Myth 5: Systems of systems are a different class of problem and need new tools and techniques Myth 6: Changing requirements are a cause of project failure so get the requirements up front Myth 7: The single systems engineering process Copyright Joseph Kasser 2010 6
  7. 7. Bear with me: helicopter view “Else” is doing her systems engineering hereSystems engineers at work in Copyright Joseph Kasser 2010 7
  8. 8. The Hitchins-Kasser-Massie Framework for understanding systems engineering** Kasser and Massie, 2000 Copyright Joseph Kasser 2010 8
  9. 9. MIL-STD’s freely available at http://www.everyspec.com Myths of systems engineering Myth  There are Standards for systems engineering Reality  There are no such Standards  Standards cover  Process for engineering systems  different parts of the process  Engineering Management  Moreover, Standards focus on wrong aspect Copyright Joseph Kasser 2010 9
  10. 10. 499 Systems engineering management Purpose to develop a Systems Engineering Management Plan  Not to do systems engineering Two templates  Generally not tailored MIL-STD-299A Systems Engineering Management Copyright Joseph Kasser 2010 10
  11. 11. EIA-632 Process for engineering a system Not process for systems engineering Copyright Joseph Kasser 2010 11
  12. 12. IEEE-1220  Management of the systems engineering process  Not doing systems engineeringThe systems engineering process providesa focused approach for productdevelopment that attempts to balance allfactors associated with product life cycleviability and competitiveness in a globalmarketplace.” Copyright Joseph Kasser 2010 12
  13. 13. ISO-IEC 15288  Systems Engineering Process  Purchase price*  CHF 168,000  Current version 15288:2008  Revised from 2002 version* http://www.iso.org/iso/catalogue_detail?csnumber=43564 Copyright Joseph Kasser 2010 13
  14. 14. Committed costs vs. LifecycleDAU, 1993 quoted in INCOSE Systems Engineering Handbook 3.1 (2nd Printing) modified Copyright Joseph Kasser 2010 14
  15. 15. Generic perspective:Common content of standards? Common content? Copyright Joseph Kasser 2010 15
  16. 16. Focus of Standards – chronological perspectiveSE Categories MIL-STD- ANSI/ EIA IEEE- CMMI ISO-15288 499C 632 1220Conceptualizing problem andalternative solutions No No No No NoMission/purpose definition No NoRequirements engineeringSystem architectingSystem implementation No NoTechnical analysisTechnical management/leadershipVerification & validationBased on Table 5 in Honour E.C., Valerdi R., “Advancing an Ontology for SystemsEngineering to Allow Consistent Measurement”, CSER 2006 Copyright Joseph Kasser 2010 16
  17. 17. Seven systems engineering myths Myth 1: There are Standards for systems engineering. Myth 2: The “V” model of the systems engineering process Myth 3: Follow the systems engineering process and all will be well Myth 4: Complexity needs new tools and techniques Myth 5: Systems of systems are a different class of problem and need new tools and techniques Myth 6: Changing requirements are a cause of project failure so get the requirements up front Myth 7: The single systems engineering process Copyright Joseph Kasser 2010 17
  18. 18. The “V” Model Copyright Joseph Kasser 2010 18 18
  19. 19. Defects in the V Model  Lacks ‘prevention of defects*’  Definition of successful test?  Design works from requirements  T&E work from the need  T&E identify defects and plan to find them after they have been built into the system  Why not prevent the defects?  Does not cope with change* Kasser, J. E., "Eight deadly defects in systems engineering and how to fix them ", Proceedings of the17th International Symposium of the INCOSE, San Diego, CA, 2007. Copyright Joseph Kasser 2010 19 19
  20. 20. Waterfall representation of series of activitiesRequirements Redraw Waterfall moving these blocks up Design Implement Test Operate Copyright Joseph Kasser 2010 20 20
  21. 21. Waterfall representation in V format Shows functional V is for relationships View [not processRequirements model] Operate Design Test Implement V is a representation of the Waterfall model, Does not cope with change Copyright Joseph Kasser 2010 21 21
  22. 22. Seven systems engineering myths Myth 1: There are Standards for systems engineering. Myth 2: The “V” model of the systems engineering process Myth 3: Follow the systems engineering process and all will be well Myth 4: Complexity needs new tools and techniques Myth 5: Systems of systems are a different class of problem and need new tools and techniques Myth 6: Changing requirements are a cause of project failure so get the requirements up front Myth 7: The single systems engineering process Copyright Joseph Kasser 2010 22
  23. 23. Focus on systems engineering process  The successful implementation of proven, disciplined systems engineering processes results in a total system solution that is--  Robust to changing technical, production, and operating environments;  Adaptive to the needs of the user; and  Balanced among the multiple requirements, design considerations, design constraints, and program budgets.*  A single process, standardizing the scope, purpose and a set of development actions, has been traditionally associated with systems engineering.*** United States Department of Defense 5000 Guidebook 4.1.1 Copyright Joseph Kasser 2010 23** Arnold, 2000 quoting (MIL-STD-499B, 1993) and (IEEE 1220, 1998)
  24. 24. Which process- 632?Process Input Requirements Analysis Systems Analysis • Analyse Missions & Environments • Identify Functional Requirements & Control • Define/Refine Performance & Design Constraint Requirements • Select Preferred Alternatives • Trade-off Studies Requirements Loop • Effectiveness Analysis Functional Analysis/Allocation • Risk Management • Decomposition to Lower-Level Functions • Configuration Mgmt • Allocate Performance & Other Limiting • Interface Management Requirements to Lower-Level Functions • Data Management • Define/Refine Functional Interfaces (Internal/External) • Performance Based Progress • Define/Refine Functional Architecture • Performance Measurement – SE Master Schedule Design Loop – Tech Perf Measurement – Technical Reviews Synthesis • Transform Architectures (Functional to Physical) Verification • Define Alternative Product Concepts • Define/Refine Physical Interfaces (Internal/External) • Define Alternative Product & Process Solutions PROCESS OUTPUT Copyright Joseph Kasser 2010 24
  25. 25. Which process- 1220? Copyright Joseph Kasser 2010 25
  26. 26. Which process- DERA? P ro b le m A p p re c ia tio n U ser In s t a lla tio n & O p e r a tio n a l r e q u ir e m e n ts d e fin itio n v a lid a t io n s y s te m A llo c a t e d P ro p o se d S u p p lie dS o lu tio n A b s tra c tioqn ir e m e n t s re u c h a r a c t e r is t ic s S o ylut e m n R e a lis a tio n s s tio Lo cal S y s te m A r c h ite c tu ra l In te g r a t io n & In te g r a te d r e q u ir e m e n t s r e q u ir e m e n ts & c o n s tra in ts d e fin itio n d e s ig n v e r ific a tio n s y s te m A llo c a t e d P ro p o se d S u p p lie d r e q u ir e m e n t s c h a r a c t e r is t ic s c o m p o n e n ts Lo cal Com ponent Com ponent Com ponent r e q u ir e m e n t s r e q u ir e m e n t s d e s ig n b u ild & t e s t C o m p o n e n ts & c o n s tra in ts a111 S o lu tio n D e v e lo p m e n t Copyright Joseph Kasser 2010 26
  27. 27. Blanchard and Fabrycky’ssystems engineering functions Functional view not a process. Note as a process time seems to be running backwards?Blanchard and Fabrycky, Systems Engineering and Analysis 1981 Copyright Joseph Kasser 2010 27 27
  28. 28. Terry Bahill’s systems engineering functions Functional view not a process. Note as a process time seems to be running backwards? SIMILAR – acronym from first letter of each boxThe Systems Engineering Process from A. T. Bahill and B. Gissing, Re-evaluating systemsengineering concepts using systems thinking, IEEE Transaction on Systems, Man andCybernetics, Part C: Applications and Reviews, 28 (4), 516-527, 1998.http://www.incose.org/practice/fellowsconsensus.aspx Copyright Joseph Kasser 2010 28 28
  29. 29. Two external perspectives: The problem solving process 1. Problem Definition* 1. Identify and Select the 2. Problem Analysis. Problem** 3. Generating possible 2. Analyze the Problem Solutions. 3. Generate Potential Solutions 4. Analyzing the Solutions. 4. Select and Plan the Solution 5. Selecting the best 5. Implement the Solution Solution(s). 6. Evaluate the Solution 6. Planning the next course of action (Next Steps)* http://www.gdrc.org/decision/problem-solve.html (accessed 11 Jan 2009)** http://www.c-pal.net/course/module3/pdf/Week3_Lesson21.pdf (accessed 11 Jan 2009) Copyright Joseph Kasser 2010 29
  30. 30. Something’s wrong here The systems engineering process seems to be the problem solving process  Semantics - levels of detail in each step differ Similar process steps in other professions  Were they doing  Systems engineering, or problem solving? Copyright Joseph Kasser 2010 30
  31. 31. What systems engineering process? Each process seems to be different  Some overlap the problem solving process  Mar, Hitchins, etc.  Some cover the whole system lifecycle  Blanchard and Fabrycky, Bahill and Gissing, etc.  Some cover the ‘realization of the solution’ part of the system lifecycle  MIL-STD 499, EIA-632, IEEE 1220, etc. Which one is “the” process? Copyright Joseph Kasser 2010 31
  32. 32. Standish Report 1994* Top 10 reasons for … Where is “process” mentioned? Project Success on people! Focus is Project Failure 1. User involvement 1. Incomplete requirements 2. Executive management support 2. Lack of user involvement 3. Clear statement of requirements 3. Lack of resources 4. Proper planning 4. Unrealistic expectations 5. Realistic expectations 5. Lack of executive support 6. Smaller project milestones 6. Changing requirements and 7. Competent staff specifications 8. Ownership 7. Lack of planning 9. Clear vision & objectives 8. Didn’t need it any longer 10. Hard-working, focused staff 9. Lack of IT management 10. Technology illiteracy Copyright Joseph Kasser 2010 32* http://www.cs.nmt.edu/~cs328/reading/Standish.pdf
  33. 33. The focus is on people not process Literature  Is full of advice as to how to make projects succeed  Has little if anything to say about the proliferating process standards Copyright Joseph Kasser 2010 33
  34. 34. Seven systems engineering myths Myth 1: There are Standards for systems engineering. Myth 2: The “V” model of the systems engineering process Myth 3: Follow the systems engineering process and all will be well Myth 4: Complexity needs new tools and techniques Myth 5: Systems of systems are a different class of problem and need new tools and techniques Myth 6: Changing requirements are a cause of project failure so get the requirements up front Myth 7: The single systems engineering process Copyright Joseph Kasser 2010 34
  35. 35. Myths of systems engineering “Complexity” and “Systems of Systems”  Dichotomy of views In general: commercial world copes, Defence has problems  First view  Difficult, need new tools and techniques  Type II?  Second view  “What’s the problem, get on with it”  Type V? Copyright Joseph Kasser 2010 35
  36. 36. Complex systems Quotes Chaos 1995 study suggesting systematic reason for project failure Suggests inherent complexity is reason for difficulties – wrong!  complexity was not a cause of project failure in Chaos study – poor management was Quotes own prior work “for all practical purposes adequate testing of complex engineered systems is impossible”  Only applies to the way they are designed today [JEK] Suggests evolutionary process for engineering large complex systems – right! But it applies to engineering any type of system Published in Systems, Man and Cybernetics, 2003. IEEE International Conference on, 2003 Copyright Joseph Kasser 2010 36 necsi.edu/projects/yaneer/E3-IEEE_final.pdf
  37. 37. Two Types of Complexity *  Real world complexity - in which elements of the real world are related in some fashion, and made up of components.  We try to abstract out real world complexity  Complexity is in the eye of the beholder  Artificial complexity – elements of the real world that should have been abstracted out when drawing the internal and external system boundaries, since they are not relevant to the system (problem at hand).  Artificial complexity gives rise to complicatedness  See cartoons by Rube Goldberg and W. Heath Robinson Copyright Joseph Kasser 2010* Kasser J.E., Palmer K., “Reducing and Managing Complexity by Changing the Boundaries of the System", Proceedings of the Conference 37on Systems Engineering Research, Hoboken NJ , 2005.
  38. 38. Representation of the systemProcesses and products are systems Complicated example in Rube Goldberg cartoon http://www.rubegoldberg.com/gallery_02.php Copyright Joseph Kasser 2010 38
  39. 39. Building artificial complexity Copyright Joseph Kasser 2010 39
  40. 40. Seven systems engineering myths Myth 1: There are Standards for systems engineering. Myth 2: The “V” model of the systems engineering process Myth 3: Follow the systems engineering process and all will be well Myth 4: Complexity needs new tools and techniques Myth 5: Systems of systems are a different class of problem and need new tools and techniques Myth 6: Changing requirements are a cause of project failure so get the requirements up front Myth 7: The single systems engineering process Copyright Joseph Kasser 2010 41
  41. 41. Focus in on a toolbox of methodologies* So why do we need OR not SE! complex systems engineering ?  Problem solver needs a methodology for [selecting the appropriate methodology for] solving a problem  “Classification of a system as complex or simple will depend on the user and on the purpose he has for considering the system”  “Systems engineering has been defined by Jenkins as ‘the science of designing complex systems in their totality to ensure that the component subsystems making up the system are designed, fitted together, checked and operated in the most efficient way’.”*** M.C. Jackson and P. Keys, 1984, J. Operations Research Society, Copyright Joseph Kasser 2010 Volume 35, Number 6, p 473-486, Published in Great Britain 42** G.M. Jenkins, (1969) The systems approach. In Systems Behaviour, J. Beishon and G Peters, Ed., 2nd Edn. P 82, Harper & Row, London
  42. 42. System or system of systems? Fighter Wing Red Leader Aircraft Ordnance Airframe NavigationIncomplete Propulsion Guidance Pilot Copyright Joseph Kasser 2010 43
  43. 43. System or system of systems? World War II Allied convoy in North Atlantic ocean Logistics suppliers for imported equipment Copyright Joseph Kasser 2010 44
  44. 44. Seven systems engineering myths Myth 1: There are Standards for systems engineering. Myth 2: The “V” model of the systems engineering process Myth 3: Follow the systems engineering process and all will be well Myth 4: Complexity needs new tools and techniques Myth 5: Systems of systems are a different class of problem and need new tools and techniques Myth 6: Changing requirements are a cause of project failure so get the requirements up front Myth 7: The single systems engineering process Copyright Joseph Kasser 2010 45
  45. 45. Incremental Model The incremental life cycle User requirements Get the requirements up front, still no consideration of change in needs System requirements Time Architectural design Operational Component Integration & system development verification Installation & Part 1 Part 1 validation Part 1 Operations 1 Component Integration & development verification Installation & Part 2 Part 2 validation Operations Part 2 2 Component Integration & development verification Installation & validation Operations Part 3 Part 3 Part 3 r135A 3 Copyright Joseph Kasser 2010 46Students are used to seeing time running horizontally
  46. 46. The evolutionary lifecycle Evolutionary Development Any part of the system may change but project discipline is followed User reqs System Operational reqs Architectural Time design Component Integration & system development verification Installation & validation Feedback from system 1 Operations User reqs System reqs Architectural 1 design Component Integration & development verification Installation & validation Operations Feedback from system 2 User reqs System 2 reqs Architectural design Component development Integration & verification Operations Installation r136A & validation 3First consideration of some changes in requirements,concept of external changes not shown Copyright Joseph Kasser 2010 47
  47. 47. Myth and reality Origins  The failure to capture the entire problem/need and create the full set of matching specifications for the solution system in the early phases of systems engineering  Confusion between the original uncaptured requirements and those requirements that arise due to changes Reality  Overlooking the fact that requirements change continuously and failure to manage that change is a cause of project failureKasser 2010 Copyright Joseph 48
  48. 48. Seven systems engineering myths Myth 1: There are Standards for systems engineering. Myth 2: The “V” model of the systems engineering process Myth 3: Follow the systems engineering process and all will be well Myth 4: Complexity needs new tools and techniques Myth 5: Systems of systems are a different class of problem and need new tools and techniques Myth 6: Changing requirements are a cause of project failure so get the requirements up front Myth 7: The single systems engineering process Copyright Joseph Kasser 2010 49
  49. 49. HKMF Area processes Systems engineering Start Non-systems engineering End Area contains activities Process consists of activities Parallel processes producing products  Systems engineering  Non-systems engineering  Project management  Engineering  Logistics  Etc. Interdependent Copyright Joseph Kasser 2010 50
  50. 50. Insight Each area in the HKMF contains a set of activities from which a process may be constructed  systems engineering (SEP)  non-systems engineering  Project management  Engineering  Logistics  Etc. Copyright Joseph Kasser 2010 51
  51. 51. Why the various versions of the SEP are different  “the systems engineer creates a unique process for his or her particular development effort”  Biemer and Sage, 2009, page 153,  Kasser and Palmer, 2005  Consider each published version of the SEP* as the unique process created for their particular development effort  by someone or some group  at some point in time,  at some point in the system lifecycle* In text books, Standards, web pages, etc. Copyright Joseph Kasser 2010 52
  52. 52. Two systems engineering processes1. Unique systems engineering process (USEP) to a project • Constructed from set of appropriate activities  by someone or some group  at some point in time,  at some point in the system lifecycle • Doing process • Instantiated in Standards2. Process that constructs the USEP for realizing a system • Planning process Copyright Joseph Kasser 2010 53
  53. 53. 10-Step systems engineering process to construct the USEP1. Plan the project  Review lessons learned, locate industry best practices2. Explore/survey the what needs to be done.3. Conceive at least two feasible processes  Explore industry best practices4. Identify ideal selection criteria for evaluation of the processes.  Cost, schedule, resources, technology5. Perform tradeoffs to determine and select the best process.6. Fine tune selected process.  Use best parts of each alternative from Step 37. Formulate strategies and plans to create preferred process.8. Create preferred process using activities as building blocks  Document them in the PP, SEP, SEMP, TEMP etc.9. Verify the preferred process can realize the system  Stakeholder consensus10. Terminate the project. Copyright Joseph Kasser 2010 55
  54. 54. Summary The state of systems engineering 2010 Seven systems engineering myths  Further details  Read paper  See CSER, EUSEC, and INCOSE 2010 publications on http://therightrequirement.com  E.g. Kasser, J. E. and Hitchins, D. K., "Unifying the different systems engineering processes", proceedings of the Conference on Systems Engineering Research, Hoboken, NJ., 2010. Copyright Joseph Kasser 2010 56
  55. 55. Any questions? "It aint what you dont know that gets you into trouble. Its what you know for sure that just aint so."  Mark Twain 1835-1910  Myth 1: There are Standards for systems engineering.  Myth 2: The “V” model of the systems engineering process  Myth 3: Follow the systems engineering process and all will be well  Myth 4: Complexity needs new tools and techniques  Myth 5: Systems of systems are a different class of problem and need new tools and techniques  Myth 6: Changing requirements are a cause of project failure so get the requirements up front.  Myth 7: The single systems engineering process. Copyright Joseph Kasser 2010 57

×