1. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing software systems l Objectives To introduce software lifecycle models To describe a number of different lifecycle models and when they may be used To describe outline process models for requirements engineering, software development, testing and evolution

2. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 2 Introduction How do we produce software and why do we need a software process ? l Software development projects are large and complex l A phased approach to control it is necessary l A process may be defined as a method of developing or producing software.

3. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 3 The importance of a process Why do we need a process ? l Software is very difficult to maintain. l Software evolve and its requirements change. l Software has too many failures. l It is very difficult to accurately gauge the quality of the finished product according to any independent assessment. l Large software projects involve large groups of people. Software development must be documented !!!!!

4. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 4 The importance of a process What do we want our process to achieve? l Effectiveness. The process should help us determine what the customer needs, produce what the customer needs, and, crucially, verify that what we have produced is what the customer needs. l Maintainability. l Predictability. It is important to predict accurately how long it will take to develop the product and how much it will cost.

5. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 5 The importance of a process What do we want our process to achieve? l Repeatability. If a process is discovered to work, it should be replicated in future projects. A closely related issue, is that of process re-use. l Quality. The process should provide a clear link between a customer's desires and a developer's product. l Improvement. No one would expect their process to reach perfection and need no further improvement itself. A goal of our defined process must then be to identify and prototype possibilities for improvement in the process itself. l Tracking. A defined process should allow the management, developers, and customer to follow the status of a project.

6. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 6 The software process l A structured set of activities required to develop a software system Specification Design Validation Evolution l A software process model is an abstract representation of a process presents a description of a process from some particular perspective

7. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 7 Software lifecycle models: Generic software process models l The waterfall model Separate and distinct phases of specification and development l Evolutionary development Specification and development are interleaved l Formal systems development A mathematical system model is formally transformed to an implementation l Reuse-based development The system is assembled from existing components

8. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 8 Waterfall model

9. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 9 Waterfall model problems l Inflexible partitioning of the project into distinct stages l This makes it difficult to respond to changing customer requirements l This model is only appropriate when the requirements are well-understood

10. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 10 Requirements Engineering l yields a description of the desired system: which functions possible extensions required documentation performance requirements l includes a feasibility study l resulting document: requirements specification

11. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 11 Design l earliest design decisions captured in software architecture l decomposition into parts/components; what are the functions of, and interfaces between, those components? l emphasis on what rather than how l resulting document: specification

12. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 12 Implementation l focus on individual components l goal: a working, flexible, robust, … piece of software l not a bag of tricks l present-day languages have a module and/or class concept

13. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 13 Testing l does the software do what it is supposed to do? l are we building the right system? (validation) l are we building the system right? (verification) l start testing activities in phase 1, on day 1

14. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 14 Maintenance l correcting errors found after the software has been delivered l adapting the software to changing requirements, changing environments,...

15. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 15 Global distribution of effort testing 45% coding 20% design 15% requirements engineering 10% specification 10%

16. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 16 Kinds of maintenance activities l corrective maintenance: correcting errors l adaptive maintenance: adapting to changes in the environment (both hardware and software) l perfective maintenance: adapting to changing user requirements

17. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 17 Distribution of maintenance activities corrective 21% adaptive 25% preventive 4% perfective 50%

18. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 18 Evolutionary development l Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements l Throw-away prototyping Objective is to understand the system requirements Should start with poorly understood requirements

19. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 19 Evolutionary development

20. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 20 Evolutionary development l Problems Lack of process visibility Systems are often poorly structured due to lack of proper planning Special skills (e.g. in languages for rapid prototyping) may be required l Applicability For small or medium-size interactive systems For parts of large systems (e.g. the user interface) For short-lifetime systems

21. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 21 Formal systems development l Based on the transformation of a mathematical specification through different representations to an executable program l Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification l Embodied in the ‘Cleanroom’ approach to software development No need to test for defects

22. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 22 Formal systems development l Problems Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface Changes require new transformations and proofs Typically does not scale l Applicability Critical systems (e.g., in terms of safety or security)

23. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 23 Reuse-oriented development l Based on systematic reuse where systems are integrated from existing components or COTS systems l Process stages Component analysis Requirements modification System design with reuse Development and integration l Becoming important but still limited experience with it

24. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 24 Process iteration l System requirements always evolve in the course of a project l Process iteration where earlier stages are reworked is always part of the process for large systems l Iteration can be applied to any of the generic process models l Two (related) approaches Incremental development Spiral development

25. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 25 Incremental development l Development and delivery is broken down into increments l Each increment delivers part of the required functionality l Requirements are prioritised and the highest priority requirements are included in early increments l Once the development of an increment is started, the requirements are frozen Requirements for later increments can continue to evolve

26. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 26 Incremental development advantages l System functionality is available earlier and customer does not have to wait as long l Early increments act as a prototype to help elicit requirements for later increments l Lower risk of overall project failure l The highest priority system services tend to receive the most testing

27. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 27 Agile Methodology

28. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 28 Agile Methodology

29. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 29 Agile Methodology

30. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 30 Agile Methodology

31. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 31 Agile Methodology

32. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 32 Spiral development l Process is represented as a spiral rather than as a sequence of activities with backtracking l Each loop in the spiral represents a phase in the process l No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required l Risks are explicitly assessed and resolved throughout the process

33. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 33 Spiral model of the software process

34. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 34 The Rational Unified Process l A modern process model derived from the work on the UML and associated process. l Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practive perspective that suggests good practice.

35. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 35 RUP phase model

36. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 36 RUP phases l Inception Establish the business case for the system. l Elaboration Develop an understanding of the problem domain and the system architecture. l Construction System design, programming and testing. l Transition Deploy the system in its operating environment.

37. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 37 RUP good practice l Develop software iteratively l Manage requirements l Use component-based architectures l Visually model software l Verify software quality l Control changes to software

38. ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 38 Key points l Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model l General activities are specification, design and implementation, validation and evolution l Lifecycle models describe the organisation of software processes l Iterative process models describe the software process as a cycle of activities