Chapter 4.

Selection of
an appropriate project
approach

1
‘Step Wise’ - an overview
0.Select
1. Identify project 2. Identify project
project objectives infrastructure

3. Analyse
project
characteristics
Review
4. Identify products
and activities

5. Estimate effort
Lower for activity activity
level For each
detail 6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan
2
Step 3 Analysis of project characteristics

 3.1 Distinguish the project as either objective

or product-based.
◦ Object v/s Product
◦ Is there more than one way of achieving
success?
◦ Mostly in earlier stage projects are objective and in later
stage it become product driven

3
Step 3 Analysis of project
characteristics

 3.2 Analyze other project characteristics

(including quality based ones)
◦ what is different about this project?
◦ Whether it is a information system or embedded system?
◦ What are the critical issues?
◦ Malfunctioning threatened human life?

4
Step 3 continued
 3.3 Identify high level project risks
◦ ‘what could go wrong?’
◦ ‘what can we do to stop it?’
 3.4 Take into account user requirements concerning
implementation
◦ For example customer want the product in java
 3.5 Select development methodology and life cycle
approach
◦ waterfall? Increments? Prototypes?
◦ Generally Company use the same method or SDLC as
they were using in past
◦ It also depends on project need.

5
Analyse project characteristics

 There is two way to develop a software:

◦ In-house
◦ Software houses
 Either it is in-house development or by
software houses it is required to review
methodologies and techniques for each
project
 This process of reviewing is known as
technical planning or project analysis
6
Steps of project analysis

 Identify project as either objective driven or product

driven
 Analyse other project characteristics
◦ Is a data-oriented or process-oriented
 Data oriented- Information systems
 Process oriented- embedded control system
◦ Will the software to be produce is a general tool or
application specific?
◦ Are there tool available for implementing the particular
type of application?
◦ Is the system to be critical?
◦ What is the nature of hardware and software
environment?

7
Steps of project analysis

 Identify high level project risk

◦ Some of the risks are:
 Product uncertainty
 Process uncertainty
 Resource uncertainty
◦ Take into account user requirement concerning
implementation.
◦ Select general life-cycle approach

8
Technical plan content list
 Output of project analysis is technical plan.
 It contains :
◦ Introduction and summary of constraints:
 Character of the system to be developed
 Risk and uncertainties
 User requirement concerning implementation
◦ Recommended approach
 Select methodology or process model
 Development methods
 Required s/w tools
 Target hardware/software environment

9
Technical plan content list
◦ Development needs
 Required development environment
 Required maintenance environment
 Required training
◦ Implementations
 Project products and activities
 Financial- this report will be used to produce costing

10
LIFE CYCLE MODELS

11
Waterfall

The waterfall model

12
Waterfall
 the ‘classical’ model
 every stage needs to be checked and signed off
 Ideal for:
◦ Where requirement are well defined
◦ Development methods are well understood

 BUT
◦ limited scope for iteration

13
V-process model

Another way of looking at the waterfall model

14
3. Spiral Model

15
Evolutionary delivery: prototyping
‘ An iterative process of creating quickly and inexpensively
live and working models to test out requirements and
assumptions’

Main types:
 ‘throw away’ prototypes
 evolutionary prototypes
What is being prototyped?
 human-computer interface
 functionality

16
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

17
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

18
INCREMENT DELIVERY
MODEL

19
 Incremental delivery
delivered
system

design build install evaluate

increment
first incremental delivery 1

design build install evaluate increment

2
second incremental delivery

increment
design build install evaluate
3

third incremental delivery

20
Increment Delivery Model(cont.)
 In this model we break the application down
into small components.
 These components are then implemented
and delivered in sequence.

21
 The incremental process

Incremental
delivery

22
Incremental approach:benefits

 feedback from early stages used in developing latter

stages
 user gets some benefits earlier
 Easy to control and manage
 project may be put aside temporarily

BUT there are some possible disadvantages

 loss of economy of scale
◦ More productivity at larger scale
 ‘software breakage’
23
The incremental delivery plan
 The nature and order of each increment to
be delivered to the user have to be planned.
 Elements of increment plan are:
◦ System objective
◦ Incremental plan
◦ Open technology plan

24
System objective

 Project planner ideally wants well defined

objective but as much freedom as possible
about how to be met.
 Objectives
◦ Function goal
 Objective
 Jobs the system is to do
 Computer/non-compute function to achieve them
◦ Quality Goal
 Reliability , response and security
25
Open technology plan
 If it is required to add new components
continually to the system the system should
be extendible, portable and maintainable
 So it require:
◦ A standard high level language
◦ A standard operating system
◦ Small modules
◦ A standard DBMS

26
The outline incremental plan
 Steps ideally 1% to 5% of the total project
 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

27
‘rules of thumb’ about approach to be
used
IF uncertainty is high
THEN use evolutionary approach

IF complexity is high but uncertainty is not

THEN use incremental approach
IF uncertainty and complexity both low
THEN use one-shot
IF schedule is tight
THEN use evolutionary or incremental
28
Combinations of approach
installation

one-shot incremental evolutionary

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 29