Introduction to Project Life Cycle (Part 2)

1
Introduction to Project Life Cycle(Part 2)
Dr.Çagatay ÜNDEGER Instructor Bilkent
University, Computer Engineering Middle East
Technical University, Game Technologies Genera
l Manager SimBT Inc. e-mail cagatay_at_undeger.com
Bilgisayar Mühendisligi Bölümü Bilkent
Üniversitesi Fall 2009
2
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

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

4
Introduction (Process Group Overlap)
5
Introduction (System Development Life Cycle)

• System development life cycle (process model)
• Contains the development phases a project goes
  through from planning to maintenance.

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

7
Usual Phases of Process Models

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

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

9
Project Management Life Cycle vs.Process Models

• Project management life cycle contains umbrella
  activities that cover process models looking from
  a higher perspective.

Project management life cycle
System development life cycle
Process model
10
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

11
Phases of Process Models (Planning)

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

12
Phases of Process Models (Planning)

• The phase where
• Need for a new or enhanced system is identified,
  and
• Proposed systems scope is determined.

13
Planning Activities

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

14
Identification of Needs

• The organizations information needs are
  examined,
• The projects 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.

15
Determination of Scope

• The requested system is further investigated by
  the system analysts, and
• The scope of the system is determined.

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

17
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 (VV) Plan
  (SVVP) may be written to guide the validation and
  verification procedures.

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

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

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

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

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

23
Sample Case 4

• Project may be evaluated and started within the
  organization for internal use.

24
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üstesarligi - SSM)
  will be provided.

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

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

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

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

29
Phases of Process Models (Analysis)

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

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

31
Analysis Activities

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

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

33
Structuring Requirements

• The analysts study the requirements, and
• Structure them according to their relationships,
  eliminating any redundancies.

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

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

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

37
Phases of Process Models (Design)

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

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

39
Design Activities

• Developing logical system design
• Generating physical system specifications

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

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

42
Details of Implementation Environment

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

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

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

45
Phases of Process Models (Implementation)

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

46
Phases of Process Models (Implementation)

• The phase where
• The system specifications are turned into a
  working system that is
• Tested and
• Ready to use.

47
Implementation Activities

• Coding
• Testing
• Writing user manuals

48
Coding

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

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

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

51
Writing User Manuals

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

52
Phases of Process Models (Deployment)

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

53
Phases of Process Models (Deployment)

• The phase where
• The implemented system is installed to the
  organization for actual use.

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

55
Phases of Process Models (Maintenance)

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

56
Phases of Process Models (Maintenance)

• The phase where
• Programmers make
• Changes that users ask for, and
• Modify the system to reflect changing business
  conditions.

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

58
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 organizations needs have changed
  substantially.
• Such problems indicate that it is time to begin
  the design of the systems replacement.

59
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

60
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

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

62
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
63

• Where to use?
• Advantages?
• Drawbacks?

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

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

66
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
67
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.

68

• Where to use?
• Advantages?
• Drawbacks?

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

70
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
integration
splitting
71

• Advantages?
• Drawbacks?

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

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

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

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

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

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

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

79
Evolutionary Process Models

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

80
Evolutionary Process Models

• In such situations,
• Using an evolutionary process model
• That will have several iterations within project
  life cycle fits the best.

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

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

83
Evolutionary Process Models(Prototyping Model)

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

84
Prototyping Model Process

• Iterations start with a quick
• Planning,
• Analysis and
• Design.
• Then a low-quality prototype system is
  constructed.

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

86
Prototyping Model Process

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

87

• Drawbacks?

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

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

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

Maintenance
91
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).

92
Evolutionary Process Models(The Spiral Model)

• A risk-driven cyclic process model
• For incrementally growing a systems degree of
  definition and implementation
• While decreasing its degree of risk.

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

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

95

• Where to use?
• Advantages?
• Drawbacks?

96
The Spiral Model(Advantage)

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

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

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

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

100
Evolutionary Process Models(Concurrent
Development Model)

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

Concurrent development model
101
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.

102

• Where to use?
• Advantages?
• Drawbacks?

103
Concurrent Development Model(Advantage)

• Applicable to all kinds of software development
  projects,
• Provides a clear picture of the current state of
  a project.

104
Concurrent Development Model(Drawbacks)

• Difficult to plan and control the project.
• Often more appropriate for system engineering
  projects where different engineering teams are
  involved.