This document discusses different project approaches and methodologies. It describes various process models including waterfall, V-model, evolutionary delivery, incremental delivery, agile, DSDM, and extreme programming. It provides pros and cons of each approach. The document also discusses factors to consider when selecting a methodology, such as risk, technology used, and project deliverables. Macro and micro processes are defined, and rules of thumb for selecting between approaches based on uncertainty, complexity, and schedule are outlined.

1. CHAPTER 4
Selection of appropriate project approach

2. WHAT IS A PROJECT APPROACH?
 An approach is a method(s) used to run the project
from inception to completion.
 Often called Methodology.
 Why use project methodology?
 To determine how the project is going to run.
 To define properties of the product

3. WHAT METHODOLOGY TO USE?
 This is determined by the following factors
 Risk – clear requirements
 New technology – need to do skills transfer or research
project deliverables
 Application type
 How simple is the application being built
 Is it accessible in all platforms
In Software houses the client might be the one to determine.

4. TYPES OF PROCESS MODELS
 Waterfall ‘one-shot’ ,’once through’
 Pros –
 ‘classical’ this mean this is a traditional model, tried and tested
 Gives a project structure
 Cannot progress till each stage is completed and signed off
 Cons – once stage is signed off not iterations might be
done
 A V-process model is a kind of waterfall
 One side is verified against the other

5. TYPES OF PROCESS MODELS(CONT…)
 Evolutionary delivery : Prototyping – Quick , live models
to test requirements and assumptions
 Types
 ‘throw away’ – proof of concept
 ‘ evolutionary – extend functionality
 Reasons
 Reduce cost of maintenance
 Improve communication
 Learn by doing
 Dangers – user confusion in role of product
 Expense
 UI changes
 Categories – sensitizing uses of product
 With small toys, little functionality

6. TYPES OF PROCESS MODELS(CONT…)
 Incremental delivery – ‘eat a cow’
 Outline plan
 Steps – 1-5% of total, 1-3 months to produce benefit to
customer
 Include manual steps
 Step dependency
 Benefits
 Benefits earlier
 Project might be put aside without affecting other deliverables
 Reduces ‘gold plating’ – polishing product over and above
requirements
o Disadvantages –
o no economies of scale – cost of producing one product against mass
production
o Which step – pre-requisites, no preferred order, value to cost

7. TYPES OF PROCESS MODELS(CONT…)
 Agile – type of structure development methods
 Benefits can sometimes be seen as disadvantages
Large unreadable documentation
Updating documents time consuming
Communication points increase
No user involvement
No delivery due to long lead times
‘You want all these benefits then ‘Agile’ is your answer’

8. TYPES OF PROCESS MODELS(CONT…)
 Dynamic System Development Method – DSDM is
project management method
 Time-boxing – fixed schedule , fixed team. 2 -6
weeks
 MOSCOW priorities – have(s) Must, should, could,
want.
 Nine core DSDM principles

9. TYPES OF PROCESS MODELS(CONT…)
 Extreme programming – Agile Process
 Stress customer satisfaction - customer can change
solution at any point.
 Meet current needs only – deliver what is needed as it is
needed.
 Test cases before design – give feedback by testing
from inception and after each increment test cases are
consolidated.
 Team work is emphasized

10. MACRO AND MICRO PROCESSES
 Macro – break huge project into phases
 Micro – have repeating steps in each phase. E.g.
requirements gathering, testing, implementation then
move to another phase

11. RULE OF THUMB – WHICH APPROACH?
 If high uncertainty – evolutionary
 If high complexity and low uncertainty – incremental
 If low complexity and low uncertainty – waterfall
 If tight schedule – evolutionary or incremental
 Can use combination of approaches one for
installation and one for construction.

12. GRADY BOOCH’S CONCERN
 Is concerned with requirement driven projects in
that.
 Conceptual integrity suffers because requirements
might be vague and not give motivation to deal with
software quality.
 Scalability
 Extensibility
 Portability
 Or reusability