Introduction to Project Life Cycle (Part 2) - PowerPoint PPT Presentation

Loading...

PPT – Introduction to Project Life Cycle (Part 2) PowerPoint presentation | free to download - id: 57da7f-ZDU0M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Introduction to Project Life Cycle (Part 2)

Description:

Introduction to Project Life Cycle (Part 2) Dr. a atay NDE ER Instructor Bilkent University, Computer Engineering Middle East Technical University, Game Technologies – PowerPoint PPT presentation

Number of Views:79
Avg rating:3.0/5.0
Slides: 105
Provided by: 61870
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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.
About PowerShow.com