Software Processes l l Coherent sets of activities

Software Processes l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 1

Introduction How do we produce software and why do we need a software process ? l l l 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. ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 2

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 !!!!! ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 3

The importance of a process What do we want our process to achieve? l l l Effectiveness. The process should help us determine what the customer needs, produce what the customer needs, and, crucially, verify that 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. ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 4

The importance of a process What do we want our process to achieve? l 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. 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. ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 5

The software process l A structured set of activities required to develop a software system • • l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 6

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

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

Waterfall model problems l l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 9

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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 10

Design l l earliest design decisions captured in software architecture 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 11

Implementation l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 12

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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 13

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

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

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

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

Evolutionary development l Exploratory development • • l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 18

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

Evolutionary development l Problems • • • l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 20

Formal systems development l l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 21

Formal systems development l Problems • • l 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) ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 22

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

Process iteration l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 24

Incremental development l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 25

Incremental development advantages l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 26

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

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

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

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

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

Spiral development l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 32

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

The Rational Unified Process l l 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. ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 34

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

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

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

Key points l l 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 ©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 38