©ian sommerville 2000, mejia-alvarez 2009 slide 1 software processes l coherent sets of activities...

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


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.


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 !!!!!



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.



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.


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


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


Waterfall modelRequirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance


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


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


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


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


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


Maintenance

correcting errors found after the software has been delivered

adapting the software to changing requirements, changing environments, ...


Global distribution of effort

testing 45%

coding 20%design 15%

requirementsengineering 10%

specification 10%


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


Distribution of maintenance activities

corrective 21%

adaptive 25%

preventive 4%

perfective 50%


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


Evolutionary development

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Concurrentactivities


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


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


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)


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


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


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


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


Agile Methodology


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


Spiral model of the software process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


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.


RUP phase model

Phase iteration

Inception Elaboration Construction Transition


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.


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


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

©ian sommerville 2000, mejia-alvarez 2009 slide 1 software processes l coherent sets of activities...

Documents