System Engineering Plan

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "System Engineering Plan"

Transcription

1 Project Documentation Document SPEC-0064 Revision A System Engineering Plan Rob Hubbard, Jeremy Wagner, Larry Daggert, Larry Stepp, Christoph Keller Systems Engineering / Project Management 5 October 2006 Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ Phone Fax

2 REVISION SUMMARY: 1. Date: 5 October 2006 Revision: A Changes: First release as a specification SPEC-0064, Revision A ii

3 Table of Contents Preface SYSTEMS ENGINEERING DESIGN REQUIREMENTS FLOW DOWN CONCEPTUAL DESIGNS INTERFACES ERROR BUDGETS STANDARDS SPECIFICATIONS DOCUMENTS PERFORMANCE MODELING QUALITY ASSURANCE PLAN ACCEPTANCE TEST PLANS INTEGRATION PLANS DOCUMENT CONTROL SYSTEMS ENGINEERING DELIVERABLES PROJECT STARTUP DELIVERABLES CONCEPTUAL DESIGN REVIEW DELIVERABLES PRELIMINARY DESIGN REVIEW DELIVERABLES CRITICAL DESIGN REVIEW DELIVERABLES SYSTEMS ENGINEERING DURING CONSTRUCTION AND IT&C CONFIGURATION MANAGEMENT AND CHANGE CONTROL QUALITY ASSURANCE AND QUALITY CONTROL PLAN EXECUTION INTEGRATION TEST AND COMMISSIONING SPEC-0064, Revision A iii

4 Preface The genesis of the first two sections of this document dates back to the writing of the ATST Design and Development proposal to the National Science Foundation. Its original title was Systems Engineering Deliverables. It has now been recast as part of a project specification (SPEC) document and designated the Systems Engineering Plan as it continues to accurately reflect systems engineering activities to date as well as those anticipated in the near future. Only a few minor changes have been made to the original document during this recasting, mostly modifying terminology slightly to maintain consistency with the nomenclature subsequently adopted by the ATST project. Section three of this document is new. It describes systems engineering during the construction phase, as the scope of the original Systems Engineering Deliverables was limited to the Design and Development phase of the project. The roles and responsibilities of systems engineering during the construction phase are summarized here, including references to other project documents that describe these aspects of systems engineering in detail. SPEC-0064, Revision A Page 1 of 11

5 1. SYSTEMS ENGINEERING Designing a facility as complex as the ATST requires concurrent engineering, i.e. the design and development activities must proceed in parallel. As the designs evolve, there must be continuous adjustment of requirements and rebalance of the interfaces between different subsystems. Also, during the design and development phase the project will need to prepare procedures and plans that will be required for the construction phase. To accomplish these goals in an efficient manner that ensures technical success and controls cost and schedule, the project will have a strong systems-engineering program. Systems engineering staff will work with project management, the scientific staff, and the other engineers to accomplish the activities described below. 1.1 DESIGN REQUIREMENTS FLOW DOWN The design of the ATST must meet the needs of the scientific programs for which the facility will be built. Systems engineering will support the scientific staff as they define system performance requirements in terms of image quality, field of view, control system interfaces, data management requirements, allowable downtime, specific needs of the scientific instruments, etc. These requirements will be developed into a formal Science Requirements Document 1. Systems engineering will then work with the scientists and engineers to flow down 2 these science requirements into the design requirements of individual subsystems, including the post-focus instruments. This flow down will occur over a period of time as the conceptual designs evolve, leading to a formal Design Specifications Document for each subsystem. 1.2 CONCEPTUAL DESIGNS Various conceptual designs of the facility already exist. These conceptual designs will be further refined during the initial phase of design and development. During this process, systems engineering will work with other engineering staff to develop a logical breakdown of the telescope into hardware and software subsystems with clearly defined interfaces 3. Error budgets will be developed to help define appropriate tradeoffs of cost vs. performance in each subsystem and to maximize the overall telescope performance within the allocated budget and schedule. 1.3 INTERFACES Project Management will set up a division of responsibilities for the project. Based on the conceptual designs, systems engineering will develop a matrix to define where interfaces exist between responsible groups. Then interface control documents (ICDs) will be developed for each interface 4. An ICD is an agreement, essentially a contract, between two or more groups in the project. It may be between two groups of project staff, or it may be between the project and a contractor or partner organization. The document must not only define the interface, but also identify who does what. Each ICD must be negotiated much like a contract would be. If a contractor will perform the work, the ICD becomes part of the contract. 1 SPEC-0001 The ATST Science Requirements Document, Rimmele, et al. 2 SPEC-0066 Requirements Flowdown, Rob Hubbard 3 ICD N 2 Chart 4 ICD Status Report SPEC-0064, Revision A Page 2 of 11

6 In general, ICDs cover optical, mechanical, electrical and software interfaces, as appropriate. All the ICDs for a given subsystem should be controlled by the time of the preliminary design review (PDR) for that subsystem. A formal revision process will be set up to control changes to the ICDs. There will often be situations where a change in an ICD affects the plans of several groups, including ones that may not have been part of the original agreement. Therefore, as changes in ICDs are required, it is important that these changes be communicated with all affected groups. In some cases, when an ICD is changed, a revision of schedules, budgets or error budgets may be required. 1.4 ERROR BUDGETS A number of error budgets will be required for this project 5. A preliminary list of potentially useful error budgets might include the following: image quality in various wavelength bands pointing and tracking accuracy scattered light instrumentally induced polarization The image quality error budgets will be among the key error budgets 6. The initial error budgets will be top-down budgets. They will divide up the allowable error into individual contributions and assign portions of the budget to each subsystem, based on educated guesses of performance feasibility. As the conceptual designs develop to the point that performance predictions can be made, the results of these analyses will be used to replace these values with bottom-up entries. As further understanding is gained about which aspects of the error budget are easy to attain and which are difficult, the error budgets will be adjusted in order to minimize costs and risks while still meeting performance requirements. 1.5 STANDARDS Systems engineering will work with the other engineering staff to develop hardware and software design standards, documentation standards 7, and standardized terminology 8. A simple example of a design standard is the need to define whether designs will be in English units or metric units. Standards will be developed for both hardware and software to ensure the use of common components, compatible subsystems, and a modular approach wherever possible. This is important to help control life-cycle costs for the facility. These include operating costs, maintenance costs such as staffing requirements and the quantity of spare parts required, and the cost to upgrade systems as new technology becomes available. Documentation standards will include standard drawing formats and file types, as well as standard templates for project documents such as ICDs, integration plans, etc. Systems engineering will also 5 SPEC-0009 ATST System Error Budgets, Rob Hubbard 6 DIQ CASE 1a, Diffraction Limited 500 nm; DIQ CASE 1b, Diffraction Limited 630 nm; DIQ CASE 2, Seeing Limited On-disk; DIQ CASE 3, Seeing Limited Coronal 7 SPEC-0002 Document Drawing and Control Plan, Ruth Kneale 8 SPEC-0012 Glossary and Acronym List, Ruth Kneale SPEC-0064, Revision A Page 3 of 11

7 compile a listing of standardized names and definitions. When writing ICDs or contracts it is very important that the terms used are clearly defined in a manner that is consistent across the entire project. 1.6 SPECIFICATIONS DOCUMENTS The engineering staff will develop a specification document for each subsystem, including each postfocus instrument. Systems engineering will coordinate these efforts and provide guidance on general requirements such as environmental conditions. The design specifications will cover subsystem performance, dimensional and weight limits, compatibility issues, reliability, maintainability, and environmental conditions. They will reference the appropriate ICDs. Where a contractor will perform the work, the specification document will be part of the contract. The specifications documents will be reviewed at a Systems Design Review which will be held during the preliminary design phase before the preliminary design review (PDR). At the preliminary design review and critical design review (CDR) for each subsystem, the designs will be judged against the requirements specified in the specifications documents 1.7 PERFORMANCE MODELING The engineering staff and contractors will develop analytical models to predict the performance of the subsystems of the telescope and the post-focus instruments. Systems engineering will coordinate these efforts and to the extent possible will integrate these analyses to provide end-to-end modeling of the total system performance. These analyses will be repeated as the designs develop to provide improved performance predictions and to allow adjustments in error budgets, interfaces, and design requirements. 1.8 QUALITY ASSURANCE PLAN The quality assurance plan 9 will define quality control procedures to be used in the construction phase of the project to ensure manufactured and purchased parts meet specified requirements. The subjects covered in the quality assurance plan will include: configuration control procedures for drawings, DRDs, and ICDs used for the fabrication of parts or subassemblies procedures for incoming inspection of purchased parts to ensure they meet specifications procedures for identification and control of parts in inventory requirements to be imposed on contractors who are manufacturing parts or subassemblies for the project Each contract will be required to have its own quality assurance plan that meets project guidelines 10. The contractor s quality assurance plan will cover: acceptance test plans; inspection methods and calibration of inspection equipment disposition of discrepant parts traceability of critical materials 9 SPEC-0025, ATST Quality Assurance and Quality Control Plan, Rob Hubbard 10 SPEC-0065, QA/QC Requirements, Mark Warner and Rob Hubbard SPEC-0064, Revision A Page 4 of 11

8 The project quality assurance plan will be written by systems engineering, with technical assistance from other engineering staff. 1.9 ACCEPTANCE TEST PLANS During the construction phase, each contractor will be required to prepare an acceptance test plan that will ensure that the part or subsystem it manufactures will comply with the requirements specified in the contract. Among other things, the acceptance test plan will define tests and inspections to ensure: compliance with all dimensional and tolerance accuracies, surface properties, weld qualities, material qualities and coatings proper form, fit and alignment of all components compliance with all interface requirements including weight limits test procedures verification of requirements on operating conditions such as power dissipation, electromagnetic compatibility or vibration levels The contractor will submit its acceptance test plan to the project for approval in advance. In addition, project staff will develop acceptance test plans for any subassemblies or equipment items that will be manufactured or assembled under their supervision. Systems engineering will work with the engineering staff to define standards for the acceptance test plans, review plans submitted by contractors, and develop acceptance test plans for any subassemblies produced by the project INTEGRATION PLANS Carefully prepared plans will be needed to guide the integration of subassemblies into the complete ATST facility 11. For each subassembly or separate piece of equipment a formal integration plan will be prepared. The integration plans will cover: required equipment and tools safety precautions for personnel and equipment step-by-step procedures to define the proper sequence of tasks test procedures to verify that the subassembly is functioning properly time estimates of tasks required Systems engineering will work with project staff to develop these integration plans during the latter portion of the design and development phase DOCUMENT CONTROL Systems engineering will coordinate the collection and control of technical documents, including: Science Requirements Document Interface Control Documents Specifications Documents 11 SPEC-0038 ATST Commissioning Plan, Eric Hansen SPEC-0064, Revision A Page 5 of 11

9 Error Budgets Technical Reports Drawings Quality Assurance Plan Acceptance Test Plans Integration Plans In addition to the responsible engineer and engineering manager, systems engineering will sign approval for release and revision of: Interface Control Documents Specifications Documents Drawings Quality Assurance Plan Acceptance Test Plans Integration Plans Systems engineering will also coordinate the collection and control of documents required for reviews. The following is a possible document set required for ATST reviews. This set should also be created for every major system (telescope, each instrument, facility) review. Every subsystem should have the same document set (and associated review) if possible, especially if the plan includes sending the design or the development out for contract. A. Design Review Generated Documents 1. Introduction/Committee/Charge/List of Deliverables 2. Design Review Product Overview 3. Committee Report 4. Response to the Committee B. Systems Engineering Deliverables 1. Design Requirements Document (final at CoDR) 2. Interface Control Documents (final at PDR) 3. Test Plan and Procedures (final at CDR) 4. Error Budgets (final at CDR) C. Engineering Team Deliverables 1. Design Document (CoDR=Conceptual Design, PDR=Preliminary Design, CDR=Detailed Design) 2. Trade Studies 3. Prototypes D. Project Management Deliverables 1. Work Breakdown Schedule SPEC-0064, Revision A Page 6 of 11

10 2. System Development Plan 3. Budget E. Reference Materials (created at the beginning of the project) 1. Proposal 2. Science Case and Justification 3. Science Requirements 4. Documentation Standards and Templates 5. Systems Definition Document (w/interface Matrix) 6. Project Plan 7. Project Standards and Specifications SPEC-0064, Revision A Page 7 of 11

11 2. SYSTEMS ENGINEERING DELIVERABLES The following sections identify the specific deliverables required at the time specific project milestones are reached. 2.1 PROJECT STARTUP DELIVERABLES a nearly fully or fully developed Science Requirements document for the Instruments and Telescope define telescope system define instrument system define instruments/telescope interface define telescope subsystems define instruments subsystems outlines for Functional Performance Requirements Documents outlines for Interface Control Documents In order to accomplish the effort listed above by project startup, it is assumed a fulltime systems engineer is onboard and works closely with the project scientist and telescope scientist for four months prior to project start. Their efforts are supported by instrument scientists, as well as part-time support from an administrative assistant and optical, mechanical and controls engineers as required. 2.2 CONCEPTUAL DESIGN REVIEW DELIVERABLES a fully developed Science Requirements document Functional Performance Requirements Documents with traceable flow down of requirements from science to technical telescope and instrument systems and sub-systems defined standards for interchangeability of instruments standards for documentation and manuals outlines for Interface Control Documents top-down system error budgets initial hardware and software compatibility standards 2.3 PRELIMINARY DESIGN REVIEW DELIVERABLES a fully developed Science Requirements document Functional Performance Requirements Documents with traceable flow down of requirements from science to technical standards for interchangeability of instruments standards for documentation and manuals fully developed Interface Control Documents bottom-up system error budgets SPEC-0064, Revision A Page 8 of 11

12 hardware and software compatibility standards initial performance evaluations and their comparison to error budgets and science requirements 2.4 CRITICAL DESIGN REVIEW DELIVERABLES a fully developed Science Requirements document Functional Performance Requirements Documents with traceable flow down of requirements from science to technical Interface Control Documents system error budget standards for interchangeability of instruments standards for documentation and manuals hardware and software compatibility standards performance evaluations and their comparison to error budgets and science requirements SPEC-0064, Revision A Page 9 of 11

13 3. SYSTEMS ENGINEERING DURING CONSTRUCTION AND IT&C During the construction and integration test and commissioning phases, systems engineering plays critical roles in several areas. The systems engineering group during this period is part of the Project Management Office. The specific roles and responsibilities within various areas are described in the sections that follow. 3.1 CONFIGURATION MANAGEMENT AND CHANGE CONTROL Systems engineering will continue to be responsible for configuration management and change control as outlined in SPEC-0002 and SPEC-0040 respectively. The systems engineer will also serve on the change control board with the project manager, the project scientist, and the project director. This group will be expanded to include the lead IT&C systems engineer during IT&C, and the operations scientist and operations manager as commissioning transitions to operations. 3.2 QUALITY ASSURANCE AND QUALITY CONTROL PLAN EXECUTION The details of executing the quality assurance and quality control plan are described in the document SPEC-0025_QAQC. In summary, systems engineering will assume responsibility for overall compliance with QA/QC plans, including acceptance testing. In support of this, systems engineering will also refine, and continuously maintain and rebalance the error budgets for the ATST system as required, initiating change orders if necessary. The error budget document (SPEC-0009) will be kept up to date by systems engineering as changes are made. The specific requirements that will be placed on contractors and vendors are outlined in SPEC- 0065_QAQC_Requirements. Systems engineering will work with the contract officer s technical representative (COTR) to enforce these requirements within each contract, with the systems engineer having ultimate responsibility for compliance. 3.3 INTEGRATION TEST AND COMMISSIONING The details of the IT&C plan are described in SPEC-0038, the ATST Commissioning plan. In summary, the goal of the integration, test and commissioning (IT&C) stage of construction is to convert a series of subsystems into a single instrument capable of delivering high quality science as specified in the ATST Science Requirements Document (SRD) and Operational Concepts Definition Documents (OCDDs) then verified by both commissioning tests as well as a science verification program. As the commissioning period is limited, it is important that the tasks and sequence of commissioning be carefully planned and executed. IT&C begins when elements from two sources, separately contracted by ATST or provided by the Project are integrated on site. This event creates the potential for conflict in areas of facility access, support staff resources, etc. As the IT&C schedule progresses and more subsystems are being integrated into the observatory, the task of orchestrating and supporting these activities becomes more complex. The Project Manager will delegate responsibility for day-to-day activities of integration, testing and commissioning to systems engineering. To execute that responsibility the systems engineering group will be staffed with skills required to perform orchestration of on-site activities, systems testing and optimization, documentation and management reporting. There are three major categories of IT&C management responsibility that fall to systems engineering. They are the orchestration of on site activities, tracking of observatory predicted performance, and status reporting. There are four specific commissioning deliverables: On site acceptance test documentation for all subsystems SPEC-0064, Revision A Page 10 of 11

14 Integration procedures and reports System calibration procedures and reports System performance Optimization procedures and report SPEC-0064, Revision A Page 11 of 11

REQUEST FOR PROPOSALS (RFP) N60354C For GEMINI Instrument Upgrades: Small Projects. RFP Main Document (IUSP-01)

REQUEST FOR PROPOSALS (RFP) N60354C For GEMINI Instrument Upgrades: Small Projects. RFP Main Document (IUSP-01) REQUEST FOR PROPOSALS (RFP) N60354C For GEMINI Instrument Upgrades: Small Projects RFP Main Document (IUSP-01) ASSOCIATION OF UNIVERSITIES FOR RESEARCH IN ASTRONOMY, INC OPERATING THE GEMINI OBSERVATORY

More information

Criteria for Flight Project Critical Milestone Reviews

Criteria for Flight Project Critical Milestone Reviews Criteria for Flight Project Critical Milestone Reviews GSFC-STD-1001 Baseline Release February 2005 Approved By: Original signed by Date: 2/19/05 Richard M. Day Director, Independent Technical Authority

More information

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > Date of Issue: < date > Document Revision #: < version # > Project Manager: < name > Project Management Plan < Insert Project Name > Revision History Name

More information

Appendix 2-A. Application and System Development Requirements

Appendix 2-A. Application and System Development Requirements Appendix 2-A. Application and System Development Requirements Introduction AHRQ has set up a Distributed Systems Engineering Lab (DSEL) to support all internal development efforts and provide a facility

More information

CDC UNIFIED PROCESS JOB AID

CDC UNIFIED PROCESS JOB AID CDC UNIFIED PROCESS JOB AID Independent Verification & Validation Activities Document Purpose This Job Aid is a brief document listing the items to be noted, checked, remembered, and delivered when completing

More information

Career Tracks- Information Technology Family

Career Tracks- Information Technology Family Career Tracks- Information Technology Family FUNCTIONAL AREA Applications Programming AV IT AV IT Engineering Bioinformatics Involved in the development of server/os/desktop/mobile applications and services

More information

PM Planning Configuration Management

PM Planning Configuration Management : a Project Support Function As stated throughout the Project Planning section, there are fundamental components that are started during the pre-performance stage of the project management life cycle in

More information

What methods are used to conduct testing?

What methods are used to conduct testing? What is testing? Testing is the practice of making objective judgments regarding the extent to which the system (device) meets, exceeds or fails to meet stated objectives What the purpose of testing? There

More information

Ch.2 Logistics System Engineering.

Ch.2 Logistics System Engineering. Part 1 : System Management. Ch.2 Logistics System Engineering. Edited by Dr. Seung Hyun Lee (Ph.D., CPL) IEMS Research Center, E-mail : lkangsan@iems.co.kr Definition of System. Definition of System An

More information

074-8432-552 Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements

074-8432-552 Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements Page 1 of 7 Software Supplier Process Requirements 1.0 QUALITY SYSTEM FRAMEWORK 1.1 QUALITY POLICY The Seller shall document and implement a quality program in the form of Quality manual or detailed Quality

More information

Partnering for Project Success: Project Manager and Business Analyst Collaboration

Partnering for Project Success: Project Manager and Business Analyst Collaboration Partnering for Project Success: Project Manager and Business Analyst Collaboration By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP,

More information

Introduction and Overview

Introduction and Overview Introduction and Overview Definitions. The general design process. A context for design: the waterfall model; reviews and documents. Some size factors. Quality and productivity factors. Material from:

More information

System/Data Requirements Definition Analysis and Design

System/Data Requirements Definition Analysis and Design EXECUTIVE SUMMARY This document provides an overview of the Systems Development Life-Cycle (SDLC) process of the U.S. House of Representatives. The SDLC process consists of seven tailored phases that help

More information

DATA REQUIREMENTS DESCRIPTION (DRD)

DATA REQUIREMENTS DESCRIPTION (DRD) DATA REQUIREMENTS DESCRIPTION (DRD) 1. DPD NO.: XXX ISSUE: Draft 2. DRD NO.: STD/EDAL 3. DATA TYPE: 3 4. DATE REVISED: 5. PAGE: 1/3 6. TITLE: Engineering Drawings and Associated Lists 7. DESCRIPTION/USE:

More information

<name of project> Software Project Management Plan

<name of project> Software Project Management Plan The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor

More information

Development, Acquisition, Implementation, and Maintenance of Application Systems

Development, Acquisition, Implementation, and Maintenance of Application Systems Development, Acquisition, Implementation, and Maintenance of Application Systems Part of a series of notes to help Centers review their own Center internal management processes from the point of view of

More information

Product Development and Commercialization Lifecycle

Product Development and Commercialization Lifecycle Product Development and Commercialization Lifecycle TM Product Development Life Cycle Definition Phase TM 1. Product Alignment with Company Strategy and Roadmap 2. Competitive Analysis Lessons/feedback

More information

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost

More information

Develop Project Charter. Develop Project Management Plan

Develop Project Charter. Develop Project Management Plan Develop Charter Develop Charter is the process of developing documentation that formally authorizes a project or a phase. The documentation includes initial requirements that satisfy stakeholder needs

More information

STATEMENT OF WORK FOR DESIGN, FABRICATION, INTEGRATION AND TESTING OF THE TELESCOPE STRUCTURE SYSTEM TMT.STR.MGT.12.001.REL01

STATEMENT OF WORK FOR DESIGN, FABRICATION, INTEGRATION AND TESTING OF THE TELESCOPE STRUCTURE SYSTEM TMT.STR.MGT.12.001.REL01 STATEMENT OF WORK FOR DESIGN, FABRICATION, INTEGRATION AND TESTING OF THE TELESCOPE STRUCTURE SYSTEM TMT.STR.MGT.12.001.REL01 27 July, 2012 TMT.STR.TEC.12.001.DRF01 Page 2 of 13 Table of Contents 1. INTRODUCTION

More information

IT Project: System Implementation Project Template Description

IT Project: System Implementation Project Template Description 2929 Campus Drive Suite 250 IT Project: System Implementation Project Template Description Table of Contents Introduction... 2 Project Phases... 3 Initiation & Requirements Gathering Milestone... 3 Initiation

More information

Exhibit F. VA-130620-CAI - Staff Aug Job Titles and Descriptions Effective 2015

Exhibit F. VA-130620-CAI - Staff Aug Job Titles and Descriptions Effective 2015 Applications... 3 1. Programmer Analyst... 3 2. Programmer... 5 3. Software Test Analyst... 6 4. Technical Writer... 9 5. Business Analyst... 10 6. System Analyst... 12 7. Software Solutions Architect...

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

Best Practices Statement Project Management. Best Practices for Managing State Information Technology Projects

Best Practices Statement Project Management. Best Practices for Managing State Information Technology Projects State of Arkansas Office of Information Technology 124 W. Capitol Ave. Suite 990 Little Rock, AR 72201 501.682.4300 Voice 501.682.4020 Fax http://www.cio.arkansas.gov/techarch Best Practices Statement

More information

Project Management Manual Update 2006. Transportation Department City of Edmonton

Project Management Manual Update 2006. Transportation Department City of Edmonton Project Management Manual Update 2006 Transportation Department City of Edmonton Project Management Manual for Transportation Projects EXECUTIVE SUMMARY This document has been updated to fulfill the requirements

More information

Requirements Management John Hrastar

Requirements Management John Hrastar Requirements Management John Hrastar NASA Project Management Conference March 30-31, 2004 University of Maryland Conference Center Introduction Three aspects of requirements management Requirements in

More information

Project Management Planning

Project Management Planning Develop Project Tasks One of the most important parts of a project planning process is the definition of activities that will be undertaken as part of the project. Activity sequencing involves dividing

More information

Project Risk Management: IV&V as Insurance for Project Success

Project Risk Management: IV&V as Insurance for Project Success Project Risk Management: IV&V as Insurance for Project Success Introduction Software development projects can be expensive and risky: Ever more complex mission-critical requirements lead to increasingly

More information

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies content and format requirements for a Physical

More information

TfNSW Standard Requirements TSR T Technical Management

TfNSW Standard Requirements TSR T Technical Management Template Applicable to: Transport Projects Quality Management System Status: Division: Approved Transport Projects Version: 5.0 Desksite No.: 3455797_1 Date of issue: 1 July 2014 Effective date: 1 July

More information

Commercialization Life Cycle

Commercialization Life Cycle Commercialization Life Cycle Commercialization Phases Commercialization Checkpoints Definition Phase 1. Product Alignment with Company Strategy and Roadmap 2. Competitive Analysis Lessons/feedback from

More information

Program Lifecycle Methodology Version 1.7

Program Lifecycle Methodology Version 1.7 Version 1.7 March 30, 2011 REVISION HISTORY VERSION NO. DATE DESCRIPTION AUTHOR 1.0 Initial Draft Hkelley 1.2 10/22/08 Updated with feedback Hkelley 1.3 1/7/2009 Copy edited Kevans 1.4 4/22/2010 Updated

More information

CalMod Design-Build Electrification Services

CalMod Design-Build Electrification Services SECTION 01800 SYSTEMS INTEGRATION AND INTEGRATOR REQUIREMENTS PART 1 GENERAL DESCRIPTION A. This section specifies the system-wide integration requirements for the Caltrain Electrification system, i.e.

More information

CHAPTER 4 TYPES OF COST ESTIMATES

CHAPTER 4 TYPES OF COST ESTIMATES CHAPTER 4 TYPES OF COST ESTIMATES 1. INTRODUCTION All projects, both construction and environmental restoration, require cost estimates to plan and budget the project efficiently. Numerous estimates are

More information

C/KOSMOS Work Breakdown Structure Summary

C/KOSMOS Work Breakdown Structure Summary C/OSMOS Work Breakdown Structure Summary Version 2.3 January 13, 2011 Version Date Changes 1.8 November 19, 2009 Final version prior to issuing contract 1.9 December 8, 2009 Added documentation control

More information

CAREER TRACKS PHASE 1 UCSD Information Technology Family Function and Job Function Summary

CAREER TRACKS PHASE 1 UCSD Information Technology Family Function and Job Function Summary UCSD Applications Programming Involved in the development of server / OS / desktop / mobile applications and services including researching, designing, developing specifications for designing, writing,

More information

R000. Revision Summary Revision Number Date Description of Revisions R000 Feb. 18, 2011 Initial issue of the document.

R000. Revision Summary Revision Number Date Description of Revisions R000 Feb. 18, 2011 Initial issue of the document. 2 of 34 Revision Summary Revision Number Date Description of Revisions Initial issue of the document. Table of Contents Item Description Page 1. Introduction and Purpose... 5 2. Project Management Approach...

More information

Why do Project Fail? 42% 37% 27% 26% 24% 24% 0% 10% 20% 30% 40% 50% IBM Software Group Rational software. Source: AberdeenGroup, August 2006

Why do Project Fail? 42% 37% 27% 26% 24% 24% 0% 10% 20% 30% 40% 50% IBM Software Group Rational software. Source: AberdeenGroup, August 2006 Why do Project Fail? Unclear or continually changing product definitions Product does not meet customer or market requirements 37% 42% Unrealistic schedule expectations Projects not adequately staffed

More information

3SL. Requirements Definition and Management Using Cradle

3SL. Requirements Definition and Management Using Cradle 3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification

More information

Answers to Review Questions

Answers to Review Questions Tutorial 2 The Database Design Life Cycle Reference: MONASH UNIVERSITY AUSTRALIA Faculty of Information Technology FIT1004 Database Rob, P. & Coronel, C. Database Systems: Design, Implementation & Management,

More information

STATE BOARD OF ELECTIONS P.O. BOX 6486, ANNAPOLIS, MD 21401-0486 PHONE (410) 269-2840

STATE BOARD OF ELECTIONS P.O. BOX 6486, ANNAPOLIS, MD 21401-0486 PHONE (410) 269-2840 MARYLAND STATE BOARD OF ELECTIONS P.O. BOX 6486, ANNAPOLIS, MD 21401-0486 PHONE (410) 269-2840 Bobbie S. Mack, Chairman David J. McManus, Jr., Vice Chairman Rachel T. McGuckian Patrick H. Murray Charles

More information

Space Project Management

Space Project Management EUROPEAN COOPERATION FOR SPACE STANDARDIZATION Space Project Management Project Phasing and Planning Secretariat ESA ESTEC Requirements & Standards Division Noordwijk, The Netherlands Published by: Price:

More information

Fundamentals Engineering Drawing Practices

Fundamentals Engineering Drawing Practices ASME Y14.24: This Standard defines the types of engineering drawings most frequently used to establish engineering requirements. It describes typical applications and minimum content requirements. Drawings

More information

Space Flight Project Work Breakdown Structure

Space Flight Project Work Breakdown Structure APPENDIX G. (WBS) Space Flight Project Work Breakdown Structure G.1 Introduction G.1.1 The Project Work Breakdown Structure (WBS) is a key element of project management. The purpose of a WBS is to divide

More information

Practice Overview. REQUIREMENTS DEFINITION Issue Date: <mm/dd/yyyy> Revision Date: <mm/dd/yyyy>

Practice Overview. REQUIREMENTS DEFINITION Issue Date: <mm/dd/yyyy> Revision Date: <mm/dd/yyyy> DEPARTMENT OF HEALTH AND HUMAN SERVICES ENTERPRISE PERFORMANCE LIFE CYCLE FRAMEWORK PRACTIICES GUIIDE REQUIREMENTS DEFINITION Issue Date: Revision Date: Document

More information

5 FAH-5 H-520 LIFE CYCLE MANAGEMENT

5 FAH-5 H-520 LIFE CYCLE MANAGEMENT 5 FAH-5 H-520 LIFE CYCLE MANAGEMENT (CT:ITS-5; 02-05-2013) (Office of Origin: (IRM/BMP/SPO/PM) 5 FAH-5 H-521 CONFIGURATION MANAGEMENT REQUIREMENTS Configuration management (CM) is a function deployed throughout

More information

Michigan Staff Augmentation Management Program Contract Job Titles and Descriptions

Michigan Staff Augmentation Management Program Contract Job Titles and Descriptions Applications... 3 1. Programmer Analyst... 3 2. Programmer... 5 3. Software Test Analyst... 6 4. Technical Writer... 9 5. Business Analyst... 10 6. System Analyst... 12 7. Software Solutions Architect...

More information

Project Management Guidelines

Project Management Guidelines Project Management Guidelines 1. INTRODUCTION. This Appendix (Project Management Guidelines) sets forth the detailed Project Management Guidelines. 2. PROJECT MANAGEMENT PLAN POLICY AND GUIDELINES OVERVIEW.

More information

Goddard Procedures and Guidelines

Goddard Procedures and Guidelines Goddard Procedures and Guidelines DIRECTIVE NO. APPROVED BY Signature: Original signed by NAME: A. V. Diaz TITLE: Director Responsible Office: Title: Code 300 / Office of Systems Safety and Mission Assurance,

More information

A Brazilian Software Industry Experience in Using ECSS for Space Application Software Development

A Brazilian Software Industry Experience in Using ECSS for Space Application Software Development A Brazilian Industry Experience in Using ECSS for Space Application Development Fátima MattielloFrancisco a,1, Valdivino Santiago a, Ana Maria Ambrósio a, Leise Jogaib b and Ricardo Costa b a National

More information

ITS Projects Systems Engineering Process Compliance Checklist

ITS Projects Systems Engineering Process Compliance Checklist ITS Projects Systems Engineering Process Compliance Checklist FHWA Final Rule (23 CFR 940) This checklist is to be completed by the MDOT or LPA Project Management Staff. Please refer to the accompanying

More information

Program/Project Management Series Work Breakdown Structure Reference Guide

Program/Project Management Series Work Breakdown Structure Reference Guide Program/Project Management Series Work Breakdown Structure Reference Guide National Aeronautics and Space Administration May 1994 2 Work Breakdown Structure Reference Guide May 1994 Table of Contents Chapter

More information

Space Project Management

Space Project Management EUROPEAN COOPERATION FOR SPACE STANDARDIZATION Space Project Management Configuration Management Secretariat ESA ESTEC Requirements & Standards Division Noordwijk, The Netherlands Published by: Price:

More information

PHASE 3: PLANNING PHASE

PHASE 3: PLANNING PHASE PHASE 3: PLANNING PHASE The ning Phase focuses principally on required project planning work. Proper comprehensive project planning is essential to a successful IT project, and incomplete project planning

More information

Quality Assurance Manual for Low Level Radioactive. Waste Disposal Facility

Quality Assurance Manual for Low Level Radioactive. Waste Disposal Facility WM 07 Conference, February 25 March 1 2007, Tucson, AZ Quality Assurance Manual for Low Level Radioactive Waste Disposal Facility Yasser T. Mohamed Hot Laboratories and Waste Management Center, Egyptian

More information

ISA CERTIFIED AUTOMATION PROFESSIONAL (CAP ) CLASSIFICATION SYSTEM

ISA CERTIFIED AUTOMATION PROFESSIONAL (CAP ) CLASSIFICATION SYSTEM ISA CERTIFIED AUTOMATION PROFESSIONAL (CAP ) CLASSIFICATION SYSTEM Domain I: Feasibility Study - identify, scope and justify the automation project Task 1: Define the preliminary scope through currently

More information

8. Master Test Plan (MTP)

8. Master Test Plan (MTP) 8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across

More information

INTRODUCTION: Plan and Schedule Development Create a Work Breakdown Structure (WBS) The detailed guidelines and examples start on the following page.

INTRODUCTION: Plan and Schedule Development Create a Work Breakdown Structure (WBS) The detailed guidelines and examples start on the following page. What This Is INTRODUCTION: Plan and Schedule Development Create a Work Breakdown Structure (WBS) The detailed guidelines and examples start on the following page. First of a series of guidelines for project

More information

SOFTWARE DEVELOPMENT PLAN

SOFTWARE DEVELOPMENT PLAN SOFTWARE DEVELOPMENT PLAN This document outline is based on the IEEE Standard 1058.1-1987 for Software Project Management Plans. This is the controlling document for managing a software project, and it

More information

Software Configuration Management Plan

Software Configuration Management Plan For Database Applications Document ID: Version: 2.0c Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 22 Copyright 2000-2005 Digital Publications LLC.

More information

Request for Proposal for Application Development and Maintenance Services for XML Store platforms

Request for Proposal for Application Development and Maintenance Services for XML Store platforms Request for Proposal for Application Development and Maintenance s for ML Store platforms Annex 4: Application Development & Maintenance Requirements Description TABLE OF CONTENTS Page 1 1.0 s Overview...

More information

SECTION I PROJECT SUMMARY (TRW)

SECTION I PROJECT SUMMARY (TRW) SECTION I PROJECT SUMMARY (TRW) Table I Summary Agency/Department Information TRW Information Executive Sponsor: Cynthia Lorenzo Received Date: Managers: Ron McCranie/Andy Loveland Status Meeting Date:

More information

Outline Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

Outline Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications Outline Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications Introduction to the BI Roadmap Business Intelligence Framework DW role in BI From Chaos to Architecture

More information

Configuration Management ISO 10007

Configuration Management ISO 10007 Configuration Management ISO 10007 Introduction Configuration Management Overview: What is Configuration Management? Collection of tools, techniques and experience designed to reduce costs and improve

More information

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY How to Write a Software Process for YOUR COMPANY 1. Introduction MicroTools is proposing to assist YOUR COMPANY in improving the existing software process. The purpose of this project is to both improve

More information

Establishing Great Software Development Process(es) for Your Organization. By Dale Mayes DMayes@HomePortEngineering.com

Establishing Great Software Development Process(es) for Your Organization. By Dale Mayes DMayes@HomePortEngineering.com Establishing Great Software Development Process(es) for Your Organization By Dale Mayes DMayes@HomePortEngineering.com Class: ETP-410 Embedded Systems Conference San Francisco 2005 Abstract: There are

More information

Qualification of Auditor and Lead Auditor to perform an assessment according NSQ-100

Qualification of Auditor and Lead Auditor to perform an assessment according NSQ-100 Page 1 / 11 ABSTRACT Qualification of Auditor and Lead Auditor to CONTENTS 0. GENERAL... 2 0.1. Purpose... 2 0.2. Scope of application... 2 0.3. References... 2 0.4. Terminology... 2 1. SECTIONS... 2 1.1.

More information

PHENIX OF IDAHO, INC. SUBCONTRACTOR QUALITY ASSURANCE PLAN

PHENIX OF IDAHO, INC. SUBCONTRACTOR QUALITY ASSURANCE PLAN PHENIX OF IDAHO, INC. SUBCONTRACTOR QUALITY ASSURANCE PLAN SUBCONTRACTOR QUALITY ASSURANCE PLAN 1.0 PURPOSE 1.1 The purpose of this Subcontractor Quality Plan (SQP) is to describe the program to be implemented

More information

Colorado Department of Health Care Policy and Financing

Colorado Department of Health Care Policy and Financing Colorado Department of Health Care Policy and Financing Solicitation #: HCPFRFPCW14BIDM Business Intelligence and Data Management Services (BIDM) Appendix B BIDM Project Phases Tables The guidelines for

More information

Montana Department of Transportation Information Services Division. System Development Life Cycle (SDLC) Guide

Montana Department of Transportation Information Services Division. System Development Life Cycle (SDLC) Guide Montana Department of Transportation Information Services Division System Development Life Cycle (SDLC) Guide Version 2 August 2, 2007 \mdt_sdlc_process\mdt_sdlc_v02.doc Table of Contents 1 Business Analysis...3

More information

Proton Launch System Mission Planner s Guide APPENDIX B. Quality Management System

Proton Launch System Mission Planner s Guide APPENDIX B. Quality Management System Proton Launch System Mission Planner s Guide APPENDIX B Quality Management System B. QUALITY MANAGEMENT SYSTEM B.1 Proton Quality Assurance Plan B.1.1 KhSC Quality Management Overview ILS Proton launch

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Document Purpose The purpose of this document is to provide guidance on the practice of Requirements Definition and to describe the practice overview, requirements, best practices, activities, and key

More information

DESIGN AND INTEGRATION OF EQUIPMENT. (B) Process Flow Guideline

DESIGN AND INTEGRATION OF EQUIPMENT. (B) Process Flow Guideline LLE INSTRUCTION 7700H LLEINST 7700H SUBJECT: APPENDIX: DESIGN AND INTEGRATION OF EQUIPMENT (A) List of Acronyms (B) Process Flow Guideline ENCLOSURES: 1. Equipment Qualification Checklist (EQC) 2. Project

More information

PMP Project Management Professional Study Guide, Third Edition

PMP Project Management Professional Study Guide, Third Edition PMP Project Management Professional Study Guide, Third Edition Joseph Phillips McGraw-Hill is an independent entity from the Project Management Institute, Inc. and is not affiliated with the Project Management

More information

PROJECT MANAGEMENT PLAN <PROJECT NAME>

PROJECT MANAGEMENT PLAN <PROJECT NAME> PROJECT MANAGEMENT PLAN TEMPLATE This Project Management Plan Template is free for you to copy and use on your project and within your organization. We hope that you find this template useful and welcome

More information

Software Project Management Plan (SPMP)

Software Project Management Plan (SPMP) Software Project Management Plan (SPMP) The basic template to be used is derived from IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans. The following is a template for the SPMP.

More information

Gulfstream Production Certificate Operations

Gulfstream Production Certificate Operations SUPPLIER QUALITY ASSURANCE SYSTEM REQUIREMENTS SQAR 0001 REV D Supplier s Quality System David H. Trucksis Donald A. Strickland R. Christiansen PREPARED BY: REVIEWED BY: APPROVED BY: Robert W. Mullen Jr.

More information

This alignment chart was designed specifically for the use of Red River College. These alignments have not been verified or endorsed by the IIBA.

This alignment chart was designed specifically for the use of Red River College. These alignments have not been verified or endorsed by the IIBA. Red River College Course Learning Outcome Alignment with BABOK Version 2 This alignment chart was designed specifically for the use of Red River College. These alignments have not been verified or endorsed

More information

Lecture 17: Requirements Specifications

Lecture 17: Requirements Specifications Lecture 17: Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications

More information

Project Start Up. Start-Up Check List. Why a Project Check List? What is a Project Check List? Initial Release 1.0 Date: January 1997

Project Start Up. Start-Up Check List. Why a Project Check List? What is a Project Check List? Initial Release 1.0 Date: January 1997 Why a Project Check List? A good way to ensure that all start-up tasks are completed prior to actually starting the project is to develop a start-up check list. The check list can be developed and then

More information

Attachment 7 Requirements Traceability Matrix (RTM) ATMS RFP. New York State Department of Transportation Advanced Traffic Management System

Attachment 7 Requirements Traceability Matrix (RTM) ATMS RFP. New York State Department of Transportation Advanced Traffic Management System Attachment 7 Requirements Traceability Matrix (RTM) ATMS RFP New York State Department of Transportation Advanced Traffic Management System i 1. INTRODUCTION This Requirements Traceability Matrix (RTM)

More information

Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews

Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews Department of Health and Human Services Centers for Medicare & Medicaid Services Center for Consumer Information and Insurance Oversight Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews

More information

PHASE 3: PLANNING PHASE

PHASE 3: PLANNING PHASE PHASE 3: PLANNING PHASE The Planning Phase focuses principally on required project planning work. Proper comprehensive project planning is essential to a successful IT project, and incomplete project planning

More information

Input, Output and Tools of all Processes

Input, Output and Tools of all Processes 1 CIS12-3 IT Project Management Input, Output and Tools of all Processes Marc Conrad D104 (Park Square Building) Marc.Conrad@luton.ac.uk 26/02/2013 18:22:06 Marc Conrad - University of Luton 1 2 Mgmt /

More information

GENERAL SERVICES ADMINISTRATION Federal Supply Schedule Authorized Federal Supply Schedule

GENERAL SERVICES ADMINISTRATION Federal Supply Schedule Authorized Federal Supply Schedule GENERAL SERVICES ADMINISTRATION Federal Supply Schedule Authorized Federal Supply Schedule On line access to contract ordering information, terms and conditions, up-to-date pricing, and the option to create

More information

Systems Development Life Cycle (SDLC)

Systems Development Life Cycle (SDLC) DEPARTMENT OF BUDGET & MANAGEMENT (SDLC) Volume 1 Introduction to the SDLC August 2006 Table of Contents Introduction... 3 Overview... 4 Page 2 of 17 INTRODUCTION 1.0 STRUCTURE The SDLC Manual consists

More information

Information Technology Project Management (ITPM)

Information Technology Project Management (ITPM) FUNCTIONAL AREA 10 Project Management (ITPM) Incumbents in this functional area direct information technology system solution and/or improvement projects for cost, time, scope, risk, and quality. They

More information

Software and Hardware Configuration Management

Software and Hardware Configuration Management DOWNLOADED AND/OR HARD COPY UNCONTROLLED Verify that this is the correct version before use. AUTHORITY DATE Jeffrey Northey (original signature on file) IMS Manager 07/09/2014 Doug Dorrer (original signature

More information

16 PROJECT IMPLEMENTATION

16 PROJECT IMPLEMENTATION 16 PROJECT IMPLEMENTATION 16.1 Introduction During the preliminary GMT phase, the project has developed the conceptual design for an optical/infrared telescope that addresses the science goals set forth

More information

Software Test Plan (STP) Template

Software Test Plan (STP) Template (STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This

More information

LISA Pathfinder SUMMARY

LISA Pathfinder SUMMARY Page 2 of 36 SUMMARY This document defines the Independent Software Verification and Validation requirements for the Implementation Phase of the LISA Pathfinder project. Page 3 of 36 TABLE OF CONTENTS

More information

Software Testing Interview Questions

Software Testing Interview Questions Software Testing Interview Questions 1. What s the Software Testing? A set of activities conducted with the intent of finding errors in software. 2.What is Acceptance Testing? Testing conducted to enable

More information

Project Zeus. Risk Management Plan

Project Zeus. Risk Management Plan Project Zeus Risk Management Plan 1 Baselined: 5/7/1998 Last Modified: N/A Owner: David Jones/Zeus Project Manager Page Section 1. Introduction 3 1.1 Assumptions, Constraints, and Policies 3 1.2 Related

More information

General Notes Time allowed 1 hour. Answer all 60 multiple choice questions Use the proforma answer sheet provided.

General Notes Time allowed 1 hour. Answer all 60 multiple choice questions Use the proforma answer sheet provided. Introductory Certificate The APM Project Fundamentals Qualification. Examination paper Candidate Number Date Location Examination Paper Sample Paper v1.4 General Notes Time allowed 1 hour. Answer all 60

More information

Introduction to the ITS Project Management Methodology

Introduction to the ITS Project Management Methodology Introduction to the ITS Project Management Methodology In September 1999 the Joint Legislative Committee on Performance Evaluation and Expenditure Review (PEER) produced a report entitled Major Computer

More information

PMP Examination Tasks Puzzle game

PMP Examination Tasks Puzzle game PMP Examination Tasks Puzzle game Here is a great game to play to test your knowledge of the tasks you will be tested on in the actual examination. What we have done is take each of the domain tasks in

More information

Project Management Plan for

Project Management Plan for Project Management Plan for [Project ID] Prepared by: Date: [Name], Project Manager Approved by: Date: [Name], Project Sponsor Approved by: Date: [Name], Executive Manager Table of Contents Project Summary...

More information

The 10 Knowledge Areas & ITTOs

The 10 Knowledge Areas & ITTOs This document is part of a series that explain the newly released PMBOK 5th edition. These documents provide simple explanation and summary of the book. However they do not replace the necessity of reading

More information

Quality System: Design Control Procedure - Appendix

Quality System: Design Control Procedure - Appendix Quality System: Design Control Procedure - Appendix Page 1 of 10 Quality System: Design Control Procedure - Appendix CORP Medical Products Various details have been removed, indicated by [ ] 1. Overview

More information