1 / 26

3. PLANNING & PROCESSES

This comprehensive guide outlines the key processes, documentation, and team roles required for the successful planning and execution of large system integration projects. It covers contract bidding, budgeting, resource allocation, risk management, design documentation, program planning, and more. Learn about the critical stages from contract proposal to project completion, including the roles of program managers, engineers, and quality assurance. Understand the importance of milestone management, requirement planning, and subcontractor oversight. Explore different project planning approaches and development methodologies such as Waterfall and V-Shape models. This guide empowers project managers and team members with the knowledge and tools needed to navigate complex system integration projects effectively.

weston
Download Presentation

3. PLANNING & PROCESSES

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Contract Bid, Ref Budget Payment Schedule Resource Risk Design Docs Program Plan Budget Schedule Criteria Solution Method Budget Schedule Subcontract Plan Material Plan Schedule Resource Risk Project Plan Engineering Plan Requirement Plan Integration Test Plan Criteria Procedure Doc quality Requirement verification Objectives Participants Schedule Objectives Method Schedule Kickoff QA Plan Unit Test Plan Team/ Resource plan Schedule Internal External Objectives Method Schedule Requirements SRS 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 • Quality Control • RISK management (program level:emergency plan) • Project and review schedule and milestone • Customer visit plan • Contract Book structure

  4. 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 ENGINEERING PLAN

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

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

  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 vendor’s activities • Risk management

  9. Design Coding & unit test System Integration Operation & maintenance 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. Requirement Test Plan Design Coding & unit test Test Model Test Case System Integration Operation & maintenance Test Data 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 Coding Code review Unit testing Subsys testing 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 N N Y/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 Integration and test plan Design validation and verification 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) -> P1 (m, e) ; P (manage m, employee e) and P (manager e, employee x) -> 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 Business Case Development Phase Portfolio Planning Phase Project Definition Phase Implementation 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.

  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. Project Definition Phase Project Initiation System Requirement Baselined System Requirement Allocated Contract Book Baselined & Approved M-Gate 10 M-Gate 9 M-Gate 8 M-Gate 7 Implementation Phase Design Readiness System Test Readiness Ready For Field Test Ready For Controlled Introduction M-Gate 6 M-Gate 5 M-Gate 4 M-Gate 3 Launch & Closeout Phase Volume Development Retirement Plan End of Life M-Gate 5 M-Gate 4 M-Gate 3 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 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 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, OperationManuals 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 1 Gate 0 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 8 Gate 7 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. Initial Product Development Definition Phase Implement Phase Launch & Closeout Phase Gate 10 Gate 7 Gate 3 Gate 2 Gate 1 Gate 0 Product Enhancement Definition Phase Implement Phase Launch & Closeout Phase Gate 10 Gate 7 Gate 3 Gate 2 Gate 1 Gate 0 LINEAR CHAN FOR MULTIPLE PRODUCT GENERATIONS

More Related