Introduction to Project Life Cycle
(Part 2)
Dr.Çağatay ÜNDEĞER
Instructor
Bilkent University, Computer Engineering
Middle East Technical University, Game Technologies
&
General Manager
SimBT Inc.
e-mail : cagatay@undeger.com
CS-413
Bilgisayar Mühendisliği Bölümü – Bilkent Üniversitesi – Fall 2009
1
Introduction To Project Life Cycle
•
•
•
CS-413
What is a Project Life Cycle?
– Project management life cycle
– System development life cycle (process model)
Usual Phases of Process Models
– Planning
– Analysis
– Design
– Implementation
– Deployment
– Maintenance
Prescriptive Process Models
– Waterfall Model
– Incremental Process Models
– Evolutionary Process Models
2
Introduction
(Project Management Life Cycle)
• Contains the management phases (project
management process groups) a project goes
through from concept to completion.
• The project management process groups:
– Initiating,
planning
– Planning,
– Executing,
initiating
closing
– Controlling,
– Closing.
executing
CS-413
3
Introduction
(Process Group Overlap)
CS-413
4
Introduction
(System Development Life Cycle)
• System development life cycle (process
model);
– Contains the development phases a
project goes through from planning to
maintenance.
planning
CS-413
maintenance
5
Introduction (Process Model)
• Defines a distinct set of;
– Activities,
– Actions,
– Tasks,
– Milestones, and
– Work products that are required to
engineer high quality software.
• Not perfect, but provide a useful road map.
CS-413
6
Usual Phases of
Process Models
planning
maintenance
CS-413
analysis
implementation
Planning
Analysis
Design
Implementation
Deployment
Maintenance
design
•
•
•
•
•
•
deployment
7
Phases of Process Models
• Generally, the deliverables (documents,
programs, hardware and data) from one
phase are approved before the next phase
starts.
• Every process model must be adapted so that
it is used effectively for a specific software
project.
CS-413
8
Project Management Life Cycle
vs.
Process Models
• Project management life cycle contains
umbrella activities that cover process models
looking from a higher perspective.
planning
analysis
design
planning
closing
Process model
executing
maintenance
CS-413
implementation
initiating
deployment
9
Introduction To Project Life Cycle
•
•
•
CS-413
What is a Project Life Cycle?
– Project management life cycle
– System development life cycle (process model)
Usual Phases of Process Models
– Planning
– Analysis
– Design
– Implementation
– Deployment
– Maintenance
Prescriptive Process Models
– Waterfall Model
– Incremental Process Models
– Evolutionary Process Models
10
Phases of Process Models
(Planning)
•
•
•
•
•
•
CS-413
Planning
Analysis
Design
Implementation
Deployment
Maintenance
11
Phases of Process Models
(Planning)
• The phase where;
– Need for a new or enhanced system is
identified, and
– Proposed system’s scope is determined.
CS-413
12
Planning Activities
• Identification of needs
• Determination of scope
• Preparation of baseline project plan
scope
quality
cost
CS-413
time
13
Identification of Needs
• The organization’s information needs are
examined,
• The project’s coarse requirements are
identified.
• The system analysts prioritize and translate
the coarse requirements into a written
document including;
– a course description of the user needs,
– feasibility statement and
– a coarse schedule.
CS-413
14
Determination of Scope
• The requested system is further investigated
by the system analysts, and
• The scope of the system is determined.
CS-413
15
Preparation of
Baseline Project Plan
• The system analysts produce a specific plan
for the development, which is called the
baseline project plan.
• This project plan;
– Customizes a process model and specifies
the time and resources required for its
execution.
CS-413
16
Baseline Project Plan
• The baseline project plan contains:
– A Software Project Management Plan (SPMP) is
written to guide the management procedures.
– A Software Configuration Management Plan
(SCMP) may be written in order to assure that the
change management is performed in a control
way.
– A Software Quality Assurance Plan (SQAP) may
be written to guide the quality assurance
procedures.
– A Software Validation & Verification (V&V) Plan
(SVVP) may be written to guide the validation and
verification procedures.
CS-413
17
Who plans, and How?
• Usually performed by the users and the
development team together,
• The first draft of plan is usually prepared
before the project formally starts.
• The plan may sometimes split into two
primary documents:
– Project Description Document (customer)
– Tender (developer)
CS-413
18
Primary Documents
• Project Description Document:
– Definition of the requirements
– Includes needs, and scope
– Usually a less technical document
• Tender:
– A proposal to meet the requirements
– Includes needs, scope, and the baseline
project plan
– Usually a more technical document
• There are many ways these documents are
prepared.
CS-413
19
Sample Case 1
• Project description document is written (customer).
• Requested system is put out to tender (awarding).
• Each interested IT company submits the customer
what they propose to do with a formal written
document, Tender.
• Tender includes:
– Objective of the system,
– Scope of the system,
– How they develop the system,
– Proposed deliverables of the system,
– Cost and time required for the development,
– Baseline project plan.
• Customer selects one of the tenders/company, and
the project is started.
CS-413
20
Sample Case 2
• Project description document is written (IT
company)
• The company estimates the requirements of
a specific customer.
• Project description document is transformed
into a tender, and presented to the customer.
• If customer finds the tender acceptable,
– Project is started with the company that
proposes the system.
CS-413
21
Sample Case 3
• Project description document is written (IT
company)
– In order to solve the requirements of a
specific market.
• Project is started internally within the
organization,
• A commercial of the shelf (COTS) product is
constructed to be sold in the market.
CS-413
22
Sample Case 4
• Project may be evaluated and started within
the organization for internal use.
CS-413
23
Project Definition Document
• A document that;
– Defines the requirements of the user
• Including the needs and the scope.
• The first part of your term project will be;
– A Project Definition Document (5%)
• A translated (English) template for project
definition document of Secretariat of Defense
Industry (Savunma Sanayii Müsteşarlığı SSM) will be provided.
CS-413
24
Software Project
Management Plan (SPMP)
•
Institute of Electrical and Electronics
Engineers (IEEE) 1058 standard that;
– Defines the approach to be used by the
project team
• To deliver the intended project
management scope of the project
[Wikipedia].
• The second part of your term project will be;
– A Software Project Management Plan
(10%)
CS-413
25
Software Configuration
Management Plan (SCMP)
•
CS-413
IEEE 828 standard that;
– Speficies the form of the document used;
– To control and monitor the change in
evolution of a software system [Walla
Wall College] .
26
Software Quality Assurance
Plan (SQAP)
•
CS-413
IEEE 730 standard that;
– Defines the techniques, procedures, and
methodologies that will be used;
• To assure timely delivery of the
software that meets specified
requirements within the project
resources [Center for Space
Research].
27
Software Validation &
Verification Plan (SVVP)
•
IEEE 1012 standard that;
– Specifies the form of the document used
• To check that a software product
meets specifications and that it fulfills
its intended purpose [Wikipedia].
• Software Validation is the process of;
– Assuring that expected requirements
defined fully satisfies real requirements.
• Software Verification is the process of;
– Assuring that software fully satisfies all
the expected requirements defined.
CS-413
28
Phases of Process Models
(Analysis)
•
•
•
•
•
•
CS-413
Planning
Analysis
Design
Implementation
Deployment
Maintenance
29
Phases of Process Models
(Analysis)
• The phase where;
– The system requirements are determined,
– Alternative solutions are developed, and
– One is chosen that best meets those
requirements given;
• Cost,
• Labor, and
• Technical resources the organization is
willing to commit.
CS-413
30
Analysis Activities
• Requirements of the system are determined.
• Requirements of the system are structured.
• Alternative designs are generated.
CS-413
31
Determining Requirements
• Analysts work with users to determine exactly
what the users will want from the proposed
system.
• This sub-phase requires a careful study of the
any current systems linked to the proposed
system.
CS-413
32
Structuring Requirements
• The analysts study the requirements, and
• Structure them according to their
relationships, eliminating any redundancies.
CS-413
33
Generating Alternative Designs
• The analysts generate alternative designs to
meet the user requirements.
• They compare the designs in order to
determine;
– Which one best meets the requirements
given;
• Cost,
• Labor, and
• Technical resources the organization is
willing to commit to the project
development.
CS-413
34
Output of Analysis
• The output of the analysis phase will be a
description of the solution,
– Software Requirements Specification
(SRS) document, finally recommended by
the analysis team.
CS-413
35
Software Requirements
Specification (SRS)
• IEEE 830 standard that;
– Specifies the form of the document used;
• To complete description of the behavior
of the system to be developed
[Wikipedia].
• The third part of your term project will be;
– A Software Requirements Specification
(15%)
CS-413
36
Phases of Process Models
(Design)
•
•
•
•
•
•
CS-413
Planning
Analysis
Design
Implementation
Deployment
Maintenance
37
Phases of Process Models
(Design)
• The phase where;
– Description of the recommended
alternative are converted into;
• A logical description and then into a
physical system specification.
• Design all the aspects of the system;
– From input and output screens
– To reports, databases, algorithms, and
computer processes.
CS-413
38
Design Activities
• Developing logical system design
• Generating physical system specifications
CS-413
39
Developing
Logical System Design
• Focuses on;
– The business aspects of the system.
• Design is not tied to;
– Any specific hardware or system software
platform.
• Theoretically, designed system could be
implemented using;
– Any hardware and system software
platform.
CS-413
40
Generating Physical
System Specifications
• Converts logical design into technical
specifications.
• The logical design is broken down into;
– Smaller and smaller system units;
• That can be converted to computer
instructions in a programming language.
• Details of the implementation environment
are specified.
CS-413
41
Details of
Implementation Environment
•
•
•
•
CS-413
Hardware platforms and operating systems,
Programming languages,
Database systems and file structures,
Network environment.
42
Output of Design
• The output of the design phase will be a
description of the solution,
– Software Design Description (SDD)
document, ready to be delivered to the
programmers and other system builders for
implementation.
CS-413
43
Software Design Description
(SDD)
• IEEE 1016 standard that;
– Specifies the form of the document used;
• To specify;
–System architecture and
–Application design in a software
related project [Wikipedia].
• The fourth part of your term project will be;
– A Software Design Description (15%)
CS-413
44
Phases of Process Models
(Implementation)
•
•
•
•
•
•
CS-413
Planning
Analysis
Design
Implementation
Deployment
Maintenance
45
Phases of Process Models
(Implementation)
• The phase where;
– The system specifications are turned into a
working system that is;
• Tested and
• Ready to use.
CS-413
46
Implementation Activities
• Coding
• Testing
• Writing user manuals
CS-413
47
Coding
• Programmers write the programs that make
up the system:
– Developing system units
– Integrating system units
– Correcting bugs
CS-413
48
Testing
• A Software Test Documentation (STD) is
written to guide the testing, and the reporting
of the test results.
• Programmers and analysts test;
– Individiual programs (unit tests), and
– Entire system (integration tests)
• Guided by the software test plan in order
to find and correct errors.
• During testing, sample data entry and data
production might be required.
CS-413
49
Software Test Documentation
(SDD)
• IEEE 829 standard that;
– Specifies the form of the document used;
• To defined stages of software testing,
each stage potentially producing its own
separate type of document [Wikipedia].
CS-413
50
Writing User Manuals
• The user manuals are written as;
– A hard copy documentation,
– A soft copy documentation, and
– An interactive help.
CS-413
51
Phases of Process Models
(Deployment)
•
•
•
•
•
•
CS-413
Planning
Analysis
Design
Implementation
Deployment
Maintenance
52
Phases of Process Models
(Deployment)
• The phase where;
– The implemented system is installed to the
organization for actual use.
CS-413
53
Deployment Activities
• Application software is installed to the
organization.
• Baseline data is entered to the system.
• Users are introduced to the new system and
trained.
• The new system becomes a part of the daily
activities of the organization.
CS-413
54
Phases of Process Models
(Maintenance)
•
•
•
•
•
•
CS-413
Planning
Analysis
Design
Implementation
Deployment
Maintenance
55
Phases of Process Models
(Maintenance)
• The phase where;
– Programmers make;
• Changes that users ask for, and
• Modify the system to reflect changing
business conditions.
CS-413
56
Time & Effort of Maintenance
• The amount of time and effort devoted to;
– System enhancement during the
maintenance phase depends on;
• How well the previous life cycle phases
were completed.
CS-413
57
Maintenance vs. Replacement
• There inevitably comes a time when an
information system no longer performs as
desired,
– When the costs of keeping it running
becomes prohibitive, or
– When the organization’s needs have
changed substantially.
• Such problems indicate that it is time to begin
the design of the system’s replacement.
CS-413
58
Introduction To Project Life Cycle
•
•
•
CS-413
What is a Project Life Cycle?
– Project management life cycle
– System development life cycle (process model)
Usual Phases of Process Models
– Planning
– Analysis
– Design
– Implementation
– Deployment
– Maintenance
Prescriptive Process Models
– Waterfall Model
– Incremental Process Models
– Evolutionary Process Models
59
Prescriptive Process Models
• Water Fall Model
• Incremental Process Models
– The Incremental Model
– The RAD Model
• Evolutionary Process Models
– Prototyping Model
– The Spiral Model
– Concurrent Development Model
CS-413
60
Water Fall Model
• The requirements of the problem can be wellunderstood.
• The work flow from planning to maintenance
could be easily seen.
• In that case;
– Development process should not need to
be so complicated, and
– Could be provided by the simplest model
called waterfall.
CS-413
61
Water Fall Model
(Classical Life Cycle)
•
Suggests a;
– Systematic,
– Sequential,
– Linear approach to software development
that;
• Progresses through planning to
maintenance phases in one iteration.
• Oldest process model,
• But very efficient for simple projects.
Water fall model
Planning
CS-413
Analysis
Design
Implementation
Deployment
Maintenance
62
Where to use?
Advantages?
Drawbacks?
CS-413
63
Water Fall Model
(Drawbacks)
• Drawbacks:
– Real projects are not usually simple, and
• Rarely follow the sequential model.
– Often very difficult for customer to define all
the requirements from the beginning.
– Customer must have patience,
• Since working version of a product could
not be delivered
–Until late in the project time-line.
• Rarely preferred in project development.
CS-413
64
Incremental Process Models
• The initial software requirements of the
problem can be well-understood;
– But overall scope of the development effort
does not follow a purely linear process.
• There can be necessary need;
– To provide a rapid, limited version of the
system to the users.
• System could be refined and expanded in
later versions.
CS-413
65
Incremental Process Models
(The Incremental Model)
• Combines elements of waterfall model
applied in an iterative staggered fashion.
• Each of iterations;
– Is a linear sequence like waterfall model,
– Provides a limited version of the system.
The incremental model
Planning
Analysis
Design
Version 2.0
Implementation
Planning
Deployment
Analysis
Version 3.0
CS-413
Planning
Maintenance
Design
Version 1.0
Implementation
Analysis
Design
Deployment
Implementation
Maintenance
Deployment
Maintenance
66
Incremental Process Models
(The Incremental Model)
• First iteration builds the core product with
basic functionality,
– But many supplementary features remain
undelivered.
• Following iterations build new versions that
– Increase the functionality of the system.
• After the end of an-iteration or late in the
time-line of an-iteration;
– Next iteration is planned, and
– Started.
CS-413
67
Where to use?
Advantages?
Drawbacks?
CS-413
68
The Incremental Model
(Drawback)
• If requirements of system for iterations,
especially for first one, are not wellunderstood,
– Hard to apply this process model,
• Since iterations follow classic waterfall
model.
CS-413
69
Incremental Process Models
(The RAD Model)
• Rapid Application Development (RAD) model;
– An incremental software process model
– Emphasizes a short development cycle
• by splitting system into modules that are
developed in parallel.
The RAD model
Design
Implementation
RAD team 1 (module 1)
Analysis
Design
Implementation
RAD team 2 (module 2)
Planning
Analysis
Design
integration
splitting
Analysis
Deployment
Maintenance
Implementation
RAD team 3 (module 3)
Analysis
CS-413
Design
Implementation
RAD team 4 (module 4)
70
Advantages?
Drawbacks?
CS-413
71
Incremental Process Models
(The RAD Model)
• If requirements are well-understood and
project scope is not very large;
– RAD process model enables a
development team to create a full
functional system in a very short period of
time.
CS-413
72
Incremental Process Models
(The RAD Model)
• A good planning is essential,
– Since system should be split into well
defined modules that;
• Enable multiple teams work in parallel
with weak interactions.
CS-413
73
Incremental Process Models
(The RAD Model)
• Implementation usually focuses on;
– Using pre-existing software components
– And application of automatic code
generation.
• At the end of implementation,
– Seperate modules are integrated to form
the whole system.
CS-413
74
The RAD Model
(Drawbacks)
• For large scalable projects,
– RAD requires sufficient human resource to
create the right number of RAD teams.
• If;
– Developers and customers are not wellcommitted to the project development,
– And cannot react rapidly when required,
• Project will most probably fail.
CS-413
75
The RAD Model
(Drawbacks)
• If the system cannot be properly modularized,
– Building components will be problematic.
• If performance is a requirement,
– RAD may not work well,
• Since highly modularized system might
provide a low performance.
• RAD may not be appropriate,
– When technical risks are high.
CS-413
76
Evolutionary Process Models
• Software usually evolves over a period of
time,
– Since business requirements often change
as the development proceeds,
• Making a linear development unrealistic.
CS-413
77
Evolutionary Process Models
• Because of high business pressure and tight
deadlines:
– Very difficult to complete a comprehensive
software product in a large scale time-line
at once;
– A limited version of the system developed
in a tight time-line could be crucial for
being competitive.
CS-413
78
Evolutionary Process Models
• Although the coarse requirements of the
system are well-understood,
– Details may not be clear.
CS-413
79
Evolutionary Process Models
• In such situations,
– Using an evolutionary process model
• That will have several iterations within
project life cycle fits the best.
CS-413
80
Evolutionary Process Models
(Prototyping Model)
• In many cases,
– Customers do not know what exactly they
require,
• But have an idea of a system, which is
unclear in their mind.
CS-413
81
Evolutionary Process Models
(Prototyping Model)
• In other case,
– Developer may not be sure about;
• Availability and efficiency of an algorithm
that will be applied to the problem,
• Adaptability of an operating system or
• Style that human-machine interaction
should take.
CS-413
82
Evolutionary Process Models
(Prototyping Model)
• In such situations,
– Prototyping could be a choice.
CS-413
83
Prototyping Model Process
• Iterations start with a quick;
– Planning,
– Analysis and
– Design.
• Then a low-quality prototype system is
constructed.
Prototyping model
Planning
prototypes
Final system development
quick
cycles
Design
Deployment
CS-413
Analysis
Planning
Analysis
Design
Implementation
Deployment
Maintenance
Implementation
Prototype system
development
84
Prototyping Model Process
• The prototype is refined;
– In multiple iterations,
– Until satisfying the customer.
• After customer is satisfied with functionality
served by prototype,
– Prototype is thrown away,
• Since it may be too slow, too big, too
disordered and too unreliable.
CS-413
85
Prototyping Model Process
• Then a high quality product is rebuilt;
– From scratch or
– by using some of the fragments within the
prototype.
CS-413
86
Drawbacks?
CS-413
87
Prototyping Model
(Drawbacks)
•
Instead of throwing away,
– Customer may request to fix problems to
make the prototype a final product.
• But since prototype is built in a rush,
– Have a low quality design and
implementation,
– And maintaining it would be very difficult
for developer.
CS-413
88
Prototyping Model
(Drawbacks)
•
Since objective of prototype is just to build a
demo,
– Programming language and algorithms to
build the system may be inappropriate for
real system.
• Developer may become comfortable with
these choices,
– And forget all reasons why they were
inappropriate.
• Less than an ideal choice may become a
part of real system.
CS-413
89
Evolutionary Process Models
(The Spiral Model)
• Originally proposed by Boehm,
• An evolutionary model that couples;
– Iterative nature of prototyping
– With systematic control of waterfall model.
Analysis
Planning
Design
Maintenance
Deployment
CS-413
Implementation
90
Evolutionary Process Models
(The Spiral Model)
• Linear sequence of waterfall is repeated as
required,
– Until an acceptable system is found.
• Incrementally enhanced and detailed through
these iterations (cycles around the spiral).
CS-413
91
Evolutionary Process Models
(The Spiral Model)
• A risk-driven cyclic process model;
– For incrementally growing a system’s
degree of definition and implementation
• While decreasing its degree of risk.
CS-413
92
The Spiral Model
(Planning)
• In each of the planning phases;
– Project plan is adjusted,
– Risks are re-evaluated.
• Each of the cycles could be planned
separately,
– Should not always outcome with an
implemented working product.
CS-413
93
The Spiral Model
(Planning)
• First cycle;
– Result in the development of a product
concept and/or specification;
• Later cycles;
– Produce some prototypes;
• Last few cycles;
– Produce sophisticated versions of the final
product.
CS-413
94
Where to use?
Advantages?
Drawbacks?
CS-413
95
The Spiral Model
(Advantage)
• Spiral is a good approach,
– For large scale, complex systems.
CS-413
96
The Spiral Model
(Drawbacks)
• Difficult to convince customers (especially in
contract situations) that spiral approach is
controllable.
• Very difficult to apply spiral with fix-budgets
(especially in contract situations),
– Since as each cycle is completed,
• Project plan and cost is revisited and
revised.
CS-413
97
The Spiral Model
(Drawbacks)
• Demands risk assessment expertise;
– Relies on this expertise for success.
• If a major risk could not be uncovered and
managed,
– Problems will occur.
CS-413
98
Evolutionary Process Models
(Concurrent Development Model)
• Can be represented schematically As;
– A series of parallel activities (e.g. process
model phases or their sub-phases) that;
– Have internal states and state transitions.
CS-413
99
Evolutionary Process Models
(Concurrent Development Model)
• Each of the activities is executed in parallel;
– Their internal states differ from each other.
Concurrent development model
Start
Under development
Start
Waiting changes
Under development
Planning
Under revision
Deployment
Waiting changes
Under review
Maintenance
Under revision
Concurrent activity 1
Completed
Under review
Concurrent activity 2
CS-413
Completed
100
Evolutionary Process Models
(Concurrent Development Model)
•
Sometimes an activity may;
– Become idle,
– Wait until some changes in the
development process
• (e.g. the activity may require an input
or correction to go on).
• Sometimes an activity may continue running
– Until some requirements come up that
make it suspended.
CS-413
101
Where to use?
Advantages?
Drawbacks?
CS-413
102
Concurrent Development Model
(Advantage)
•
•
CS-413
Applicable to all kinds of software
development projects,
Provides a clear picture of the current state
of a project.
103
Concurrent Development Model
(Drawbacks)
•
•
CS-413
Difficult to plan and control the project.
Often more appropriate for system
engineering projects where different
engineering teams are involved.
104