1. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 1 Introduction to Systems Engineering by Rolv Bræk NTNU

2. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 2 What is most important in systems engineering? Following a strict project plan with phases and milestones? Focus on documents: requirements specifications; testplans, …? Mastering the best platform technologies: J2EE, J2ME, Web Services, SOA, …? Being a good programmer? Knowing how to test and integrate? Mastering the best development tools? Ability to cooperate in teams? Domain/application understanding? Business and marketing aspects? Understanding the needs of stakeholders? Separating modelling from building to promote understanding and communication?

3. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 3 Not engineering: no modelling, just building It may be OK for: simple data handling algorithmic problems prototyping Otherwise too much in one step: Complex and therefore errorprone Big communication problem Impossible to manage! Expensive in the long run Technology sensitive

4. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 4 Quality depends on Stakeholders Users – those that interact directly with the system and use the system services to achieve some operative purpose. May be persons or technical systems, such as the process plant controlled by a process control system. Owners – those that own or are responsible for the system during parts of its lifetime. Typically preoccupied with economy and cost/benefit considerations. Subjects – those that are known to the system, but not directly interacting with it, e.g. persons and things represented in a database such as the customers of a company. Definition: System quality System quality is the systems ability to satisfy the needs and expectations of the users and the owners (and the subjects), i.e. the stake holders

5. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 5 Typical errors we make We plan a functionality that is not in harmony with the purpose of the system. We define the functionality in a way that is internally inconsistent. We implement a different functionality from the one we planned. What can we do about it?

6. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 6 Building a common understanding

7. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 7 Modelling - the foundation of all ENGINEERING disciplines! Models improve communication and understanding about: why the system is needed; what its functionality should be; how it should be implemented.

8. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 8 The systems engineering cycle/spiral Domain System models Develop Install System Manufacture Domain models Model has needs quality = satisfaction of needs

9. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 9 How to model complex realities? Combine two golden rules: Separation of concerns. Identify aspects that are as independent as possible and describe them separately. Conceptual abstraction. Replace low level concepts representing technical detail by more abstract concepts better suited to describe and study some aspects, i.e. by some kind of model. Domain models System models First we separate domain from system; then what to separate? Can user aspects be separated from realisation aspects? First we separate domain from system; then what to separate? Can user aspects be separated from realisation aspects?

10. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 10 The main separations Since the purpose of ICT systems is to provide functionality (perform logical behaviour and handle information); and the functionality may be realised in many ways: separate functionality from realisation describe the deployment mapping separately

11. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 11 Functionality Is a conceptual abstraction intended to describes logical behaviour and information as clearly as possible It should enable users and developers: to communicate precisely to establish a common understanding to ensure that the descriptions of functionality correctly represents the existing domain and/or the system being developed It provides a view where the system may be seen as a whole, independently of realisation and technology Is normally described in terms of structures of active and passive objects with associated object behaviours Is a conceptual abstraction intended to describes logical behaviour and information as clearly as possible It should enable users and developers: to communicate precisely to establish a common understanding to ensure that the descriptions of functionality correctly represents the existing domain and/or the system being developed It provides a view where the system may be seen as a whole, independently of realisation and technology Is normally described in terms of structures of active and passive objects with associated object behaviours

12. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 12 Languages for functionality should Support human comprehension so that human beings may fully understand and communicate precisely about the functionality => build on concepts that are suitable, well defined, and easy to understand. Provide analytical possibilities so that one may reason about behaviours in order to compare systems, to validate interfaces, and to verify properties. => have a semantic foundation suitable for analysis. Be realistic. Although overlooked in many cases, this requirement is essential for two main reasons: 1.That it shall be possible to implement the functionality 2.That the description of the functionality can serve as valid documentation of the real system. => build on concepts that can be effectively realised in the real world.

13. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 13 Realisation Is a precise technical definition of the realisation in terms of the technologies used, such as mechanics, electronics and software Is necessary to actually produce a working system The choice of realisation depends on what properties are desired from the realisation itself (often called non-functional properties) Is a precise technical definition of the realisation in terms of the technologies used, such as mechanics, electronics and software Is necessary to actually produce a working system The choice of realisation depends on what properties are desired from the realisation itself (often called non-functional properties)

14. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 14 Deployment (Implementation design) Describes aspects that come in addition to the functionality, such as distribution, hardware/software allocation and use of middleware and defines a mapping between functionality and realisation by: describing the realisation (the physical system) on a high level identifying the technologies used describing how and where the functionality is realised describes configurations Serves together with functionality as the main documentation. Describes aspects that come in addition to the functionality, such as distribution, hardware/software allocation and use of middleware and defines a mapping between functionality and realisation by: describing the realisation (the physical system) on a high level identifying the technologies used describing how and where the functionality is realised describes configurations Serves together with functionality as the main documentation. –configuration data; –priorities; –versions; –etc.

15. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 15 Relationship with RM-ODP viewpoints Enterprise Information Computation Information Computation Engineering Technology Engineering Technology Enterprise

16. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 16 Objects and properties

17. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 17 General modelling pattern objects properties context content component types (follow same pattern) design specification

18. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 18 The ITU-T languages and UML

19. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 19 Methodology and Methods A methodology is a system of methods and principles. A method defines a systematic way to produce given results. Which is the way to quality results? Methods provide a kind of “roadmap” with guidelines and rules The main results of systems engineering are target systems and descriptions expressed using languages. Without any methods there would be no systems engineering discipline! The main results of systems engineering are target systems and descriptions expressed using languages. Without any methods there would be no systems engineering discipline!

20. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 20 Macro process

21. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 21 Develop system activity (process)

22. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 22 … related to the textbook models

23. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 23 Dealing with important errors: We plan a functionality that is not in harmony with the purpose of the system. We define the functionality in a way that is internally inconsistent. We implement a different functionality than the one we planned.

24. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 24 Two main approaches : Elaboration approach: the functionality description is incomplete and expressed using languages with incomplete semantics => the realisation description ends up as the only complete view of the system and the functionality description is not maintained Most UML use including the Rational Unified Process, RUP, follows the elaboration approach. Translation approach: the functionality description is complete and expressed using languages with well-defined and realistic semantics => the functionality description is valid for the realisation, serve as documentation and is maintained Realisation is by (manual or automatic) translation of the functionality description. Deployment is orthogonal to the functionality (using the principle of distribution transparency). Most SDL use follow this approach. The UML ModelDrivenArchitecture (MDA) follows this approach too. “Model Driven” has now become a buzzword!

25. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 25 Which is your favourite? Implementation oriented Design oriented The traditional The model driven

26. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 26 Quality assurance Techniques: Corrective techniques: defect detection, with subsequent correction, e.g. formal verification, simulation, testing and inspection. Constructive techniques: defect avoidance, i.e. to avoid introducing errors in the first place, e.g. synthesis and automatic program generation, languages and methods that help to improve understanding and communication. Aspects Quality of functionality: related to the main purposes, i.e. the needs of the domain. Quality of realisation, i.e. way the functionality is realised. the most effective separated in the translation approach

27. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 27 Planning and process management aspects Managemet issues time-schedule resources, costs control and decision making Models provide the key! Models define the quality! Baselines Milestones Concrete System (CS) Models time, cost Functional Requirements (FR) Functional Design (FD) Implementation Design (ID) Requirements Specification DesignImplementation Phases make FD make FR make ID Make CS CS FRFD ID Activities Revisions FD

28. Science and Technology Norwegian University of NTNU Rolv Bræk, January 2008 28 Documents vs. models Documents contain models and more Documents are deliverables Models live and evolve Documents contain snapshots of models Focus on models rather than documents! specify requirements design functionality design implementation implement system Functional design Documentation = Functional design + Implementation design User´s manual Operator´s manual Functional + non-functional requirements Project plan Test plan Quality plan Test documents