AGILE SoftwareConstruction

Beatrice Åkerblombeatrice@dsv.su.se

2

Outline for the lecture

SoftwareSoftwareLife-CycleLife-CycleModelsModels

The SoftwareThe SoftwareProcessProcess

Software Life-CycleSoftware Life-CycleModelsModels

A software life-cycle model is a structure imposed onthe development of a software product. There areseveral different models available, each describing

relations and orders of a variety of tasks or activitiesthat take place during the life-cycle and we will take a

look at some of them

Software Life-Software Life-Cycle ModelsCycle Models

The SoftwareThe SoftwareProcessProcess

4

Software Life-CycleModels

❖ Life-cycle model (formerly, processmodel)

❖ The steps through which the productprogresses

~ Requirements phase

~ Specification phase

~ Design phase

~ Implementation phase

~ Integration phase

~ Maintenance phase

~ Retirement

5

Software Life-CycleModels

❖ Build-and-fix model

❖ Waterfall model

❖ Prototyping model

❖ Incremental model

❖ eXtreme programming

❖ Synchronize-and-stabilize model

❖ Spiral model

❖ Object-Oriented model

❖ Unified Process Model

❖ Open source development

6

Build and Fix Model

❖ Problems

~ No specifications -- No design

❖ Totally unsatisfactory

❖ Need life-cycle model

~ “Game plan”

~ Phases

~ Milestones

7

Waterfall Model

8

Waterfall Model(contd)

❖ Characterized by

~ Feedback loops

~ Documentation-driven

❖ Advantages

~ Documentation

~ Maintenance easier

❖ Disadvantages

~ Specifications

❖ Joe and Jane Johnson

❖ Mark Marberry

9

Prototyping Model

❖ Exploratory development

~ Objective is to work with customers and toevolve a final system from an initial outlinespecification. Should start with well-understood requirements

❖ Throw-away prototyping

~ Objective is to understand the systemrequirements. Should start with poorlyunderstood requirements

10

Three Key Points

❖ Do not turn rapid prototype intoproduct

❖ Rapid prototyping may replacespecification phase — never the designphase

❖ Comparison:

~ Waterfall model — try to get it rightfirst time

~ Rapid prototyping — frequent change,then discard

11

Waterfall and RapidPrototyping Models

❖ Waterfall model

~ Many successes

~ Client needs

❖ Rapid prototyping model

~ Not proved

~ Has own problems

❖ Solution

~ Rapid prototyping for requirementsphase

~ Waterfall for rest of life cycle

12

Incremental Model

❖ Divide project into “builds”

13

Incremental Model(contd)

❖ Waterfall, rapid prototyping models

~ Operational quality complete productat end

❖ Incremental model

~ Operational quality portion ofproduct within weeks

❖ Less traumatic

❖ Smaller capital outlay, rapid return oninvestment

❖ Need open architecture – maintenanceimplications

❖ Different approaches – top-down,bottom-up, middle-out, use-case-driven

14

Incremental Model(contd)

❖ Problems:

~ Build-and-fix danger

~ Contradiction in terms

~ Same problems as waterfall model,only a little at a time

15

Incremental Model(contd)

❖ More risky version — pieces may not fit

16

eXtremeProgramming

❖ Somewhat controversial new approach

❖ Stories (features client wants)

❖ Estimate duration and cost of eachstory

❖ Select stories for next build

❖ Each build is divided into tasks

❖ Test cases for task are drawn up first

❖ Pair programming

❖ Continuous integration of tasks

17

Unusual Featuresof XP

❖ XP team work in the same room

❖ Client representative is always present

❖ No overtime work

❖ Pair programming

❖ Refactoring

18

The agile manifesto

Four core values:

❖ Individuals and interactions overprocesses and tools

❖ Working software over comprehensivedocumentation

❖ Customer collaboration over contractnegotiation

❖ Responding to change over following aplan

19

Evaluating XP

❖ XP has had some successes

❖ Good when requirements are vague orchanging

❖ Too soon to evaluate XP

20

Synchronize-andStabilize Model

❖ Microsoft’s life-cycle model

❖ Requirements analysis—interviewpotential customers

❖ Draw up specifications

❖ Divide project into 3 or 4 builds

❖ Each build is carried out by smallteams working in parallel

21

Synchronize-andStabilize Model

(contd)❖ At the end of the day—synchronize

(test and debug)

❖ At the end of the build—stabilize(freeze build)

❖ Components always work together

~ Get early insights into operation ofproduct

22

Spiral Model

❖ Simplified form

~ Waterfall model plus risk analysis

❖ Precede each phase by

~ Alternatives and risk analysis

❖ Follow each phase by

~ Evaluation and planning of next phase

23

Simplified Spiral Model

❖ If risks cannot be resolved, project isimmediately terminated

24

Full Spiral Model

❖ Radial dimension: cumulative cost todate

❖ Angular dimension: progress throughthe spiral

25

Analysis of Spiral Model

❖ Strengths

~ Easy to judge how much to test

~ No distinction made betweendevelopment and maintenance

❖ Weaknesses

~ For large-scale software only

~ For internal (in-house) software only

26

Unified Process model

Unified Process aims to:

❖ Meet user needs

❖ Accommodate risks

The method makes heavy use of:

❖ Use cases

❖ Iteration

❖ Software architecture

Four phases:

❖ Inception

❖ Elaboration

❖ Construction

❖ Transition

27

Unified Process model(contd)

Techniques used:

❖ Iteration

❖ Use cases

❖ Working architecture early on

❖ Components

❖ Effective team

❖ Quality

28

Conclusions

❖ Different life-cycle models

❖ Each with own strengths

❖ Each with own weaknesses

❖ Criteria for deciding on a modelinclude

~ The organization

~ Its management

~ Skills of the employees

~ The nature of the product

❖ Best suggestion

~ “Mix-and-match” life-cycle model

Introduction toSoftware

Engineering

We will start out by introducing calssical SoftwareEngineering. Agile methods do by no means rule outthe value of Software Engineering practices, theyonly change the way we use them in the end.

What will IWhat will Ihave to do tohave to do topass thispass thiscourse?course?

Introduction toIntroduction toSoftwareSoftware

EngineeringEngineering

Introduction toIntroduction tothe coursethe course

The SoftwareThe SoftwareProcessProcess

The SoftwareProcess

The software process includes a Software Life-Cycle Model, methodologies, tools and

techniques used and the people performing thework.

Software Life-Software Life-Cycle ModelsCycle Models

31

Overview

❖ Client, Developer, and User

❖ Requirements Phase

❖ Specification Phase

❖ Design Phase

❖ Implementation Phase

❖ Integration Phase

❖ Maintenance Phase

❖ Retirement

❖ Problems with Software Production:

~ Essence and Accidents

~ Improving the Software Process

32

The SoftwareProcess

❖ The life-cycle model

❖ Tools and methodologies

❖ The individuals

33

Planning Phase?

❖ There is NO planning phase

❖ Project begins with preliminary planning tomanage requirements and analysis phases

❖ Once it is kown what is to be developed, a projectplan is created

~ Budget

~ Staffing requirements

~ schedule

❖ This project plan is watched and updated duringthe whole project

34

Testing Phase?

❖ There is NO testing phase

❖ Testing is an activity performed throughoutsoftware production

❖ Verification

~ Performed at the end of each phase

❖ Validation

~ Performed before delivering the product to theclient

35

DocumentationPhase?

❖ There is NO documentation phase

❖ Every phase must be fully documented beforestarting the next phase

~ Postponed documentation may never becompleted

~ The responsible individual may leave

~ The product is constantly changing — we needthe documentation to do this

~ The design (for example) will be modifiedduring development, but the original designersmay not be available to document it

36

RequirementsPhase

❖ Assumption

~ The software being considered is economicallyjustifiable

❖ Concept exploration

~ Determine what the client needs, not what theclient wants

❖ Moving target problem

37

RequirementsPhase Testing

❖ Rapid prototyping

38

RequirementsPhase

Documentation

❖ Rapid prototype, or

❖ Requirements document

39

Specification Phase

❖ Specifications document (“specifications”)

~ Legal document

~ Must not have phrases like “optimal,” or “98%complete”

❖ Specifications must not be

~ Ambiguous

~ Incomplete

~ Contradictory

❖ Once the specifications have been signed off

~ The project plan is drawn up

~ This is the earliest possible time for the projectplan

40

Specification PhaseTesting

❖ Traceability

❖ Review

❖ Check the project plan

41

Specification PhaseDocumentation

❖ Specification document (specifications)

❖ Project plan

42

Design Phase

❖ Specification—what

❖ Design—how

❖ Retain design decisions

~ When a dead-end is reached

~ For the maintenance team

~ Ideally, the design should be open-ended

❖ Architectural design

~ Decompose the product into modules

❖ Detailed design

~ Design each module: data structures,algorithms

43

Design PhaseTesting

❖ Traceability

❖ Review

44

Design PhaseDocumentation

❖ Design

~ Architectural design

~ Detailed design

45

ImplementationPhase

❖ Implement the detailed design in code

46

ImplementationPhase Testing

❖ Review

❖ Test cases

~ Informal testing (desk checking)

~ Formal testing (SQA)

47

ImplementationPhase

Documentation

❖ Source code

❖ Test cases (with expected output)

48

Integration Phase

❖ Combine the modules and check the product as awhole

49

Integration PhaseTesting

❖ Product testing

❖ Acceptance testing

50

Integration PhaseDocumentation

❖ Commented source code

❖ Test cases for the product as a whole

51

Maintenance Phase

❖ Maintenance

~ Any change once the client has accepted thesoftware

❖ The most money is devoted to this phase

❖ The problem of lack of documentation

52

Maintenance PhaseTesting

❖ Regression testing

53

Maintenance PhaseDocumentation

❖ Record of all changes made, with reasons

❖ Regression test cases

54

Retirement

❖ Good software is maintained

❖ Sometimes software is rewritten from scratch

~ Software is now unmaintainable because

❖ A drastic change in design has occurred

❖ The product must be implemented on atotally new hardware/operating system

❖ Documentation is missing or inaccurate

❖ Hardware is to be changed—it may becheaper to rewrite the software fromscratch than to modify it

❖ True retirement is a rare event

55

Process-SpecificDifficulties

❖ Does the product meets the user’s real needs?

❖ Is the specification document free ofambiguities, contradictions, and omissions?

56

Inherent Problemsof SoftwareProduction

❖ Hardware has inherent limits

❖ So does software

❖ No Silver Bullet

~ Complexity

~ Conformity

~ Changeability

~ Invisibility

❖ Aristotelian categories

~ Essence

~ Accidents

57

Complexity

❖ Software is far more complex than hardware

~ Traditional abstraction will not work

~ We cannot understand the whole, so we cannotunderstand any part

~ Management is difficult

~ Maintenance is a nightmare (documentation,too)

58

Changeability

❖ Software is easier to change than hardware

❖ Pressure to change

~ Reality

~ Useful software

~ Easier to change

~ Software has a long lifetime (~15 yrs)compared to hardware (~4 yrs)

59

Changeability

❖ Software is easier to change than hardware

❖ Pressure to change

~ Reality

~ Useful software

~ Easier to change

~ Software has a long lifetime (~15 yrs)compared to hardware (~4 yrs)

60

Invisibility

❖ Software is invisible and unvisualizable

❖ Complete views are incomprehensible

❖ Partial views are misleading

❖ However, all views can be helpful

61

Is There a SilverBullet?

❖ What about

~ High-level languages

~ Time sharing

~ CASE tools

❖ These did not solve the intrinsic problems

❖ But, no “silver bullet” (order-of-magnitudeincrease) is possible

62

Improving theSoftware Process

❖ U.S. Department of Defense initiative

❖ Software Engineering Institute (SEI)

❖ The fundamental problem with software

~ The software process is badly managed

❖ Software process improvement initiatives

~ Capability maturity model (CMM)

~ ISO 9000-series

~ ISO/IEC 15504

63

Capability MaturityModel

❖ Not a life-cycle model

❖ Set of strategies for improving the softwareprocess

~ SW–CMM for software

~ P–CMM for human resources (“people”)

~ SE–CMM for systems engineering

~ IPD–CMM for integrated product development

~ SA–for software acquisition

❖ These strategies are being unified into CMMI(capability maturity model integration)

64

SW–CMM

❖ A strategy for improving the software process

❖ Put forward in 1986 by the SEI

❖ Fundamental idea:

~ Improving the software process leads to

❖ Improved software quality

❖ Delivery on time, within budget

~ Improved management leads to

❖ Improved techniques

❖ Five levels of “maturity” are defined

~ Organization advances stepwise from level tolevel

65

SW-CMM Level 1. Initial Level

❖ Ad hoc approach

~ Entire process is unpredictable

~ Management consists of responses to crises

❖ Most organizations world-wide are at level 1

66

SW-CMM Level 2. Repeatable Level

❖ Basic software management

~ Management decisions should be made on thebasis of previous experience with similarproducts

~ Measurements (“metrics”) are made

~ These can be used for making cost andduration predictions in the next project

~ Problems are identified, immediate correctiveaction is taken

67

SW-CMM Level 3. Defined Level

❖ The software process is fully documented

~ Managerial and technical aspects are clearlydefined

~ Continual efforts are made to improve qualityand productivity

~ Reviews are performed to improve softwarequality

~ CASE-tools are applicable now (and not forlevel 1 or 2)

68

SW-CMM Level 4. Managed Level

❖ Quality and productivity goals are set for each project

~ Quality, productivity are continually monitored

~ Statistical quality controls are in place

69

SW-CMM Level 5. Optimizing Level

❖ Continuous process improvement

~ Statistical quality and process controls

~ Feedback of knowledge from each project tothe next

70

SW-CMM Summary

71

SW-CMM KeyProcess Areas

❖ There are key process areas (KPAs) for eachlevel

❖ Level 2 KPAs include:

~ Requirements management

~ Project planning

~ Project tracking

~ Configuration management

~ Quality assurance

❖ Compare

~ Level 2: Detection and correction of faults

~ Level 5: Prevention of faults

72

Experience

❖ It takes:

~ 3 to 5 years to get from level 1 to level 2

~ 1.5 to 3 years from level 2 to level 3

~ SEI questionnaires highlight shortcomings,suggest ways to improve the process

❖ Original idea: U.S. Defense contracts would beawarded only to capable firms

73

Other SPIInitiatives

❖ Other software process improvement (SPI)initiatives:

~ ISO 9000-series

~ ISO/IEC 15504

74

ISO 9000

❖ Set of five standards for industrial activities

~ ISO 9001 for quality systems

~ ISO 9000-3, guidelines to apply ISO 9001 tosoftware

~ There is an overlap with CMM, but they are notidentical

~ ISO 9000 is not process improvement

~ Stress on documenting the process

~ Emphasis on measurement and metrics

~ ISO 9000 is required to do business with theE.U.

75

ISO/IEC 15504

❖ Original name: Software Process ImprovementCapability dEtermination (SPICE)

~ International process improvement initiative

~ Started by British Ministry of Defence (MOD)

~ Includes process improvement, softwareprocurement

~ Extends and improves CMM, ISO 9000

~ Framework, not a method

❖ CMM, ISO 9000 conform to this framework

❖ Now referred to as ISO/IEC 15504 (or just15504 for short)

76

ProcessImprovement Data

❖ SEI report on 13 organizations in the originalstudy

❖ They used a variety of process improvementtechniques, not just SW–CMM

77

ProcessImprovement Data

(contd)

❖ Results of 34 Motorola projects

End of Today’sLecture

Thanks for your attention!