Lecture 7 & 8 - Selection of an Appropriate Approach

8/17/2019 Lecture 7 & 8 - Selection of an Appropriate Approach

1/31

Selection of an

appropriateapproachLecture 7 & 8


2/31

‘Step Wise’ - an overview0.Select project

1. Ientif!

project o"jectives

#. Ientif! project

infrastructure

3. Analyseproject

characteristics

$. Ientif! proucts

an activities

%. sti'ate e(ort

for activit!

8. )eview* pu"lici+e

plan

,. Ientif! activit!

riss

7. llocate

resources

/. ecute plan

10. Lower level

plannin

)eview

Lowerleveletail

2or each activit!


3/31

Outline of lecture

• Building versus buying software

• Taking account of the characteristics of the project

• Process models

• Waterfall

• Prototyping and iterative approaches

• Incremental delivery

• gile approaches


4/31

!election of project

approaches• This lecture concerned with choosing the right approach

to a particular project" variously called technical planning #

project analysis# methods engineering and methods

tailoring

• In$house" often the methods to be used dictated byorgani%ational standards

• !uppliers" need for tailoring as different customers have

different needs


5/31

Build or buy&

3utsource4In-house

evelop'ent4

5uil 5u!

either

Software project management (5e) - introduction © The McGraw-Hill Companies !"##


6/31

!ome advantages of off$the$shelf 'OT!(

software

• )heaper as supplier can spread development costs over

a large number of customers

• !oftware already e*ists

• )an be trialled by potential customer

• +o delay while software being developed

• Where there have been e*isting users# bugs are likely to

have been found and eradicated


7/31

!ome possible disadvantages of off$the$

shelf

• )ustomer will have same application as everyone else"no competitive advantage# but competitive advantagemay come from the way application is used

• )ustomer may need to change the way they work in

order to fit in with OT! application• )ustomer does not own the code and cannot change it

• ,anger of over$reliance on a single supplier


8/31

-eneral approach• .ook at risks and uncertainties e/g/

• are re0uirement well understood&• are technologies to be used well understood&

• .ook at the type of application being built e/g/

• information system& embedded system&

• criticality& differences between target and development

environments&

• )lients1 own re0uirements

• need to use a particular method


9/31

!tructure versus speed of

delivery!tructured approach

• lso called 2heavyweight1 approaches

• !tep$by$step methods where each step and intermediateproduct is carefully defined

• 3mphasis on getting 0uality right first time

• 3*ample" use of 45. and 4!,P

• 6uture vision" 5odel$,riven rchitecture '5,(/ 45.supplemented with Object )onstraint .anguage# press thebutton and application code generated from the 45.7O).model


10/31

!tructure versus speed of

delivery gile methods

• 3mphasis on speed of delivery rather thandocumentation

• 8, 8apid application development emphasi%ed use of

0uickly developed prototypes• 9, 9oint application development/ 8e0uirements are

identified and agreed in intensive workshops with users


11/31

Processes versus Process

5odels• !tarting from the inception stage"

• product undergoes a series of transformations through a

few identifiable stages

• 4ntil it is fully developed and released to the customer/

• This forms its life cycle or development process/• .ife cycle model 'also called a process model("

• graphical or te*tual representation of the life cycle/


12/31

)hoice of process models

• 2waterfall1 also known as 2one$shot1# 2once$through1

• incremental delivery

• evolutionary development

lso use of 2agile methods1 e/g/ e*treme programming


13/31

Waterfall


14/31

Waterfall

• the 2classical1 model

• imposes structure on the project

• every stage needs to be checked and signed off

• B4T

• limited scope for iteration• : model approach is an e*tension of waterfall where different

testing phases are identified which check the 0uality of

different development phases


15/31


16/31

3volutionary delivery" prototyping

5ain types• 2throw away1 prototypes

• evolutionary prototypes

what is being prototyped&

• human$computer interface• functionality


17/31

8easons for prototyping• learning by doing

• improved communication

• improved user involvement

• a feedback loop is established

• reduces the need for documentation

• reduces maintenance costs i/e/ changes after theapplication goes live

• prototype can be used for producing e*pected results


18/31

prototyping" some dangers

• users may misunderstand the role of the prototype

• lack of project control and standards possible

• additional e*pense of building prototype

• focus on user$friendly interface could be at e*pense ofmachine efficiency


19/31

other ways of categori%ing

prototyping• what is being learnt&

• organi%ational prototype

• hardware7software prototype '2e*perimental1(

• application prototype '2e*ploratory1(

• to what e*tent• mock$ups

• simulated interaction

• partial working models" vertical versus horizontal


20/31

! "

Incremental delivery

esin "uil install evaluate



incre'ent1

incre'ent#

incre'ent

first incremental delivery

second incremental delivery

third incremental delivery

delivered

system


21/31

The incremental process


22/31

Incremental approach" benefits• feedback from early stages used in developing latter

stages

• shorter development thresholds

• user gets some benefits earlier

• project may be put aside temporarily

• reduces 2gold$plating1

B4T there are some possible disadvantages

• ,evelopers may be less productive

• 2software breakage1


23/31

Overview of incremental plan• steps ideally ;< to =< 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


24/31

which step first&

• some steps will be pre$re0uisite because of physicaldependencies

• others may be in any order

• value to cost ratios may be used

• :7) where

• : is a score ;$;> representing value to customer

• ) is a score >$;> representing value to developers


25/31

:7) ratios" an e*ample

step value cost ratio

profit reports ? ; ? @nd

online database ; ? >/;; =thad hoc en0uiry = = ; Ath

purchasing plans ? A @/@= Brd

profit$ based payfor managers

? > inf ;st


26/31

-enesis of 2gile1 methods

!tructured development methods have severaldisadvantages

• produce large amounts of documentation which can largely

remain unread

• documentation has to be kept up to date

• division into specialist groups and need to follow procedures

stifles communication

• users can be e*cluded from decision process

• long lead times to deliver anything etc/ etc

The answer& 2gile1 methods&


27/31

gile 5ethods

• gile is an umbrella term that refers to a group of

development processes"

• )rystal technologies

• tern 'formerly ,!,5(

• 6eature$driven development• !crum

• 3*treme Programming 'CP(

• !imilar themes"

• !ome variations


28/31

Important Themes of gile

5ethods• Incremental approach"

• t a time# only one increment is planned# developed# and

then deployed at the customer site/

• gile model emphasi%es face$to$face communication

over written documents/• n agile project usually includes a customer

representative in the team/

• gile development projects usually deploy pair

programming/


29/31

3*treme programming

• increments of one to three weeks• code to be developed to meet current needs only

• fre0uent re$factoring to keep code structured

• developers work in pairs

• test cases and e*pected results devised before softwaredesign

• after testing of increment# test cases added to a

consolidated set of test cases


30/31

.imitations of e*treme programming

• 8eliance on availability of high 0uality developers

• ,ependence on personal knowledge D after development

knowledge of software may decay making future

development less easy

• 8ationale for decisions may be lost e/g/ which test casechecks a particular re0uirement

• 8euse of e*isting code less likely


31/31

2rules of thumb1 about approach to

be usedI6 uncertainty is high

TE3+ use evolutionary approach

I6 comple*ity is high but uncertainty is not

TE3+ use incremental approach

I6 uncertainty and comple*ity both low

TE3+ use one$shotI6 schedule is tight

TE3+ use evolutionary or incremental

Lecture 7 & 8 - Selection of an Appropriate Approach

Documents

Transcript of Lecture 7 & 8 - Selection of an Appropriate Approach