Quality System: Design Control Standard Operating Procedure

Similar documents
Software Testing. Knowledge Base. Rajat Kumar Bal. Introduction

SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE. Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions.

Internal Quality Management System Audit Checklist (ISO9001:2015) Q# ISO 9001:2015 Clause Audit Question Audit Evidence 4 Context of the Organization

Quality System: Design Control Procedure - Appendix

Controlling Risks Safety Lifecycle

Procedure for Corrective and Preventative Action. Procedure No. 304

EXHIBIT L. Application Development Processes

ADDENDUM. Product Category Rules for preparing an environmental product declaration (EPD) for PCR:

SOFTWARE-IMPLEMENTED SAFETY LOGIC Angela E. Summers, Ph.D., P.E., President, SIS-TECH Solutions, LP

ISO 9001:2000 AUDIT CHECKLIST

Quality Management. Lecture 12 Software quality management

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

Test Specification. Introduction

Custom Software Development Approach

Assignment Kits. Summary Kit Contents Lecture 1: Kit cover sheet (page 40)

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34.

Abu Dhabi EHSMS Regulatory Framework (AD EHSMS RF)

Verification and Validation of Software Components and Component Based Software Systems

SOFTWARE QUALITY & SYSTEMS ENGINEERING PROGRAM. Quality Assurance Checklist

Introduction to Software Engineering. 8. Software Quality

Quality Management System Manual ISO9001:2008

AAMI TIR 36: Validation of SW for Regulated Processes. Denise Stearns April 2008

Levels of Software Testing. Functional Testing

Independent Verification and Validation of SAPHIRE 8 Software Project Plan

Software Engineering Question Bank

Testing Introduction. IEEE Definitions

Design Verification The Case for Verification, Not Validation

DO-178B compliance: turn an overhead expense into a competitive advantage

ISO 9001:2000 Gap Analysis Checklist

Software Development: The Waterfall Model

When the template is complete, the whole Product Description document can be printed and approved.

Supplier Quality Management System Audit Checklist (ISO 9000:2000, TS 16949:2002)

White Paper Outsourcing of Embedded Software Testing

Software Process Models. Xin Feng

THE PROCESS APPROACH IN ISO 9001:2015

Independent Verification and Validation of SAPHIRE 8 Software Quality Assurance Plan

Supervisor of Banks: Proper Conduct of Banking Business [9] (4/13) Sound Credit Risk Assessment and Valuation for Loans Page 314-1

Summary of GE Healthcare's Quality Management System (QMS) Covering BioProcess chromatography media, equipment, software, and spare parts

Standard for Software Component Testing

Basic Testing Concepts and Terminology

Certification Authorities Software Team (CAST) Position Paper CAST-15

CONSOLIDATED VERSION IEC Medical device software Software life cycle processes. colour inside. Edition

Attachment 2 Project Management Plan Template PROJECT MANAGEMENT PLAN WORK PERFORMED UNDER AGREEMENT SUBMITTED BY PRINCIPAL INVESTIGATOR SUBMITTED TO

AC REUSABLE SOFTWARE COMPONENTS

<name of project> Software Project Management Plan

Higher Computing. Software Development. LO1 Software Development process

Aberdeen Drilling Consultants Presentation on Asset Integrity and The ADC TRAMS System

ISO 9001 (2000) QUALITY MANAGEMENT SYSTEM ASSESSMENT REPORT SUPPLIER/ SUBCONTRACTOR

ISO 9001:2008 Quality Management System Requirements (Third Revision)

Software Process Training

Product Build. ProPath. Office of Information and Technology

Document issued on: May 11, 2005

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

ISO 9001 : 2008 QUALITY MANAGEMENT SYSTEM AUDIT CHECK LIST INTRODUCTION

ISO 9001: 2008 Boosting quality to differentiate yourself from the competition. xxxx November 2008

CORPORATE QUALITY MANUAL

Software Testing Interview Questions

SOE. managing change in system development projects: configuration management

How To Write Software

Failure Mode and Effect Analysis. Software Development is Different

THE OPEN UNIVERSITY OF TANZANIA FACULTY OF SCIENCE TECHNOLOGY AND ENVIRONMENTAL STUDIES BACHELOR OF SIENCE IN DATA MANAGEMENT

ITS Projects Systems Engineering Process Compliance Checklist

Certification Authorities Software Team (CAST) Position Paper CAST-26

Quality Management System Manual

Independent Verification and Validation of SAPHIRE 8 Software Configuration Management Plan

Parameters for Efficient Software Certification

Sound Transit Internal Audit Report - No

EMA CMDB Assessment Service

Recipe for Mobile Data Security: TPM, Bitlocker, Windows Vista and Active Directory

ISO 9001:2008 Audit Checklist

Introduction to Automated Testing

codebeamer INTLAND SOFTWARE codebeamer Medical ALM Solution is built for IEC62304 compliance and provides a wealth of medical development knowledge

Scrum QA Assessment. John Scarborough VP System Engineering STeP-IN Summit January 2006

Assured Joint Integrity

Certification of a Scade 6 compiler

Karas Engineering AS9100 QUALITY MANAGEMENT SYSTEM MANUAL

ISO 9000 Introduction and Support Package: Guidance on the Concept and Use of the Process Approach for management systems

Software quality engineering. Quality assurance. Testing

FSW QA Testing Levels Definitions

September 2005 Report No

STUDENT OUTCOMES ASSESSMENT PLAN (SOAP)

DNV GL Assessment Checklist ISO 9001:2015

QW Enterprises, LLP. Quality Manual

ájoƒ ùdg á«hô dg áµلªÿg Yesser Overall SDLC Process Definition

THE PER-UNIT SYSTEM. (2) The per-unit values for various components lie within a narrow range regardless of the equipment rating.

ELECTRICAL AND I&C EQUIPMENT OF A NUCLEAR FACILITY

Specialties Manufacturing. Talladega Castings & Machine Co., Inc. ISO 9001:2008. Quality Manual

Software Test Plan (STP) Template

Software Process for QA

Example Software Development Process.

System Development Life Cycle Guide

Cost of Production : An Example

Software Development Processes

Transcription:

Quality System: Design Control Standard Operating Procedure Page 1 of 16 Quality System: Design Control Standard Operating Procedure CORP Medical Products Various details have been removed, indicated by [ ] 1. Overview 1.1 Objective This document describes the standard operating procedures required to carry out the process described in the CORP Quality System: Design Control Procedure for Project Change Requests (PCR). Refer to that document for more detail, along with other CORP references cited here. 1.2 Scope This is required for any PCR. 1.3 Responsibility This document shall be maintained by CORP Management personnel. This document shall be followed by all CORP personnel involved with PCRs. 1.4 Procedure and Outputs Each of the following sections applies to one process in the CORP Cyclic Development State Machine. Sections that follow 2. Create Concept... 3 3. Create Initial Design... 4 4. Standard Review: of Create Initial Design... 5 5. Create Design Input... 6 6. Standard Review: of Create Design Input... 7 7. Design Process... 8 8. Standard Review: of Design Process... 10 9. Verification... 11 10. Standard Review: of Verification... 12 11. Validation... 13 12. Standard Review: of Validation... 14 13. Transfer... 15 14. Standard Review... 16 1.5 Definitions PCR CDSM Product Change Request Cyclic Development State Machine

Quality System: Design Control Standard Operating Procedure Page 2 of 16 1.6 References CORP Quality System: Design Control Procedure (CORP.820.30.top.txt) CORP Quality System: Design Control Procedure Appendix (CORP.820.30.app.txt) CORP Quality System: Design Control Procedure Tools (CORP.820.30.tools.txt) CORP Quality System: Introductory presentation (CORP.820.30.intro.ppt) CORP Quality System WEB SCR Tool

Quality System: Design Control Standard Operating Procedure Page 3 of 16 2. Create Concept 2.1 Objective To create an initial high-level description of the Project Change Request (PCR). This shall capture input from all parties with an interest in the PCR goals. 2.2 Scope A PCR shall be created for any proposed change to a CORP product or new product. This can range from simple cosmetic modifications, to bug fixes, to complex functional enhancements, to new programs. All PCRs shall be subject to the CORP Design Control Standard Operating Procedure, regardless of the complexity or type of change. A PCR can be created for many reasons, including: Hazard analysis results Suggestions for improvements 2.3 Responsibility Create Concept shall be carried out by: Any CORP Trusted Personnel. Suggestions and input can come from many sources, such as: Alpha or beta test sites Literature reviews 2.4 Procedure and Outputs The following Outputs shall be created: Unique Identifier Title: Simple title for PCR. [ ] Unique Identifier: A unique identifier for this PCR.

Quality System: Design Control Standard Operating Procedure Page 4 of 16 3. Create Initial Design 3.1 Objective Evaluate the Concept and create the Initial Design plan. 3.2 Scope This is required for any PCR to progress into a development state. 3.3 Responsibility Create Initial Design shall be carried out by: Any CORP Trusted Personnel. 3.4 Procedure and Outputs The following Outputs shall be created: Requirements specification Risk Assessment Review Checklist Requirements Specification: High-level requirements of PCR, which will generally include one or more of: Functional requirements Interface requirements Master Plan: Roadmap of anticipated design phase cycles. Risk Assessment: Evaluation of risks associated with this project, and consequences. This shall be utilized for two purposes: [ ] Review Checklist: List of issues that shall be addressed in a Review of this step, including at least the following: Requirements specification captures overall goals comprehensively. Requirements specification is written unambiguously. Master Plan is appropriate. Overall objectives are in line with user, company, and safety needs. Participants are valid.

Quality System: Design Control Standard Operating Procedure Page 5 of 16 4. Standard Review: of Create Initial Design REQUIRED for any PCR to progress further. Standard Review is defined in Section 14 of this document.

Quality System: Design Control Standard Operating Procedure Page 6 of 16 5. Create Design Input 5.1 Objective Create the design input specifications, which are the starting point for any design phase. 5.2 Scope Required for any PCR to progress further. The completion of any PCR shall require one or more design phase cycles as determined by the Master Plan, where a design phase consists of: Create Design Input Optional: Standard Review of Design Input Optional: Verification 5.3 Responsibility Create Design Input shall be carried out by: Any CORP Trusted Personnel with appropriate training/skills. 5.4 Procedure and Outputs The following Outputs shall be created upon completion of all required design phase cycles. Prior to final cycle, one or more may be incomplete: Requirements Specification High level architecture specification Verification Criteria Review Checklist Requirements Specification: Upon completion of all required design phase cycles, this shall specify the requirements at an engineering level of detail. Prior to [ ]: Functional requirements Interface requirements High level architecture specification: Specification of the anticipated means of achieving the Requirement Specifications for this design phase. Verification Criteria: Detailed specification of the means of verifying conformance between Design Output and Design Input [ ]. Review Checklist: List of issues that shall be addressed in a Review of this step, [ ]: Requirements specification captures goals comprehensively. Requirements specification is written unambiguously.

Quality System: Design Control Standard Operating Procedure Page 7 of 16 6. Standard Review: of Create Design Input OPTIONAL: Shall be carried out only if specified in Review Schedule. Standard Review is defined in Section 14 of this document.

Quality System: Design Control Standard Operating Procedure Page 8 of 16 7. Design Process 7.1 Objective The process of realizing the Design Input requirements for this design phase cycle, thus creating the Design Output. 7.2 Scope Required for any PCR to progress further. 7.3 Responsibility Design Process shall be carried out by: Any CORP Trusted Personnel with appropriate training/skills. 7.4 Procedure and Outputs The following Outputs shall be created: Means of providing for each Design Input requirement Means of demonstrating that each requirement has been met Means of providing for each Design Input requirement: This is everything required [ ]. Means of demonstrating that each requirement has been met: This can be included in any of the actions and documents listed below. The actions that shall occur during this step depend on the phase of development and target of development, and can include: Evaluations Meetings Risk/fault analysis Design Output documentation shall provide for at least: Assessment of conformance to design input requirements. Identifying characteristics of the design and that are crucial to the safety and proper functioning of the device. Design Output documentation shall be maintained as appropriate for the complexity or criticality of the problem. Such documentation can include: Software pseudo-code Software source code Risk or Fault analysis Verification activities Test procedures and results QA specifications and procedures CORP Pair Programming shall be employed if specified in risk assessment.

Quality System: Design Control Standard Operating Procedure Page 9 of 16 CORP guidelines for documentation and coding shall be employed as required to improve correctness, safety, robustness, and maintainability. [ ] Review Checklist: List of issues that shall be addressed in a Review of this step, including at least the following: Output documentation meets Design Input requirements for this cycle. Appropriate guidelines for coding were followed. Participants are valid.

Quality System: Design Control Standard Operating Procedure Page 10 of 16 8. Standard Review: of Design Process OPTIONAL: Shall be carried out only if specified in Review Schedule. Standard Review is defined in Section 14 of this document.

Quality System: Design Control Standard Operating Procedure Page 11 of 16 9. Verification 9.1 Objective To establish conformance of the Design Output with the Design Input as specified in Verification Criteria. 9.2 Scope Required for any PCR to progress further. 9.3 Responsibility Verification shall be carried out by: Any CORP Trusted Personnel with appropriate training/skills. 9.4 Procedure and Outputs The following Outputs shall be created: Results of Design Input Verification Criteria Review Checklist Results of Design Input Verification Criteria: Address each item in the Verification Criteria (which was produced in Create Design Input) and record results. [ ] Review Checklist: List of issues that shall be addressed in a Review of this step, including at least the following: Each item in Design Input Verification Criteria has been addressed. Each item in Standard Verification Criteria has been addressed. Participants are valid

Quality System: Design Control Standard Operating Procedure Page 12 of 16 10. Standard Review: of Verification OPTIONAL: Shall be carried out only if specified in Review Schedule. Standard Review is defined in Section 14 of this document.

Quality System: Design Control Standard Operating Procedure Page 13 of 16 11. Validation 11.1 Objective To establish conformance of the Design Output with the Design Input and comprehensive environment as specified in Validation Criteria. 11.2 Scope Required for any PCR to progress further. 11.3 Responsibility Validation shall be carried out by: Any CORP Trusted Personnel with appropriate training/skills. 11.4 Procedure and Outputs The following Outputs shall be created: Results of Design Input Validation Criteria Review Checklist Results of Design Input Validation Criteria: Address each item in the Validation Criteria (which was produced in Create Design Input) and record results. [ ] Review Checklist: List of issues that shall be addressed in a Review of this step, including at least the following: Each item in Design Input Validation Criteria has been addressed. Participants are valid.

Quality System: Design Control Standard Operating Procedure Page 14 of 16 12. Standard Review: of Validation REQUIRED for any PCR to progress further. Standard Review is defined in Section 14 of this document.

Quality System: Design Control Standard Operating Procedure Page 15 of 16 13. Transfer 13.1 Objective To get the verified and validated product to the end user. 13.2 Scope Required for any PCR to progress further. 13.3 Responsibility Transfer shall be carried out by: Any CORP Management Personnel with appropriate training/skills. 13.4 Procedure and Outputs The following Outputs shall be created: Verification of released software Verification of released software: Ensure that released software is identical to that which was verified and validated. [ ]. Review Checklist: List of outputs or processes that shall be reviewed for correctness in a Review of this step, including at least the following: Verification of released software has been addressed.

Quality System: Design Control Standard Operating Procedure Page 16 of 16 14. Standard Review 14.1 Objective Verify that the previous state has met its requirements. If so, allow progression to the next CDSM transition. If not, recommend changes and cycle back to a previous CDSM transition. 14.2 Scope Input is taken from the Outputs of the previous state. Output determines the next CDSM transition, and can add action items to other CDSM states. 14.3 Responsibility Standard Review shall be carried out by: Any CORP Design Review Committee personnel. 14.4 Procedure and Outputs The following Outputs shall be created: Results of Review Next CDSM transition Results of Review: Evaluation of whether the previous state s Review Checklist requirements were met in terms of: The transition process that created the state. If they were not met, this shall also provide recommendations for change. Next CDSM transition: If previous state met the requirements, this shall be set to [ ]. Otherwise, this shall be set to [ ], causing a cycle back. Action items added to other CDSM states: If previous state did not meet the requirements, then, if necessary, [ ] as required to correct the problems. [ ]