selection of an appropriate project approach
TRANSCRIPT
![Page 1: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/1.jpg)
1 ©The McGraw-Hill Companies, 2005
Software Project Management4th Edition
Selection of an appropriate project
approach
Chapter 4
![Page 2: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/2.jpg)
2 ©The McGraw-Hill Companies, 2005
Selection of project approaches
• In-house development: most of these issues resolved by IS 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 built
![Page 3: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/3.jpg)
3 ©The McGraw-Hill Companies, 2005
General approach• Look at risks and uncertainties e.g.
– are requirement 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 environments?• Clients’ own requirements
– need to use a particular method
![Page 4: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/4.jpg)
4 ©The McGraw-Hill Companies, 2005
Choice of process models• ‘waterfall’ also known as ‘one-shot’,
‘once-through’• incremental delivery• evolutionary development
Also use of ‘agile methods’ e.g. extreme programming
![Page 5: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/5.jpg)
5 ©The McGraw-Hill Companies, 2005
Waterfall
The waterfall model
![Page 6: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/6.jpg)
6 ©The McGraw-Hill Companies, 2005
Waterfall• the ‘classical’ model• imposes structure on the project• every stage needs to be checked
and signed off• BUT
– limited scope for iteration
![Page 7: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/7.jpg)
7 ©The McGraw-Hill Companies, 2005
V-process model
Another way of looking at the waterfall model
![Page 8: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/8.jpg)
8 ©The McGraw-Hill Companies, 2005
Evolutionary delivery: prototyping
‘ 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 prototypeswhat is being prototyped?• human-computer interface• functionality
![Page 9: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/9.jpg)
9 ©The McGraw-Hill Companies, 2005
Reasons 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 the application goes live• prototype can be used for producing
expected results
![Page 10: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/10.jpg)
10 ©The McGraw-Hill Companies, 2005
Prototyping: some dangers
• 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
![Page 11: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/11.jpg)
11 ©The McGraw-Hill Companies, 2005
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
![Page 12: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/12.jpg)
12 ©The McGraw-Hill Companies, 2005
Incremental delivery
design build install evaluate
design build install evaluate
design build install evaluate
increment 1
increment 2
increment 3
first incremental delivery
second incremental delivery
third incremental delivery
deliveredsystem
![Page 13: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/13.jpg)
13 ©The McGraw-Hill Companies, 2005
The incremental process
Intentional incremental delivery
![Page 14: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/14.jpg)
14 ©The McGraw-Hill Companies, 2005
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 ‘gold-plating’:BUT there are some possible disadvantages
• loss of economy of scale• ‘software breakage’
![Page 15: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/15.jpg)
15 ©The McGraw-Hill Companies, 2005
The outline incremental plan
• 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
![Page 16: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/16.jpg)
16 ©The McGraw-Hill Companies, 2005
Which step first?• some steps will be pre-requisite
because of physical dependencies• others may be in any order• value to cost ratios may be used
– V/C where– V is a score 1-10 representing value to
customer– C is a score 0-10 representing value to
developers
![Page 17: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/17.jpg)
17 ©The McGraw-Hill Companies, 2005
V/C ratios: an examplestep value cost ratioprofit 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 payfor managers
9 0 inf 1st
![Page 18: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/18.jpg)
18 ©The McGraw-Hill Companies, 2005
‘Agile’ methodsstructured development methods have
some perceived advantages– produce large amounts of documentation
which can be 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. etc
The answer? ‘Agile’ methods?
![Page 19: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/19.jpg)
19 ©The McGraw-Hill Companies, 2005
Dynamic system development method
• UK-based consortium• arguably DSDM can be seen as
replacement for SSADM• DSDM is more a project
management approach than a development approach
• Can still use DFDs, LDSs etc!
![Page 20: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/20.jpg)
20 ©The McGraw-Hill Companies, 2005
Nine core DSDM principles
1. Active user involvement2. Teams empowered to make decisions3. Frequent delivery of products4. Fitness for business purpose5. Iterative and incremental delivery6. Changes are reversible7. Requirements base-lined at a high level8. Testing integrated with development9. Collaborative and co-operative
approach
![Page 21: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/21.jpg)
21 ©The McGraw-Hill Companies, 2005
DSDM framework
Figure 4.6 here
DSDM process model
![Page 22: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/22.jpg)
22 ©The McGraw-Hill Companies, 2005
DSDM: 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 - but probably won’t get!
![Page 23: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/23.jpg)
23 ©The McGraw-Hill Companies, 2005
Extreme programming• increments of one to three weeks
– customer can suggest improvement at any point• argued that distinction between design and
building of software are artificial• code to be developed to meet current needs
only• frequent re-factoring to keep code
structured
![Page 24: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/24.jpg)
24 ©The McGraw-Hill Companies, 2005
Extreme programming - contd
• 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 cases
![Page 25: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/25.jpg)
25 ©The McGraw-Hill Companies, 2005
Grady Booch’s concernBooch, 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?
![Page 26: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/26.jpg)
26 ©The McGraw-Hill Companies, 2005
Macro and micro processes
A macro process containing three iterative micro processes
![Page 27: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/27.jpg)
27 ©The McGraw-Hill Companies, 2005
‘rules of thumb’ about approach to be used
IF uncertainty is highTHEN use evolutionary approach
IF complexity is high but uncertainty is notTHEN use incremental approach
IF uncertainty and complexity both lowTHEN use one-shot
IF schedule is tightTHEN use evolutionary or incremental
![Page 28: Selection of an appropriate project approach](https://reader033.vdocuments.mx/reader033/viewer/2022061516/588282301a28ab24788b6b33/html5/thumbnails/28.jpg)
28 ©The McGraw-Hill Companies, 2005
Combinations of approach
yes yes no
yes yes yes
yes yes no
evolutionary
incremental
evolutionaryincrementalone-shot
one-shot
installation
cons
truc
tion
one-shot or incremental installation - any construction approach possible
evolutionary installation implies evolutionary construction