1

IT607 - Software IT607 - Software EngineeringEngineering

Kavi AryaKavi Arya

KReSIT, IIT-BombayKReSIT, IIT-Bombay

2

• From software verticals to embedded systems• Growing number of critical applications

Beware of the computer!

3

Designer ProductivityDesigner Productivity ““The Mythical Man Month” by Frederick Brooks ’75The Mythical Man Month” by Frederick Brooks ’75 More designers on team => lower productivity because of More designers on team => lower productivity because of

increasing communication costs between groupsincreasing communication costs between groups Consider 1M transistor project:Consider 1M transistor project:

- - Say, a designer has productivity of 5000 transistor/mthSay, a designer has productivity of 5000 transistor/mth- - Each extra designer => decrease of 100 transistor/mth Each extra designer => decrease of 100 transistor/mth

productivity in group due to comm. costsproductivity in group due to comm. costs 1 designer1 designer 1M/5000 =>1M/5000 => 200mth200mth 10 designer10 designer 1M/(10*4100) => 1M/(10*4100) => 24.3mth24.3mth 25 designer25 designer 1M/(25*2600) =>1M/(25*2600) => 15.3mth15.3mth 27 designer27 designer 1M/(27*2400) =>1M/(27*2400) => 15.4mth15.4mth

Need new design technology to shrink design gapNeed new design technology to shrink design gap

Source: Embedded System Design: Frank Vahid/ Tony Vargis (John Wiley & Sons, Inc.2002)

4

Software Chronic CrisisSoftware Chronic Crisis

Studies in the USA have shown: Studies in the USA have shown: For every 6 new For every 6 new large-scalelarge-scale software systems software systems

put into operation, 2 others are cancelled!put into operation, 2 others are cancelled! The average software development project over The average software development project over

shoots its schedule by half (and shoots its schedule by half (and largerlarger projects projects generally do worse).generally do worse).

Around 75% of all Around 75% of all largelarge systems are “operating systems are “operating failures” i.e. do not function as intended or are failures” i.e. do not function as intended or are not used at all. not used at all. [Source of USA figures: Software [Source of USA figures: Software Productivity Research]Productivity Research]

W. Wayt Gibbs, Software Chronic Crisis, Scientific American, September 1994

5

The ProblemThe Problem

• • 1/4 of large software projects are canceled1/4 of large software projects are canceled

• • Average software project 50% over costAverage software project 50% over cost

• • 3/4 of large systems are “operating failures”3/4 of large systems are “operating failures”

• • Software in high demandSoftware in high demand

• • Cell phone: 30 kLOCCell phone: 30 kLOC 4-speed transmission: 20 kLOC4-speed transmission: 20 kLOC

• • B-2 Stealth Bomber: 3.5 MLOCB-2 Stealth Bomber: 3.5 MLOC

6

Current SituationCurrent Situation

However, today the vast majority of code is still hand However, today the vast majority of code is still hand crafted from programming languages by artisans using crafted from programming languages by artisans using techniques they neither techniques they neither measuremeasure nor are able to nor are able to repeatrepeat consistently.consistently.

But academics have made some progress in But academics have made some progress in formal formal methodsmethods and in instituting and in instituting software engineeringsoftware engineering degreesdegrees..

Industry has made some progress towards market Industry has made some progress towards market structures and technology supporting structures and technology supporting reusablereusable software software partsparts..

Even so, a research innovation typically requires Even so, a research innovation typically requires 1818 years to become standard industrial practice.years to become standard industrial practice.

[SEI finding][SEI finding]

7

Current trends: The decade aheadCurrent trends: The decade ahead A combination of academic industry and government A combination of academic industry and government

is needed to hoist software development to the level of is needed to hoist software development to the level of an industrial age engineering discipline within the an industrial age engineering discipline within the decade (2005)decade (2005)

As we move into the Information Age, As we move into the Information Age, error-free error-free software will become the expected norm. software will become the expected norm.

This will be especially true for embedded software in This will be especially true for embedded software in consumer products.consumer products.

The amount of s/w in consumer products is The amount of s/w in consumer products is doublingdoubling every 2 years e.g. TV 500Kb, Shaver 2Kbevery 2 years e.g. TV 500Kb, Shaver 2Kb

Existing problems in attempts to develop error-free Existing problems in attempts to develop error-free Real-Time s/w for defense applications do not give us Real-Time s/w for defense applications do not give us confidence confidence (Gilles Kahn of INRIA)(Gilles Kahn of INRIA)

8

Some SolutionsSome Solutions

Progress on Software Process, e.g. the SEI’s Progress on Software Process, e.g. the SEI’s Capability Maturity Model (CMM)Capability Maturity Model (CMM)

5 Level Model - 1 is Chaotic, 2 is Repeatable, 5 Level Model - 1 is Chaotic, 2 is Repeatable, 3 is Defined, 4 is Managed and 5 is 3 is Defined, 4 is Managed and 5 is OptimisingOptimising

But 75% of companies are at Level 1 and But 75% of companies are at Level 1 and 24% are at Levels 2 and 3.24% are at Levels 2 and 3.

USA Space Shuttle software maintenance is USA Space Shuttle software maintenance is at Level 5.at Level 5.

9

Progress on Software ReuseProgress on Software Reuse

There is some work on component based There is some work on component based development, reusable parts and development, reusable parts and standardisation to support reusestandardisation to support reuse

But more research is needed before this But more research is needed before this becomes widespread industrial practice.becomes widespread industrial practice.

10

Causes of FailureCauses of Failure• • Shifting requirementsShifting requirements

• • Denver had $20M changes after construction Denver had $20M changes after construction beganbegan

• • New or legacy system dependenciesNew or legacy system dependencies

• • Poor specificationPoor specification

• • High complexity, couplingHigh complexity, coupling

• • Large sizeLarge size

• • Lack of calendar timeLack of calendar time

• • Insufficient tools and techniquesInsufficient tools and techniques

• • Poor managementPoor management

11

Some ProgressSome Progress

• • Shifting requirements: Prototype-firstShifting requirements: Prototype-first

• • System dependencies: Architectures, System dependencies: Architectures, processesprocesses

• • Poor Specification: Formal methodsPoor Specification: Formal methods

• • High complexity: Domain analysis, High complexity: Domain analysis, architecturesarchitectures

• • Large size: Modular decompositionLarge size: Modular decomposition

• • Lack of calendar time: ProcessesLack of calendar time: Processes

• • Insufficient tools and techniques: More Insufficient tools and techniques: More work…work…

• • Poor management: BooksPoor management: Books

12

Formal MethodsFormal Methods

• • The science behind software engineeringThe science behind software engineering

• • Based on sets, Boolean logic, predicate logicBased on sets, Boolean logic, predicate logic

• • Or graph theory, automata theory, probability and Or graph theory, automata theory, probability and statisticsstatistics

13

New ProcessesNew Processes

• • XP: lightweight evolutionary processXP: lightweight evolutionary process• • On-site customer, prototypesOn-site customer, prototypes• • Always a working system, trade time for Always a working system, trade time for

featuresfeatures• • Write test cases firstWrite test cases first• • Cleanroom: Don’t let bugs inCleanroom: Don’t let bugs in• • Don’t execute code (and maybe don’t Don’t execute code (and maybe don’t

compile!)compile!)• • Independent verification groupIndependent verification group• • Analyze quality statisticallyAnalyze quality statistically• • Only integrate verified componentsOnly integrate verified components• • And others…And others…

14

Evaluation: The Capability Maturity Evaluation: The Capability Maturity ModelModel

• • SEI’s Capability Maturity Model (CMM)SEI’s Capability Maturity Model (CMM)

• • Levels 1 (chaos) to 5 (repeatable, Levels 1 (chaos) to 5 (repeatable, predictable)predictable)

• • Increased productivity and quality, lower Increased productivity and quality, lower riskrisk

• • Understand and fix process problemsUnderstand and fix process problems

• • Most organizations are at level 1Most organizations are at level 1

15

Does It Work?Does It Work?

• • Raytheon went from level 1 to 2 to 3 ’87 to Raytheon went from level 1 to 2 to 3 ’87 to ’92’92

• • 15 projects saved $15M15 projects saved $15M• • 2x productivity, 7.7x ROI2x productivity, 7.7x ROI• • Motorola 1993 reportMotorola 1993 report• • 34 projects assessed at all CMM levels34 projects assessed at all CMM levels• • Level 5 vs level 1: defect rate 10x lower, Level 5 vs level 1: defect rate 10x lower,

cycle time 8x shorter, productivity 3x bettercycle time 8x shorter, productivity 3x better• • 6.77x ROI6.77x ROI• • Also: no improvement at level 3, costs are Also: no improvement at level 3, costs are

highhigh

16

But…But…

• • Companies can fool the ratingCompanies can fool the rating

• • Discourages companies from hard projectsDiscourages companies from hard projects

• • Doesn’t encourage valuable projectsDoesn’t encourage valuable projects

• • CMM is a poor predictor for challenging projectsCMM is a poor predictor for challenging projects

• • Honeywell (CMM level 5) and QRASHoneywell (CMM level 5) and QRAS

17

Characteristics of a Good ProcessCharacteristics of a Good Process

Should be precisely defined – no ambiguity Should be precisely defined – no ambiguity about what is to be done, when, how, etc.about what is to be done, when, how, etc.

It must be predictable – can be repeated in It must be predictable – can be repeated in other projects with confidence about its other projects with confidence about its outcomeoutcome

Predictable with respect to effort, cost:Predictable with respect to effort, cost:

Project A: Web-bawd library applications done by Project A: Web-bawd library applications done by 3 persons in 4 months3 persons in 4 months

another project B (guest house bookings), another project B (guest house bookings), similar in complexity should also take about 12 similar in complexity should also take about 12 person months. person months.

18

A Good Process …A Good Process … Predictable for quality: with respect to number Predictable for quality: with respect to number

and type of defects, performance, …and type of defects, performance, … Predictable process is said to be ‘under Predictable process is said to be ‘under

statistical control’ , where actual values statistical control’ , where actual values are close to expected valuesare close to expected values

It supports testing and maintainabilityIt supports testing and maintainability Maintenance by third partyMaintenance by third party Follow standards, provide necessary Follow standards, provide necessary

documentationdocumentation This characteristic differentiates between This characteristic differentiates between

prototype and productprototype and product

19

A Good Process …A Good Process …Facilitates early detection of and Facilitates early detection of and removal of defectsremoval of defects

Defects add to project costDefects add to project cost Late detection/correction is costlyLate detection/correction is costly

It should facilitate monitoring and It should facilitate monitoring and improvementimprovement

Based on feedbackBased on feedback Permit use of new tools, technologiesPermit use of new tools, technologies Permit measurementsPermit measurements

20

ProjectsProjectsSome Ideas: Ekalavya Infrastructure (Prof. DB Phatak)Some Ideas: Ekalavya Infrastructure (Prof. DB Phatak)• • Build Ekalavya core infrastructure using software engineering principlesBuild Ekalavya core infrastructure using software engineering principles Core infrastructure: 2 projectsCore infrastructure: 2 projects Modules: 2 projectsModules: 2 projects

Some Ideas: “J to E Simulator (capacity planning tool) Some Ideas: “J to E Simulator (capacity planning tool) Prof. Umesh BellurProf. Umesh Bellur

• • Architect, design , build.Architect, design , build.

Some Ideas: Affordable ERP System (Prof. Kavi / Prof. Bernard)Some Ideas: Affordable ERP System (Prof. Kavi / Prof. Bernard)• • Think of an ERP for Kirana storesThink of an ERP for Kirana stores 15M shops threatened by Malls15M shops threatened by Malls Each shop supporting 5-6 peopleEach shop supporting 5-6 people

Some Ideas: Prof. Kavi AryaSome Ideas: Prof. Kavi Arya• • Customer Relationship Management Tool (brandable)Customer Relationship Management Tool (brandable) Architect, design , build.Architect, design , build.

21

ReferencesReferences ““Software’s Chronic Crisis” by W. Wayt Gibbs Software’s Chronic Crisis” by W. Wayt Gibbs

20032003 W. Wayt Gibbs, Software Chronic Crisis, W. Wayt Gibbs, Software Chronic Crisis,

Scientific American, September 1994Scientific American, September 1994 ““Topics in Tools and Environments for a Topics in Tools and Environments for a

Distributed Cooperative Work”, Koichiro Distributed Cooperative Work”, Koichiro Ochimizu. Japan Adv. Inst. of Science and Ochimizu. Japan Adv. Inst. of Science and Technologies School of Information ScienceTechnologies School of Information Science

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, Roger Pressman, McGraw Hill Approach, Roger Pressman, McGraw Hill International EditionInternational Edition..

Misc web-based resourcesMisc web-based resources

22

Software Software ApplicationsApplications system softwaresystem software

application softwareapplication software engineering/scientific engineering/scientific

software software embedded software embedded software product-line softwareproduct-line software WebApps (Web applications)WebApps (Web applications) AI softwareAI software

23

Software—New CategoriesSoftware—New Categories Ubiquitous computingUbiquitous computing—wireless networks—wireless networks NetsourcingNetsourcing—the Web as a computing engine—the Web as a computing engine Open sourceOpen source—”free” source code open to the —”free” source code open to the

computing community (a blessing, but also a computing community (a blessing, but also a potential curse!)potential curse!)

Also … (see Chapter 32)Also … (see Chapter 32) Data miningData mining Grid computingGrid computing Cognitive machinesCognitive machines Software for nanotechnologiesSoftware for nanotechnologies

24

Legacy SoftwareLegacy Software

software must be software must be adaptedadapted to meet the needs to meet the needs of new computing environments or of new computing environments or technology.technology.

software must be software must be enhancedenhanced to implement to implement new business requirements.new business requirements.

software must be software must be extended to make it extended to make it interoperableinteroperable with other more modern with other more modern systems or databases.systems or databases.

software must be software must be re-architectedre-architected to make it to make it viable within a network environmentviable within a network environment.

Why must it change?

25

Software EvolutionSoftware Evolution The Law of Continuing Change (1974):The Law of Continuing Change (1974): E-type systems must be continually adapted else they E-type systems must be continually adapted else they

become progressively less satisfactory.become progressively less satisfactory. The Law of Increasing Complexity (1974):The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases As an E-type system evolves its complexity increases

unless work is done to maintain or reduce it.unless work is done to maintain or reduce it. The Law of Self Regulation (1974):The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with The E-type system evolution process is self-regulating with

distribution of product and process measures close to normal.distribution of product and process measures close to normal. The Law of Conservation of Organizational Stability (1980):The Law of Conservation of Organizational Stability (1980): The average effective global The average effective global

activity rate in an evolving E-type system is invariant over product lifetime.activity rate in an evolving E-type system is invariant over product lifetime. The Law of Conservation of Familiarity (1980):The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with As an E-type system evolves all associated with

it, developers, sales personnel, users, for example, must maintain mastery of its content and it, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution. behavior to achieve satisfactory evolution.

The Law of Continuing Growth (1980):The Law of Continuing Growth (1980): The functional content of E-type systems must be The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.continually increased to maintain user satisfaction over their lifetime.

The Law of Declining Quality (1996):The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.unless they are rigorously maintained and adapted to operational environment changes.

The Feedback System Law (1996):The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.over any reasonable base.

Source: Lehman, M., et al, “Metrics and Laws of Software Evolution—The Nineties View,” Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be downloaded from: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf

26

A Layered A Layered TechnologyTechnology

Software Engineering

a “quality” focusa “quality” focus

process modelprocess model

methodsmethods

toolstools

27

A Process A Process FrameworkFramework

Process frameworkProcess frameworkFramework activitiesFramework activities

work taskswork taskswork productswork productsmilestones & deliverablesmilestones & deliverablesQA checkpointsQA checkpoints

Umbrella ActivitiesUmbrella Activities

28

Framework ActivitiesFramework Activities

CommunicationCommunication PlanningPlanning ModelingModeling

Analysis of requirementsAnalysis of requirements DesignDesign

ConstructionConstruction Code generationCode generation TestingTesting

DeploymentDeployment

29

Umbrella ActivitiesUmbrella Activities Software project managementSoftware project management Formal technical reviewsFormal technical reviews Software quality assuranceSoftware quality assurance Software configuration managementSoftware configuration management Work product preparation and Work product preparation and

productionproduction Reusability managementReusability management MeasurementMeasurement Risk managementRisk management

30

The Process Model:The Process Model:AdaptabilityAdaptability

the framework activities will the framework activities will alwaysalways be be applied on applied on everyevery project ... BUT project ... BUT

the tasks (and degree of rigor) for each the tasks (and degree of rigor) for each activity will vary based on:activity will vary based on: the type of project the type of project characteristics of the projectcharacteristics of the project common sense judgment; concurrence of the common sense judgment; concurrence of the

project teamproject team

31

The CMMIThe CMMI The CMMI defines each process area in terms of The CMMI defines each process area in terms of

“specific goals” and the “specific practices” “specific goals” and the “specific practices” required to achieve these goals.required to achieve these goals.

Specific goalsSpecific goals establish the characteristics that establish the characteristics that must exist if the activities implied by a process must exist if the activities implied by a process area are to be effective. area are to be effective.

Specific practicesSpecific practices refine a goal into a set of refine a goal into a set of process-related activities.process-related activities.

32

Process PatternsProcess Patterns Process patterns define a set of activities, Process patterns define a set of activities,

actions, work tasks, work products and/or related actions, work tasks, work products and/or related behaviorsbehaviors

A template is used to define a patternA template is used to define a pattern Typical examples:Typical examples:

Customer communication (a process activity)Customer communication (a process activity) Analysis (an action)Analysis (an action) Requirements gathering (a process task)Requirements gathering (a process task) Reviewing a work product (a process task)Reviewing a work product (a process task) Design model (a work product)Design model (a work product)

33

Process AssessmentProcess Assessment

The process should be assessed to ensure that it The process should be assessed to ensure that it meets a set of basic process criteria that have meets a set of basic process criteria that have been shown to be essential for a successful been shown to be essential for a successful software engineeringsoftware engineering.

Many different assessment options are available: Many different assessment options are available: SCAMPISCAMPI CBA IPICBA IPI SPICESPICE ISO 9001:2000ISO 9001:2000

34

Assessment and ImprovementAssessment and Improvement

Software Process

Software Process Assessment

is examined by identifies capabilitiesand risk of

identifiesmodifications to

Software Process Improvement

Capability Determination

leads to leads to

motivates

35

Personal Software Process Personal Software Process (PSP)(PSP)

Recommends five framework activities:Recommends five framework activities: PlanningPlanning High-level designHigh-level design High-level design reviewHigh-level design review DevelopmentDevelopment PostmortemPostmortem

stresses the need for each software stresses the need for each software engineer to identify errors early and as engineer to identify errors early and as important, to understand the types of important, to understand the types of errorserrors

36

Team Software Process (TSP)Team Software Process (TSP)

Each project is “launched” using a “script” Each project is “launched” using a “script” that defines the tasks to be accomplishedthat defines the tasks to be accomplished

Teams are self-directedTeams are self-directed Measurement is encouragedMeasurement is encouraged Measures are analyzed with the intent of Measures are analyzed with the intent of

improving the team processimproving the team process

37

The Primary Goal of Any Software The Primary Goal of Any Software Process: Process: High QualityHigh Quality

Remember:Remember:

High quality = project timelinessHigh quality = project timeliness

Why?Why?

Less rework!Less rework!

38

Prescriptive ModelsPrescriptive Models

Prescriptive process models advocate an orderly approach Prescriptive process models advocate an orderly approach to software engineeringto software engineering

That leads to a few questions …That leads to a few questions … If prescriptive process models strive for structure and If prescriptive process models strive for structure and

order, order, are they inappropriate for a software world that are they inappropriate for a software world that thrives on change?thrives on change?

Yet, if we reject traditional process models (and the order Yet, if we reject traditional process models (and the order they imply) and replace them with something less they imply) and replace them with something less structured, structured, do we make it impossible to achieve do we make it impossible to achieve coordination and coherence in software work?coordination and coherence in software work?

39

The Waterfall The Waterfall ModelModel

Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

40

The Incremental The Incremental ModelModel

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e ry f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

De p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t es t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des igncode t es t

41

The RAD ModelThe RAD Model

Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation test ing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback

42

Evolutionary Models: Evolutionary Models: PrototypingPrototyping

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

43

Evolutionary Models: The Evolutionary Models: The SpiralSpiral

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

44

Evolutionary Models: ConcurrentEvolutionary Models: Concurrent

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

45

Still Other Process Still Other Process ModelsModels

Component based developmentComponent based development—the process to —the process to apply when reuse is a development objectiveapply when reuse is a development objective

Formal methodsFormal methods—emphasizes the mathematical —emphasizes the mathematical specification of requirementsspecification of requirements

AOSDAOSD—provides a process and methodological —provides a process and methodological approach for defining, specifying, designing, and approach for defining, specifying, designing, and constructing constructing aspectsaspects

Unified ProcessUnified Process—a “use-case driven, architecture-—a “use-case driven, architecture-centric, iterative and incremental” software process centric, iterative and incremental” software process closely aligned with the Unified Modeling Language closely aligned with the Unified Modeling Language (UML)(UML)

46

inceptioninception

The Unified Process (UP)The Unified Process (UP)

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration

47

UP PhasesUP Phases

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

48

UP Work ProductsUP Work ProductsInception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Description. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment

Delivered software increment Beta test reports General user feedback

49

The Manifesto for The Manifesto for Agile Software Agile Software DevelopmentDevelopment

““We are uncovering better ways of We are uncovering better ways of developing software by doing it and developing software by doing it and helping others do it. Through this work helping others do it. Through this work we have come to value: we have come to value:

•Individuals and interactionsIndividuals and interactions over over processes and tools processes and tools •Working softwareWorking software over over comprehensive documentation comprehensive documentation •Customer collaborationCustomer collaboration over contract over contract negotiation negotiation •Responding to changeResponding to change over following over following a plana plan

That is, while there is value in the items That is, while there is value in the items on the right, we value the items on the on the right, we value the items on the left more.”left more.”

Kent Beck et alKent Beck et al

50

What is “Agility”?What is “Agility”?

Effective (rapid and adaptive) response to Effective (rapid and adaptive) response to changechange

Effective communication among all Effective communication among all stakeholdersstakeholders

Drawing the customer onto the teamDrawing the customer onto the team Organizing a team so that it is in control of Organizing a team so that it is in control of

the work performedthe work performed

Yielding …Yielding … Rapid, incremental delivery of softwareRapid, incremental delivery of software

51

An Agile ProcessAn Agile Process

Is driven by customer descriptions of what Is driven by customer descriptions of what is required (scenarios)is required (scenarios)

Recognizes that plans are short-livedRecognizes that plans are short-lived Develops software iteratively with a heavy Develops software iteratively with a heavy

emphasis on construction activitiesemphasis on construction activities Delivers multiple ‘software increments’Delivers multiple ‘software increments’ Adapts as changes occurAdapts as changes occur

52

Extreme Programming (XP)Extreme Programming (XP)

The most widely used agile process, originally The most widely used agile process, originally proposed by Kent Beckproposed by Kent Beck

XP PlanningXP Planning Begins with the creation of “Begins with the creation of “user storiesuser stories”” Agile team assesses each story and assigns a Agile team assesses each story and assigns a costcost Stories are grouped to for a Stories are grouped to for a deliverable incrementdeliverable increment A A commitmentcommitment is made on delivery date is made on delivery date After the first increment “After the first increment “project velocityproject velocity” is used to ” is used to

help define subsequent delivery dates for other help define subsequent delivery dates for other incrementsincrements

53

Extreme Programming (XP)Extreme Programming (XP)

XP DesignXP Design Follows the Follows the KIS principleKIS principle Encourage the use of Encourage the use of CRC cardsCRC cards (see Chapter 8) (see Chapter 8) For difficult design problems, suggests the creation of “For difficult design problems, suggests the creation of “spike spike

solutionssolutions”—a design prototype”—a design prototype Encourages “Encourages “refactoringrefactoring”—an iterative refinement of the internal ”—an iterative refinement of the internal

program designprogram design XP CodingXP Coding

Recommends the Recommends the construction of a unit testconstruction of a unit test for a store for a store beforebefore coding coding commencescommences

Encourages “Encourages “pair programmingpair programming”” XP TestingXP Testing

All All unit tests are executed dailyunit tests are executed daily ““Acceptance tests”Acceptance tests” are defined by the customer and excuted to assess are defined by the customer and excuted to assess

customer visible functionalitycustomer visible functionality

54

Extreme Programming (XP)Extreme Programming (XP)

unit test continuous integration

acceptance testing

pair programming

Release

user stories values acceptance test criteria iteration plan

simple design CRC cards

spike solutions prototypes

refactoring

software incrementproject velocity computed

55

Adaptive Software Adaptive Software DevelopmentDevelopment

Originally proposed by Jim HighsmithOriginally proposed by Jim Highsmith ASD — distinguishing featuresASD — distinguishing features

Mission-drivenMission-driven planning planning Component-based focusComponent-based focus Uses “Uses “time-boxingtime-boxing” (See Chapter 24)” (See Chapter 24) Explicit consideration of Explicit consideration of risksrisks Emphasizes Emphasizes collaborationcollaboration for requirements for requirements

gatheringgathering Emphasizes “Emphasizes “learninglearning” throughout the process” throughout the process

56

Adaptive Software Adaptive Software DevelopmentDevelopment

adaptive cycle planning uses mission statement project constraints basic requirements time-boxed release plan

Requirements gathering J AD mini-specs

components implemented/ tested focus groups for feedback formal technical reviews postmortems

software incrementadjustments for subsequent cycles

Release

57

Dynamic Systems Development Dynamic Systems Development MethodMethod

Promoted by the DSDM Consortium (Promoted by the DSDM Consortium (www.dsdm.orgwww.dsdm.org))

DSDM—distinguishing featuresDSDM—distinguishing features Similar in most respects to XP and/or ASDSimilar in most respects to XP and/or ASD Nine guiding principlesNine guiding principles

Active user involvement is imperative. Active user involvement is imperative. DSDM teams must be empowered to make decisions.DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of Fitness for business purpose is the essential criterion for acceptance of

deliverables.deliverables. Iterative and incremental development is necessary to converge on an Iterative and incremental development is necessary to converge on an

accurate business solution.accurate business solution. All changes during development are reversible.All changes during development are reversible. Requirements are baselined at a high levelRequirements are baselined at a high level Testing is integrated throughout the life-cycle.Testing is integrated throughout the life-cycle.

58

Dynamic Systems Development Dynamic Systems Development MethodMethod

DSDM Life Cycle (with permission of the DSDM consortium)

59

ScrumScrum

Originally proposed by Schwaber and BeedleOriginally proposed by Schwaber and Beedle Scrum—distinguishing featuresScrum—distinguishing features

Development work is partitioned into “Development work is partitioned into “packetspackets”” Testing and documentation are on-goingTesting and documentation are on-going as the product as the product

is constructedis constructed Work occurs in “Work occurs in “sprintssprints” and is derived from a ” and is derived from a

““backlogbacklog” of existing requirements” of existing requirements Meetings are very shortMeetings are very short and sometimes conducted and sometimes conducted

without chairswithout chairs ““demosdemos” are delivered to the customer with the time-box ” are delivered to the customer with the time-box

allocatedallocated

60

ScrumScrum

61

CrystalCrystal

Proposed by Cockburn and HighsmithProposed by Cockburn and Highsmith Crystal—distinguishing featuresCrystal—distinguishing features

Actually a Actually a family of process modelsfamily of process models that allow that allow ““maneuverabilitymaneuverability” based on problem characteristics” based on problem characteristics

Face-to-face communicationFace-to-face communication is emphasized is emphasized Suggests the use of “Suggests the use of “reflection workshopsreflection workshops” to ” to

review the work habits of the teamreview the work habits of the team

62

Feature Driven DevelopmentFeature Driven Development

Originally proposed by Peter Coad et alOriginally proposed by Peter Coad et al FDD—distinguishing featuresFDD—distinguishing features

Emphasis is on defining Emphasis is on defining “features”“features” aa featurefeature “is a client-valued function that can be “is a client-valued function that can be

implemented in two weeks or less.”implemented in two weeks or less.” Uses a Uses a feature templatefeature template

<action> the <result> <by | for | of | to> a(n) <object><action> the <result> <by | for | of | to> a(n) <object>

A A features listfeatures list is created and “ is created and “plan by featureplan by feature” is ” is conductedconducted

Design and construction merge in FDDDesign and construction merge in FDD

63

Feature Driven DevelopmentFeature Driven Development

Reprinted with permission of Peter CoadReprinted with permission of Peter Coad

64

Agile ModelingAgile Modeling

Originally proposed by Scott AmblerOriginally proposed by Scott Ambler Suggests a set of agile modeling principlesSuggests a set of agile modeling principles

Model with a purposeModel with a purpose Use multiple modelsUse multiple models Travel lightTravel light Content is more important than representationContent is more important than representation Know the models and the tools you use to create Know the models and the tools you use to create

themthem Adapt locallyAdapt locally