The concept of a project life The concept of a project life cycle cycle

17  Download (0)

Full text

(1)

The concept of a project life The concept of a project life

cycle cycle

Grzegorz Gronkiewicz Grzegorz Gronkiewicz

Radosław Całka

Radosław Całka

(2)

What is the purpose of having a What is the purpose of having a

project life cycle?

project life cycle?

To define the activities to be carried out in a To define the activities to be carried out in a systems development project.

systems development project.

To introduce consistency among many systems To introduce consistency among many systems development projects in the same organization.

development projects in the same organization.

To provide checkpoints for management control for To provide checkpoints for management control for go/no-go decisions.

go/no-go decisions.

(3)

The classical project life cycle The classical project life cycle

The survey phase and the analysis phase may be lumped together The survey phase and the analysis phase may be lumped together

into a single phase (this is especially common in organizations in into a single phase (this is especially common in organizations in

which anything the user wants is deemed at the outset to be which anything the user wants is deemed at the outset to be

feasible).

feasible).

There may not be a phase called hardware study if it can be taken There may not be a phase called hardware study if it can be taken

for granted that any new system can be implemented on an existing for granted that any new system can be implemented on an existing

computer without causing any major operational impact.

computer without causing any major operational impact.

The preliminary design and detail design phases may be lumped The preliminary design and detail design phases may be lumped

together in a single phase simply called design.

together in a single phase simply called design.

Several of the testing phases may be grouped together into a single Several of the testing phases may be grouped together into a single

phase; indeed, they may even be included with coding.

phase; indeed, they may even be included with coding.

(4)
(5)

Bottom-Up Implementation Bottom-Up Implementation

Nothing is done until it's

Nothing is done until it's allall done. done.

Module testing uncovers relatively simple Module testing uncovers relatively simple

logic errors inside individual modules.

logic errors inside individual modules.

Debugging tends to be extremely difficult Debugging tends to be extremely difficult during the final stages of system testing.

during the final stages of system testing.

The requirement for computer test time The requirement for computer test time

usually rises exponentially during the final usually rises exponentially during the final

stages of testing.

stages of testing.

(6)
(7)

Sequential Progression Sequential Progression

sequential approach doesn't allow for real-world sequential approach doesn't allow for real-world

phenomena having to do with personnel phenomena having to do with personnel

we rarely do a complex job right the first time, we rarely do a complex job right the first time,

but we are very good at making repeated but we are very good at making repeated

improvements to an imperfect job improvements to an imperfect job

the user may change his or her mind about what the user may change his or her mind about what

the system should do the system should do

the classical project life cycle relies on outdated the classical project life cycle relies on outdated

techniques techniques

(8)

The semi structured life cycle The semi structured life cycle

The bottom-up sequence of coding, module The bottom-up sequence of coding, module

testing, and system testing is replaced by top- testing, and system testing is replaced by top-

down implementation down implementation

Approach where high-level modules are coded Approach where high-level modules are coded

and tested first, followed by the lower-level, and tested first, followed by the lower-level,

detailed modules.

detailed modules.

Strong indication that structured programming is Strong indication that structured programming is

to be used as the method of actually coding the to be used as the method of actually coding the

system.

system.

Classical design is replaced by structured Classical design is replaced by structured

design.

design.

(9)
(10)
(11)

The structured project life cycle The structured project life cycle

The Survey The Survey

Systems Analysis Systems Analysis

Design Design

Implementation Implementation

Acceptance Test Generation Acceptance Test Generation

Quality Assurance Quality Assurance

Procedure Description Procedure Description Database Conversion Database Conversion

Installation Installation

(12)
(13)

Radical versus conservative top- Radical versus conservative top-

down implementation down implementation

In the most extreme In the most extreme

situation, all the activities situation, all the activities

in the structured project in the structured project

life cycle could be taking life cycle could be taking

place simultaneously place simultaneously

in a

in a conservativeconservative approach to the approach to the

structured project life structured project life

cycle, all of activity N is cycle, all of activity N is

completed before activity completed before activity

N + 1 begins.

N + 1 begins.

(14)

How does a project manager How does a project manager

decide whether to adopt a radical decide whether to adopt a radical

or conservative approach?

or conservative approach?

How fickle is the user?

How fickle is the user?

What pressure is the project team under to What pressure is the project team under to

produce immediate, tangible results?

produce immediate, tangible results?

What pressure is the project manager under to What pressure is the project manager under to

produce an accurate schedule, budget, and produce an accurate schedule, budget, and

estimate of people and other resources?

estimate of people and other resources?

What are the dangers of making a major What are the dangers of making a major

technical blunder?

technical blunder?

(15)

The Prototyping life cycle The Prototyping life cycle

An alternative approach to requirements An alternative approach to requirements

definition is to capture an initial set of definition is to capture an initial set of

needs and to implement quickly those needs and to implement quickly those

needs with the stated intent of iteratively needs with the stated intent of iteratively

expanding and refining them as mutual expanding and refining them as mutual

user/developer understanding of the user/developer understanding of the

system grows system grows

(16)

Good candidates for a prototyping Good candidates for a prototyping

approach approach

The user is unable (or unwilling) to examine The user is unable (or unwilling) to examine

abstract paper models like dataflow diagrams.

abstract paper models like dataflow diagrams.

The user is unable or unwilling to articulate (or The user is unable or unwilling to articulate (or

“prespecify”) his or her requirements in any form

“prespecify”) his or her requirements in any form and can only determine the requirements

and can only determine the requirements through a process of trial and error.

through a process of trial and error.

The system is intended to be on-line with full- The system is intended to be on-line with full-

screen terminal activities, as opposed to batch screen terminal activities, as opposed to batch

edit, update, and report systems.

edit, update, and report systems.

(17)

Figure

Updating...

References

Related subjects :