cs-413 1 introduction to project life cycle (part 2) bilgisayar mühendisliği bölümü – bilkent...

1CS-413

Introduction to Project Life Cycle(Part 2)

Bilgisayar Mühendisliği Bölümü – Bilkent Üniversitesi – Fall 2009

Dr.Çağatay ÜNDEĞER

InstructorBilkent University, Computer Engineering

Middle East Technical University, Game Technologies

&

General ManagerSimBT Inc.

e-mail : [email protected]

2CS-413

Introduction To Project Life Cycle

• 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

3CS-413

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,– Executing,– Controlling,– Closing.

initiating

planning

closing

executing

controlling

monitorin

g

4CS-413

Introduction (Process Group Overlap)

5CS-413

Introduction (System Development Life Cycle)

• System development life cycle (process model);– Contains the development phases a

project goes through from planning to maintenance.

planning maintenance

6CS-413

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.

7CS-413

Usual Phases of Process Models

• Planning• Analysis• Design• Implementation• Deployment• Maintenance

planning analysis

deploymentmaintenance

designim

plementation

8CS-413

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.

9CS-413

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

deploymentmaintenance

implem

entationdesign

initiating

planning

closing

executing

controlling

monitorin

gProcess model

Project management

life cycle

System development

life cycle

10CS-413





11CS-413

Phases of Process Models (Planning)

• Planning • Analysis• Design• Implementation• Deployment• Maintenance

12CS-413

Phases of Process Models (Planning)

• The phase where;– Need for a new or enhanced system is

identified, and – Proposed system’s scope is determined.

13CS-413

Planning Activities

• Identification of needs• Determination of scope• Preparation of baseline project plan

scope

cost

time

quality

14CS-413

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.

15CS-413

Determination of Scope

• The requested system is further investigated by the system analysts, and

• The scope of the system is determined.

16CS-413

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.

17CS-413

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.

18CS-413

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)

19CS-413

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.

20CS-413

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.

21CS-413

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.

22CS-413

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.

23CS-413

Sample Case 4• Project may be evaluated and started within

the organization for internal use.

24CS-413

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.

25CS-413

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%)

26CS-413

Software Configuration Management Plan (SCMP)

• 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] .

27CS-413

Software Quality Assurance Plan (SQAP)

• 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].

28CS-413

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.

29CS-413

Phases of Process Models (Analysis)


30CS-413

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.

31CS-413

Analysis Activities

• Requirements of the system are determined.• Requirements of the system are structured.• Alternative designs are generated.

32CS-413

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.

33CS-413

Structuring Requirements

• The analysts study the requirements, and • Structure them according to their

relationships, eliminating any redundancies.

34CS-413

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.

35CS-413

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.

36CS-413

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%)

37CS-413

Phases of Process Models (Design)


38CS-413

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.

39CS-413

Design Activities

• Developing logical system design• Generating physical system specifications

40CS-413

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.

41CS-413

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.

42CS-413

Details of Implementation Environment

• Hardware platforms and operating systems, • Programming languages,• Database systems and file structures,• Network environment.

43CS-413

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.

44CS-413

Software Design Description (SDD)


• 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%)

45CS-413

Phases of Process Models (Implementation)


46CS-413

Phases of Process Models (Implementation)

• The phase where;– The system specifications are turned into a

working system that is;• Tested and • Ready to use.

47CS-413

Implementation Activities

• Coding• Testing• Writing user manuals

48CS-413

Coding

• Programmers write the programs that make up the system:– Developing system units– Integrating system units– Correcting bugs

49CS-413

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.

50CS-413

Software Test Documentation (SDD)


• To defined stages of software testing, each stage potentially producing its own separate type of document [Wikipedia].

51CS-413

Writing User Manuals

• The user manuals are written as;– A hard copy documentation,– A soft copy documentation, and– An interactive help.

52CS-413

Phases of Process Models (Deployment)


53CS-413

Phases of Process Models (Deployment)

• The phase where;– The implemented system is installed to the

organization for actual use.

54CS-413

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.

55CS-413

Phases of Process Models (Maintenance)


56CS-413

Phases of Process Models (Maintenance)

• The phase where;– Programmers make;

• Changes that users ask for, and • Modify the system to reflect changing

business conditions.

57CS-413

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.

58CS-413

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.

59CS-413





60CS-413

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

61CS-413

Water Fall Model

• The requirements of the problem can be well-understood.

• 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.

62CS-413

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.

Planning Analysis Design Implementation Deployment Maintenance

Water fall model

63CS-413

Where to use?Advantages?Drawbacks?

64CS-413

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.

65CS-413

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.

66CS-413

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



Version 1.0

Version 2.0

Version 3.0

67CS-413

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.

68CS-413


69CS-413

The Incremental Model(Drawback)

• If requirements of system for iterations, especially for first one, are not well-understood, – Hard to apply this process model,

• Since iterations follow classic waterfall model.

70CS-413

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

Planning

Analysis Design Implementation

Deployment Maintenance




RAD team 1 (module 1)




inte

grat

ion

split

ting

71CS-413

Advantages?

Drawbacks?

72CS-413


• 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.

73CS-413


• A good planning is essential, – Since system should be split into well

defined modules that;• Enable multiple teams work in parallel

with weak interactions.

74CS-413


• 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.

75CS-413

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 well-committed to the project development,

– And cannot react rapidly when required, • Project will most probably fail.

76CS-413

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.

77CS-413

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.

78CS-413


• 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.

79CS-413


• Although the coarse requirements of the system are well-understood, – Details may not be clear.

80CS-413


• In such situations, – Using an evolutionary process model

• That will have several iterations within project life cycle fits the best.

81CS-413

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.

82CS-413


• 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.

83CS-413


• In such situations, – Prototyping could be a choice.

84CS-413

Prototyping Model Process

• Iterations start with a quick;– Planning, – Analysis and – Design.

• Then a low-quality prototype system is constructed.

Planning Analysis

Desig

n

Implementation

Dep

loym

en

t

quick cycles

prototypesPlanning Analysis Design Implementation Deployment Maintenance

Prototyping model

Final system development

Prototype systemdevelopment

85CS-413


• 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.

86CS-413


• Then a high quality product is rebuilt;– From scratch or – by using some of the fragments within the

prototype.

87CS-413

Drawbacks?

88CS-413

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.

89CS-413

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.

90CS-413

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.

Planning

Analysis

Design

ImplementationDeployment

Maintenance

91CS-413


• 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).

92CS-413


• A risk-driven cyclic process model; – For incrementally growing a system’s

degree of definition and implementation • While decreasing its degree of risk.

93CS-413

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.

94CS-413

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.

95CS-413


96CS-413

The Spiral Model(Advantage)

• Spiral is a good approach,– For large scale, complex systems.

97CS-413

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.

98CS-413

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.

99CS-413

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.

100CS-413


• Each of the activities is executed in parallel;– Their internal states differ from each other.

Maintenance

Start

Under development

Waiting changes

Under revision

Under review

Completed

Start

Under development

Waiting changes

Under revision

Under review

Completed

Concurrent activity 1

Concurrent activity 2

DeploymentPlanning

Concurrent development model

101CS-413


• 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.

102CS-413


103CS-413

Concurrent Development Model(Advantage)

• Applicable to all kinds of software development projects,

• Provides a clear picture of the current state of a project.

104CS-413

Concurrent Development Model(Drawbacks)

• Difficult to plan and control the project.• Often more appropriate for system

engineering projects where different engineering teams are involved.