SDPM - Lecture 3 - Selecting an appropriate software development approach.pdf

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

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. 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


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


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


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


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


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


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


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


„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


Lifecycle Models

ONE-SHOT APPROACHES


One-shot: The waterfall model
Feasibility study

User Requirements

Analysis

System Design

Program Design

Coding

Testing

Operation


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


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


Lifecycle Models

INCREMENTAL APPROACHES


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

The incremental plan outline

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


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)


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


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


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


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


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


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)


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


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


Possible disadvantages of incremental
delivery
!   Loss of economy of scale
!  Some costs will be repeated
!   Software breakage
!  Later increments might change earlier increments

28


Lifecycle Models

EVOLUTIONARY APPROACHES


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?


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


•  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


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


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


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!

!"#$%&'$()*+',,$-$!"#".$/+)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&#3+4&)20$$ 36


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


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


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


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


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


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


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


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


Lifecycle Models

AGILE APPROACHES


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


Agile methods

Examples
•  Extreme Programming


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


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


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


Lifecycle Models

A FEW FINAL REMARKS


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


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


„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 !


Conclusions

55

SDPM - Lecture 3 - Selecting an appropriate software development approach.pdf

More Related Content

What's hot

Viewers also liked

Similar to SDPM - Lecture 3 - Selecting an appropriate software development approach.pdf

More from OpenLearningLab

Recently uploaded

SDPM - Lecture 3 - Selecting an appropriate software development approach.pdf