AGILE SoftwareConstruction
Beatrice Å[email protected]
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!
Top Related