bull Software Engineering bull USDPbull Agile and Scrum
What is Software Engineering (SE)
Wikipedia saysbull the application of a systematic disciplined quantifiable approach to the development operation and maintenance of software
bull an engineering discipline that is concerned with all aspects of software productionldquo
bull the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines
3
>
Software Engineering
bull Ian Sommerville
ndash Software Engineering is concerned with method tools and techniques for developing and managing the process of creating and evolving software products
bull Oxford English Dictionary
ndash The professional development production and management of system software
4
>
Design and Engineering
bull Engineering isndash the application of scientific principles and methods to the
construction of useful structures or machines
bull Design is ndash the essence of any engineering disciplinendash the creative selection of appropriate principles and methods
to efficiently and effectively transform concept into reality
bull A large part of software development is really about design in various forms
5
>
SE Originsbull The idea and the label are over 40 years old
ndash First used at NATO Conference on Software Engineering Garmisch-Partenkirchen Germany 1968
bull Software Engineering deliberately chosen as provocative an aspirationndash Expressed a need rather than a realityldquo
bull Serious problems with software development needed to be solved scientifically and rigourouslyndash Ironically many of the same problems remain today
bull By the time of the conference the following year in Rome the label Software Engineering had stuck fast even if no one knew how to achieve the goals ndash still donrsquot really know
6
>
Present day reality
bull The reality is mixedndash Computer Science provides the scientific basisndash A growing number of software development approaches are
recognised as good engineering practicendash But many aspects of development are still ad hoc rather than
good scientific or engineering practice
bull Software design is still very difficultndash Few guiding scientific principlesndash Few universally applicable methodsndash Much poor practicendash Frequent failures
7
>
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
2
Key topics learning outcomes of this lecture
bull Software Engineering bull USDPbull Agile and Scrum
What is Software Engineering (SE)
Wikipedia saysbull the application of a systematic disciplined quantifiable approach to the development operation and maintenance of software
bull an engineering discipline that is concerned with all aspects of software productionldquo
bull the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines
3
>
Software Engineering
bull Ian Sommerville
ndash Software Engineering is concerned with method tools and techniques for developing and managing the process of creating and evolving software products
bull Oxford English Dictionary
ndash The professional development production and management of system software
4
>
Design and Engineering
bull Engineering isndash the application of scientific principles and methods to the
construction of useful structures or machines
bull Design is ndash the essence of any engineering disciplinendash the creative selection of appropriate principles and methods
to efficiently and effectively transform concept into reality
bull A large part of software development is really about design in various forms
5
>
SE Originsbull The idea and the label are over 40 years old
ndash First used at NATO Conference on Software Engineering Garmisch-Partenkirchen Germany 1968
bull Software Engineering deliberately chosen as provocative an aspirationndash Expressed a need rather than a realityldquo
bull Serious problems with software development needed to be solved scientifically and rigourouslyndash Ironically many of the same problems remain today
bull By the time of the conference the following year in Rome the label Software Engineering had stuck fast even if no one knew how to achieve the goals ndash still donrsquot really know
6
>
Present day reality
bull The reality is mixedndash Computer Science provides the scientific basisndash A growing number of software development approaches are
recognised as good engineering practicendash But many aspects of development are still ad hoc rather than
good scientific or engineering practice
bull Software design is still very difficultndash Few guiding scientific principlesndash Few universally applicable methodsndash Much poor practicendash Frequent failures
7
>
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
What is Software Engineering (SE)
Wikipedia saysbull the application of a systematic disciplined quantifiable approach to the development operation and maintenance of software
bull an engineering discipline that is concerned with all aspects of software productionldquo
bull the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines
3
>
Software Engineering
bull Ian Sommerville
ndash Software Engineering is concerned with method tools and techniques for developing and managing the process of creating and evolving software products
bull Oxford English Dictionary
ndash The professional development production and management of system software
4
>
Design and Engineering
bull Engineering isndash the application of scientific principles and methods to the
construction of useful structures or machines
bull Design is ndash the essence of any engineering disciplinendash the creative selection of appropriate principles and methods
to efficiently and effectively transform concept into reality
bull A large part of software development is really about design in various forms
5
>
SE Originsbull The idea and the label are over 40 years old
ndash First used at NATO Conference on Software Engineering Garmisch-Partenkirchen Germany 1968
bull Software Engineering deliberately chosen as provocative an aspirationndash Expressed a need rather than a realityldquo
bull Serious problems with software development needed to be solved scientifically and rigourouslyndash Ironically many of the same problems remain today
bull By the time of the conference the following year in Rome the label Software Engineering had stuck fast even if no one knew how to achieve the goals ndash still donrsquot really know
6
>
Present day reality
bull The reality is mixedndash Computer Science provides the scientific basisndash A growing number of software development approaches are
recognised as good engineering practicendash But many aspects of development are still ad hoc rather than
good scientific or engineering practice
bull Software design is still very difficultndash Few guiding scientific principlesndash Few universally applicable methodsndash Much poor practicendash Frequent failures
7
>
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Software Engineering
bull Ian Sommerville
ndash Software Engineering is concerned with method tools and techniques for developing and managing the process of creating and evolving software products
bull Oxford English Dictionary
ndash The professional development production and management of system software
4
>
Design and Engineering
bull Engineering isndash the application of scientific principles and methods to the
construction of useful structures or machines
bull Design is ndash the essence of any engineering disciplinendash the creative selection of appropriate principles and methods
to efficiently and effectively transform concept into reality
bull A large part of software development is really about design in various forms
5
>
SE Originsbull The idea and the label are over 40 years old
ndash First used at NATO Conference on Software Engineering Garmisch-Partenkirchen Germany 1968
bull Software Engineering deliberately chosen as provocative an aspirationndash Expressed a need rather than a realityldquo
bull Serious problems with software development needed to be solved scientifically and rigourouslyndash Ironically many of the same problems remain today
bull By the time of the conference the following year in Rome the label Software Engineering had stuck fast even if no one knew how to achieve the goals ndash still donrsquot really know
6
>
Present day reality
bull The reality is mixedndash Computer Science provides the scientific basisndash A growing number of software development approaches are
recognised as good engineering practicendash But many aspects of development are still ad hoc rather than
good scientific or engineering practice
bull Software design is still very difficultndash Few guiding scientific principlesndash Few universally applicable methodsndash Much poor practicendash Frequent failures
7
>
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Design and Engineering
bull Engineering isndash the application of scientific principles and methods to the
construction of useful structures or machines
bull Design is ndash the essence of any engineering disciplinendash the creative selection of appropriate principles and methods
to efficiently and effectively transform concept into reality
bull A large part of software development is really about design in various forms
5
>
SE Originsbull The idea and the label are over 40 years old
ndash First used at NATO Conference on Software Engineering Garmisch-Partenkirchen Germany 1968
bull Software Engineering deliberately chosen as provocative an aspirationndash Expressed a need rather than a realityldquo
bull Serious problems with software development needed to be solved scientifically and rigourouslyndash Ironically many of the same problems remain today
bull By the time of the conference the following year in Rome the label Software Engineering had stuck fast even if no one knew how to achieve the goals ndash still donrsquot really know
6
>
Present day reality
bull The reality is mixedndash Computer Science provides the scientific basisndash A growing number of software development approaches are
recognised as good engineering practicendash But many aspects of development are still ad hoc rather than
good scientific or engineering practice
bull Software design is still very difficultndash Few guiding scientific principlesndash Few universally applicable methodsndash Much poor practicendash Frequent failures
7
>
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
SE Originsbull The idea and the label are over 40 years old
ndash First used at NATO Conference on Software Engineering Garmisch-Partenkirchen Germany 1968
bull Software Engineering deliberately chosen as provocative an aspirationndash Expressed a need rather than a realityldquo
bull Serious problems with software development needed to be solved scientifically and rigourouslyndash Ironically many of the same problems remain today
bull By the time of the conference the following year in Rome the label Software Engineering had stuck fast even if no one knew how to achieve the goals ndash still donrsquot really know
6
>
Present day reality
bull The reality is mixedndash Computer Science provides the scientific basisndash A growing number of software development approaches are
recognised as good engineering practicendash But many aspects of development are still ad hoc rather than
good scientific or engineering practice
bull Software design is still very difficultndash Few guiding scientific principlesndash Few universally applicable methodsndash Much poor practicendash Frequent failures
7
>
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Present day reality
bull The reality is mixedndash Computer Science provides the scientific basisndash A growing number of software development approaches are
recognised as good engineering practicendash But many aspects of development are still ad hoc rather than
good scientific or engineering practice
bull Software design is still very difficultndash Few guiding scientific principlesndash Few universally applicable methodsndash Much poor practicendash Frequent failures
7
>
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Key Issuesbull Software Engineering principles are particularly relevant to construction
of large systemsndash Involving large numbers of people to manage
bull Mastering complexityndash Abstraction information hiding separation of concerns
bull Continual evolutionndash For improved reliability fixing errors incorporation of new features
improving other desirable qualitiesbull Efficiency of development
ndash Human-centred tasks are extremely costlybull Cooperation of people
ndash Cannot develop a system in isolated piecesbull Usability
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
ndash can evolve to meeting changes in requirementsbull Dependable
ndash Robust reliable trustworthybull Efficient
ndash Good use of resources computational user time development timecost
bull Usablendash Usable by the users (or systems) it is designed to interact with
9
>
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scale
bull Scaling-up does not work reliablyndash too much detail for any one person to deal withndash communication overheadndash effect of changes not obviousndash need for discipline documentation and
management
10
NoteIt is very important that you keep the problems of scale and complexity firmly in mind throughout the course
>
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Failure
bull Numerous examples of failed or seriously delayed software development projectsndash Or fail to deliver full functionality within time and
budgetndash Eg Pensions system NHS patient records Taurus
(Stock Exchange) Air Traffic Controlndash Disasters ESA Arianne 5 Patriot Missile System
Therac-25 radiation therapy machinendash Just about every UK government software
development project11
>
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
12
>
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
By 1995
13
>
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The Chaos Report 2009
14
>
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The Solution
bull Dont know yetndash Many unresolved issuesndash Much active research (eg SSE group in CS department)
bull But building blocks arendash Educationndash Professionalismndash Standards Quality Assurancendash Defining sound methodologies and practicendash Application of scientific techniquesndash Communicationndash Self evaluation
15
>
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The Software Development Process
bull Structured set of activities required to develop a software system includingndash Requirements Gatheringndash Analysisndash Designndash Implementationndash Testingndash Deploymentndash Maintenance
bull Activities vary depending on organization and type of system being developed
bull Must be modelled in order to be managed16
>
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Requirements Gathering
bull Aim a complete description of the problem and of the constraints imposed byon the environment
bull Description may containndash Functions of the systemndash Future extensionsndash Amount of documentation requiredndash Response time and performancendash Acceptance criteria
bull Result Requirements Specification
17
>
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Analysis
bull Aim Analyse requirements to create a conceptual model of the software systemndash Data modellingndash Functional modelling and informationcontrol flowndash Behavioural modelling and statendash User interface modelling
bull Result A set of Analysis Models
18
What is a model A systematic conceptual description of a system or aspect of a system defining its structure and behaviour Abstraction and simplification are used to constrain the complexity while retaining the essential information
>
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Design
bull Aim an implementable model of the software systemndash Sufficient information to allow system to be built
bull Architecture is definedndash The definition of the global architecture of the system is essential
bull System is decomposed to components within the architecturendash Definition of component interfaces and functionalities
bull Design decisions dramatically impact system qualityndash Wrong architecturedesign == throw it away
bull You canrsquot build a tower block on the foundations for a bungalow
bull Result Detailed Design Documentation
19
>
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Implementation
bull Aim implementation of all design elementsbull Starts from the component specifications
developed during designndash Interfaces defined in the design should be respected
by the implementation of the componentbull Code should be well documented and easy to
read flexible correct reliable AND fully testedbull Result working software
20
>
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Testing
bull Kinds of testingndash Unit testing Classesmethodsndash Functional testing Component implementations against their
interfacesndash Integration testing Component integration against system
architecturendash System testing validation of the extent to which the
requirements specification is fulfilledndash Acceptance testing validation of external behaviour against
user expectationsndash Testing and implementation should run in parallel
bull Result Fully tested software21
>
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Deployment
bull Package software ready to install on a computer system
bull Actually installing the softwarebull Live testing in real environmentbull Documentation and manualsbull Trainingbull Result Working software in situ
22
>
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Maintenancebull Aim keeping the system operational after delivery to the customer
ndash Corrective identification and removal of faultsndash Adaptive modifications needed to achieve interoperability with
other systems and platformsndash Perfective incorporation of new features improved
performance and other modifications to increase customer satisfaction
ndash Preventive modifications to mitigate possible degradation of usability maintainability etc
bull The maintenance phase needs to be considered part of the overall development process
ndash Even though the activities within maintenance are requirements analysis design implementation and testing
ndash Maintenance is ongoing and expensive
23
>
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Process Modelbull A development process is described in a process model
ndash There are many ways of organising developmentndash There are many process models described in the literature
bull You need to model the process becausendash when a team writes down a description of its development process it
forms a common understanding of the activities resources and constraints involved in software development
ndash creating a process model helps the team find inconsistencies redundancies and omissions in the process as these problems are noted and corrected the process becomes more effective
24
>
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Process Model (cont)bull You need to model the process because (cont)
ndash the model reflects the goals of development and shows explicitly how the product characteristics are to be achieved
ndash each development is different and a process has to be tailored for different situations and so the model helps people to understand these differences
25
>
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Common Software Lifecycle Models
bull Waterfall Developmentndash Separate and distinct phases of specification and development
bull Prototypingndash Interleaved specification and development
bull Incremental Developmentndash Development of a system in increments
bull Agile Developmentndash Continual availability of a fully tested functioning system developed with
minimal organisational overhead
bull Ad Hoc
26
>
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The Waterfallbull Winston Royce defined the seven-step Waterfall Model in 1970
ndash (see ldquoManaging the development of large software systemsrdquo proceedings of IEEE Wescon)
bull Widely referenced as the ldquodefault process modelrdquobull Each step is distinctly different needing to be planned and resourced
differently
27
>
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
But
bull Not all is what is seemsbull Royce actually introduced the Waterfall as a
lsquostrawmanrsquo that he argued was flawed bull Constrained iteration is needed to make the
process work
28
>
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The problem in practice
bull The risk is that iteration is not confined to successive steps
bull Flaws are not discovered until after significant work has been done which then has to be revised or throw away
29
>
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Spiral Model (Boehm 1988)
30
>
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Spiral
bull Successive repetitions of the same activitiesbull Emphasis on prototyping well before
operational software builtbull Accommodates successive discovery of
requirements bull A better reflection of what designers dobull Accepted as an industry standard model
ndash Like the waterfall (ironically)
31
>
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
V Model
32
Relates each phase of the development cycle to an associated testing phaseEmphasises different kinds of testing required for each phase
From Wikipedia
>
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Iterative Model
33
From Wikipedia
In practice many developers take an iterative approach often informal without a defined processSelect a requirement analysedesignimplementtest repeatHas advantage of getting a basic version working early and thendeveloping it step-by-step from one working version to the next
>
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Incremental Model
34
analysis design code test
deliver 1stincrement
analysis design code test
deliver 2ndincrement
analysis design code test
conception
architecture
feedback
feedback
structure
Essentially an iterative approach but organised to allow increments to be developed in parallelAllows multiple teams to develop same system providing application structure can be broken down into relatively independent componentsmodules Needs a well defined architecture and interfaces between parts
>
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Exploratory Model
35
develop outlinespecification
build softwaresystem
use softwaresystem
test adequacy
deliver
yes
no
Incrementally build a system using testuser feedback to guide developmentFind and refine the real requirements by building versions and getting realusers to use them
>
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Prototyping Model
36
establish outlinespecification
developprototype
evaluateprototype
specifysystem
design andimplement system
validate system
components
Construct a prototype to determine how to specify and build the real systemThe prototype implementation should not be used as the real systemBuild the system once to find out what it should really be throw it away andbuild a second system using the knowledge gained
>
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Agile Development
37
From Wikipedia
A rethink of process and values to address the problems encountered in software developmentLightweight highly iterative short iterations test-driven focus on value to customer frequent releases ability to cope with change
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
No Model
38
Muddle through and hope for the best
>
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Unified Software Development Process(USDP or just UP) Jacobsen 1999
bull UP is the development process associated with the Unified Modeling Language (UML)ndash It is use-case driven and risk-confrontingndash It is architecture-centricndash It is iterative and incremental ndash It is free
bull UP is based on an incremental modelbull Each iteration delivers a part of the systembull Provides a structural framework for a software
development project39
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Overall Structure of the UP Lifecycle
40
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
UP Lifecycle Phases and Milestones
41
time
Inception Elaboration Construction Transition
bull Inception Define scope of project and develop business casebull Elaboration Plan project specify features and baseline architecturebull Construction Build productbull Transition Transition product to its users
Life-cycleobjectives
Life-cycle architecture
Initial operationalcapability
Product Release
Adapted from [Booch 1999]
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
UP Milestone Acceptance Criteriabull Lifecycle objectives system scope key requirements outline
architecture risk assessment business case feasibility agreed project objectives with stakeholders
bull Lifecycle architecture executable architectural baseline updated risk assessment project plan to support bidding process business case verified against plan continued stakeholder agreement
bull Initial operational capability product ready for beta test in user environment
bull Product release completed beta and acceptance tests defects fixed with fixes in the user community
42
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
UP Iterations
43
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis amp Design
Preliminary Iteration(s)
Iter1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter2
Itern
Itern+1
Itern+2
Iterm
Iterm+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Adapted from [Jacobson 1999]an iteration in the elaboration phase
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
An iteration is a sequence of activitieswith an established plan and evaluation
criteria resulting in an executable release
Adapted from [Booch 1999]
Iteration is key to UPEach iteration is like a mini-projectResults in an increment
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Iteration Workflows
45
Requirements Analysis DesignImplemen-
tationTesting
UP specifies 5 core workflows
An iterationPlanning
Assessment
SpecificActivities
Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Iterations may overlap
46
Iteration 1
Iteration 2
Iteration 3
In order to allow parallel development and flexible working in large teams iterations can and often do overlapIn the example above Iteration 1 overlaps significantly with iteration 2 This requires
carefulplanning
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
UP Increments
bull Each iteration results in the release of various artefacts which together are called a baseline
bull Baselines assist with review and approvals procedures
bull An increment is actually the difference between two successive baselines
47
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Inception
48
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary
Iterations
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Inception - Goals
bull Establish feasibility of the project bull Create a business casebull Capture key requirementsbull Scope the systembull Identify critical risksbull Create proof of concept prototypebull Decide whether project is feasible and should
proceed further
49
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Inception - Focus
bull Requirements ndash establish business case scope and core requirements
bull Analysis ndash establish feasibilitybull Design ndash design proof of concept or technical
prototypesbull Implementation ndash build the proof of concept
prototypebull Test ndash not generally applicable
ndash But do want feedback from stakeholders50
NB The bars indicate approximately the relative amount of resource needed
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Life Cycle Objectives
bull Conditions of satisfactionndash System scope has been definedndash Key requirements for the system have been captured
These have been defined and agreed with the stakeholders
ndash An architectural vision exists This is just a sketch at this stage
ndash A Risk Assessmentndash A Business Casendash Project feasibility is confirmedndash The stakeholders agree on the objectives of the project
51
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Elaboration
52
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Elaboration - Goals
bull Establish an executable architectural baselinebull Refine Risk Assessmentbull Define quality attributes (defect rates etc)bull Capture use-cases around 80 of the functional
requirementsbull Create a detailed plan for the construction
phasebull Formulate a bid which includes resources time
equipment staff and cost53
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Elaboration - Focus
bull Requirements ndash refine system scope and requirements
bull Analysis ndash establish what to build
bull Design ndash create a stable architecture
bull Implementation ndash build the architectural baseline
bull Test ndash test the architectural baseline54
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Life Cycle Objectives
bull Conditions of satisfactionndash A resilient robust executable architectural
baseline has been createdndash The Risk Assessment has been updatedndash A project plan has been created to enable a
realistic bid to be formulatedndash The business case has been verified against the
planndash The stakeholders agree to continue
55
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Construction
56
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Construction - Goals
bull Completing use-case identification description and realisation
bull Finish analysis design implementation and testing
bull Maintain the integrity of the system architecture
bull Revise the Risk Assessment
57
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Construction - Focus
bull Requirements ndash uncover any requirements that had been missed
bull Analysis ndash finish the analysis modelbull Design ndash finish the design modelbull Implementation ndash build the Initial
Operational Capabilitybull Test ndash test the Initial Operational Capability
58
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Life Cycle Objectives
bull Conditions of satisfactionndash The product is ready for beta testing in the user
environment
59
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Transition
60
Requirements
Analysis
Design
Implementation
Test
InceptionElaboration Construction Transition
I1 I2 In In+1 In+2 Im Im+1Preliminary Iterations
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Transition - Goals
bull Correct defectsbull Prepare the users site for the new softwarebull Tailor the software to operate at the users sitebull Modify software if unforeseen problems arisebull Create user manuals and other documentationbull Provide customer consultancybull Trainingbull Conduct post project review
61
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Transition - Focus
bull Requirements ndash not applicablebull Analysis ndash not applicablebull Design ndash modify the design if problems emerge
in beta testingbull Implementation ndash tailor the software for the
users site and correct problems uncovered in beta testing
bull Test ndash beta testing and acceptance testing at the users site
62
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Agile Methods
bull Over the past decade there has been much focus on how to improve the development process
bull Agile Methods have emerged as a widely used approachndash Focus on short iterations teamwork collaboration and process
adaptability throughout the life-cycle of the projectndash Minimal planning and overheads (eg short stand-up meetings)
bull Relies on skilled professional approachbull Minimal = low standards or sloppy work
ndash Code-centred approachbull Code embodies the design
ndash Very strong focus on delivering value
63
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Key factors
bullldquoResearch also indicates that smaller timeframes with delivery of software components early and often will increase the success rate Shorter time frames result in an iterative process rdquobullldquothe approach of full requirements definition followed by a long gap before those requirements are delivered is no longer appropriate The high ranking of changing business requirements suggests that any assumption that there will be little significant change to requirements once they have been documented is fundamentally flawed and that spending significant time and effort defining them to the maximum level is inappropriaterdquo
64
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The cost of defects
65
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Extreme Programming (Beck 1999)bull A disciplined iterative agile approach to software systems
developmentbull Some key XP practices
ndash Test-driven developmentndash The tests are the system specificationndash Releases are as small and frequent as possiblendash Pair programmingndash Collective code ownershipndash Coding standardsndash Continuous integrationndash Frequent refactoring of codendash Onsite customer is a member of the development teamndash 40-hour work week
66
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
When to use XP
bull XP works best whenndash Requirements are changing rapidlyndash Projects are high-risk with new challengesndash Development can be carried out by small groups
(2-10 developers)ndash Automated testing is possiblendash Direct customer involvement is possible
67
Remember that the process must be matched to the problem
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scrum
bull A widely used iterativeincremental method used with agile development
bull The following slides describing Scrum were created by Mike Cohn of Mountain Goat Softwarendash Creative Commons License
bull Widely used by the Open Source movement
68
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
bull Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time
bull It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
bull The business sets the priorities Teams self-organize to determine the best way to deliver the highest priority features
bull Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint
Scrum in 100 words
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scrum originsbull Jeff Sutherland
ndash Initial scrums at Easel Corp in 1993ndash IDX and 500+ people doing Scrum
bull Ken Schwaberndash ADMndash Scrum presented at OOPSLA 96 with Sutherlandndash Author of three books on Scrum
bull Mike Beedlendash Scrum patterns in PLOPD4
bull Ken Schwaber and Mike Cohnndash Co-founded Scrum Alliance in 2002 initially
within the Agile Alliance
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scrum has been used bybullMicrosoftbullYahoobullGooglebullElectronic ArtsbullIBMbullLockheed MartinbullPhilipsbullSiemensbullNokiabullCapital OnebullBBCbullIntuit
bullNielsen MediabullFirst American Real EstatebullBMC SoftwarebullIpswitchbullJohn DeerebullLexis NexisbullSabrebullSalesforcecombullTime WarnerbullTurner BroadcastingbullOce
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scrum has been used forbull Commercial softwarebull In-house developmentbull Contract developmentbull Fixed-price projectsbull Financial applicationsbull ISO 9001-certified
applicationsbull Embedded systemsbull 24x7 systems with
99999 uptime requirements
bull the Joint Strike Fighter
bull Video game developmentbull FDA-approved life-critical
systemsbull Satellite-control softwarebull Websitesbull Handheld softwarebull Mobile phonesbull Network switching
applicationsbull ISV applicationsbull Some of the largest
applications in use
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Characteristics
bull Self-organizing teamsbull Product progresses in a series of 2-4 week
ldquosprintsrdquobull Requirements are captured as items in a list of
ldquoproduct backlogrdquobull No specific engineering practices prescribedbull Uses generative rules to create an agile
environment for delivering projectsbull One of the ldquoagile processesrdquo
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The Agile Manifestondasha statement of values
Process and toolsProcess and toolsIndividuals and interactions
Individuals and interactions
over
Following a planFollowing a planResponding to change
Responding to change
over
Source wwwagilemanifestoorg
Comprehensive documentationComprehensive documentationWorking softwareWorking software over
Contract negotiationContract
negotiationCustomer
collaborationCustomer
collaborationover
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scrum
Cancel
Gift wrap
Return
Sprint2-4 weeks
Return
Sprint goal
Sprint backlog
Potentially shippableproduct increment
Productbacklog
CouponsGift wrap
Coupons
Cancel
24 hours
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Putting it all together
Image available at wwwmountaingoatsoftwarecomscrum
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Sprints
bull Scrum projects make progress in a series of ldquosprintsrdquondash Analogous to Extreme Programming iterations
bull Typical duration is 2ndash4 weeks or a calendar month at most
bull A constant duration leads to a better rhythmbull Product is designed coded and tested during
the sprint
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Sequential vs overlapping development
Source ldquoThe New New Product Development Gamerdquo by Takeuchi and Nonaka Harvard Business Review January 1986
Rather than doing all of one thing at a time Scrum teams do a
little of everything all the time
Requirements
Design Code Test
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
No changes during a sprintbull Plan sprint durations around how long you
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Product owner
bull Define the features of the productbull Decide on release date and contentbull Be responsible for the profitability of the
product (ROI)bull Prioritize features according to market value bull Adjust features and priority every iteration as
needed bull Accept or reject work results
The ScrumMaster
bull Represents management to the projectbull Responsible for enacting Scrum values and
practicesbull Removes impediments bull Ensure that the team is fully functional and
productivebull Enable close cooperation across all roles and
functionsbull Shield the team from external interferences
The team
bull Typically 5-9 peoplebull Cross-functional
ndash Programmers testers user experience designers etc
bull Members should be full-timebull May be exceptions (eg database administrator)
The team
bull Teams are self-organizingndash Ideally no titles but rarely a possibility
bull Membership should change only between sprints
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The ScrumMaster
bull Represents management to the projectbull Responsible for enacting Scrum values and
practicesbull Removes impediments bull Ensure that the team is fully functional and
productivebull Enable close cooperation across all roles and
functionsbull Shield the team from external interferences
The team
bull Typically 5-9 peoplebull Cross-functional
ndash Programmers testers user experience designers etc
bull Members should be full-timebull May be exceptions (eg database administrator)
The team
bull Teams are self-organizingndash Ideally no titles but rarely a possibility
bull Membership should change only between sprints
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The team
bull Typically 5-9 peoplebull Cross-functional
ndash Programmers testers user experience designers etc
bull Members should be full-timebull May be exceptions (eg database administrator)
The team
bull Teams are self-organizingndash Ideally no titles but rarely a possibility
bull Membership should change only between sprints
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The team
bull Teams are self-organizingndash Ideally no titles but rarely a possibility
bull Membership should change only between sprints
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Sprint planning meeting
Sprint prioritizationbullAnalyze and evaluate product backlog
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Sprint planningbull Team selects items from the product backlog they
can commit to completingbull Sprint backlog is created
ndash Tasks are identified and each is estimated (1-16 hours)ndash Collaboratively not done alone by the ScrumMaster
bull High-level design is considered
As a vacation planner I want to see photos of the hotels
As a vacation planner I want to see photos of the hotels
Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Everyone answers 3 questionsbull These are not status for the ScrumMaster
ndash They are commitments in front of peers
What did you do yesterdayWhat did you do yesterday11
What will you do todayWhat will you do today22
Is anything in your wayIs anything in your way33
The sprint review
bull Team presents what it accomplished during the sprint
bull Typically takes the form of a demo of new features or underlying architecture
bull Informalndash 2-hour prep time rulendash No slides
bull Whole team participatesbull Invite the world
Sprint retrospective
bull Periodically take a look at what is and is not working
bull Typically 15ndash30 minutesbull Done after every sprintbull Whole team participates
ndash ScrumMasterndash Product ownerndash Teamndash Possibly customers and others
Sprint retrospective
bull Periodically take a look at what is and is not working
bull Typically 15ndash30 minutesbull Done after every sprintbull Whole team participates
ndash ScrumMasterndash Product ownerndash Teamndash Possibly customers and others
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The sprint review
bull Team presents what it accomplished during the sprint
bull Typically takes the form of a demo of new features or underlying architecture
bull Informalndash 2-hour prep time rulendash No slides
bull Whole team participatesbull Invite the world
Sprint retrospective
bull Periodically take a look at what is and is not working
bull Typically 15ndash30 minutesbull Done after every sprintbull Whole team participates
ndash ScrumMasterndash Product ownerndash Teamndash Possibly customers and others
Sprint retrospective
bull Periodically take a look at what is and is not working
bull Typically 15ndash30 minutesbull Done after every sprintbull Whole team participates
ndash ScrumMasterndash Product ownerndash Teamndash Possibly customers and others
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Sprint retrospective
bull Periodically take a look at what is and is not working
bull Typically 15ndash30 minutesbull Done after every sprintbull Whole team participates
ndash ScrumMasterndash Product ownerndash Teamndash Possibly customers and others
Sprint retrospective
bull Periodically take a look at what is and is not working
bull Typically 15ndash30 minutesbull Done after every sprintbull Whole team participates
ndash ScrumMasterndash Product ownerndash Teamndash Possibly customers and others
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Sprint retrospective
bull Periodically take a look at what is and is not working
bull Typically 15ndash30 minutesbull Done after every sprintbull Whole team participates
ndash ScrumMasterndash Product ownerndash Teamndash Possibly customers and others
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Product backlog
bull The requirementsbull A list of all desired work on the projectbull Ideally expressed such that each item has
value to the users or customers of the product bull Prioritized by the product ownerbull Reprioritized at the start of each sprint
This is the product backlog
This is the product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest I want to cancel a reservation
5
As a guest I want to change the dates of a reservation
3
As a hotel employee I can run RevPAR reports (revenue-per-available-room)
8
Improve exception handling 8
30
50
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
The sprint goal
bull A short statement of what the work will be focused on during the sprint
Database Application
Financial services
Life SciencesSupport features necessary for population genetics studies
Support more technical indicators than company ABC with real-time streaming data
Make the application run on SQL Server in addition to Oracle
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Managing the sprint backlogbull Individuals sign up for work of their own choosing
ndash Work is never assigned
bull Estimated work remaining is updated daily
bull Any team member can add delete or change the sprint backlog
bull Work for the sprint emerges
bull If work is unclear define a sprint backlog item with a larger amount of time and break it down later
bull Update work remaining as more becomes known
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
A sprint backlog
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
Write the foo class
MonMon8
16
8
12
8
TuesTues4
12
16
8
WedWed ThurThur
4
11
8
4
FriFri
8
8
Add error logging
8
10
16
8
8
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
A sprint burndown chartH
ours
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Hou
rs
40
30
20
10
0Mon Tue Wed Thu Fri
TasksTasksCode the user interfaceCode the middle tier
Test the middle tier
Write online help
MonMon8
16
8
12
TuesTues WedWed ThurThur FriFri4
12
16
7
11
8
10
16 8
50
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scalability
bull Typical individual team is 7 plusmn 2 peoplendash Scalability comes from teams of teams
bull Factors in scalingndash Type of applicationndash Team sizendash Team dispersionndash Project duration
bull Scrum has been used on multiple 500+ person projects
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
Scrum of scrums of scrums
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
A Scrum reading listbull Agile and Iterative Development A Managerrsquos Guide by Craig
Larman
bull Agile Estimating and Planning by Mike Cohn
bull Agile Project Management with Scrum by Ken Schwaber
bull Agile Retrospectives by Esther Derby and Diana Larsen
bull Agile Software Development Ecosystems by Jim Highsmith
bull Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
bull Scrum and The Enterprise by Ken Schwaber
bull User Stories Applied for Agile Software Development by Mike Cohn
bull Lots of weekly articles at wwwscrumallianceorg
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
106
Essential work for next week
bull Please consult the OLE for details ofndash Essential readingsndash Seminarworkshop preparation workndash Recommended further readingsndash Any additional learning
Essential readings and preparation work must always be completed in time for the next session
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
Overall Structure of the UP Lifecycle
UP Lifecycle Phases and Milestones
UP Milestone Acceptance Criteria
UP Iterations
UP Phases and Iterations
Iteration Workflows
Iterations may overlap
UP Increments
Inception
Inception - Goals
Inception - Focus
Life Cycle Objectives
Elaboration
Elaboration - Goals
Elaboration - Focus
Life Cycle Objectives (2)
Construction
Construction - Goals
Construction - Focus
Life Cycle Objectives (3)
Transition
Transition - Goals
Transition - Focus
Agile Methods
Key factors
The cost of defects
Extreme Programming (Beck 1999)
When to use XP
Scrum
Slide 69
Scrum origins
Scrum has been used by
Scrum has been used for
Characteristics
The Agile Manifestondasha statement of values
Scrum (2)
Putting it all together
Sprints
Sequential vs overlapping development
No changes during a sprint
Scrum framework
Scrum framework (2)
Product owner
The ScrumMaster
The team
The team (2)
Scrum framework (3)
Slide 87
Sprint planning
The daily scrum
Everyone answers 3 questions
The sprint review
Sprint retrospective
Sprint retrospective (2)
Scrum framework (4)
Product backlog
A sample product backlog
The sprint goal
Managing the sprint backlog
A sprint backlog
A sprint burndown chart
Slide 101
Scalability
Scaling through the Scrum of scrums
Scrum of scrums of scrums
A Scrum reading list
Essential work for next week
Slide 107
End of presentation
copy Pearson College 2013
Slide 1
Key topics learning outcomes of this lecture
What is Software Engineering (SE)
Software Engineering
Design and Engineering
SE Origins
Present day reality
Key Issues
Properties of Good Software
Scale
Failure
Slide 12
By 1995
The Chaos Report 2009
The Solution
The Software Development Process
Requirements Gathering
Analysis
Design
Implementation
Testing
Deployment
Maintenance
Process Model
Process Model (cont)
Common Software Lifecycle Models
The Waterfall
But
The problem in practice
Spiral Model (Boehm 1988)
Spiral
V Model
Iterative Model
Incremental Model
Exploratory Model
Prototyping Model
Agile Development
No Model
Unified Software Development Process (USDP or just UP) Jacobsen
