Post on 19-Dec-2015
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