1. Winter 2011SEG2106 - Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process

2. Winter 2011SEG2106 - Chapter 12 Issues with software quality The quality and cost of software has been a growing concern Delivered long behind schedule At much higher cost than anticipated Without giving the desired benefits and user satisfaction

3. Winter 2011SEG2106 - Chapter 13 Reasons It is hard to understand the purpose of a system well enough to plan its functionality in advance so that it will really satisfy the user needs. The complexity of systems and their dynamic behavior is too high. The visibility nature of the product makes the development and maintenance process itself difficult to understand and control. There is a lack of proven components to use as high level building blocks. Too much is developed from scratch.

4. Winter 2011SEG2106 - Chapter 14 System Quality System quality is the systems ability to satisfy the needs and expectations of the user and the owners, i.e. the system environment. Quality depends on clear and unambiguous communication.

5. Winter 2011SEG2106 - Chapter 15 Quality

6. Winter 2011SEG2106 - Chapter 16 Communication Problem

7. Winter 2011SEG2106 - Chapter 17 Essence of Quality Control To ensure that each communication link and transformation step worked as intended. –Overall process: the organization of the development process into major steps where specific documents are produced and certain quality assessment procedures performed. –Technical content: the information content in the various documents, e.g. requirements specification, system specification, and test plans.

8. Winter 2011SEG2106 - Chapter 18 Quality Assurance

9. Winter 2011SEG2106 - Chapter 19 Benefits of Systems Engineering Step-wise quality assurance can be performed during the entire development. The user and owner needs are put into focus. The functionality can be validated at an early stage. The number of aspects to be considered at each step is reduced. The cost of error correction is reduced since error can be detected earlier.

10. Winter 2011SEG2106 - Chapter 110 Concepts of the SE process Activity: the means of producing results Phase: period of time where specific activities are carried out and results produced Baseline: phase result, basis for future work Milestone: phase transition

11. Winter 2011SEG2106 - Chapter 111 Activity Model

12. Winter 2011SEG2106 - Chapter 112 Possibilities for automating the software construction process State machines or Activity diagrams may be used as prototypes that model the functional requirements of the system to be built – or that represent the functional design of the system. After validation, correct implementation code can be generated automatically by appropriate CASE tools.

13. Winter 2011SEG2106 - Chapter 113 Vision by David Harel (i) in relation with his work on Live Sequence Charts (LSC)

14. Winter 2011SEG2106 - Chapter 114 Vision by David Harel (ii) the future … (near and more remote)

15. Winter 2011SEG2106 - Chapter 115 Chapter 1 Review from previous courses Subject 2: Analysis of the Problem Domain

16. Winter 2011SEG2106 - Chapter 116 Problem Domain Analysis This is an important phase during Requirements Analysis The aim of domain analysis is to understand the problem domain independently of the particular system we intend to develop. We do not try to draw the borderline between the system and the environment. We focus on the concepts and the terminology of the application domain with a wider scope than future system.

17. Winter 2011SEG2106 - Chapter 117 Activities and Results of Domain Analysis A dictionary of terms defining the common terminology and concepts of the problem domain; Description of the problem domain from a conceptual modeling viewpoint, including inheritance hierarchies. Note: Later, one also wants a clear statement of purpose, i.e., objectives and goals for the new system to be built and its border with the other entities within the domain. (This system to be built is part of the future version of the domain)

18. Winter 2011SEG2106 - Chapter 118 Documenting the conceptual model of the problem domain Entity-Relationship modeling (originally proposed by Peter Chen in 1976) –Entity: represents a type of entity instances, defines the properties that hold for all such instances. –Relationship: represents relationship instances that hold between certain pairs of entity instances. The related entity types are also called roles. Multiplicity information indicate how many instances of the “other” side may be related to a given instance of “this” side. –Attribute: An entity or a relationship may have one or several attributes. Each attribute is identified by a name and its type, where such a type is usually some simple data type such as integer or character string. Note: An entity type is normally not used as the type of an attribute, because such a situation is rather represented by a relationship between the given entity and the attribute type. Notation: e.g. UML Class diagrams

19. Winter 2011SEG2106 - Chapter 119 Requirements Specification = External Design Requirements Specification is «The invention and definition of the behavior of a new system (solution domain) such that it will produce the required effects in the problem domain » During Requirements Analysis, one finds the existing properties of the problem domain, as well as the requirements that should be satisfied in the domain-to-be. We assume that the domain-to-be will include a new system-to-be-built and other aspects of the domain may also be changed. The determination of this domain-to-be, including the system-to- be) is a typical design process. It is called external design because the system-to-be is considered during this process as a black-box and the external environment of it is designed (in a white-box manner) – the domain-to-be. Note: During this process, the boundary (and interfaces) of the system-to-be will be established