Software Processes

1. Software Processes • Coherent sets of activities for specifying, designing, implementing and testing software systems • 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. Introduction How do we produce software and why do we need a software process ? • Software development projects are large and complex • A phased approach to control it is necessary • A process may be defined as a method of developing or producing software.

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

4. The importance of a process What do we want our process to achieve? • 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. • Maintainability. • Predictability. It is important to predict accurately how long it will take to develop the product and how much it will cost.

5. The importance of a process What do we want our process to achieve? • 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. • Quality. The process should provide a clear link between a customer's desires and a developer's product. • 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. • Tracking. A defined process should allow the management, developers, and customer to follow the status of a project.

6. The software process • A structured set of activities required to develop a software system • Specification • Design • Validation • Evolution • A software process model is an abstract representation of a process • presents a description of a process from some particular perspective

7. Software lifecycle models:Generic software process models • The waterfall model • Separate and distinct phases of specification and development • Evolutionary development • Specification and development are interleaved • Formal systems development • A mathematical system model is formally transformed to an implementation • Reuse-based development • The system is assembled from existing components

8. Waterfall model

9. Waterfall model problems • Inflexible partitioning of the project into distinct stages • This makes it difficult to respond to changing customer requirements • This model is only appropriate when the requirements are well-understood

10. Requirements Engineering • yields a description of the desired system: • which functions • possible extensions • required documentation • performance requirements • includes a feasibility study • resulting document: requirements specification

11. Design • earliest design decisions captured in software architecture • decomposition into parts/components; what are the functions of, and interfaces between, those components? • emphasis on what rather than how • resulting document: specification

12. Implementation • focus on individual components • goal: a working, flexible, robust, … piece of software • not a bag of tricks • present-day languages have a module and/or class concept

13. Testing • does the software do what it is supposed to do? • are we building the right system? (validation) • are we building the system right? (verification) • start testing activities in phase 1, on day 1

14. Maintenance • correcting errors found after the software has been delivered • adapting the software to changing requirements, changing environments, ...

15. Global distribution of effort design 15% coding 20% requirements engineering 10% specification 10% testing 45%

16. Kinds of maintenance activities • corrective maintenance: correcting errors • adaptive maintenance: adapting to changes in the environment (both hardware and software) • perfective maintenance: adapting to changing user requirements

17. Distribution of maintenance activities corrective 21% perfective 50% adaptive 25% preventive 4%

18. Evolutionary development • 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 • Throw-away prototyping • Objective is to understand the system requirements • Should start with poorly understood requirements

19. Evolutionary development

20. Evolutionary development • 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 • Applicability • For small or medium-size interactive systems • For parts of large systems (e.g. the user interface) • For short-lifetime systems

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

22. Formal systems development • 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 • Applicability • Critical systems (e.g., in terms of safety or security)

23. Reuse-oriented development • Based on systematic reuse where systems are integrated from existing components or COTS systems • Process stages • Component analysis • Requirements modification • System design with reuse • Development and integration • Becoming important but still limited experience with it

24. Process iteration • System requirements always evolve in the course of a project • Process iteration where earlier stages are reworked is always part of the process for large systems • Iteration can be applied to any of the generic process models • Two (related) approaches • Incremental development • Spiral development

25. Incremental development • Development and delivery is broken down into increments • Each increment delivers part of the required functionality • Requirements are prioritised and the highest priority requirements are included in early increments • Once the development of an increment is started, the requirements are frozen • Requirements for later increments can continue to evolve

26. Incremental development advantages • System functionality is available earlier and customer does not have to wait as long • Early increments act as a prototype to help elicit requirements for later increments • Lower risk of overall project failure • The highest priority system services tend to receive the most testing

27. Agile Methodology

28. Agile Methodology

29. Agile Methodology

30. Agile Methodology

31. Agile Methodology

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

33. Spiral model of the software process

34. The Rational Unified Process • A modern process model derived from the work on the UML and associated process. • 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. RUP phase model

36. RUP phases • Inception • Establish the business case for the system. • Elaboration • Develop an understanding of the problem domain and the system architecture. • Construction • System design, programming and testing. • Transition • Deploy the system in its operating environment.

37. RUP good practice • Develop software iteratively • Manage requirements • Use component-based architectures • Visually model software • Verify software quality • Control changes to software

38. Key points • Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model • General activities are specification, design and implementation, validation and evolution • Lifecycle models describe the organisation of software processes • Iterative process models describe the software process as a cycle of activities