View
217
Download
0
Embed Size (px)
Citation preview
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
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
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
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)
• Planning • Analysis• Design• Implementation• Deployment• Maintenance
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)
• Planning • Analysis• Design• Implementation• Deployment• Maintenance
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)
• 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%)
45CS-413
Phases of Process Models (Implementation)
• Planning • Analysis• Design• Implementation• Deployment• Maintenance
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.
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)
• 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].
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)
• Planning • Analysis• Design• Implementation• Deployment• Maintenance
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)
• Planning • Analysis• Design• Implementation• Deployment• 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
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
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
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.
Planning Analysis Design Implementation Deployment Maintenance
The incremental model
Planning Analysis Design Implementation Deployment Maintenance
Planning Analysis Design Implementation Deployment Maintenance
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.
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
Analysis Design Implementation
Analysis Design Implementation
Analysis Design Implementation
RAD team 1 (module 1)
RAD team 2 (module 2)
RAD team 3 (module 3)
RAD team 4 (module 4)
inte
grat
ion
split
ting
72CS-413
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.
73CS-413
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.
74CS-413
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.
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
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.
79CS-413
Evolutionary Process Models
• Although the coarse requirements of the system are well-understood, – Details may not be clear.
80CS-413
Evolutionary Process Models
• 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
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.
83CS-413
Evolutionary Process Models(Prototyping Model)
• 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
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.
86CS-413
Prototyping Model Process
• Then a high quality product is rebuilt;– From scratch or – by using some of the fragments within the
prototype.
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
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).
92CS-413
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.
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.
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
Evolutionary Process Models(Concurrent Development Model)
• 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
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.
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.