PDF generated on 21 Dec 2013 DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM MQP Specific Plan SEQA-45 - Software Engineering and Quality Assurance for CODAC This document describes general rules, practices and recommendations for software engineering and quality assurance in the scope of ITER CODAC activities. Approval Process Name Action Affiliation Author Stepanov D. 11 Dec 2013:signed IO/DG/DIP/CHD/CSD/CDC Co-Authors Reviewers Kazachenko O. * Klora J. Park M. Sands D. Thomas P. Wallander A. 18 Dec 2013:recommended 12 Dec 2013:recommended 12 Dec 2013:recommended 19 Dec 2013:recommended 19 Dec 2013:recommended 11 Dec 2013:recommended IO/DG/DIP/CEP/FCED/TP IO/DG/ADM/FBM/IT IO/DG/DIP/CHD/CSD/CDC IO/DG/SQS/QA IO/DG/DIP/CHD IO/DG/DIP/CHD/CSD Approver Haange R. 21 Dec 2013:approved IO/DG/DIP Document Security: level 1 (IO unclassified) RO: Croset Jean-Philippe Read Access GG: MAC Members and Experts, GG: STAC Members & Experts, LG: QA DOC Editors, LG: FDR_RO, AD: ITER, AD: External Collaborators, AD: Division - Control System Division - EXT, AD: Section - CODAC - EXT, AD: Division - Control System Division, AD: Section - CODAC, AD: DA, AD: Section - Plant Control and... IDM UID 2NRS2K VERSION CREATED ON / VERSION / STATUS 11 Dec 2013 / 3.2 / Approved EXTERNAL REFERENCE
Transcript
PDF generated on 21 Dec 2013DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
MQP Specific Plan SEQA-45 - Software Engineering and Quality Assurance
for CODAC
This document describes general rules, practices and recommendations for software engineering and quality assurance in the scope of ITER CODAC activities.
Approval Process Name Action AffiliationAuthor Stepanov D. 11 Dec 2013:signed IO/DG/DIP/CHD/CSD/CDCCo-AuthorsReviewers Kazachenko O. *
Klora J. Park M. Sands D. Thomas P. Wallander A.
18 Dec 2013:recommended12 Dec 2013:recommended12 Dec 2013:recommended19 Dec 2013:recommended19 Dec 2013:recommended11 Dec 2013:recommended
Approver Haange R. 21 Dec 2013:approved IO/DG/DIPDocument Security: level 1 (IO unclassified)
RO: Croset Jean-PhilippeRead Access GG: MAC Members and Experts, GG: STAC Members & Experts, LG: QA DOC Editors, LG: FDR_RO,
AD: ITER, AD: External Collaborators, AD: Division - Control System Division - EXT, AD: Section - CODAC - EXT, AD: Division - Control System Division, AD: Section - CODAC, AD: DA, AD: Section - Plant Control and...
IDM UID
2NRS2KVERSION CREATED ON / VERSION / STATUS
11 Dec 2013 / 3.2 / Approved
EXTERNAL REFERENCE
PDF generated on 21 Dec 2013DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
Change LogTitle (Uid) Versio
nLatest Status Issue Date Description of Change
SEQA-45 - Software Engineering and Quality Assurance for CODAC (2NRS2K_v3_2)
v3.2 Approved 11 Dec 2013
- explicit adherence to ISO/IEC 15288 for system engineering- mapping of the CODAC QA stack to the ITER MQP pyramid- introduction of software integrity level (SWIL)- introduction of hardware-related templates and SDSDs- updates of subordinate documentation (notably changes in the management plans)- updates in processes' implementation following the last two years progress- stylistic updates for the latest PCDH and CODAC DDD
SEQA-45 - Software Engineering and Quality Assurance for CODAC (2NRS2K_v3_1)
v3.1 Approved 17 Nov 2011
The version for the CODAC PDR:- Updated the documentation overview figure;- Implemented comments from J.Poole.
SEQA-45 - Software Engineering and Quality Assurance for CODAC (2NRS2K_v3_0)
v3.0 In Work 20 Oct 2011
Major rewrite in view of ISO/IEC 12207 conformance. Version for internal review.
SEQA-45 - Software Engineering and Quality Assurance for CODAC (2NRS2K_v2_1)
v2.1 Approved 11 Feb 2011
Minor corrections after the internal and external reviews.
SEQA-45 - Software Engineering and Quality Assurance for CODAC (2NRS2K_v2_0)
v2.0 Signed 10 Jan 2011
Updated for the inclusion into the PCDH v6.
SEQA-45 - Software Engineering and Quality Assurance for CODAC (2NRS2K_v1_0)
5.1 PLANT CONTROL DESIGN HANDBOOK ...............................................................................65.2 CODAC DDD ...................................................................................................................65.3 ITER MQP ........................................................................................................................6
6 GENERAL METHODOLOGY.........................................................................................76.1 APPROACH .........................................................................................................................76.2 PROJECT CLASSIFICATION..................................................................................................76.3 PRINCIPAL DOCUMENTATION.............................................................................................8
7.3.1 Acquisition Process.................................................................................................127.3.2 Supply Process ........................................................................................................127.3.3 Life Cycle Model Management Process..................................................................127.3.4 Infrastructure Management Process.......................................................................127.3.5 Project Portfolio Management Process..................................................................137.3.6 Human Resource Management Process .................................................................137.3.7 Quality Management Process .................................................................................137.3.8 Project Planning Process .......................................................................................137.3.9 Project Assessment and Control Process ...............................................................147.3.10 Decision Management Process...............................................................................147.3.11 Risk Management Process ......................................................................................147.3.12 Configuration Management Process ......................................................................147.3.13 Information Management Process ..........................................................................157.3.14 Measurement Management Process .......................................................................157.3.15 Stakeholder Requirements Definition Process........................................................157.3.16 System Requirements Analysis Process ..................................................................157.3.17 System Architectural Design Process .....................................................................167.3.18 Implementation Process..........................................................................................167.3.19 System Integration Process.....................................................................................167.3.20 System Qualification Testing Process.....................................................................16
Page 2 of 21
7.3.21 Software Installation Process .................................................................................167.3.22 Software Acceptance Support Process....................................................................177.3.23 Software Operation Process ...................................................................................177.3.24 Software Maintenance Process...............................................................................177.3.25 Software Disposal Process .....................................................................................177.3.26 Software Implementation Process...........................................................................187.3.27 Software Requirements Analysis Process ...............................................................187.3.28 Software Architectural Design Process ..................................................................187.3.29 Software Detailed Design Process..........................................................................187.3.30 Software Construction Process...............................................................................187.3.31 Software Integration Process..................................................................................197.3.32 Software Qualification Testing Process..................................................................197.3.33 Software Documentation Management Process .....................................................197.3.34 Software Configuration Management Process .......................................................197.3.35 Software Quality Assurance Process ......................................................................197.3.36 Software Verification Process.................................................................................207.3.37 Software Validation Process...................................................................................207.3.38 Software Review Process ........................................................................................207.3.39 Software Audit Process ...........................................................................................207.3.40 Software Problem Resolution Process....................................................................207.3.41 Domain Engineering Process .................................................................................217.3.42 Reuse Asset Management Process ..........................................................................217.3.43 Reuse Program Management Process ....................................................................21
Page 3 of 21
1 PurposeThis document describes general rules, practices and recommendations for ITER control system (CODAC) software engineering.
2 ScopeThis document defines the overall engineering approach and gives a brief overview of implementation; technology-specific topics are described in separate reference documents. System engineering is supposed to be sufficiently covered in ITER general documentation (see the ITER Systems Engineering Management Plan, [RD1]), so this document only expands on system engineering aspects when they are specific to CODAC.The content of this document applies to the development of the CODAC System (PBS 45). Plant system I&Cs (PBS interfacing with CODAC) prepared in the scope of the ITER Plant Control Design Handbook ([RD4]) are also subject to these requirements. PBS 47 (plasma control system) is subject to these requirements for those parts implemented as an integral part of CODAC. The Central Interlock System (PBS 46) and Central Safety Systems (PBS 48) are out of the scope of this document. The rest of this document is written from the CODAC system point of view.Software for control system elements which are COTS devices does not have to follow these rules and should follow the engineering and quality assurance guidelines of their respective manufacturers and/or maintainers instead. COTS components must be selected in such a way that their integration does not degrade the overall quality level of CODAC.
3 DefinitionsMany terms and definitions used in this document are explained in the glossaries of the ISO/IEC 15288 and 12207 international standards ([RD2], [RD3]). The standards are broken down into two main parts – system engineering and software engineering. By the “system” we understand hereafter a plant system I&C or a central system (central systems are treated as plant systems PBS 45, PBS 46, PBS 47 and PBS 48, with some special control features). The system includes both hardware and software.The following abbreviations and acronyms are used in this document (Table 3-1):
ADM ADMinistration directorate
CIE Central Integration and Engineering directorate
CIS Central Interlock System
CODAC Control, Data Access and Communication
COTS Commercial Off-The-Shelf
CWS Cooling Water System
D-T Deuterium-Tritium
DDD Design Description Document
DOORS Dynamic Object Oriented Requirements System
DR Document Review
DT Document Templates
EPICS Experimental Physics and Industrial Control System
Page 4 of 21
FDIS Final Draft International Standard
FPGA Field Programmable Gate Array
GD Generic Document
HMI Human-Machine Interface
HPN High Performance Networks
I&C Instrumentation and Control
IDM ITER Document Management
IEC International Electrotechnical Commission
IO ITER Organization
ISO International Standards Organization
LCC Local Control Cubicle
MQP Management and Quality Programme
N/A Not Applicable
PBS Plant Breakdown Structure
PCDH Plant Control Design Handbook
PIS Plant Interlock System
PLC Programmable Logic Controller
PS Plant System
PSS Plant Safety System
QA Quality Assurance
QC Quality Class
R&D Research and Development
RD Reference Document
SADD Software Architecture and Design Description
SCC Signal Conditioning Cubicle
SCMP Software Configuration Management Plan
SCP System Context Processes
SDMP Software Documentation Management Plan
SDP Software Development Plan
SDSD Software Development Standards Description
SEQA Software Engineering and Quality Assurance
SPMP Software Project Management Plan
SQAP Software Quality Assurance Plan
SQL Structured Query Language
SQS Safety, Quality and Security department
SRC SouRCe code
SRD System Requirements Document
SRS Software Requirements Specification
SSP Software Specific Processes
STP Software Test Plan
STR Software Test Report
Page 5 of 21
SUM Software User Manual
SVN SubVersioN
SW SoftWare
SWIL SoftWare Integrity Level
TBD To Be Defined
-T Template
-β Beta- or draft version
Table 3-1: Abbreviations
4 References[RD1] ITER Systems Engineering Management Plan (SEMP) (2F68EX v2.2)[RD2] ISO/IEC 15288:2008 (http://www.iso.org/iso/catalogue_detail?csnumber=43564)[RD3] ISO/IEC 12207:2008 (http://www.iso.org/iso/catalogue_detail?csnumber=43447) [RD4] Plant Control Design Handbook (27LH2V v7.0)[RD5] CODAC DDD (6M58M9 v1.3)[RD6] ITER Quality Assurance Program (QAP) (22K4QX v7.3)[RD7] Quality Classification Determination (24VQES v4.1)[RD8] SDP-45 – Software Development Plan for CODAC (6SLYRM v1.2)[RD9] SQAP-45 – Software Quality Assurance Plan for CODAC (6SNDEV v1.3)[RD10] SVVP-45 – Software Verification and Validation Plan for CODAC (4346RL v2.1)[RD11] SCMP-45 – Software Configuration Management Plan for CODAC (6SNQCR v1.0)[RD12] SDMP-45 – Software Documentation Management Plan for CODAC (6SR4UQ v1.0)[RD13] HWQAP-45 – Hardware Quality Assurance Plan for CODAC (CZZBWG v1.0)[RD14] Plant system I&C Integration plan (3VVU9W v4.6)[RD15] ITER Procurement Quality Requirements (22MFG4 v4.0)[RD16] IDM Manual (22223J v8.11)[RD17] Central I&C Systems - Implementation Plan (33HDSA v1.0)[RD18] CODAC Management Plan (6VMVZW v1.0)[RD19] CODAC Component Lifecycle Management (https://psp.iter.org/PsProfile/page/inventory/)[RD20] CODAC Component Lifecycle Management user guide (EBTPAJ v1.1)[RD21] ITER Quality Assurance Program (22K4QX v7.3)[RD22] ITER Templates (2DJT9B)[RD23] System Requirements Documents (SRDs) (29D6G7)[RD24] Using DOORS on ITER Technical Baseline Documents (2MR6Z9 v1.1)[RD25] ITER System Design Process (SDP) Working Instruction (4CK4MT v1.0)[RD26] Design Review Procedure (2832CF v3.1)[RD27] System Design Description Documents (DDDs) (29D8PA)[RD28] Requirements for Preparing and Implementing a Manufacturing and Inspection Plan (22MDZD v2.1)[RD29] CODAC Core System Installation Manual (33JNKW v4.5)[RD30] CODAC Core System Training (4F9M4T)[RD31] CODAC Core System Support Procedures (34EHTM v1.7)[RD32] Bugzilla Tutorial (33KAC4 v1.0)[RD33] Software Qualification Policy (KTU8HH v1.1)
5.1 Plant Control Design HandbookThe Plant Control Design Handbook (PCDH) [RD4] defines the methodology, standards, specifications and interfaces applicable to ITER plant systems’ instrumentation and control (I&C) system life cycle. I&C standards are essential for ITER to:
Integrate all plant systems into one integrated control system; Maintain all plant systems after delivery acceptance; Contain cost by economy of scale.
The PCDH comprises a core document which describes the plant system I&C life cycle and recaps the main rules to be applied to the plant system I&Cs for conventional controls, interlocks and safety controls. Some I&C topics will be explained in greater detail in dedicated documents associated with PCDH as presented on Figure 5-1. This document is one of them. Its objective is to describe the software engineering and quality assurance (QA) in more detail.
Figure 5-1: PCDH documentation structure
5.2 CODAC DDDThe Design Description Document for CODAC (DDD-45, [RD5]) describes CODAC design assumptions and solutions for them. Some of these topics are covered in more detail in the annex documents. This document is part of the DDD-45 package focusing on the system and software engineering and QA.
5.3 ITER MQPThis document is prepared in line with the ITER Management and Quality programme ([RD6]). In the MQP pyramid this document represents an MQP detailed plan.
Page 7 of 21
6 General MethodologyThis chapter gives a brief overview of the key elements of the CODAC system, software engineering and quality assurance.
6.1 ApproachITER system engineering is driven by the ISO/IEC 15288 international standard ([RD2]), as explained in the ITER Systems Engineering Management Plan, [RD1]. This standard has a compatible extension, ISO/IEC 12207 standard ([RD3]) focusing specifically on software life cycle. It is thus a natural choice to adopt the ISO/IEC 12207 standard for ITER CODAC software-related activities.The ISO/IEC 12207 standard breaks down all the software activities into groups of processes, which are presented in Figure 6-1. These processes are analysed in detail in chapter 7.3.
Figure 6-1: ISO/IEC 12207 life cycle processes
6.2 Project ClassificationProjects executed in the scope of CODAC activities are classified using project levels, called “software integrity levels” (SWIL). They represent a software-specific interpretation of the ITER quality classes defined in reference [RD7]. The aim of this classification is to apply rigorous quality control procedures for critical software projects and to relieve non-critical projects from unnecessary and time-consuming bureaucracy. Three levels of software integrity are defined; their description and mapping to ITER quality class is shown in Table 6-1.
Page 8 of 21
ITER QC Software Integrity Level QA Degree
QC1 N/A (no such systems in CODAC)
QC2 SWIL-1 – CODAC critical systems - Full traceability of requirements - 100% code coverage- Performance tests- Regression tests- Backward compatibility control- Specific release / deployment procedures- Full user and developer documentation
QC3 SWIL-2 – CODAC regular systems - Requirement / architecture documents- Unit and integration testing- Standard release / deployment procedures- User and developer documentation
QC4 SWIL-3 – CODAC auxiliary systems - Reduced QA (requirements, user documentation)- Tests are optional
Table 6-1: ITER CODAC software integrity levels
The assignment of the level of software integrity depends on the importance of the system and takes the risk analysis into account. Once the project level is defined, the key development milestones and deliverables are applied as follows (Table 6-2):
Final Software Implementation Review and Acceptance
SRC, STR, SUM SRC, STR, SUM SRC, STR, SUM
Table 6-2: Key milestones and deliverables for different project levels
More details on the metrics of project classification are given in the CODAC software development plan ([RD8]).
6.3 Principal DocumentationThe Software Documentation Management Process (see section 7.3.33) defines documentation to support the CODAC software life cycle. An overview of the documentation is shown in Figure 6-2.
Page 9 of 21
Figure 6-2: CODAC quality assurance documentation
The documentation is organized as follows:1) SEQA-45 – top level CODAC policy (this document), serving as an overview of system
and software engineering and quality assurance practices in the CODAC context. It is annexed to both the CODAC DDD ([RD5]) and to the Plant Control Design Handbook ([RD4]).
2) GP – ITER general system design and implementation guidelines, built on the basis of the ISO/IEC 15288 standard. The key document is the ITER Systems Engineering Management Plan, [RD1]; some other useful procedures are collected there. These procedures are largely applicable to the design of the CODAC infrastructure.
3) SP-45 – CODAC process customisations, mostly for software-specific processes of ISO/IEC 12207. These processes contain CODAC specifics, but can be reused or serve as an example for other IO divisions involved in I&C, or to IO/DA suppliers. The processes are covered by a number of management plans, listed below:
4) DT – various document templates, which must be used to support projects and processes in the scope of CODAC activities. They include in particular:
a. GT – general templates (ITER standard templates + customisations of them);b. SWT – software-related templates;c. IST – infrastructure support templates.
Page 10 of 21
5) SDSD – system and software development standards descriptions. This is a collection of project-independent manuals, how-to’s and guidelines, intended to describe system and software development practices which facilitate development, integration and maintenance of CODAC and CODAC-related systems. The SDSDs include in particular:
a. LS – language standards;b. DTG – development tool guidelines;c. DDM – device development methods;d. HWM – hardware manufacturing methods.
More information about the documentation is available in the software documentation management plan [RD12], or directly in the dedicated folder in IDM, 6J7RW4.
7 CODAC ISO/IEC 12207 ConformityThis chapter provides detailed analysis of the implementation of standard processes. The reader is invited to select processes of interest and check the details of their implementation.Hereafter, “the International Standard” refers to the ISO/IEC 12207, as defined in the reference [RD3].
7.1 ISO/IEC 12207 Conformity StatementCODAC claims tailored conformity for all processes defined in the International Standard, except for the Project Portfolio Management Process.The tailored conformity claim is based on the zero level analysis executed for existing practices of CODAC and ITER Organization. The ultimate goal of standardization is to go for full conformity for some of the aforementioned processes, subject to thorough analysis, documentation and adjustment of the existing processes. This will be gradually implemented in the future.
7.2 ISO/IEC 12207 Conformity MatrixThe Table 7-1 summarizes the current conformity level for CODAC. The cell color means the following: green – the process has been implemented (levels 1 to 5 on the process capability scale, as defined in Annex B of the Standard ([RD3])); yellow – the process has been partially implemented (level 0 on the process capability scale); red – the process is missing / not implemented; no color – the process is not applicable. The cell content means the following: “IO” – regular IO procedures apply; “IO + CODAC” – CODAC-specific procedures defined on top of the regular IO procedures; “CODAC” – the procedures defined only in the CODAC context.
№ Process CODAC implementation Details (see section)1 Acquisition Process IO + CODAC 7.3.12 Supply Process IO 7.3.23 Life Cycle Model Management Process CODAC 7.3.34 Infrastructure Management Process CODAC 7.3.45 Project Portfolio Management Process N/A 7.3.56 Human Resource Management Process IO + CODAC 7.3.67 Quality Management Process IO 7.3.78 Project Planning Process IO + CODAC 7.3.8
9 Project Assessment and Control Process IO + CODAC 7.3.910 Decision Management Process IO 7.3.1011 Risk Management Process IO + CODAC 7.3.1112 Configuration Management Process IO 7.3.1213 Information Management Process IO 7.3.1314 Measurement Management Process IO 7.3.1415 Stakeholder Requirements Definition Process IO 7.3.1516 System Requirements Analysis Process IO 7.3.1617 System Architectural Design Process IO 7.3.1718 Implementation Process IO 7.3.1819 System Integration Process IO 7.3.1920 System Qualification Testing Process IO 7.3.2021 Software Installation Process IO + CODAC 7.3.2122 Software Acceptance Support Process CODAC 7.3.2223 Software Operation Process IO + CODAC 7.3.2324 Software Maintenance Process CODAC 7.3.2425 Software Disposal Process CODAC 7.3.2526 Software Implementation Process CODAC 7.3.2627 Software Requirements Analysis Process CODAC 7.3.2728 Software Architectural Design Process CODAC 7.3.2829 Software Detailed Design Process CODAC 7.3.2930 Software Construction Process CODAC 7.3.3031 Software Integration Process CODAC 7.3.3132 Software Qualification Testing Process CODAC 7.3.3233 Software Documentation Management Process CODAC 7.3.3334 Software Configuration Management Process CODAC 7.3.3435 Software Quality Assurance Process CODAC 7.3.3536 Software Verification Process CODAC 7.3.3637 Software Validation Process CODAC 7.3.3738 Software Review Process CODAC 7.3.3839 Software Audit Process CODAC 7.3.3940 Software Problem Resolution Process CODAC 7.3.4041 Domain Engineering Process CODAC 7.3.4142 Reuse Asset Management Process CODAC 7.3.4243 Reuse Program Management Process CODAC 7.3.43
Table 7-1: ISO/IEC 12207 conformity matrix for CODAC
7.3 ISO/IEC 12207 ImplementationCODAC implements the ISO/IEC 12207 processes to a different level of completeness and/or robustness, depending on the current activities and priorities. Each process is introduced with the purpose taken directly from the standard. The following sections provide explanations of process implementation.
Page 12 of 21
7.3.1 Acquisition ProcessPurpose:The purpose of the Acquisition Process is to obtain the product and/or service that satisfy the need expressed by the acquirer. The process begins with the identification of customer needs and ends with the acceptance of the product and/or service needed by the acquirer.Implementation:Standard IO practices apply (defined and maintained by the IO Directorate for Administration, Procurement and Contract Division). The acquirer acceptance activity in the scope of PCDH is defined in reference [RD14].
7.3.2 Supply ProcessPurpose:The purpose of the Supply Process is to provide a product or service to the acquirer that meets the agreed requirements.Implementation:Standard IO practices apply (defined and maintained by the IO Directorate for Administration, Procurement and Contract Division). The quality requirements for procurement are defined in reference [RD15].
7.3.3 Life Cycle Model Management ProcessPurpose:The purpose of the Life Cycle Model Management Process is to define, maintain, and assure availability of policies, life cycle processes, life cycle models, and procedures for use by the organization with respect to the scope of this International Standard.This process provides life cycle policies, processes, and procedures that are consistent with the organization's objectives, that are defined, adapted, improved and maintained to support individual project needs within the context of the organization, and that are capable of being applied using effective, proven methods and tools.Implementation:This process is implemented selectively for the most important life cycle models, like the I&C life cycle, documented in the PCDH ([RD4]). The working instrument for this process is IDM (see [RD16]).
7.3.4 Infrastructure Management ProcessPurpose:The purpose of the Infrastructure Management Process is to provide the enabling infrastructure and services to projects to support organization and project objectives throughout the life cycle.This process defines, provides and maintains the facilities, tools, and communications and information technology assets needed for the organization’s business with respect to the scope of this International Standard.Implementation:CODAC has defined a strategy for infrastructure procurement and management which is described in references [RD17] and [RD18]. The process is supported by the inventory database [RD19] and is documented in the corresponding manual [RD20].
Page 13 of 21
7.3.5 Project Portfolio Management ProcessPurpose:The purpose of the Project Portfolio Management Process is to initiate and sustain necessary, sufficient and suitable projects in order to meet the strategic objectives of the organization.This process commits the investment of adequate organization funding and resources, and sanctions the authorities needed to establish selected projects. It performs continued qualification of projects to confirm they justify, or can be redirected to justify, continued investment.Implementation:This process is not very applicable in the ITER context. Certain R&D projects could be managed under this process.
7.3.6 Human Resource Management ProcessPurpose:The purpose of the Human Resource Management Process is to provide the organization with necessary human resources and to maintain their competencies, consistent with business needs.The process assures the providing of a supply of skilled and experienced personnel qualified to perform life cycle processes to achieve organization, project and customer objectives.Implementation:Standard organization practices apply (defined and maintained by the IO Directorate for Administration, Human Resources Division). The projected profile of CODAC staffing until the ITER D-T phase is available in references [RD17] and [RD18].
7.3.7 Quality Management ProcessPurpose:The purpose of the Quality Management Process is to assure that products, services and implementations of life cycle processes meet organizational quality objectives and achieve customer satisfaction.Implementation:Standard IO practices apply (defined and maintained by the IO Department for Safety, Quality and Security, Quality Assurance Division). The general process is described in the ITER quality assurance program, [RD21] . Software-specific procedures are covered in section 7.3.35.
7.3.8 Project Planning ProcessPurpose:The purpose of the Project Planning Process is to produce and communicate effective and workable project plans.This process determines the scope of the project management and technical activities, identifies process outputs, project tasks and deliverables, establishes schedules for project task conduct, including achievement criteria, and required resources to accomplish project tasks.Implementation:Standard IO practices apply (defined and maintained by the IO Directorate for Administration, Project Management Division).
Page 14 of 21
7.3.9 Project Assessment and Control ProcessPurpose:The purpose of the Project Assessment and Control Process is to determine the status of the project and ensure that the project performs according to plans and schedules, and within projected budgets, and that it satisfies technical objectives.This process includes redirecting the project activities, as appropriate, to correct identified deviations and variations from other project management or technical processes. Redirection may include replanning as appropriate.Implementation:Standard IO practices apply (defined and maintained by the IO Directorate for Administration, Project Management Division).
7.3.10 Decision Management ProcessPurpose:The purpose of the Decision Management Process is to select the most beneficial course of project action where alternatives exist.This process responds to a request for a decision encountered during the system life cycle, whatever its nature or source, in order to reach specified, desirable or optimized outcomes. Alternative actions are analyzed and a course of action selected and directed. Decisions and their rationale are recorded to support future decision-making.Implementation:Standard IO practices apply (defined and maintained by the IO Directorate for Administration, Project Management Division).
7.3.11 Risk Management ProcessPurpose:The purpose of the Risk Management Process is to identify, analyze, treat and monitor the risks continuously.The Risk Management Process is a continuous process for systematically addressing risk throughout the life cycle of a system or software product or service. It can be applied to risks related to the acquisition, development, maintenance or operation of a system.Implementation:Standard IO practices apply (defined and maintained by the IO Department for Administration, Project Management Division). Software management aspects are covered in the CODAC software development plan [RD8].
7.3.12 Configuration Management ProcessPurpose:The purpose of the Configuration Management Process is to establish and maintain the integrity of all identified outputs of a project or process and make them available to concerned parties.Implementation:Standard IO practices apply (defined and maintained by the IO Department for ITER Project, Technical Integration Division). Software-specific procedures are covered in section 7.3.34.
Page 15 of 21
7.3.13 Information Management ProcessPurpose:The purpose of the Information Management Process is to provide relevant, timely, complete, valid and, if required, confidential information to designated parties during and, as appropriate, after the system life cycle.This process generates, collects, transforms, retains, retrieves, disseminates and disposes of information. It manages designated information, including technical, project, organizational, agreement and user information.Implementation:Standard IO practices apply (defined and maintained by the IO Directorate for Administration, Document Control and Project Information System Sections). The principal instrument is IDM (see [RD16]). Standard document templates are given in reference [RD22].
7.3.14 Measurement Management ProcessPurpose:The purpose of the Measurement Process is to collect, analyze, and report data relating to the products developed and processes implemented within the organizational unit, to support effective management of the processes and to objectively demonstrate the quality of the products.Implementation:Standard IO practices apply (defined and maintained by the IO Directorate for Administration, Project Management Division).
7.3.15 Stakeholder Requirements Definition ProcessPurpose:The purpose of the Stakeholder Requirements Definition Process is to define the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment.It identifies stakeholders, or stakeholder classes, involved with the system throughout its life cycle, and their needs and desires. It analyzes and transforms these into a common set of stakeholder requirements that express the intended interaction the system will have with its operational environment and that are the reference against which each resulting operational service is validated in order to confirm that the system fulfils needs.Implementation:Standard IO practices apply (defined and maintained by the IO Department for ITER Project, Technical Integration Division).
7.3.16 System Requirements Analysis ProcessPurpose:The purpose of System Requirements Analysis is to transform the defined stakeholder requirements into a set of desired system technical requirements that will guide the design of the system.Implementation:Standard IO practices apply (defined and maintained by the IO Department for ITER Project, Technical Integration Division). System requirements are maintained as set of change
Page 16 of 21
controlled documents, available in reference [RD23]. The tool to manage requirements is DOORS (see [RD24]).
7.3.17 System Architectural Design ProcessPurpose:The purpose of the System Architectural Design Process is to identify which system requirements should be allocated to which elements of the system.Implementation:Standard IO practices apply (defined and maintained by the IO Department for ITER Project, Technical Integration Division). The design process is explained in the working instruction, [RD25]; the design review procedure is described in reference [RD26] and the design description documents are available in reference [RD27].
7.3.18 Implementation ProcessPurpose:The purpose of the Implementation Process is to realize a specified system element.Implementation:Standard IO practices apply (defined and maintained by the IO Department for ITER Project, Technical Integration Division). More information is available in the Requirements for Manufacturing Plans [RD28].
7.3.19 System Integration ProcessPurpose:The purpose of the System Integration Process is to integrate the system elements (including software items, hardware items, manual operations and other systems, as necessary) to produce a complete system that will satisfy the system design and the customers’ expectations expressed in the system requirements.Implementation:Standard IO practices apply (defined and maintained by the IO Department for ITER Project, Technical Integration Division). For systems procured in the scope of the PCDH, the details are available in the corresponding integration plan, [RD14].
7.3.20 System Qualification Testing ProcessPurpose:The purpose of the Systems Qualification Testing Process is to ensure that the implementation of each system requirement is tested for compliance and that the system is ready for delivery.Implementation:Standard IO practices apply (defined and maintained by the IO Department for Safety, Quality and Security, Quality Assurance Division).
7.3.21 Software Installation ProcessPurpose:The purpose of the Software Installation Process is to install the software product that meets the agreed requirements in the target environment.Implementation:
Page 17 of 21
CODAC has defined a specific procedure of software subscription, distribution, installation and updates, described in reference [RD29]. The user documentation is available in reference [RD30]. Otherwise, for Windows-based systems and standard office software, standard IO practices apply (defined and maintained by the IO Directorate for Administration, Project Information System Section).
7.3.22 Software Acceptance Support ProcessPurpose:The purpose of the Software Acceptance Support Process is to assist the acquirer to achieve confidence that the product meets requirements.Implementation:CODAC delivers its products in accordance with the software installation process (see section 7.3.21). To support acquirer acceptance, the CODAC team runs training sessions for the software delivered (see [RD30] for details). Software problems found in the customer’s environment are resolved in accordance with the software operation process, described in section 7.3.23.
7.3.23 Software Operation ProcessPurpose:The purpose of the Software Operation Process is to operate the software product in its intended environment and to provide support to the customers of the software product.Implementation:The operation strategy will be defined by the Department for ITER Project, Assembly and Operations Division. CODAC contributes to this process by providing conditions for correct operation of the software in its intended environment. A helpdesk is established to react to problems encountered in the customer’s environment. Support procedures are defined in reference [RD31].
7.3.24 Software Maintenance ProcessPurpose:The purpose of the Software Maintenance Process is to provide cost-effective support to a delivered software product.Implementation:The CODAC maintenance process is described in reference [RD31]. The detailed follow-up is done using Bugzilla (see [RD32]).
7.3.25 Software Disposal ProcessPurpose:The purpose of the Software Disposal Process is to end the existence of a system’s software entity.This process ends active support by the operation and maintenance organization, or deactivates, disassembles and removes the affected software products, consigning them to a final condition and leaving the environment in an acceptable condition. This process destroys or stores system software elements and related products in a sound manner, in accordance with legislation, agreements, organizational constraints and stakeholder requirements. Where required, it maintains records that may be monitored.Implementation:
Page 18 of 21
Currently this process is not implemented on its own and exists as part of the Software Installation Process (see section 7.3.21). Knowledge retention and software archive are implemented as a part of the Software Configuration Management Process (see section 7.3.34).
7.3.26 Software Implementation ProcessPurpose:The purpose of the Software Implementation Process is to produce a specified system element implemented as a software product or service.This process transforms specified behavior, interfaces and implementation constraints into actions that create a system element implemented as a software product or service, otherwise known as a "software item." This process results in a software item that satisfies architectural design requirements through verification and stakeholder requirements through validation.Implementation:This is a principal process implemented by CODAC. It is documented in the CODAC software development plan [RD8].
7.3.27 Software Requirements Analysis ProcessPurpose:The purpose of Software Requirements Analysis Process is to establish the requirements of the software elements of the system.Implementation:This process is a lower-level process of the Software Implementation Process (see section 7.3.26).
7.3.28 Software Architectural Design ProcessPurpose:The purpose of the Software Architectural Design Process is to provide a design for the software that implements and can be verified against the requirements.Implementation:This process is a lower-level process of the Software Implementation Process (see section 7.3.26).
7.3.29 Software Detailed Design ProcessPurpose:The purpose of the Software Detailed Design Process is to provide a design for the software that implements and can be verified against the requirements and the software architecture and is sufficiently detailed to permit coding and testing.Implementation:This process is a lower-level process of the Software Implementation Process (see section 7.3.26).
7.3.30 Software Construction ProcessPurpose:The purpose of the Software Construction Process is to produce executable software units that properly reflect the software design.Implementation:
Page 19 of 21
This process is a lower-level process of the Software Implementation Process (see section 7.3.26).
7.3.31 Software Integration ProcessPurpose:The purpose of the Software Integration Process is to combine the software units and software components, producing integrated software items, consistent with the software design, that demonstrate that the functional and non-functional software requirements are satisfied on an equivalent or complete operational platform.Implementation:This process is a lower-level process of the Software Implementation Process (see section 7.3.26).
7.3.32 Software Qualification Testing ProcessPurpose:The purpose of the Software Qualification Testing Process is to confirm that the integrated software product meets its defined requirements.Implementation:This process is a lower-level process of the Software Implementation Process (see section 7.3.26). A general ITER policy is equally defined ([RD33]).
7.3.33 Software Documentation Management ProcessPurpose:The purpose of the Software Documentation Management Process is to develop and maintain the recorded software information produced by a process.Implementation:This process is a specialization of the Information Management Process from the Project Process Group (see section 7.3.13). The software-specific guidelines are given in CODAC software documentation management plan [RD12]. CODAC software documentation templates (see chapter 6.3) are based on general ITER templates.
7.3.34 Software Configuration Management ProcessPurpose:The purpose of the Software Configuration Management Process is to establish and maintain the integrity of the software items of a process or project and make them available to concerned parties.Implementation:This process is a specialization of the Configuration Management Process from the Project Process Group (see section 7.3.12). The software-specific guidelines are given in the CODAC software configuration management plan [RD11]. The principal working tool is Subversion.
7.3.35 Software Quality Assurance ProcessPurpose:The purpose of the Software Quality Assurance Process is to provide assurance that work products and processes comply with predefined provisions and plans.Implementation:
Page 20 of 21
This process is executed in accordance with the CODAC software quality assurance plan [RD9]. The principal tracking tool is Bugzilla.
7.3.36 Software Verification ProcessPurpose:The purpose of the Software Verification Process is to confirm that each software work product and/or service of a process or project properly reflects the specified requirements.Implementation:This process is executed in accordance with the CODAC software verification and validation plan [RD10].
7.3.37 Software Validation ProcessPurpose:The purpose of the Software Validation Process is to confirm that the requirements for a specific intended use of the software work product are fulfilled.Implementation:This process is executed in accordance with the CODAC software verification and validation plan [RD10].
7.3.38 Software Review ProcessPurpose:The purpose of the Software Review Process is to maintain a common understanding with the stakeholders of the progress against the objectives of the agreement and what should be done to help ensure development of a product that satisfies the stakeholders. Software reviews are at both project management and technical levels and are held throughout the life of the project.Implementation:This process is executed in accordance with the CODAC software quality assurance plan [RD9].
7.3.39 Software Audit ProcessPurpose:The purpose of the Software Audit Process is to independently determine compliance of selected products and processes with the requirements, plans and agreements, as appropriate.Implementation:This process is executed in accordance with the CODAC software quality assurance plan [RD9].
7.3.40 Software Problem Resolution ProcessPurpose:The purpose of the Software Problem Resolution Process is to ensure that all discovered problems are identified, analyzed, managed and controlled to resolution.Implementation:This process is executed in accordance with the CODAC software quality assurance plan [RD9].
Page 21 of 21
7.3.41 Domain Engineering ProcessPurpose:The purpose of the Domain Engineering Process is to develop and maintain domain models, domain architectures and assets for the domain.Implementation:The processes 7.3.41, 7.3.42, 7.3.43 have currently only been partially implemented and have not yet been documented properly; a more formalized approach and better implementation are planned for the future.
7.3.42 Reuse Asset Management ProcessPurpose:The purpose of the Reuse Asset Management Process is to manage the life of reusable assets from conception to retirement.Implementation:See section 7.3.41.
7.3.43 Reuse Program Management ProcessPurpose:The purpose of the Reuse Program Management Process is to plan, establish, manage, control, and monitor an organization’s reuse program and to systematically exploit reuse opportunities.Implementation:See section 7.3.41.
