3. planning & processes the life cycle of a large system integration project
TRANSCRIPT
3. PLANNING & PROCESSES 3. PLANNING & PROCESSES 3. PLANNING & PROCESSES 3. PLANNING & PROCESSES
The Life Cycle of A Large System Integration Project The Life Cycle of A Large System Integration Project The Life Cycle of A Large System Integration Project The Life Cycle of A Large System Integration Project
PLANNINGPLANNING
Unit Test PlanUnit Test Plan
ObjectivesMethod
Schedule
IntegrationTest Plan
IntegrationTest Plan
ObjectivesMethod
Schedule
Internal ExternalRequirementsRequirements
SRSSRS
SubcontractPlan
SubcontractPlan
MaterialPlan
MaterialPlan
BudgetScheduleCriteria
BudgetSchedule
Project PlanProject PlanScheduleResource
RiskEngineering
Plan
EngineeringPlan
SolutionMethod
KickoffKickoff
Team/Resource plan
Schedule
QA PlanQA Plan
CriteriaProcedure
Doc qualityRequirementverification
ObjectivesParticipants
Schedule
RequirementPlan
RequirementPlan
Design Design DocsDocs
BudgetPaymentScheduleResource
Risk
Program PlanProgram Plan
ContractContractBid, RefBid, Ref
PROGRAM PLANPROGRAM PLAN
BASE DOCUMENTS:BASE DOCUMENTS: BID PROPOSAL: solutionCONTRACT: what we promised, schedule, priceREFERENCES: estimation and document format
TEAM:TEAM: Program Manager, Contract ManagerChief Engineers
OUTPUT:OUTPUT:PROGRAM PLAN, reviewed by AQ and approved by business director
KEY CONTENTS:KEY CONTENTS:Objectives and reference projectsScope and process SelectionBudget: Material (LAB), manpower, Travel cost
Payment schedule and Cash flowSkill set and manpower distributionContract & subcontractor managementQuality ControlRISK management (program level:emergency plan)Project and review schedule and milestoneCustomer visit planContract Book structure
ENGINEERING PLANENGINEERING PLAN BASE DOCUMENTS:BASE DOCUMENTS:
BID PROPOSAL: solutionCONTRACT: what we promised
PROGRAM PLAN: scheduleREFERENCES: experiences and document format
• OUTPUT:OUTPUT:ENGINEERING PLAN, Reviewed by QA and approved by Program Manager and Engineer Manager
• TEAM:TEAM:Chief Engineer, Network Engineer, Software Engineer
KEY CONTENTS:KEY CONTENTS:High level overview
System architectureSoftware architectureSystem operation
Technology and PrototypeTasks and quality control in every step of the process: requirement to acceptance testIntegration test methodologyDevicesCMMI execution planSubcontract items listMajor material selection
PROJECT PLANPROJECT PLAN
BASE DOCUMENTS:BASE DOCUMENTS:
PROGRAM PLAN: schedule, manpower, ENGINEERING PLAN: solution, REFERENCES: experiences and document
OUTPUT:OUTPUT:PROJECT PLAN, reviewed by QA and approved by Program Manager
TEAM:TEAM:Project Manager, Program Manager, Chief Engineers
KEY CONTENTS:KEY CONTENTS:ScheduleSkill set and manpower managementProcess executionLab establishmentMilestone (deliverable) managementRisk managementRequirement managementRelation with other functions: QA, PM, Monthly and weekly report plan
REQUIREMENT PLANREQUIREMENT PLAN
BASE DOCUMENTS:BASE DOCUMENTS:
PROJECT PLAN: schedule ENGINEERING PLAN: solution, REFERENCES: experiences and document
OUTPUT:OUTPUT:REQUIREMENT PLAN, reviewed by QA and approved by Project Manager
TEAM:TEAM:Engineers, Chief Engineer, Project Manager
KEY CONTENTS:KEY CONTENTS:ScheduleQuestionnaires for all parts
CONTRACT MANAGEMENTCONTRACT MANAGEMENT
Contract manager is specialized in contract execution and has legal background and sufficient knowledge of company’s charging structure.
When risks caused by customers, he/she must evaluate the impact and estimate it’s 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.
SUBCONTRACT MANAGEMENTSUBCONTRACT 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 vendor’s activities
Risk management
WATERFALL MODEL (1)WATERFALL MODEL (1)
RequirementRequirement
Operation Operation &&
maintenancemaintenance
System System IntegrationIntegration
Coding Coding & &
unit testunit test
DesignDesign
(Winston Roy 1970)
WATERFALL MODEL (2)WATERFALL MODEL (2)
Advantages:Advantages:• A better model than the primitive model: code/fix • Recognize the need for feedback loops between stages.
Disadvantages:Disadvantages:• When requirements are huge, a
project may never get into the design phase before deadline.
• Does not reference prototyping activities.
(Winston Roy 1970)
V-SHAPE DEVELOPMENT PROCESSV-SHAPE DEVELOPMENT PROCESS
Operation Operation &&
maintenancemaintenance
Operation Operation &&
maintenancemaintenance
Coding Coding & &
unit testunit test
Coding Coding & &
unit testunit test
RequirementRequirementRequirementRequirement
DesignDesignDesignDesign
System System IntegrationIntegration
System System IntegrationIntegration
Test PlanTest PlanTest PlanTest Plan
Test ModelTest ModelTest ModelTest Model
Test CaseTest CaseTest CaseTest Case
Test DataTest DataTest DataTest Data
DEVELOPING PROCESSDEVELOPING PROCESS
Requirementsspecificationapproved by
customer
Detaildesign
Unittesting
Subsystesting
Integration
Integrationplanning
System testplanning
Warranty Installation
FATSystemtesting
UTplanning
Codereview
Coding
REQUIREMENT, CONFIGURATION AND RISK MANAGEMENT
Document
High leveldesign
CODE INSPECTION AND UNIT TESTCODE INSPECTION AND UNIT TEST
Unit TestUnit TestPlanPlan
Unit TestUnit TestPlanPlan
Coding Coding Coding Coding
CodeCodeInspectionInspection
CodeCodeInspectionInspection
Unit TestUnit TestPlanPlan
Unit TestUnit TestPlanPlan
DesignDesignDesignDesign
System System IntegrationIntegration
System System IntegrationIntegration
CHANGE CONTROLCHANGE CONTROLCHANGE CONTROLCHANGE CONTROL
Change Control BoardChange Control Board(CCB)(CCB)
Change Control BoardChange Control Board(CCB)(CCB)
Initial Investigation
Estimation
FeasibilityStudy
Design &Modification
Local Test &Regression Test
Fix DONE
Y/N
Y/N Y/N
DONE
Fix Delivery& CLOSE
New change requests or stars
N
N N
N
ARCHIEVEARCHIEVE
REDO
N
SPIRAL MODEL (1)
SPIRAL MODEL (1)
Riskanalysis
Riskanalysis
Riskanalysis
Progress through steps
Evaluate alternativesIdentify, resolve risks
Prototype
Softwareproductdesign
Operational
prototype
Design validationand verification
CodeUnittest
Integ
ratio
n
and te
st
Accep
tance
test
Implem
enta
tion
Integrationand test plan
Developmentplan Requirement
validation
CommitmentPartition Requirements plan
lifecycle plan
Plan next phasesDevelop, verifyNext-level product
Determine objectives,Alternative, constraints
Softwarerequirement
Prototype
Concept ofoperation
Prototype
Cumulativecost
(Barry Boehm 1988)
Risk-Driven and Incremental Model
SPIRAL MODEL (2)
SPIRAL MODEL (2)(Barry Boehm 1988)
Risk-Driven and Incremental Prototype ModelRisk-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
ITERATIVE MODEL (1)
ITERATIVE MODEL (1)
Inception Elaboration Construction Transition
PrelimIteration
…Arch
Iteration…
DevIteration
DevIteration
…Trans
Iteration…
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.
Release Release Release Release AlphaRelease
BetaRelease
ProductRelease
(Krutchten 1995)
ITERATIVE MODEL (2)
ITERATIVE MODEL (2)
Inception Elaboration Construction Transition
Process WorkflowProcess Workflow
Requirement
Analysis/design
Implementation
Test
Deployment
Supporting WorkflowSupporting Workflow
ConfigurationChange Management
Project & processManagement
ITERATIVE MODEL (3)
ITERATIVE MODEL (3)
ConstructionDevelopment Group
ElaborationDesign Group
InceptionTheory and Concept Group
TransitionRelease Group
THE DOOD PROJECTTHE DOOD PROJECTDeductive Object-Oriented Database
• Based on Predicate Logic• Support recursion• Data, rules, queries are in the sam
e format
Alpha Beta
P (manager, employ)
select P1(manager), P2 (employee)from P1 as P , P2 as Pwhere P1.employee = P2 (manager);
P (manager m, employee e) -> P1 (m, e) ;P (manage m, employee e) and P (manager e, employee x) -> P1 (m, x);
M-GATE PROCESSM-GATE PROCESS
M-G
ate 15 M
-Gate
14 M-G
ate 13 M
-Gate
12 M-G
ate 11 M
-Gate
10 M-G
ate 9 M
-Gate
8 M-G
ate 7 M
-Gate
6 M-G
ate 5 M
-Gate
4 M-G
ate 3 M
-Gate
2 M-G
ate 1 M
-Gate
0
MPPMPPMarket Product PlanningMarket Product Planning
SPDSPDSystem Product DevelopmentSystem Product Development
Project DefinitionPhase
ImplementationPhase
Launch & CloseoutPhase
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.
Business CaseDevelopment
Phase
PortfolioPlanning
Phase
MARKET INTELLIGENCE AND ANALYSIS PHASE
M-GATE BUSINESS OBJECTIVESM-GATE BUSINESS OBJECTIVES
M-Gates defines a set of requirements that must be satisfied by M-Gates defines a set of requirements that must be satisfied by all proposed solutions from different sectors/business units all proposed solutions from different sectors/business units enabling the selection of cross-sector solutions that are the best enabling the selection of cross-sector solutions that are the best fit for the company and its customers.fit for the company and its customers.
Clearly define roles and responsibilities that are cross-sector Clearly define roles and responsibilities that are cross-sector and cross-functional to enable efficient and sound decision-and cross-functional to enable efficient and sound decision-making.making.
Clearly identified and documented M-Gate decisions that allow Clearly identified and documented M-Gate decisions that allow all sectors and business units to understand why certain all sectors and business units to understand why certain solutions are selected and why others are not, which helps solutions are selected and why others are not, which helps sectors understand the overall strategy of the company.sectors understand the overall strategy of the company.
SPD M-GATE PROCESS (1)SPD M-GATE PROCESS (1)
Contract Book
Baselined
& Approved
System
Requirement
Allocated
System
Requirement Baselined
Project
Initiation
M-Gate10
M-Gate9
M-Gate8
M-Gate7
Project Definition PhaseProject Definition Phase
Ready For
Controlled
Introduction
Ready For
Field Test
System Test
Readiness
Design
Readiness
M-Gate6
M-Gate5
M-Gate4
M-Gate3
Implementation PhaseImplementation Phase
End of LifeRetirement
Plan
Volume
Development
M-Gate5
M-Gate4
M-Gate3
Launch & Closeout PhaseLaunch & Closeout Phase
SPD M-GATE PROCESS (2)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 ArchitectureKey Note: These deliverables are base lined in a formal contract book that defined the project’s
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 ReportsKey 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 ManualsKey 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.
SPD M-GATE PROCESS (3)SPD M-GATE PROCESS (3)
Complete -- all applicable requirements and associated criteria have been evaluated and are completed
• 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
In Progress -- not all of the applicable requirements and criteria have been completed, the project has not deviated from the inter
M-GATE IN SPIRIL LIFECYCLE MODEL
M-GATE IN SPIRIL LIFECYCLE MODEL
Gate 10 Gate 9
Definition PhaseDefinition Phase
Gate 7Gate 8Project
DefinitionSystem ReqBaselined
System ReqAllocated
Contract BookBaselined &Approved
System Validation&verification
System TestReadiness
Gate 5
System DesignReadiness
Gate 6
Ready forField Test
Gate 4
Start
Next LevelRequirement
Design ImplementationSubsystem Integration& Evaluation
Gate 3 Gate 2
Launch & Closeout PhaseLaunch & Closeout Phase
Gate 0Gate 1Volume
DevelopmentRetirement
PlanApproved
End of
Life
Ready RorControlled
Information
LINEAR CHAN FOR MULTIPLE PRODUCT
GENERATIONS
LINEAR CHAN FOR MULTIPLE PRODUCT
GENERATIONS
Gate 10 Gate 7 Gate 3 Gate 2
Definition Phase Implement Phase Launch & Closeout Phase
Gate 0Gate 1
Initial Product Development
Gate 10 Gate 7 Gate 3 Gate 2
Definition Phase Implement Phase Launch & Closeout Phase
Gate 0Gate 1
Product Enhancement