Software Project

Management Chapter 4
4th Edition

Selection of an
appropriate project
approach

A project approach=process
model.
e.g: waterfall.

1
©The McGraw-Hill Companies, 2005
 *Build or buy
• With in-house development ,developers and users are in
the same organization.
• If development is outsourced, they are in different
organizations.

• Software houses: more applicable as different customers

have different needs.
The relevant part
• Selection of approach governed by: of the stepwise is
step3: analysis
1. uncertainties of the project project
2. properties of application to be built characteristic.

2
©The McGraw-Hill Companies, 2005
• Software development can be:

- In house development .
- Out sourced development .

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 who own requirements

– need to use a particular method imposed by the
contractor who will develop the system
4
©The McGraw-Hill Companies, 2005
 Choosing Technologies and
methodologies:
• An output of project analysis ( step 3) will be the
selection of the most appropriate methodology
(like OO development) and technologies that
might include an appropriate application building
and testing environment. The choosing of
methods and technology will influence:
1- the training requirements for staff.
2- the type of staff to be recruited.
3- the development environment.
4- System maintenance arrangement.

©The McGraw-Hill Companies, 2005

 Some steps in project analysis
• Identify project as either objective driven or product driven.
• Analyses other project characteristic, the following questions can be usefully
asked:
is it data oriented (info. System) or process oriented (embedded system).
is the software to be produced be a general tool or application specific.
is the system to be created safety critical malfunction endanger human life
what is the nature of HW/SW environment in which system will operate.
• Identify high level project risks.
- product uncertainty: users could be uncertain about what is to do.
- process uncertainty: uncertain of the approach which will be used.
- resource uncertainty: the availability of staff of the right ability and
experience.

• Take into account user requirements concerning implementation(i.e.

standards).
• Select general life cycle approach.

©The McGraw-Hill Companies, 2005

 *Choice of process models
• process models: a number of activities that
can be organized in different ways to
create a final product:
1. ‘waterfall’ also known as ‘one-shot’, ‘once-
through’
2. incremental delivery.
3. evolutionary development.

7
©The McGraw-Hill Companies, 2005
 Waterfall

The waterfall model

8
©The McGraw-Hill Companies, 2005
 Waterfall
• the ‘classical’ model
• imposes structure on the project
• every stage needs to be checked and signed off.
• There is a sequence of activity.
• BUT
– limited scope for iteration.
– (a little of go back)
Which is the strength of the process model . Having
reopened completed activities delay the promised
completion dates.
So waterfall allows project completion times to be
forecast with confidence (allowing effective control
of the project) . 9
©The McGraw-Hill Companies, 2005
 V-process model

Another way of looking at the waterfall model

10
©The McGraw-Hill Companies, 2005
• Waterfall model can be expanded into
V_process model.
• This expansion is done by expanding the
testing process into different types of
testing which check the executable code
against the products of each activity in the
project life cycle leading up to the coding.

11
©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’

• Prototype can be classified as:

1. ‘throw away’ prototypes: test some ideas before the real
system (operational system) is started.
2. evolutionary prototypes: is developed and modified until
it is finally become the operational system.
• what is being prototyped?
1. human-computer interface
2. functionality
12
©The McGraw-Hill Companies, 2005
 Reasons for prototyping
(advantages)
1. learning by doing: we see where we have made
mistakes.
2. Improved communication: by practice better than by
specification.
3. Improved user involvement: in the design decision.
4. A feedback loop is established
5. Reduces the need for documentation: less need for
detailed specification of requirements.
6. Reduces maintenance costs i.e. changes after the
application goes live will be costly.
7. Prototype can be used for producing expected results (
expected results of test cases).Creating test cases is not
the problem, the problem is to calculate
13 accurate
©The McGraw-Hill Companies, 2005
expected results.
 Prototyping: some dangers
(disadvantages)

1. users may misunderstand the role of the

prototype.
2. lack of project control and standards possible:
not structured system, Maintenance is difficult.
3. 3. additional expense of building prototype.
4. focus on user-friendly interface could be at
expense of machine efficiency.

14
©The McGraw-Hill Companies, 2005
 Other ways of categorizing
prototyping

• what is being learnt?

• most important reason for prototyping is the need to learn

about the area of uncertainty.
• Prototype can be used in different stages:
1. At the requirements gathering stages to confirm
requirements that are not clear.
2. At the design stages to navigate through a sequence of
input screens.

15
©The McGraw-Hill Companies, 2005
• To what extent:

It is unusual for the whole of the application to be prototyped.

The prototype is simulates only some aspects of the target
application, for example:

– Mock-ups: as when copies of input screens are shown to

the user workstation, but the screens can’t actually be
used ( without data).
– Simulated interaction: same data always shown and the
user can’t change database.
– Partial working models: vertical (some features) versus
horizontal (all features but not full validation of input).
• Vertical : some functions and prototyped fully .
• Horizontal : all functions are prototyped but not in detail.
©The McGraw-Hill Companies, 2005
 Incremental delivery
delivered
system

design build install evaluate increment

1
first incremental delivery

design build install evaluate increment

2
second incremental delivery
- Incremental delivery : this
approach breaks the application increment
design build install evaluate
down into small components, which 3
are then implemented and delivered
third incremental delivery
in sequence .
- Each component gives some
benefits

17
©The McGraw-Hill Companies, 2005
 The incremental process

Intentional
incremental
delivery

18
©The McGraw-Hill Companies, 2005
 Incremental approach: benefits
1. Feedback from early stages used in developing latter stages
2. Shorter development thresholds
3. User gets some benefits earlier
4. Project may be put aside temporarily
5. Reduces ‘gold-plating’
- gold-plating : unnecessary features are not requested because
users know that features can be included in next increment .
- BUT there are some possible disadvantages
1. Loss of economy of scale : conceptual integrity sometimes suffers
because there is little motivation to deal with scalability and
extensibility.
2. Programmers may be more productive working on one large system
than a series of smaller ones.
3. Software breakage : later increment may require modifications to
earlier increment.

19
©The McGraw-Hill Companies, 2005
 The outline incremental plan
should consist of:
• Having defined the overall objectives and an open
technology plan, the next stage is to plan the increments
using the following guidelines:
1. Steps ideally 1% to 5% of the total project
2. Non-computer steps should be included
3. Ideal if a step takes one month or less:
not more than three months
4. Each step should deliver some benefit to the user (must
have output)
5. Some steps will be physically dependent on others.
• In other cases value-to-cost ratio may be used to decide
priorities.
20
©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, written
by customer.
– C is a score 0-10 representing value to developers,
written by developer.
– value-to-cost ratios can be used to establish the order in
which increment are to be delivered .

21
©The McGraw-Hill Companies, 2005
 V/C ratios: an example
step value cost ratio
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 9 0 inf 1st
for managers

22
©The McGraw-Hill Companies, 2005
 ‘Agile’ methods
• Agile method : are designed to overcome disadvantage of heavy weigh
methodologies
• There are various agile approaches : DSDM ,scrum, extreme
programming (xp).
structured development methods have some perceived
advantages:
1. Produce large amounts of documentation which can be largely
unread
2. Documentation has to be kept up to date
3. Division into specialist groups and need to follow procedures stifles
communication
4. Users can be excluded from decision process
5. Long lead times to deliver anything etc.
The answer? ‘Agile’ methods?
23
©The McGraw-Hill Companies, 2005
 Extreme programming
1. Increments are of one to four weeks ,increment in xp
means release ,each release improve old features and may
add new features.
2. Customer can suggest improvement at any point,
communication is face-to-face ,formal documentation is
avoided.
3. Argued that distinction between design and building of
software are artificial.
4. Simplicity: code to be developed to meet current needs only,
because future needs might never realized.
5. Refactoring: frequent re-factoring to keep code structured.
 don’t make a little changes in the code, but be courage to
rewrite whole section of the code. If this will keep the code
structured, otherwise the code will be “spaghetti-like”.
24
©The McGraw-Hill Companies, 2005
 Extreme programming - contd

6. Developers work in pairs (pair programming )

- The programming pair site at the same computer to
develop the software one typing and other observing “two
heads are often better than one”
- Pair programming discovers high percentages of software
error.
7. Test cases and expected results devised before software
design (before the software created).
8. After testing of increment, test cases added to a
consolidated set of test cases. To ensure that later
development don’t insert error into existing working code.
25
©The McGraw-Hill Companies, 2005
‘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 (waterfall) approach.
IF schedule is tight (dead line are tight)
THEN use evolutionary or incremental, because both models
should allow at list something to be delivered at the deadline.
26
©The McGraw-Hill Companies, 2005
 Combinations of approach

installation

one-shot incremental evolutionary

one-shot yes yes no

incremental yes yes no

evolutionary yes yes yes

-Construction of an application can be distinguished

from its installation.
-one-shot or incremental installation, any construction
approach possible.
-evolutionary installation implies evolutionary
27
construction.
©The McGraw-Hill Companies, 2005
• Construction of an application can be
distinguished from its installation.

• Example: an application could be

constructed using waterfall (one shot) but
then be released using incremental
technique.

28
©The McGraw-Hill Companies, 2005