Hierarchy of management that covers different levels of management
SDPM - Lecture 3 - Selecting an appropriate software development approach.pdf
1. Leiden Institute of Advanced Computer Science
Software development
Selecting an appropriate software
development approach
Prof. Dr. Thomas Bäck
System‘s Development and Project Management - Prof. Dr. Thomas Bäck 1
2. Leiden Institute of Advanced Computer Science Dates
Feb. 1 14:45 – 17:30 Introduction, Project Description
Feb. 2 13:45 – 16:30 STEP WISE Approach to Project Planning
Feb. 9 13:10 – 15:45 Selecting an Appropriate Software Dev.
Approach
Feb. 15 14:45 – 17:30 Activity Planning and Resource Allocation
Feb. 16 13:45 – 16:30 Software Effort Estimation
Feb. 22 14:45 – 17:30 Risk management, project escalation
Feb. 23 13:45 – 16:30 Project monitoring and control
Mar. 1 14:45 – 17:00 Exam
Mar. 2 13:45 – 16:30 Software Quality Assurance
Mar. 8 14:45 – 17:30 Managing People; Contract Management
Mar. 9 13:45 – 16:30 Various
Mar. 15 14:45 – 17:30 Trade Fair
2
3. Leiden Institute of Advanced Computer Science
3. Analyze project characteristics
1. Identify project objectives 0. Select Project 2. Identify project infrastructure
3. Analyze pr. characteristics
4. Identify products and activities
Review lower
level detail
5. Estimate effort for activity
For each activity
6. Identify activity risks
10. Lower level planning 7. Allocate resources
9. Execute plan 8. Review / publicize plan
3
4. Leiden Institute of Advanced Computer Science
Outcome
! Selection of most appropriate methodologies
& technologies
! Impacts on
! Training requirements for development staff
! Types of staff to be recruited
! Development environment (HW & SW)
! System maintenance arrangements
! E.g. SSADM (Structured Systems Analysis
and Design Methodology), UK standard.
4
5. Leiden Institute of Advanced Computer Science
Selection of software development
approaches
! In-house development: most of these issues
resolved by IT planning and standards
! Software houses: more applicable as different
customers have different needs
! Selection of approach governed by:
! Uncertainties of the project
! Properties of application to be buildt
5
6. Leiden Institute of Advanced Computer Science
Analyse project characteristics
! Data-oriented or process-oriented ?
! General tool or application specific software to be
developed ?
! Particular type for which specific tools have been
developed ?
! Concurrent processing ?
! Knowledge based ?
! Heavy use of computer graphics ?
! Safety critical ?
! Nature of HW/SW environment in which system will
operate ?
6
7. Leiden Institute of Advanced Computer Science
Technical plan (part of the project plan)
1. Introduction and summary constraints
• Character of the system to be developed
• Risks and uncertainties of project
• User requirements concerning implementation
2. Recommended approach
• Selected methodology / process model
• Development methods
• Required software tools
• Target HW/SW environment
3. Implementation
• Required development environment
• Required maintenance environment
• Required training
4. Implications
• Project products and activities
• Financial
7
8. Leiden Institute of Advanced Computer Science
General approach
! Look at risks and uncertainties, e.g.
! Are requirements well understood ?
! Are technologies to be used well understood ?
! Look at the type of application being built, e.g.
! Information system ? Embedded system ?
! Criticality ? Differences between target and
development environment ?
! Client‘s own requirements
! Need to use a particular model
8
9. Leiden Institute of Advanced Computer Science
SDLC Model: General approach
Right Lifecycle Model Wrong Lifecycle Model
• Improve • Slow, repeated work
development speed • Unnecessary work
• Improve quality • Frustration
• Improve project
tracking and control
• Minimize overhead
• Minimize risk
exposure
• Improve client
relationship
10. Leiden Institute of Advanced Computer Science
Choice of process models
One-Shot Incremental Evolutionary Agile
• Whole • Application is • System is • Many
application is implemented implemented intermediary
implemented in steps via a number prototypes
in one go • Each step of versions • Very frequent
• Also known as delivers a • Each version user
„waterfall“, subset of is „exercised“ interaction
„once- functionality by users • No upfront
through“, etc. • Functions in • Suggestions specifications
the subset are for • Focus on
fully improvement coding
implemented, are made • Small projects
i.e., can be only
used by client
• Waterfall • Spiral • Prototyping • Extreme
• V-Model • Staged- • SCRUM Programming
Delivery • DSDM
• RUP
One-Shot Incremental Evolutionary Agile
10
11. Leiden Institute of Advanced Computer Science
„Rules of thumb“
IF Uncertainty
high • Evolutionary Approach
IF Complexity
high AND • Incremental Approach
Uncertainty low
IF Complexity low
AND Uncertainty • One-shot Approach
low
• Evolutionary Approach or
IF Schedule tight
• Incremental Approach
12. Leiden Institute of Advanced Computer Science
Lifecycle Models
ONE-SHOT APPROACHES
13. Leiden Institute of Advanced Computer Science
One-shot: The waterfall model
Feasibility study
User Requirements
Analysis
System Design
Program Design
Coding
Testing
Operation
14. Leiden Institute of Advanced Computer Science
One-shot: The waterfall model (cont‘d)
Pros Cons
• Imposes structure on • Limited scope for
complex projects flexibility/iterations
• Every stage needs to be • Full requirements
checked and signed off specification at the
• Eliminates midstream beginning
changes • User specifications
• Good when quality • No tangible product until
requirements dominate the end
cost and schedule
requirements
15. Leiden Institute of Advanced Computer Science
One-shot: The V-process model
Validation process
Feasibility study Review
Corrections
User requirements User acceptance
System design System test
Program design Program testing
Another way of looking at Code
the waterfall model
16. Leiden Institute of Advanced Computer Science
Lifecycle Models
INCREMENTAL APPROACHES
17. Leiden Institute of Advanced Computer Science
Incremental delivery delivered
system
design build install evaluate increment
1
first incremental delivery
design build install evaluate increment
2
second incremental delivery
increment
design build install evaluate 3
third incremental delivery
17
18. The incremental plan outline
Leiden Institute of Advanced Computer Science
Characteristics of Increments
! Some steps will be pre-requisite
because of physical dependencies
• Steps ideally 1% to 5% of
the total project ! Others may be in any order
• Non-computer steps should
be included ! Value to cost ratios may be used
• Ideal if a step takes one ! Fraction V/C where
month or less:
• Not more than three • V is a score 1-10 representing value to
months customer (rated by customer)
• Each step should deliver • C is a score 0-10 representing cost for
some benefit to the user developers (rated by developers)
• Some steps will be physically ! Rather crude, but helpful and easy to
dependent on others
do
Step
Value
C ost
Ratio
Rank
Profit
reports
9
1
9
2nd
Online
database
1
9
0.11
5th
Ad
hoc
enquiry
5
5
1
4th
Purchasing
plans
9
4
2.25
3rd
Profit-‐based
pay
for
9
0
inf
1st
managers
19. Leiden Institute of Advanced Computer Science
Incremental delivery
Pros Cons
• Feedback from earlier • Loss of economy of scale
stages used in later ones (some costs will be
• Shorter development repeated)
thresholds (important • „Software breakage“ (later
when requirements are increments might change
likely to change) earlier increments)
• User gets some benefits
earlier
• Project may be put aside
temporarily
• Reduces „gold-
plating“ (features
requested but not used)
20. Leiden Institute of Advanced Computer Science
The spiral model Spiral Model
• Risk-oriented
lifecycle model
• Breaks project into
miniprojects
• Start on small
scale in the middle
• Explore risks
• Make plan to
handle risks
• Commit to
approach for next
iteration
• Terminates as a
waterfall-model
would
21. Leiden Institute of Advanced Computer Science
The spiral model (cont d)
Each Iteration:
• Determine objectives, alternatives,
constraints
• Identify and resolve risks
• Evaluate alternatives
• Develop deliverables, verify correctness
• Plan next iteration
• Commit to approach for next iteration
• Each stage of development considers a
greater level of detail
! Early iterations are the cheapest
! Can incorporate other lifecycle models as iterations
! See Boehm s
A spiral model of software development and enhancement
22. Leiden Institute of Advanced Computer Science
The spiral model (cont‘d)
Pros Cons
• As costs increase, • Complicated
risks decrease • Requires
• At least as much conscentious,
management control attentive
as waterfall management
(checkpoints)
• Early indications of
insurmountable risks
23. Leiden Institute of Advanced Computer Science
Rational Unified Process Macrocycle
Microcycle
Image Source: Wikimedia
• Serial in the large
• Iterative in the small
• Delivering incremental releases over time
• Following proven best practices
24. Leiden Institute of Advanced Computer Science
RUP: Macrocycle
Macrocycle
Inception Phase Elaboration Construction Transition Phase
Phase Phase
• Business Case • Analysis of problem • Iterative, incremental • Deployment at
• Project Boundaries domain development of customer
• Success Criteria • Baseline architecture complete, executable • Add-ons, bug fixes,
• Project plan product …
• Risk Analysis
• Elimination of largest • Remaining • Check, whether
• Resource Estimation
risks requirements and project goals have
• Working plan and acceptance criteria
• Global architecture been achieved
milestones
decisions • Implementation • Evaluation of work;
• Executable prototype • Testing process
as proof-of-concept • Prototype
• Check, whether system improvements
• Decision about • Analysis of detailed
system requirements, and users are fit for
continuation of
architecture, risk „going life“
project, based on life-
cycle project goals management as
decision point for
transfer to next phase
25. Leiden Institute of Advanced Computer Science
RUP: Iterations
Iteration:
• Steps within a
single phase
• Results in
release of a
Image Source: Wikimedia subset of total
product
Microcycle
• Runs through all
work steps (with
varying weights)
26. Leiden Institute of Advanced Computer Science
RUP: Roles & Activities
Activities:
• Responsibility of
a staff member
• Defined Inputs
and Outputs
• Can be split up
into single steps
• About 30 role models
• Can shift/change over time
• Single staff member can play different
roles
27. Leiden Institute of Advanced Computer Science
Benefits of incremental delivery
! Feedback from early stages used in developing later
stages
! Shorter development thresholds
! Important when requirements are likely to change
! User gets some benefits earlier
! May assist cash flow
! Project may be put aside temporarily
! More urgent jobs may emerge
! Reduces gold-plating i.e. features requested but
not used
27
28. Leiden Institute of Advanced Computer Science
Possible disadvantages of incremental
delivery
! Loss of economy of scale
! Some costs will be repeated
! Software breakage
! Later increments might change earlier increments
28
29. Leiden Institute of Advanced Computer Science
Lifecycle Models
EVOLUTIONARY APPROACHES
30. Leiden Institute of Advanced Computer Science
Motivation
Perceived disadvantages of structure methods
• Large amounts of documentation, largely
unread
• Documentation has to be kept up-to-date
• Division into specialist groups and need to
follow procedures stifles communication
• Users can be excluded from decision process
• Long lead times to deliver anything
The Answer: Evolutionary Methods?
31. Leiden Institute of Advanced Computer Science
Evolutionary prototyping
Refine
Design and Complete
prototype
Initial implement and
until
concept initial release
acceptable:
prototpye prototype
Iterations
An iterative process of creating quickly and • Very useful when requirements are changing rapidly
• Or when customer is reluctant to commit to a set of
inexpensively live and working models to requirements
test out requirements and assumptions • Or when neither you or your customer understands the
application area well
Sprague and McNurlin
• Or when developers are unsure of optimal architecture/
algorithm to use
32. Leiden Institute of Advanced Computer Science
Evolutionary prototyping
• Throw-away
Types • Evolutionary
• Human-computer interface
What? • Functionality
What is being • Organizational prototype
• Hardware/software prototype („experimental“)
learnt? • Application prototype („exploratory“)
• Mockups
To what extent? • Simulated Interaction
• Partial working models: Vertical vs. horizontal
32
33. Leiden Institute of Advanced Computer Science
Evolutionary prototyping
Pros Cons
• Learning by doing • Users may misunderstand
• Improved communication the role of the prototype
• Improved user involvement • Lack of project control and
• Feedback loop is standards possible
established • Additional expense for
• Reduces the need for building prototype (throw-
documentation away)
• Reduces maintenance • Focus on user-friendly
costs interface could be at
expense of machine
• Prototype can be used for efficiency
producing expected results
34. Leiden Institute of Advanced Computer Science
DSDM: Dynamic systems development method
! UK-based consortium
! Arguably DSDM can be seen as replacement for SSADM (Structured
Systems Analysis and Design Methodology)
! DSDM is more a project management approach than a development
approach
Nine core principles feasibility
business study
• 1. Active user involvement agree schedule implement
• 2. Teams empowered to make decisions create
functional model identify review implementation train
functional functional
• 3. Frequent delivery of products prototype
iteration
prototype
business users
user approval and user
• 4. Fitness for business purpose review prototype guidelines
• 5. Iterative and incremental delivery
• 6. Changes are reversible identify design
prototype
• 7. Requirements base-lined at a high level agree design/build
review
design
schedule iteration
• 8. Testing integrated with development prototype
create design prototype
• 9. Collaborative and co-operative stakeholder approach
34
35. Leiden Institute of Advanced Computer Science
DSDM Key indicators
• Visibility of functionality at user interface
• Clear identification of all classes of users
• Not too much complexity
• Not large applications - split into components
• Need for time constraints
• Flexible high-level requirements
Time-Boxing:
! Time-box fixed deadline by which something has to be delivered
! Typically two to six weeks
! MoSCoW priorities
! Must have - essential
! Should have - very important, but system could operate without
! Could have
! Want (won t have) - but probably won t get!
36. Leiden Institute of Advanced Computer Science
!"#$%&'$()*+',,$-$!"#".$/+)01$234$5167)7+28$()*+',,$9
SCRUM ! Also, an agile approach
!"#"$%&'()*%+,-%.*/0(0'+1%2(3'455%63,7(31
/+)01$&2,$373'$6)',+)7;'4$)*8',$234$6)2+:7+',$6)*<7473=$:&'$;2,7+$,':06"$%&*,'$2)'$:&'$4'>73'
! Based on Sprints
>*)$:&'$%'21?$:&'$/+)01@2,:')$234$()*40+:$AB3')?$:&'$:&)''$+'3:)28$1'':73=$:C6',$2,$:&'
6823373=$1'':73=?$:&'$D278C$/+)01$234$:&'$/6)73:$)'<7'B?$2,$B'88$2,$:&'$)'E07)'4$;2,7+$2
321'8C$:&'$()*40+:$F2+G8*=?$:&'$/6)73:$F2+G8*=$234$:&'$F0)34*B3$+&2):$HI37;')=?$!JJKL"
Rugby term: Close-knit, shoulder-to-shoulder formation
Image Source: Stettina.org
!""#$%&'%()*+,-+./0+12+4&)20$$ 36
37. Leiden Institute of Advanced Computer Science
SCRUM Sprint: Rugby term: Close-knit,
shoulder-to-shoulder formation
! Creating a backlog (product owner) • Daily Scrum
! Sprint phase – Brief meeting every day
! Create sprint backlog
– What have you done since the last meeting?
– What will you do between now and the next meeting?
! Work on spring backlog
– Is there anything preventing you from doing what you have
planned?
• Demonstration and Evaluation (Sprint finish)
– Functioning software is demonstrated to a larger group
– Basis for an evaluation meeting à start of next sprint
38. Leiden Institute of Advanced Computer Science
SCRUM
Product
Product Owner Sprint Backlog SCRUM team SCRUM Master
Backlog
• Compiles all • To-do-list • Highest • 5-9 people • Coaches team
changes • Constantly prioritized list • Self-organized • Removes
• Prioritizes reprioritized for sprint • Joint impediments
functionalities responsibility • Constantly
• Voice of the • No fixed works to
customer project roles provide best
possible
circumstances
for the team
• Runs brief
meeting with
team every
day
39. Leiden Institute of Advanced Computer Science
Grady Booch s concern
! Booch, an OO authority, is concerned that with
requirements driven projects:
Conceptual integrity sometimes suffers because this
is little motivation to deal with scalability, extensibility,
portability, or reusability beyond what any vague
requirement might imply
! Tendency towards a large number of discrete
functions with little common infrastructure?
39
40. Leiden Institute of Advanced Computer Science
Prototyping as evolutionary delivery
An iterative process of creating quickly and
inexpensively live and working models to test out
requirements and assumptions
-- Sprague and McNurlin
Main types:
• Throw away prototypes
• Evolutionary prototypes
What is being prototyped?
• Human-computer interface
• Functionality
40
41. Leiden Institute of Advanced Computer Science
Reasons for prototyping
! Learning by doing
! Useful where requirements are only partially known
! Improved communication
! Users reluctant to read massive documents
! When system is live you get a better feeling for it
! Improved user involvement
! User ideas and requests are quickly implemented
41
42. Leiden Institute of Advanced Computer Science
Reasons for prototyping (cont d)
! Feedback loop is established
! Ensures that the specification is correct
! Reduces the need for documentation
! Debatable?
! Reduces maintenance costs i.e. changes
after the application goes live
! Prototype can be used for producing
expected results
42
43. Leiden Institute of Advanced Computer Science
Dangers of prototyping
! Users may misunderstand the role of the
prototype
! Lack of project control and standards possible
! Additional expense of building prototype
! Focus on user-friendly interface could be at
expense of machine efficiency
43
44. Leiden Institute of Advanced Computer Science
Other ways of categorizing prototyping
! What is being learnt?
! Organizational prototype
! Hardware/software prototype ( experimental )
! Application prototype ( exploratory )
! To what extent?
! Mock-ups
! Simulated interaction
! Partial working models: vertical versus horizontal
44
45. Leiden Institute of Advanced Computer Science
Lifecycle Models
AGILE APPROACHES
46. Leiden Institute of Advanced Computer Science
Agile methods
! Structured development methods have some
perceived disadvantages
! Produce large amounts of documentation which is
largely unread
! Documentation has to be kept up to date
! Division into specialist groups and need to follow
procedures stifles communication
! Users can be excluded from decision process
! Long lead times to deliver anything, etc.
! The answer? Agile methods?
46
47. Leiden Institute of Advanced Computer Science
Agile methods
Examples
• Extreme Programming
48. Leiden Institute of Advanced Computer Science
Extreme programming
! Associated with Kent Beck - see Extreme
programming explained
! Developed originally on Chrysler C3 payroll
(Smalltalk) project
! Agile methods include
! Jim Highsmith s Adaptive Software Development
and
! Alistair Cocburn s Chrystal Lite
methods
48
49. Leiden Institute of Advanced Computer Science
Extreme programming
Characteristics
• Argues: Disctinction between design and building of software is
artificial
• Code to be developed to meet current needs only
• Frequent re-factoring to keep code structured
• Increments of one to three weeks
• Customer can suggest improvement at any point
• Developers work in pairs
• Test cases and expected results devised before software design
• After testing of increment, test cases added to a consolidated
set of test case
! Associated with Kent Beck - see Extreme programming explained
! Jim Highsmith s Adaptive Software Development and
! Alistair Cocburn s Chrystal Lite
50. Leiden Institute of Advanced Computer Science
Lifecycle Models Overview
Capability Pure Waterfall Spiral RUP, Evolutionary
Increments
Works with poorly understood Poor Excellent Fair to Excellent Excellent
requirements
Works with poorly understood Poor Excellent Fair to Excellent Poor to Fair
architecture
Produces highly reliable system Excellent Excellent Excellent Fair
Produces system with large Excellent Excellent Excellent Excellent
growth envelope
Manages risk Poor Excellent Fair Fair
Can be constrained by a Fair Fair Fair Poor
predefined schedule
Has low overhead Poor Fair Excellent Fair
Allows for midcourse corrections Poor Fair Fair Excellent
Provides customer with progress Poor Excellent Fair Excellent
visibility
Provides management with Fair Excellent Fair to Excellent Fair
progress visibility
Requires little manager or Fair Poor Poor to Fair Poor
developer sophistication
51. Leiden Institute of Advanced Computer Science
Lifecycle Models
A FEW FINAL REMARKS
52. Leiden Institute of Advanced Computer Science
Construction vs Installation
installation
one-shot incremental evolutionary
construction
one-shot yes yes no
incremental yes yes no
evolutionary yes yes yes
! One-shot or incremental installation – any construction
approach possible
! Evolutionary installation implies evolutionary construction
52
53. Leiden Institute of Advanced Computer Science
Iterative process management
Closely related macro-process
to waterfall model micro-
stop/check-
point
process
Iterate as
required
macro-process
stop/check-
micro- point
process
Iterate as
required
macro-process
stop/check-
micro- point
process
Iterate as
required
53
54. Leiden Institute of Advanced Computer Science
„Rules of thumb“
IF Uncertainty
high • Evolutionary Approach
IF Complexity
high AND • Incremental Approach
Uncertainty low
IF Complexity low
AND Uncertainty • One-shot Approach
low
• Evolutionary Approach or
IF Schedule tight
• Incremental Approach
Students, be aware of
this in student projects !