3. PLANNING & PROCESSES - PowerPoint PPT Presentation

About This Presentation
Title:

3. PLANNING & PROCESSES

Description:

The Life Cycle of A Large System Integration Project 3. PLANNING & PROCESSES PLANNING PROGRAM PLAN ENGINEERING PLAN PROJECT PLAN REQUIREMENT PLAN CONTRACT MANAGEMENT ... – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 27
Provided by: itUuSeed
Category:

less

Transcript and Presenter's Notes

Title: 3. PLANNING & PROCESSES


1
3. PLANNING PROCESSES
The Life Cycle of A Large System Integration
Project
2
PLANNING
3
PROGRAM PLAN
  • BASE DOCUMENTS
  • BID PROPOSAL solution
  • CONTRACT what we promised, schedule, price
  • REFERENCES estimation and document format
  • TEAM
  • Program Manager, Contract Manager
  • Chief Engineers
  • OUTPUT
  • PROGRAM PLAN, reviewed by AQ and approved by
    business director
  • KEY CONTENTS
  • Objectives and reference projects
  • Scope and process Selection
  • Budget Material (LAB), manpower, Travel cost
  • Payment schedule and Cash flow
  • Skill set and manpower distribution
  • Contract subcontractor management

4
ENGINEERING PLAN
  • BASE DOCUMENTS
  • BID PROPOSAL solution
  • CONTRACT what we promised
  • PROGRAM PLAN schedule
  • REFERENCES experiences and document format
  • OUTPUT
  • ENGINEERING PLAN,
  • Reviewed by QA and approved by Program Manager
    and Engineer Manager
  • TEAM
  • Chief Engineer, Network Engineer, Software
    Engineer
  • KEY CONTENTS
  • High level overview
  • System architecture
  • Software architecture
  • System operation
  • Technology and Prototype

5
PROJECT PLAN
  • BASE DOCUMENTS
  • PROGRAM PLAN schedule, manpower,
  • ENGINEERING PLAN solution,
  • REFERENCES experiences and document
  • OUTPUT
  • PROJECT PLAN, reviewed by QA and approved by
    Program Manager
  • TEAM
  • Project Manager, Program Manager, Chief
    Engineers
  • KEY CONTENTS
  • Schedule
  • Skill set and manpower management
  • Process execution
  • Lab establishment
  • Milestone (deliverable) management
  • Risk management
  • Requirement management

6
REQUIREMENT PLAN
  • BASE DOCUMENTS
  • PROJECT PLAN schedule
  • ENGINEERING PLAN solution,
  • REFERENCES experiences and document
  • OUTPUT
  • REQUIREMENT PLAN, reviewed by QA and approved by
    Project Manager
  • TEAM
  • Engineers, Chief Engineer, Project Manager
  • KEY CONTENTS
  • Schedule
  • Questionnaires for all parts

7
CONTRACT MANAGEMENT
  • Contract manager is specialized in contract
    execution and has legal background and sufficient
    knowledge of companys charging structure.
  • When risks caused by customers, he/she must
    evaluate the impact and estimate its associated
    cost, and sends memorandum to customer. A
    personal visit may be necessary, get layer
    involved when issues become serious.
  • Know the process and procedure of arbitration and
    suit
  • Participate in milestone review meeting with the
    Program Manager.

8
SUBCONTRACT MANAGEMENT
  • With combined functions of a program manager and
    a contract manager, but at a smaller scale
  • Identify potential vendors
  • Access vendors profile and evaluate their
    qualification
  • Contract negotiation price, schedule
  • Supervise the vendors activities
  • Risk management

9
WATERFALL MODEL (1)
(Winston Roy 1970)
Requirement
10
WATERFALL MODEL (2)
(Winston Roy 1970)
  • Advantages
  • A better model than the primitive model
    code/fix
  • Recognize the need for feedback loops between
    stages.
  • Disadvantages
  • When requirements are huge, a project may never
    get into the design phase before deadline.
  • Does not reference prototyping activities.

11
V-SHAPE DEVELOPMENT PROCESS
12
DEVELOPING PROCESS
REQUIREMENT, CONFIGURATION AND RISK MANAGEMENT
Requirements specification approved by customer
Integration planning
UT planning
High level design
Detail design
Unit testing
Subsys testing
Code review
Coding
Integration
System test planning
System testing
FAT
Warranty
Installation
Document
13
CODE INSPECTION AND UNIT TEST
Design
Coding
Unit Test Plan
Code Inspection
Unit Test Plan
System Integration
14
CHANGE CONTROL
New change requests or stars
ARCHIEVE
Change Control Board (CCB)
N
REDO
Initial Investigation
DONE
N
Design Modification
N
Y/N
Local Test Regression Test
Fix Delivery CLOSE
Estimation
Y/N
N
N
Y/N
Feasibility Study
Fix DONE
15
SPIRAL MODEL (1)
Cumulative cost
(Barry Boehm 1988)
Risk-Driven and Incremental Model
Progress through steps
Determine objectives, Alternative, constraints
Risk analysis
Evaluate alternatives Identify, resolve risks
Risk analysis
Risk analysis
Operational prototype
Prototype
Prototype
Prototype
Commitment Partition
Requirements plan lifecycle plan
Concept of operation
Software requirement
Development plan
Requirement validation
Code
Software product design
Unit test
Design validation and verification
Integration and test plan
Integration and test
Acceptance test
Develop, verify Next-level product
Plan next phases
Implementation
16
SPIRAL MODEL (2)
(Barry Boehm 1988)
Risk-Driven and Incremental Prototype Model
  • It works for large projects with complicated
    requirements that can be divided into phases
  • It is driven by a series of risk-driven prototype
    followed by a structured waterfall-like process
  • Multiple feedback opportunities with the users
    and customers to get Yes. Buts out early

17
ITERATIVE MODEL (1)
(Krutchten 1995)
Inception
Elaboration
Construction
Transition
Prelim Iteration

Arch Iteration

Dev Iteration
Dev Iteration

Trans Iteration

Release
Release
Release
Release
Alpha Release
Beta Release
Product Release
Inception focus on understanding the business of
the project, project scope and feasibility
define estimated schedule, budget, risk the
Vision document is created. Elaboration Refine
the requirements, executable architecture early
prototype(s) is developed and demonstrated for
validation. Construction focus on
implementation, architecture and design are fully
developed most of code are done. Transition
alpha, beta (testing) releases are done and
deployed for use internally or by customers.
18
ITERATIVE MODEL (2)
Inception
Elaboration
Construction
Transition
Process Workflow
Requirement
Analysis/design
Implementation
Test
Deployment
Supporting Workflow
Configuration Change Management
Project process Management
19
ITERATIVE MODEL (3)
THE DOOD PROJECT
Inception Theory and Concept Group
  • Deductive Object-Oriented Database
  • Based on Predicate Logic
  • Support recursion
  • Data,rules,queries are in the same format

Elaboration Design Group
Construction Development Group
P (manager, employ) select P1(manager), P2
(employee) from P1 as P , P2 as P where
P1.employee P2 (manager) P (manager m,
employee e) -gt P1 (m, e) P (manage m, employee
e) and P (manager e, employee x) -gt P1 (m, x)
Transition Release Group
Alpha
Beta
20
M-GATE PROCESS
MARKET INTELLIGENCE AND ANALYSIS PHASE
MPP Market Product Planning
SPD System Product Development
M-Gate 15
M-Gate 14
M-Gate 13
M-Gate 12
M-Gate 11
M-Gate 10
M-Gate 9
M-Gate 8
M-Gate 7
M-Gate 6
M-Gate 5
M-Gate 4
M-Gate 3
M-Gate 2
M-Gate 1
M-Gate 0
Project Definition Phase
Implementation Phase
Launch Closeout Phase
Business Case Development Phase
Portfolio Planning Phase
The Market and Product Planning (MPP) M-Gates,
M-15 through M-11, address the Market
Intelligence and Analysis, Business Case
Development, and Portfolio Planning phase of the
Marketing Activities associated with candidate
project. The MPP M-Gates result in the
development of a Business Solution. This
Solution is transitioned to the System and
Product Development (SPD) Project M-Gates
activities of Project Definition, Implementation,
Launch and Close out.
21
M-GATE BUSINESS OBJECTIVES
  • M-Gates defines a set of requirements that must
    be satisfied by all proposed solutions from
    different sectors/business units enabling the
    selection of cross-sector solutions that are the
    best fit for the company and its customers.
  • Clearly define roles and responsibilities that
    are cross-sector and cross-functional to enable
    efficient and sound decision-making.
  • Clearly identified and documented M-Gate
    decisions that allow all sectors and business
    units to understand why certain solutions are
    selected and why others are not, which helps
    sectors understand the overall strategy of the
    company.

22
SPD M-GATE PROCESS (1)
23
SPD M-GATE PROCESS (2)
Project Definition Phase (M-Gate 10 M-Gate
7) Deliverables Project Plan, Engineering Plan,
Quality Assurance Plan, Requirement Plan,
Requirement Specification, System
Architecture Key Note These deliverables are
base lined in a formal contract book that defined
the projects commitment to deliver the specified
system, product or platform within the identified
schedule and cost targets.
Implementation Phase (M-Gate 7
M-Gate3) Deliverables Integration Test Plan,
High Level Design, Low Level Design, Code, Unit
Test Plan, Test Reports Key Notes These
deliverables are the design, implementation, the
implementation, and validations of the product
according to the allocated requirements. Each
performing team organization may have its own
unique development lifecycle for this phase.
Launch Closeout Phase (M-Gate3 M-Gate
0) Deliverables Final Acceptance Report, User
Manual, Operation Manuals Key Notes All required
sources, manufacturing, sales, customer services,
and marketing process are in-place for volume
production until a trigger is activated for the
retirement or the the product. If the product
is a system, the deliverable signals the end of
the project and maintenances/services process
begin.
24
SPD M-GATE PROCESS (3)
Complete -- all applicable requirements and
associated criteria have been evaluated and are
completed
In Progress -- not all of the applicable
requirements and criteria have been completed,
the project has not deviated from the inter
  • A risk assessment has been performed and an
    action plan developed, with owners, complete with
    triggers and final due dates that are tracked at
    a solution level. The review board at the
    specific M-Gate will approve these action plans,
    complete execution or which is required for final
    completion of the gate or
  • Activities are in progress, and on target but
    not enough to satisfy gate completion

Significant Issues -- this status arises when the
project is deviating from the intent (e.g.,
critical success factors, schedule etc) and this
condition can occur due to one or a combination
of reasons
  • Majority of the requirements and criteria have
    not been completed
  • Associated action plans are incomplete
  • Factors or influences external to the project are
    impacting the project to an unacceptable extent
  • To proceed with the current status would incur
    unacceptable risk
  • Not started or late

No Issues not started yet
25
M-GATE IN SPIRIL LIFECYCLE MODEL
Gate 3
Gate 2
Gate 0
Gate 1
Volume Development
Retirement Plan Approved
End of Life
Ready Ror Controlled Information
Gate 4
Ready for Field Test
Contract Book Baselined Approved
Launch Closeout Phase
Gate 10
Gate 9
Gate 7
Gate 8
Project Definition
System Req Baselined
System Req Allocated
System Validation verification
Definition Phase
Start
Gate 5
System Test Readiness
Next Level Requirement
Design Implementation Subsystem Integration
Evaluation
Gate 6
System Design Readiness
26
LINEAR CHAN FOR MULTIPLE PRODUCT GENERATIONS
Write a Comment
User Comments (0)
About PowerShow.com