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

1 System‘s Development and Project Management - Prof. Dr. Thomas Bäck

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

3

1. Identify project objectives 0. Select Project 2. Identify project infrastructure

3. Analyze pr. characteristics

4. Identify products and activities

5. Estimate effort for activity

6. Identify activity risks

7. Allocate resources

8. Review / publicize plan 9. Execute plan

10. Lower level planning

For each activity

Review lower level detail


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

•  Improve development speed

•  Improve quality •  Improve project

tracking and control •  Minimize overhead •  Minimize risk

exposure •  Improve client

relationship

Wrong Lifecycle Model

•  Slow, repeated work •  Unnecessary work •  Frustration


Choice of process models

10

One-Shot

•  Whole application is implemented in one go

•  Also known as „waterfall“, „once-through“, etc.

Incremental

•  Application is implemented in steps

•  Each step delivers a subset of functionality

•  Functions in the subset are fully implemented, i.e., can be used by client

Evolutionary

•  System is implemented via a number of versions

•  Each version is „exercised“ by users

•  Suggestions for improvement are made

Agile

•  Many intermediary prototypes

•  Very frequent user interaction

•  No upfront specifications

•  Focus on coding

•  Small projects only

• Waterfall •  V-Model

One-Shot

•  Spiral •  Staged-

Delivery • RUP

Incremental

•  Prototyping •  SCRUM • DSDM

Evolutionary

•  Extreme Programming

Agile


„Rules of thumb“

•  Evolutionary Approach IF Uncertainty high

•  Incremental Approach IF Complexity

high AND Uncertainty low

•  One-shot Approach IF Complexity low AND Uncertainty

low

•  Evolutionary Approach or •  Incremental Approach IF Schedule tight


ONE-SHOT APPROACHES Lifecycle Models


One-shot: The waterfall model Feasibility study

User Requirements

System Design

Coding

Operation

Testing

Analysis

Program Design


One-shot: The waterfall model (cont‘d)

Pros

•  Imposes structure on complex projects

•  Every stage needs to be checked and signed off •  Eliminates midstream

changes •  Good when quality

requirements dominate cost and schedule requirements

Cons

•  Limited scope for flexibility/iterations

•  Full requirements specification at the beginning •  User specifications

•  No tangible product until the end


One-shot: The V-process model

Feasibility study

User requirements

System design

Program design Program testing

Code

System test

User acceptance

Review

Cor

rect

ions

Another way of looking at the waterfall model

Validation process


INCREMENTAL APPROACHES Lifecycle Models


Incremental delivery

17

increment 1

increment 2

increment 3

first incremental delivery

second incremental delivery

third incremental delivery

delivered system

design build install evaluate



Leiden Institute of Advanced Computer Science The incremental plan outline

Characteristics of Increments

•  Steps ideally 1% to 5% of the total project

•  Non-computer steps should be included

•  Ideal if a step takes one month or less: •  Not more than three

months •  Each step should deliver

some benefit to the user •  Some steps will be physically

dependent on others

!   Some steps will be pre-requisite because of physical dependencies

!   Others may be in any order !   Value to cost ratios may be used

!   Fraction V/C where •  V is a score 1-10 representing value to

customer (rated by customer) •  C is a score 0-10 representing cost for

developers (rated by developers)

!   Rather crude, but helpful and easy to do

Step Value Cost 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 managers 9 0 inf 1st


Incremental delivery

Pros

•  Feedback from earlier stages used in later ones

•  Shorter development thresholds (important when requirements are likely to change)

•  User gets some benefits earlier

•  Project may be put aside temporarily

•  Reduces „gold-plating“ (features requested but not used)

Cons

•  Loss of economy of scale (some costs will be repeated)

•  „Software breakage“ (later increments might change earlier increments)


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)

!   Early iterations are the cheapest !   Can incorporate other lifecycle models as iterations !   See Boehm’s

A spiral model of software development and enhancement

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


The spiral model (cont‘d)

Pros

•  As costs increase, risks decrease

•  At least as much management control as waterfall (checkpoints)

•  Early indications of insurmountable risks

Cons

•  Complicated •  Requires

conscentious, attentive management


Rational Unified Process

Microcycle

Macrocycle

•  Serial in the large •  Iterative in the small •  Delivering incremental releases over time •  Following proven best practices

Image Source: Wikimedia


RUP: Macrocycle

Inception Phase

• Business Case • Project Boundaries • Success Criteria • Risk Analysis • Resource Estimation • Working plan and milestones

• Executable prototype as proof-of-concept

• Decision about continuation of project, based on life-cycle project goals

Elaboration Phase

• Analysis of problem domain

• Baseline architecture • Project plan • Elimination of largest risks

• Global architecture decisions

• Prototype • Analysis of detailed system requirements, architecture, risk management as decision point for transfer to next phase

Construction Phase

• Iterative, incremental development of complete, executable product

• Remaining requirements and acceptance criteria

• Implementation • Testing • Check, whether system and users are fit for „going life“

Transition Phase

• Deployment at customer

• Add-ons, bug fixes, …

• Check, whether project goals have been achieved

• Evaluation of work; process improvements

Macrocycle


RUP: Iterations

Microcycle

Iteration:

•  Steps within a single phase

•  Results in release of a subset of total product

•  Runs through all work steps (with varying weights)

Image Source: Wikimedia


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


EVOLUTIONARY APPROACHES Lifecycle Models


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

Initial concept

Design and implement

initial prototpye

Refine prototype

until acceptable: Iterations

Complete and

release prototype

“An iterative process of creating quickly and inexpensively live and working models to test out requirements and assumptions’’ Sprague and McNurlin

•  Very useful when requirements are changing rapidly •  Or when customer is reluctant to commit to a set of

requirements •  Or when neither you or your customer understands the

application area well •  Or when developers are unsure of optimal architecture/

algorithm to use



32

• Throw-away • Evolutionary Types

• Human-computer interface • Functionality What?

• Organizational prototype • Hardware/software prototype („experimental“) • Application prototype („exploratory“)

What is being learnt?

• Mockups • Simulated Interaction • Partial working models: Vertical vs. horizontal

To what extent?



Pros

•  Learning by doing •  Improved communication •  Improved user involvement •  Feedback loop is

established •  Reduces the need for

documentation •  Reduces maintenance

costs •  Prototype can be used for

producing expected results

Cons

•  Users may misunderstand the role of the prototype

•  Lack of project control and standards possible

•  Additional expense for building prototype (throw-away)

•  Focus on user-friendly interface could be at expense of machine efficiency


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

34

Nine core principles

•  1. Active user involvement •  2. Teams empowered to make decisions •  3. Frequent delivery of products •  4. Fitness for business purpose •  5. Iterative and incremental delivery •  6. Changes are reversible •  7. Requirements base-lined at a high level •  8. Testing integrated with development •  9. Collaborative and co-operative stakeholder approach

feasibility

business study

functional model iteration

agree schedule

identify functional prototype

review prototype

create functional prototype

design/build iteration

identify design prototype

review design prototype

agree schedule

create design prototype

implementation

implement

train users

user approval and user guidelines

review business


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

Time-Boxing:

DSDM


SCRUM !   Also, an agile approach !   Based on “Sprints”

36

Rugby term: Close-knit, shoulder-to-shoulder formation

!"#$%&'$()*+',,$-$!"#".$/+)01$234$5167)7+28$()*+',,$9*3:)*8

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

>*)$:&'$%'21?$:&'$/+)01@2,:')$234$()*40+:$AB3')?$:&'$:&)''$+'3:)28$1'':73=$:C6',$2,$:&'$/6)73:$

6823373=$1'':73=?$:&'$D278C$/+)01$234$:&'$/6)73:$)'<7'B?$2,$B'88$2,$:&'$)'E07)'4$;2,7+$2):7>2+:,$

321'8C$:&'$()*40+:$F2+G8*=?$:&'$/6)73:$F2+G8*=$234$:&'$F0)34*B3$+&2):$HI37;')=?$!JJKL"

!""#$%&'%()*+,-+./0+12&#3+4&)20$$

!"#$%&'#(

M,$6*73:'4$:*$B7:&73$:&'$73:)*40+:7*3$:*$:&7,$:&',7,$2:$7:,$>7),:$62='?$/+)01$4'>73',$+'):273$)*8',$

682C73=$62):$B7:&73$:&'$6)*+',,"$D7,:73=07,&73=$;':B''3$67=,$234$+&7+G'3$7:$4'>73',$:&'$7347<74028,$

;'73=$N+*117::'4N$234$:&*,'$*38C$N73<*8<'4N"$%&7,$47<7,7*3$73:*$:B*$62):,$12)G,$:&'$7347<74028,$

47)'+:8C$62):7+762:73=$73$:&'$4'<'8*61'3:$*>$:&'$6)*40+:$234$:&'$6)*O'+:P,$,0++',,?$234$:&*,'$;'73=$

73:')',:'4$234$73<*8<'4$;0:$*38C$7347)'+:8C$2>>'+:'4$;C$:&'$6)*O'+:P,$,0++',,"

/:2))73=$:&'$:&'$:'21?$:&'$/+)01@2,:')$234$:&'$()*40+:$AB3')?$:&'$N67=,N$2)'$)',6*3,7;8'$*>$:&'$

6)*40+:$+)'2:7*3"$%&'$:'21$:C67+288C$+*3,7,:,$*>$.-K$6'*68'$B7:&$+)*,,->03+:7*328$,G788,$234$7,$73$

+&2)='$*>$4',7=3? $4'<'8*61'3:? $:',:73=$234$4'87<')C" $%&'$/+)01@2,:')$ 7, $,*1'B&2:$2$3'B$)*8'$

4'<'8*6'4"$Q7:&$2$:')1$4'87;')2:'8C$+&*,'3$:*$47,:73=07,&$&7,$)*8'$>)*1$:&2:$*>$2$3*)128$6)*O'+:$

1232=') $ :&' $/+)01@2,:') $ 7, $1*)' $ *> $ 2 $ >2+787:2:*) $ *) $ +*2+& $ :* $ :&' $ :'21 $2, $ :&' $ :'21$ 7, $ ,'8>-

*)=237R73="$S'$7,$'3,0)73=$:&2:$:&'$)08',$*>$/+)01$2)'$>*88*B'4?$)'1*<',$716'471'3:,$>)*1$:&'$

:'21$234$7,$73$+&2)='$*>$7168'1'3:73=$/+)01$B7:&73$:&'$*)=237R2:7*3P,$+08:0)'$H/+&B2;')?$!JJTL"$

%&'$()*40+:$AB3')$7,$:&'$<*7+'$*>$:&'$+0,:*1')$*3$,7:'?$,71782)8C$:*$U($H+*162)'$:*$82,:$,'+:7*3L"$

S'$B)7:',$:&'$V,')$/:*)7',$234$6)7*)7:7R',$:&'1$B7:&73$:&'$()*40+:$F2+G8*="

%&'$N+&7+G'3N $2)' $2+:73= $ 7347)'+:8C $40)73= $ :&' $682C? $ :&'C $2)'$+*3,7,:73= $*> $288 $ :&'$,:2G'&*84'),$

#.

Image Source: Stettina.org


!   Creating a backlog (product owner) !   Sprint phase

!   Create sprint backlog !   Work on spring backlog

•  Daily Scrum –  Brief meeting every day –  What have you done since the last meeting? –  What will you do between now and the next meeting? –  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

Sprint: Rugby term: Close-knit, shoulder-to-shoulder formation

SCRUM


SCRUM Product Owner

• Compiles all changes

• Prioritizes functionalities

• Voice of the customer

Product Backlog

• To-do-list • Constantly

reprioritized

Sprint Backlog

• Highest prioritized list for sprint

SCRUM team

• 5-9 people • Self-organized • Joint

responsibility • No fixed

project roles

SCRUM Master

• Coaches team • Removes

impediments • Constantly

works to 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

40

Main types: •  ‘Throw away’ prototypes •  Evolutionary prototypes What is being prototyped? •  Human-computer interface •  Functionality


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


AGILE APPROACHES Lifecycle Models


‘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,

Increments Evolutionary

Works with poorly understood requirements

Poor Excellent Fair to Excellent Excellent

Works with poorly understood architecture

Poor Excellent Fair to Excellent Poor to Fair

Produces highly reliable system Excellent Excellent Excellent Fair

Produces system with large growth envelope

Excellent Excellent Excellent Excellent

Manages risk Poor Excellent Fair Fair

Can be constrained by a predefined schedule

Fair Fair Fair Poor

Has low overhead Poor Fair Excellent Fair

Allows for midcourse corrections Poor Fair Fair Excellent

Provides customer with progress visibility

Poor Excellent Fair Excellent

Provides management with progress visibility

Fair Excellent Fair to Excellent Fair

Requires little manager or developer sophistication

Fair Poor Poor to Fair Poor


A FEW FINAL REMARKS Lifecycle Models


Construction vs Installation

!   One-shot or incremental installation – any construction approach possible

!   Evolutionary installation implies evolutionary construction

52

yes yes no

yes yes no

yes yes yes

one-shot incremental evolutionary

one-shot

incremental

evolutionary

installation

cons

truct

ion


Iterative process management

53

micro-process

Iterate asrequired

macro-processstop/check-point

micro-process

Iterate asrequired


micro-process

Iterate asrequired


Closely related to waterfall model


„Rules of thumb“

•  Evolutionary Approach IF Uncertainty high

•  Incremental Approach IF Complexity

high AND Uncertainty low

•  One-shot Approach IF Complexity low AND Uncertainty

low

•  Evolutionary Approach or •  Incremental Approach IF Schedule tight

Students, be aware of this in student projects !


Conclusions

55

sdpm - lecture 3 - selecting an appropriate software development approach.pdf

Education