A program of research into systems engineering

464 views

Published on

This paper provides an overview of a number of research areas that include investigating the nature of systems engineering and its underlying concepts, defining the properties of object-oriented requirements, producing prototype object-oriented tools for systems engineering, and applying of systems engineering to various domains.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
464
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

A program of research into systems engineering

  1. 1. A Program of Research into Systems Engineering Joseph E. Kasser DSc CEng CM MIEE, Stephen C. Cook PhD FIEE FIEAust Systems Engineering and Evaluation Centre University of South Australia School of Electrical and Information Engineering Mawson Lakes Campus, South Australia 5095 Telephone: +61 (08) 8302 3941, Fax: +61 (08) 8302 4723Emails: Joseph.Kasser@unisa.edu.au, Stephen.Cook@unisa.edu.au © University of South Australia, 2003 1
  2. 2. Topics The elements of a framework for the engineering of complex systems; Object-oriented systems engineering; Research into prototype object- oriented tools for systems engineering; The application of systems engineering to various domains. © University of South Australia, 2003 2
  3. 3. Systems Engineering Academia is teaching it Industry is practicing it INCOSE is trying to improve itTower of Systems Engineering © University of South Australia, 2003 3
  4. 4. Systems Engineering But nobody knows what it is No agreed definition Academic debate about degrees in the subjectTower of Systems Engineering © University of South Australia, 2003 4
  5. 5. The 5-Layer Systems Engineering Model Socio-Economic  Government Regulation and Control.Systems Engineering Economic, legal and political influences. Industry System  National Wealth Creation, the Nation’s Engineering Engine. (Japan operates at this level) Business System  Industrial Wealth Creation. Many Engineering Businesses make an industry Project System  Corporate Wealth Creation. (The West Engineering operates at this level.)Product/sub-system  Technology Artefacts. To some the only Engineering “real” systems engineering. Many Products (can) make a system Time Derek Hitchins, SETE 2000 © University of South Australia, 2003 5
  6. 6. ISO/IEC 15288 Road MapEnterprise Processes Technical Processes Project Enterprise Environment Stakeholder Requirements Management Process Processes Definition Process Project Planning Requirements Analysis ProcessInvestment Management Process Process Architectural Design Process Project Assessment System Life Cycle Process Management Process Implementation Process Project Control Resource Management Process Integration Process Process Decision -making Verification Process Process Quality Management Process Transition Process Risk Management Process Validation Process Configuration Operation ProcessAgreement Processes Management Process Acquisition Process Maintenance Process Information Management Process Supply Process Disposal Process © University of South Australia, 2003 6
  7. 7. Elements for Area of Research The Area of Concern (A), • which might be a particular problem in a discipline (area of study), a real-world problem situation, or a system of interest. A particular linked Framework of Ideas (F) in which the knowledge about the area of concern is expressed. • includes current theories, bodies of knowledge, heuristics, etc as documented in the literature as well as tacit knowledge. The Methodology (M) in which the framework is embodied • incorporates methods, tools, and techniques in a manner appropriate to the discipline that uses them to investigate the area of concern. © University of South Australia, 2003 7
  8. 8. Relationships Between F,M&A Elements relevant to any piece of research (Checkland and Holwell, 1998: p 13). © University of South Australia, 2003 8
  9. 9. Broad Areas of Concern A designed physical system • (that also contains human components). A human activity system • (engineering organisation). Each span many disciplines and require pluralistic approaches that not only invoke multiple methodologies but ones that rest on quite distinctly different frameworks of ideas. They are of fundamentally different types and hence will probably have to be approached with different methodologies. As such we now understand why: • Many systems engineers cannot clearly articulate the functions and benefits of systems engineering (Kasser and Shoshany 2001). • It has been extremely difficult to establish a systems engineering body of knowledge (SEBOK) for the diverse activities that are known by the term “systems engineering.” (Kasser and Massie, 2001). © University of South Australia, 2003 9
  10. 10. Topics The elements of a framework for the engineering of complex systems; Object-oriented systems engineering; Research into prototype object- oriented tools for systems engineering; The application of systems engineering to various domains. © University of South Australia, 2003 10
  11. 11. Object-Oriented SE has a Gap Concept of operations(Use Cases) Systems (objects) Object-oriented Object-oriented software hardware © University of South Australia, 2003 11
  12. 12. What is a Requirement? It is a means of communication It is a representation of a need • Traditionally text based Requirements are crucial to delivering the right system and producing it in the most effective manner (optimal costs) © University of South Australia, 2003 12
  13. 13. What is a Good Requirement? Describes something (“what”) about the system to be implemented • Product dimension Facilitates the process of implementing the system • Process dimension It’s a real requirement • Well-written but useless © University of South Australia, 2003 13
  14. 14. RequirementTest The RealDesignRequirement Acceptance criteria (property of a requirement) © University of South Australia, 2003 14
  15. 15. Research Questions Can an object-oriented approach provide traceability from the highest level need statement to the lowest level of implementation? Can a conversion to object-oriented requirements bypass or resolve today’s problem of poor requirements? What are the properties of object- oriented requirements? • Product dimension • Process dimension © University of South Australia, 2003 15
  16. 16. Topics The elements of a framework for the engineering of complex systems; Object-oriented systems engineering; Research into prototype object-oriented tools for systems engineering; • OCH • CREAP • PETS The application of systems engineering to various domains. © University of South Australia, 2003 16
  17. 17. The Operational Concept Harbinger Takes a holistic approach through greater participation of stakeholders in a form that allows them to contribute meaningfully Helps to elicit (complete the set of) requirements Reduces poorly articulated requirements Minimizes undocumented requirements Minimizes immeasurable requirements © University of South Australia, 2003 17
  18. 18. OCH Evolutionary Sequence - Summary Combined Operations Concept and Requirements information Added • Measures of effectiveness • Multi-media and diagrammatic information • Non-sequential access to, and display of, information • Parallel display (views) of information © University of South Australia, 2003 18
  19. 19. The Place of the OCH in the SDLC © University of South Australia, 2003 19
  20. 20. Structure of the OCH Frame-based Underlying sequential State Machine Use Case scenarios UML swim lane format Activity sequence (PERT like) relationships © University of South Australia, 2003 20
  21. 21. Scenario Formats UML, basic and enhanced with graphics • the current way of working. Static workflow diagrams • adding user perspective, Dynamic workflow diagrams • animated diagrams showing sequences. Audio files • containing verbal descriptions  such as environmental conditions for the deployed system, or user concerns. Video files • showing scenarios  animated or filmed. Simulations • of all or part of the system. Text mode • for those people who still think in terms of “requirements” © University of South Australia, 2003 21
  22. 22. Example© University of South Australia, 2003 22
  23. 23. Physical View of OCH Server LAN/Internet S1 S2 SnCONTROL © University of South Australia, 2003 23
  24. 24. A Practical OCH© University of South Australia, 2003 24
  25. 25. Advantages of the OCH Bypasses today’s problems due to “poor requirements” Connects development effort more directly to the user needs Visual representation of “needs” • Improves the requirements elicitation process by providing an interactive facility for exploring the capabilities of the customer’s needs. • leads to inherited non-functional “needs” which reduces the quantity of “missing requirements” Helps bridge the gap between soft and hard systems © University of South Australia, 2003 25
  26. 26. The Purpose of the CommunicationsRequirements Evaluation & AssessmentPrototype (CREAP) To determine if Requirements Engineering tools could be extended to: • Constrain writers of requirements to feasible specifications • Generates a list of feasible implementation options consistent with a defined inventory To determine if • User selected combinations of equipment from inventory list • Would provide the needed communications capability • For a specific category of service Antennas Receivers Transmitters Modems © University of South Australia, 2003 26
  27. 27. Communications coverage © University of South Australia, 2003 27
  28. 28. Elements of the CREAP The frames • General purpose so that the contents of the frames can be replaced by a set of frames for a different scenario allowing the tool to be used in another scenario potentially with no additional programming. The user interface template • Provides the template for the information to be displayed on the GUI. The frame interpreter • A state machine, which interprets the contents of the frames. © University of South Australia, 2003 28
  29. 29. CREAP© University of South Australia, 2003 29
  30. 30. Prototype Educational Tools forSystem and Software Engineering (PETS) © University of South Australia, 2003 30
  31. 31. Prototype Educational Tools forSystem and Software Engineering (PETS) © University of South Australia, 2003 31
  32. 32. Prototype Educational Tools forSystem and Software Engineering (PETS) © University of South Australia, 2003 32
  33. 33. Prototype Educational Tools forSystem and Software Engineering (PETS) © University of South Australia, 2003 33
  34. 34. Prototype Educational Tools forSystem and Software Engineering (PETS) © University of South Australia, 2003 34
  35. 35. Prototype Educational Tools forSystem and Software Engineering (PETS) © University of South Australia, 2003 35
  36. 36. Prototype Educational Tools forSystem and Software Engineering (PETS) © University of South Australia, 2003 36
  37. 37. Topics The elements of a framework for the engineering of complex systems; Object-oriented systems engineering; Research into prototype object- oriented tools for systems engineering; The application of systems engineering to various domains. © University of South Australia, 2003 37
  38. 38. Research areas An Acquisition Methodology for the Procurement and Integration of a Network Enabled Warfare System of Systems A Systems Approach to the Evaluation of Complex, Real- Time Information Systems: Determining the Effectiveness of Command and Control Organisations Developing methodologies to make efficient use of Commercial Off The Shelf software products in Research How the audio interface for short range infrared guided air-to-air missiles can be improved Measures of Effectiveness: The Standards for Success Strategic Planning and Capability Engineering © University of South Australia, 2003 38
  39. 39. Systems Engineering Glossary Project Student summer project • One iteration through the Development Life Cycle Initial announcement on Discuss Reflector Prototype (limited vocabulary) in test SECOE project © University of South Australia, 2003 39
  40. 40. Conclusions A research program into systems engineering covers a broad range of activities The incorporation of process elements into the requirement object has shown to be a promising approach for increasing the effectiveness of the systems engineering process and providing customers with a product that meets their needs. The reductionist approach to solving the problem of poor requirements is the time-phased parallel process of building a suite of tools for performing specific tasks. While the reductionist approach may not be applicable to solving all complex problems, in these applications the results have been promising. FRED, CREAP, TIGER, the remaining PETS and the OCH provide capability that shows that parts of the problem of poor requirements can be alleviated by applying the appropriate technology. © University of South Australia, 2003 40
  41. 41. Summary The elements of a framework for the engineering of complex systems; Object-oriented systems engineering; Research into prototype object- oriented tools for systems engineering; The application of systems engineering to various domains. © University of South Australia, 2003 41
  42. 42. Questions ?© University of South Australia, 2003 42

×