ABS 185-2012 GUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM).pdf

1、 GUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) SEPTEMBER 2012 Guide to Color Coding Used in Online Version of the Guide The following summarizes the colors corresponding to Rule Changes, Corrigenda items and editorial changes in the Guide files which are available for download. Rule Change

2、s: Changes effective 1 September 2012 Corrigenda: CORRIGENDA/EDITORIALS 1 February 2014 CORRIGENDA/EDITORIALS 1 July 2014 Editorials: Editorial Changes Guide for Integrated Software Quality Management (ISQM) GUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) SEPTEMBER 2012 (Updated July 2014 se

3、e next page) American Bureau of Shipping Incorporated by Act of Legislature of the State of New York 1862 Copyright 2012 American Bureau of Shipping ABS Plaza 16855 Northchase Drive Houston, TX 77060 USA Updates July 2014 consolidation includes: February 2014 version plus Corrigenda/Editorials Febru

4、ary 2014 consolidation includes: September 2012 version plus Corrigenda/Editorials ABSGUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) .2012 iii Foreword Foreword The marine and offshore industries are increasingly relying on computer-based control systems; therefore the verification of the s

5、oftware used in control systems and their integration into the system is an important element within the overall safety assessment. Accordingly, ABS is introducing this Guide for Integrated Software Quality Management (ISQM). Compliance with the procedures and criteria given in this Guide may result

6、 in the granting of the optional notation ISQM to a vessel or offshore unit. ISQM is a risk-based software development and maintenance process built on internationally recognized standards. The ISQM process verifies the software installation on the facility and then monitors for consistency when the

7、re are software updates or a change in hardware. ISQM provides a process to manage software over the vessels or offshore facilitys life. The benefit to the Owner and Driller or Crew Organization is an increased level of confidence in software reliability with the goal of increasing safety, decreasin

8、g commissioning time, decreasing downtime, and reducing the risk of software related incidents. As control systems for marine and offshore vessels or units become increasingly more complex and highly integrated, successful implementation relies heavily on the software developed by multiple vendors a

9、nd the interfaces required for the integration of the software. The ABS ISQM Guide places emphasis on the verification of the integration of multiple software packages. This Guide is meant to be used with other Rules and Guides issued by ABS and other recognized Industry Standards. This Guide become

10、s effective on the first day of the month of publication. Users are advised to check periodically on the ABS website www.eagle.org to verify that this version of this Guide is the most current. We welcome your feedback. Comments or suggestions can be sent electronically by email to rsdeagle.org. iv

11、ABSGUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) .2012 Table of Contents GUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) CONTENTS SECTION 1 General 1 1 Scope and Application 1 3 Basis of Notation . 1 3.1 Extent of Notation 2 5 Documentation 2 5.1 Required Plans and Documentation to

12、 Be Submitted 2 7 References 2 9 Abbreviations, Acronyms and Definitions . 3 SECTION 2 Introduction 4 1 Background . 4 1.1 Software Development Life Cycle (SDLC) . 4 1.3 Support Processes 5 3 Stakeholder Roles and Responsibilities . 5 3.1 Roles of Organizations 6 5 Use of Terms. 8 5.1 Explanation of

13、 Software Module 8 5.3 Verification . 9 7 ISQM Process . 11 7.1 Project Management (PM) and Software Development Life Cycle (SDLC) . 12 7.3 Concept Phase (C) 12 7.5 Requirements and Design Phase (RD) 13 7.7 Design Group and Production Software 13 7.9 Construction Phase (CON) 15 7.11 Verification, Va

14、lidation and Transition (V V subsequently, leading to the beginning of operation of the affected system. Maintenance of the ISQM notation over the operational life of the system is subject to the periodic surveys carried out on board the vessel or unit in accordance with Section 8 of this Guide. Int

15、egrated or non-integrated control systems affected by and classed with the ISQM (for integrated control system) and SQM (for non-integrated control system) notation will be listed in the ABS Record to describe the exact coverage of the notation. For example, the describer could be one or more of the

16、 following: Dynamic Positioning Control System Drilling Control System Vessel Management Control System Hydraulic Power Units Control System Power Management Control System etc. Section 1 General 2 ABSGUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) .2012 3.1 Extent of Notation When the ISQM

17、notation is given to a control system, the connected control systems of the controlled equipment and functions are not included in the notation. However, the interface between the ISQM control system and other connected control systems are included in the Guide. The term “approved” or “approval” is

18、to be interpreted to mean that the plans, reports or documents have been or are to be reviewed for compliance with one or more of the Rules, Guides, standards or other criteria of ABS. 5 Documentation 5.1 Required Plans and Documentation to Be Submitted (1 September 2012) In order to receive the ISQ

19、M notation, plans and documentation, as applicable, are to be submitted by the responsible organization. For plans and data to be submitted for approval, refer to Appendix 1 of this Guide. 7 References IEEE Std 14764-2006, Second edition 2006-09-01, Software Engineering Software Life Cycle Processes

20、 Maintenance IEEE Std 12207-2008 Second edition, 2008-02-01, Systems and Software Engineering Software Life Cycle Processes IEEE Std 730-2002 IEEE Standard for Software Quality Assurance Plans IEEE Std 828-2005, IEEE Standard for Software Configuration Management Plans IEEE Std 829-2008, IEEE Standa

21、rd for Software and System Test Documentation IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications IEEE Std 1012-2004, IEEE Standard for Software Verification and Validation IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions IEEE Std 1219-

22、1998, IEEE Standard for Software Maintenance IEEE Std 1362-1998 (R2007), IEEE Guide for Information Technology System Definition Concept of Operations (ConOps) Document IEEE Std 1490-2003, IEEE Guide Adoption of PMI Standard A Guide to the Project Management Body of Knowledge IEEE SWEBOK 2004, Softw

23、are Engineering Body of Knowledge IEC 61508-0 (2005-01), Functional safety of electrical/electronic/programmable electronic safety-related systems Part 0: Functional safety and IEC 61508 IEC 61508-1 (2010-04), Functional safety of electrical/electronic/programmable electronic safety-related systems

24、Part 1: General requirements IEC 61508-2 (2010-04), Functional safety of electrical/electronic/programmable electronic safety-related systems Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems IEC 61508-3 (2010-04), Functional safety of electrical/electroni

25、c/programmable electronic safety-related systems Part 3: Software requirements IEC 61508-4 (2010-04), Functional safety of electrical/electronic/programmable electronic safety-related systems Part 4: Definitions and abbreviations IEC 61508-5 (2010-04), Functional safety of electrical/electronic/prog

26、rammable electronic safety-related systems Part 5: Examples of methods for the determination of safety integrity levels Section 1 General ABSGUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) .2012 3 IEC 61508-6 (2010-04), Functional safety of electrical/electronic/programmable electronic safet

27、y-related systems Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3 IEC 61508-7 (2010-04), Functional safety of electrical/electronic/programmable electronic safety-related systems Part 7: Overview of techniques and measures IEC 61511-1 (2003-01), Functional safety Safety instrume

28、nted systems for the process industry sector, Functional safety Safety instrumented systems for the process industry sector Part 1: Framework, definitions, system, hardware and software requirements IEC 61511-2 (2003-07), Functional safety Safety instrumented systems for the process industry sector,

29、 Functional safety Safety instrumented systems for the process industry sector Part 2: Guidelines for the application of IEC 61511-1 IEC 61511-3 (2003-03), Functional safety Safety instrumented systems for the process industry sector, Functional safety Safety instrumented systems for the process ind

30、ustry sector Part 3: Guidance for the determination of the required safety integrity levels ISO/IEC 9126-1:2001 Software engineering Product quality Part 1: Quality model ISO 17894-2005 General principles for the development and use of programmable electronic systems in marine applications ISO 9001:

31、2008 Quality Management Systems Requirements ANSI/ISA-84.00.01-2004 Part 2 (IEC 61511-2 Mod) Functional Safety: Safety Instrumented Systems for the Process Industry Sector Part 2: Guidelines for the Application of ANSI/ISA-84.00.01-2004 Part 1 (IEC 61511-1 Mod) Informative Department of Defense and

32、US Army: Practicable Software The Owner could be the SBI (Builder or shipyard) during initial construction; System Integrator (SI) could also be the Verification and Validation (V i) Detecting any Critical or Major Defects (Refer to Section 6, Table 1 for software defect ranking table) ii) Detecting

33、 any IL2 or IL3 defects or other defects that systemically affect IL2 or IL3 level functions. Regression testing is used to test the “corrected” software for new defects that may have been introduced during the coding to correct a previously known or detected defect. Regression testing is to include

34、 complete testing of all inputs to and outputs from the changed software module that interfaces with any IL2 or IL3 components. After verification of the completed software, all activities necessary to transition the integrated system to the Owner and DCO are accomplished. The software is installed

35、on the target hardware and support services arranged, as selected by the Owner. The SI submits all documentation to the Owner and DCO. 7.13 Operation and Maintenance (O & M) Phase (1 September 2012) This phase covers the operation and maintenance activities, including scheduled and unscheduled upgra

36、des and problem resolution activities (Section 7). This phase also extends to retirement activities. The responsibilities for activities in this phase lie with the DCO with activities by Suppliers. The SI is to provide the Operation and Maintenance Plan towards the end of verification activities. Re

37、fer to Appendix 7 for an example Operation and Maintenance Plan template. Most software requires maintenance such as adding functionality, correcting latent software defects, etc., over time. ABSGUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) .2012 17 Section 3: Software Development Life Cyc

38、le: Concept Phase SECTION 3 Software Development Life Cycle: Concept Phase 1 Scope (1 September 2012) At the beginning of an ISQM software project, there are two paths for developing the software detailed description, see Section 2, Figure 9. The paths are: Design Group (Section 9) delivering Functi

39、onal Description Documents (FDD). Concept Phase (Section 3) delivering a Concept of Operation Document (ConOps) followed by Requirements and Design Phase (Section 4) delivering the SRS and SDS documents. If the control system functions (code) meet the following requirements, then proceeding using th

40、e Design Group and producing the FDD is acceptable to ABS: i) The control system software to be provided to control or monitor the equipment, control system or integrated system is to be comprised of approximately 85% or more utilizing established functions and code modules or code with the remainde

41、r being configuration modifications and/or new code to meet the requirements or specifications. And ii) The control system software is to be currently in use within the industry. a) Multiple updates or modifications that have been made to the control system software over time does not preclude the u

42、se of this section and is acceptable to ABS. Or i) Special consideration from ABS is granted. If the control system software meets the above requirements, see Section 9. Below are the requirements and recommendations for the Concept Phase with the major deliverable being the ConOps. The goal of the

43、Concept Phase is to define the integrated system with sufficient detail to facilitate safety review(s), Integrity Level assessments, and identify selected components of the integrated system. The objective of the Concept Phase is to complete a Concept of Operations document (ConOps) which contains t

44、he needed architecture, standards, descriptions and requirements that are used by the System Integrator (SI) to begin the Requirements and Design (RD) Phase. Refer to Appendix 1 for activities and requirements for this phase. The Owner may request input from the SI or SBI, as needed, for the development of the ConOps.