The Life Cycle of A Large System Integration

The Life Cycle of A Large System Integration Project 3. PLANNING & PROCESSES

Contract Bid, Ref Budget Payment Schedule Resource Risk Program Plan Schedule Resource Risk Project Plan Criteria Procedure Doc quality Requirement verification Internal PLANNING Design Docs Solution Method QA Plan Engineering Plan Kickoff Budget Schedule Criteria Budget Schedule Subcontract Plan Material Plan Requirement Plan Integration Test Plan Objectives Participants Schedule Objectives Method Schedule Unit Test Plan External Team/ Resource plan Schedule Requirements SRS Objectives Method Schedule

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 Quality Control RISK management (program level: emergency plan) Project and review schedule and milestone Customer visit plan Contract Book structure

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 Tasks and quality control in every step of the process: requirement to acceptance test Integration test methodology Devices CMMI execution plan Subcontract items list Major material selection

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 Relation with other functions: QA, PM, Monthly and weekly report plan

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

CONTRACT 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 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) (Winston Roy 1970) Requirement Design Coding & unit test System Integration Operation & maintenance

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.

V-SHAPE DEVELOPMENT PROCESS Requirement Test Plan Test Model Test Case Test Data Design Coding & unit test System Integration Operation & maintenance

DEVELOPING PROCESS REQUIREMENT, CONFIGURATION AND RISK MANAGEMENT Integration planning Requirements specification approved by customer High level design UT planning Detail design Coding Code review Unit testing Subsys testing Integration System test planning FAT Warranty Installation Document System testing

CODE INSPECTION AND UNIT TEST Design Coding Unit Test Plan Code Inspection Unit Test Plan System Integration

New change requests or stars CHANGE CONTROL ARCHIEVE N Change Control Board (CCB) REDO Initial Investigation N DONE Local Test & Regression Test Fix Delivery & CLOSE Y/N Estimation N Design & Modification Y/N Feasibility Study N Y/N Fix DONE N

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 al ion at e er typ Op oto pr Risk analysis Prototype Commitment Partition Requirements plan lifecycle plan Development plan Integration and test plan Concept of operation Software requirement Requirement validation Software product design Design validation and verification n io at t n Plan next phases e Im em pl ce Ac st te e nc a pt n tio a gr t te es In d t an Unit test Code Develop, verify Next-level product

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

ITERATIVE MODEL (1) (Krutchten 1995) Inception Prelim Iteration … Release Elaboration Arch Iteration Construction … Dev Iteration Release Transition … Trans Iteration 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.

ITERATIVE MODEL (2) Inception Process Workflow Requirement Analysis/design Implementation Test Deployment Supporting Workflow Configuration Change Management Project & process Management Elaboration Construction Transition

ITERATIVE MODEL (3) THE DOOD PROJECT Inception Theory and Concept Group Deductive Object-Oriented Database • • • Elaboration Design Group Based on Predicate Logic Support recursion Data，rules，queries are in the same format Construction Development Group P (manager, employ) select P 1(manager), P 2 (employee) from P 1 as P , P 2 as P where P 1. employee = P 2 (manager); P (manager m, employee e) -> P 1 (m, e) ; P (manage m, employee e) and P (manager e, employee x) -> P 1 (m, x); Transition Release Group Alpha Beta

M-GATE PROCESS MARKET INTELLIGENCE AND ANALYSIS PHASE MPP SPD Market Product Planning System Product Development M-Gate 0 M-Gate 1 M-Gate 2 M-Gate 3 Implementation Phase M-Gate 4 M-Gate 5 M-Gate 6 Project Definition Phase M-Gate 7 M-Gate 8 M-Gate 9 M-Gate 10 Portfolio Planning Phase M-Gate 11 M-Gate 12 M-Gate 13 M-Gate 14 M-Gate 15 Business Case Development Phase Launch & Closeout 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.

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

SPD M-GATE PROCESS (1) Project Definition Phase Project Initiation M-Gate 10 System Requirement Baselined System Requirement Allocated M-Gate 9 Contract Book Baselined & Approved M-Gate 8 M-Gate 7 Implementation Phase Design Readiness M-Gate 6 System Test Readiness Ready For Field Test M-Gate 5 M-Gate 4 Ready For Controlled Introduction M-Gate 3 Launch & Closeout Phase Volume Development M-Gate 5 Retirement Plan M-Gate 4 End of Life M-Gate 3

SPD M-GATE PROCESS (2) Project Definition Phase (M-Gate 10 – M-Gate 7) Deliverables: Project Plan, Engineering Plan, Quality Assurance Plan, Requirement Specification, System Architecture Key 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-Gate 3) 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-Gate 3 –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 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) 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 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

M-GATE IN SPIRIL LIFECYCLE MODEL Gate 3 Gate 10 Gate 9 Gate 8 Gate 1 Volume Retirement Ready Ror Plan Controlled Development Approved Information Gate 4 Contract Book Baselined & Approved Gate 2 Ready for Field Test Launch & Closeout Phase Gate 7 Project System Req Definition Baselined 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 Gate 0 End of Life

LINEAR CHAN FOR MULTIPLE PRODUCT GENERATIONS Initial Product Development Definition Phase Gate 10 Implement Phase Gate 7 Launch & Closeout Phase Gate 3 Gate 2 Gate 1 Gate 0 Product Enhancement Definition Phase Gate 10 Implement Phase Gate 7 Launch & Closeout Phase Gate 3 Gate 2 Gate 1 Gate 0