IDM UID
2NRS2K
VERSION CREATED ON / VERSION / STATUS
17 Nov 2011 / 3.1 / APPROVED
EXTERNAL REFERENCE
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.
Author
CoAuthor
Reviewers
Approver
Read Access
Name
Stepanov D.
Approval Process
Action
17-Nov-2011:signed
Klotz W.- D.
Wallander A.
Bora D.
Affiliation
IO/DG/DIP/CHD/CSD/CDC
21-Nov-2011:recommended
IO/DG/DIP/CHD/CSD
17-Nov-2011:recommended
IO/DG/DIP/CHD/CSD/CDC
22-Nov-2011:approved
IO/DG/DIP/CHD
Document Security: level 1 (IO unclassified)
RO: Stepanov Denis
AD: ITER, AD: External Collaborators, AD: Division - Control System Division - EXT, AD: Section CODAC - EXT, AD: Division - Control System Division, AD: Section - CODAC, AD: ITER Management
Assessor, project administrator, RO, AD: Section - Plant Control and Instrumentation
PDF generated on 23-Nov-2011
Title (Uid)
SEQA-45 - Software
Engineering and Quality
Assurance for CODAC
(2NRS2K_v3_1)
SEQA-45 - Software
Engineering and Quality
Assurance for CODAC
(2NRS2K_v3_0)
SEQA-45 - Software
Engineering and Quality
Assurance for CODAC
(2NRS2K_v2_1)
SEQA-45 - Software
Engineering and Quality
Assurance for CODAC
(2NRS2K_v2_0)
SEQA-45 - Software
Engineering and Quality
Assurance for CODAC
(2NRS2K_v1_0)
Change Log
Issue Date
17 Nov
2011
Version
v3.1
Latest Status
Approved
Description of Change
The version for the CODAC PDR:
- Updated the documentation overview figure;
- Implemented comments from J.Poole.
v3.0
In Work
20 Oct
2011
Major rewrite in view of ISO/IEC 12207
conformance. Version for internal review.
v2.1
Approved
11 Feb
2011
Minor corrections after the internal and external
reviews.
v2.0
Signed
10 Jan 2011
Updated for the inclusion into the PCDH v6.
v1.0
Approved
22 Jul 2009
PDF generated on 23-Nov-2011
Table of contents
1
INTRODUCTION...................................................................................................................3
1.1
1.2
1.3
1.4
1.5
1.6
2
Purpose ...............................................................................................................................3
PCDH Context ...................................................................................................................3
DDD-45 Context.................................................................................................................4
Scope ...................................................................................................................................4
Definitions...........................................................................................................................4
References...........................................................................................................................6
CODAC ISO/IEC 12207 CONFORMITY ............................................................................7
2.1 Approach ............................................................................................................................7
2.2 ISO/IEC 12207 Conformity Statement............................................................................7
2.3 ISO/IEC 12207 Conformity Matrix .................................................................................8
2.4 ISO/IEC 12207 Implementation Details ..........................................................................9
2.4.1 Acquisition Process......................................................................................................10
2.4.2 Supply Process .............................................................................................................10
2.4.3 Life Cycle Model Management Process ......................................................................10
2.4.4 Infrastructure Management Process.............................................................................10
2.4.5 Project Portfolio Management Process ........................................................................11
2.4.6 Human Resource Management Process.......................................................................11
2.4.7 Quality Management Process ......................................................................................11
2.4.8 Project Planning Process..............................................................................................11
2.4.9 Project Assessment and Control Process .....................................................................12
2.4.10 Decision Management Process ....................................................................................12
2.4.11 Risk Management Process ...........................................................................................12
2.4.12 Configuration Management Process ............................................................................13
2.4.13 Information Management Process ...............................................................................13
2.4.14 Measurement Management Process.............................................................................13
2.4.15 Stakeholder Requirements Definition Process.............................................................13
2.4.16 System Requirements Analysis Process ......................................................................14
2.4.17 System Architectural Design Process ..........................................................................14
2.4.18 Implementation Process ...............................................................................................14
2.4.19 System Integration Process ..........................................................................................14
2.4.20 System Qualification Testing Process .........................................................................15
2.4.21 Software Installation Process .......................................................................................15
2.4.22 Software Acceptance Support Process.........................................................................15
2.4.23 Software Operation Process .........................................................................................15
2.4.24 Software Maintenance Process ....................................................................................16
2.4.25 Software Disposal Process ...........................................................................................16
2.4.26 Software Implementation Process................................................................................16
2.4.27 Software Requirements Analysis Process....................................................................16
2.4.28 Software Architectural Design Process .......................................................................17
2.4.29 Software Detailed Design Process ...............................................................................17
2.4.30 Software Construction Process ....................................................................................17
2.4.31 Software Integration Process .......................................................................................17
2.4.32 Software Qualification Testing Process.......................................................................18
2.4.33 Software Documentation Management Process ..........................................................18
Page 1 of 22
2.4.34
2.4.35
2.4.36
2.4.37
2.4.38
2.4.39
2.4.40
2.4.41
2.4.42
2.4.43
Software Configuration Management Process.............................................................18
Software Quality Assurance Process ...........................................................................18
Software Verification Process......................................................................................18
Software Validation Process ........................................................................................19
Software Review Process.............................................................................................19
Software Audit Process................................................................................................19
Software Problem Resolution Process .........................................................................19
Domain Engineering Process .......................................................................................19
Reuse Asset Management Process...............................................................................20
Reuse Program Management Process ..........................................................................20
3
PRINCIPAL DOCUMENTATION.....................................................................................21
4
PROJECT CLASSIFICATION...........................................................................................22
Page 2 of 22
1 INTRODUCTION
1.1
Purpose
This document describes general rules, practices and recommendations for software
engineering in the scope of ITER CODAC activities.
1.2
PCDH Context
The Plant Control Design Handbook (PCDH) [RD1] 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 presents 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 1-1. This document is one of them.
Its objective is to describe the software engineering and quality assurance (QA) in more detail.
Figure 1-1: PCDH documentation structure
Page 3 of 22
1.3
DDD-45 Context
The Design Description Document for CODAC (DDD-45, [RD2]) describes CODAC design
assumptions and candidate solutions for them. Some of these topics are covered in more detail
in the annex documents. This document makes a part of the DDD-45 package focusing on the
software engineering and QA topic.
1.4
Scope
This document describes general rules, practices and recommendations for software
engineering in the scope of ITER CODAC activities. It defines the overall approach;
technology-specific topics are described in separate reference documents.
The content of this document applies to the development of the CODAC System (PBS 45).
Plant system I&Cs prepared in the scope of the PCDH are also subject to these requirements.
The Central Interlock System (PBS 46), the plasma control algorithms (PBS 47), and Central
Safety Systems (PBS 48) are not addressed yet.
This document is primarily focused on the CODAC System (PBS 45). Chapter 2 gives a
standard conformity statement for CODAC.
Software for control system elements qualified as 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 will be selected in such a way
that their integration does not degrade the overall quality level of CODAC.
1.5
Definitions
Many terms and definitions used in this document are explained in the glossary of the ISO/IEC
12207 standard ([RD3]).
The ISO/IEC 12207 standard is 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. System
engineering in the I&C context is addressed by the PCDH ([RD1]) and this annex document is
focused on software engineering. For some processes the system engineering for I&C follows
the same life cycle as for its plant system and is thus governed by overall ITER Organization
(IO) practices; this is noted specifically in section 2.2.
The following abbreviations and acronyms are used in this document (Table 1-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
Page 4 of 22
DOORS
Dynamic Object Oriented Requirements System
DR
Document Review
DT
Document Templates
EPICS
Experimental Physics and Industrial Control System
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
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
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
Page 5 of 22
STP
Software Test Plan
STR
Software Test Report
SUM
Software User Manual
SVN
SubVersioN
SW
SoftWare
TBD
To Be Defined
-T
Template
-β
Beta- or draft version
Table 1-1: Abbreviations
1.6
References
[RD1]
[RD2]
[RD3]
[RD4]
[RD5]
[RD6]
[RD7]
[RD8]
[RD9]
[RD10]
[RD11]
[RD12]
[RD13]
[RD14]
[RD15]
[RD16]
[RD17]
[RD18]
[RD19]
[RD20]
[RD21]
[RD22]
[RD23]
[RD24]
[RD25]
Plant Control Design Handbook (27LH2V v6.1)
CODAC DDD (6M58M9 v1.1)
ISO/IEC FDIS 12207:2008(E) (http://www.iso.org/iso/catalogue_detail?csnumber=43447)
Plant Systems Factory Acceptance Plan for I&C systems (3VVU9W v1.5)
ITER Procurement Quality Requirements (22MFG4 v4.0)
IDM Manual (22223J v5.12)
Central I&C Systems - Implementation Plan (33HDSA v1.0)
CODAC Inventory Management System (4EEDXH)
Linux Admin Pages (https://portal.iter.org/departments/CHD/CODAC/Linux%20Admin/1ndex.aspx)
SPMP-45 – Software Project Management Plan for CODAC (6SGJKJ, version TBD)
ITER Quality Assurance Program (22K4QX v7.3)
ITER Templates (2DJT9B)
System Requirements Documents (SRDs) (29D6G7)
Using DOORS on ITER Technical Baseline Documents (2MR6Z9 v1.1)
Design Review Procedure (2832CF v1.12)
System Design Description Documents (DDDs) (29D8PA)
CODAC Core System Installation Manual (33JNKW v1.17)
CODAC Core System Training (4F9M4T)
CODAC Core System Support Procedures (34EHTM v1.3)
Core Systems Roadmap (2LTB5T v3.0)
Bugzilla Tutorial (33KAC4 v1.0)
SDP-45 – Software Development Plan for CODAC (6SLYRM v1.0)
SDMP-45 – Software Documentation Management Plan for CODAC (6SR4UQ v1.0)
SCMP-45 – Software Configuration Management Plan for CODAC (6SNQCR v1.0)
SQAP-45 – Software Quality Assurance Plan for CODAC (6SNDEV v1.0)
Page 6 of 22
2 CODAC ISO/IEC 12207 CONFORMITY
2.1
Approach
CODAC has decided to follow the ISO/IEC 12207 international standard ([RD3]) for its
software-related activities. This standard breaks down all the software activities into groups of
processes, which are presented in Figure 2-1.
Figure 2-1: ISO/IEC 12207 life cycle processes
Hereafter, “the International Standard” refers to the ISO/IEC 12207, as defined in the reference
[RD3].
2.2
ISO/IEC 12207 Conformity Statement
CODAC claims tailored conformity for all processes defined in the ISO/IEC 12207
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.
Page 7 of 22
2.3
ISO/IEC 12207 Conformity Matrix
The Table 2-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
1
Acquisition Process
2
Supply Process
3
CODAC implementation
Details (see section)
IO + CODAC
2.4.1
IO
2.4.2
Life Cycle Model Management Process
CODAC
2.4.3
4
Infrastructure Management Process
CODAC
2.4.4
5
Project Portfolio Management Process
N/A
2.4.5
6
Human Resource Management Process
IO + CODAC
2.4.6
7
Quality Management Process
IO
2.4.7
8
Project Planning Process
IO + CODAC
2.4.8
9
Project Assessment and Control Process
IO + CODAC
2.4.9
10
Decision Management Process
IO
2.4.10
11
Risk Management Process
IO + CODAC
2.4.11
12
Configuration Management Process
IO
2.4.12
13
Information Management Process
IO
2.4.13
14
Measurement Management Process
IO
2.4.14
15
Stakeholder Requirements Definition Process
IO
2.4.15
16
System Requirements Analysis Process
IO
2.4.16
17
System Architectural Design Process
IO
2.4.17
18
Implementation Process
IO
2.4.18
19
System Integration Process
IO
2.4.19
20
System Qualification Testing Process
IO
2.4.20
Page 8 of 22
21
Software Installation Process
IO + CODAC
2.4.21
22
Software Acceptance Support Process
CODAC
2.4.22
23
Software Operation Process
IO + CODAC
2.4.23
24
Software Maintenance Process
CODAC
2.4.24
25
Software Disposal Process
CODAC
2.4.25
26
Software Implementation Process
CODAC
2.4.26
27
Software Requirements Analysis Process
CODAC
2.4.27
28
Software Architectural Design Process
CODAC
2.4.28
29
Software Detailed Design Process
CODAC
2.4.29
30
Software Construction Process
CODAC
2.4.30
31
Software Integration Process
CODAC
2.4.31
32
Software Qualification Testing Process
CODAC
2.4.32
33
Software Documentation Management Process
CODAC
2.4.33
34
Software Configuration Management Process
CODAC
2.4.34
35
Software Quality Assurance Process
CODAC
2.4.35
36
Software Verification Process
CODAC
2.4.36
37
Software Validation Process
CODAC
2.4.37
38
Software Review Process
CODAC
2.4.38
39
Software Audit Process
CODAC
2.4.39
40
Software Problem Resolution Process
CODAC
2.4.40
41
Domain Engineering Process
CODAC
2.4.41
42
Reuse Asset Management Process
CODAC
2.4.42
43
Reuse Program Management Process
CODAC
2.4.43
Table 2-1: ISO/IEC 12207 conformity matrix for CODAC
2.4
ISO/IEC 12207 Implementation Details
CODAC implements the ISO/IEC 12207 processes to a different level of completeness and/or
robustness, depending on the current activities and priorities. The following sections provide
explanations of process implementation.
Page 9 of 22
2.4.1
Acquisition Process
Purpose:
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 Department for Administration,
Procurement and Contract Division). The acquirer acceptance activity in the scope of PCDH is
defined in reference [RD4].
2.4.2
Supply Process
Purpose:
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 Department for Administration,
Procurement and Contract Division). The quality requirements for procurement are defined in
reference [RD5].
2.4.3
Life Cycle Model Management Process
Purpose:
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 ([RD1]). The working instrument for this process is IDM
(see [RD6]).
2.4.4
Infrastructure Management Process
Purpose:
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.
Page 10 of 22
Implementation:
CODAC has defined a strategy for infrastructure procurement and management which is
described in references [RD7] and Error! Reference source not found.. The process is
supported by the inventory database [RD8] and is documented in SharePoint [RD9].
2.4.5
Project Portfolio Management Process
Purpose:
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.
2.4.6
Human Resource Management Process
Purpose:
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 Department for
Administration, Human Resources Division). Projected profile of CODAC hiring until the
ITER D-T phase is available in reference [RD7]. Software management aspects are covered in
the CODAC software project management plan [RD10].
2.4.7
Quality Management Process
Purpose:
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 [RD10].
Software-specific procedures are covered in section 2.4.35.
Page 11 of 22
2.4.8
Project Planning Process
Purpose:
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 Department for Administration,
Project Management Division). Software management aspects are covered in the CODAC
software project management plan [RD10].
2.4.9
Project Assessment and Control Process
Purpose:
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 Department for Administration,
Project Management Division). Software management aspects are covered in the CODAC
software project management plan [RD10].
2.4.10 Decision Management Process
Purpose:
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 Department for Administration,
Project Management Division).
2.4.11 Risk Management Process
Purpose:
The purpose of the Risk Management Process is to identify, analyze, treat and monitor the risks
continuously.
Page 12 of 22
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 project management plan [RD10].
2.4.12 Configuration Management Process
Purpose:
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 2.4.34.
2.4.13 Information Management Process
Purpose:
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 Department for Administration,
Document Control and Project Information System Sections). The principal instrument is IDM
(see [RD6]). Standard document templates are given in reference [RD12].
2.4.14 Measurement Management Process
Purpose:
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 Department for Administration,
Project Management Division).
Page 13 of 22
2.4.15 Stakeholder Requirements Definition Process
Purpose:
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).
2.4.16 System Requirements Analysis Process
Purpose:
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
controlled documents, available in reference [RD13]. The tool to manage requirements is
DOORS (see [RD14]).
2.4.17 System Architectural Design Process
Purpose:
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 review procedure is described in reference [RD15]
and the design description documents are available in reference [RD16].
2.4.18 Implementation Process
Purpose:
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).
Page 14 of 22
2.4.19 System Integration Process
Purpose:
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).
2.4.20 System Qualification Testing Process
Purpose:
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).
2.4.21 Software Installation Process
Purpose:
The purpose of the Software Installation Process is to install the software product that meets
the agreed requirements in the target environment.
Implementation:
CODAC has defined a specific procedure of software subscription, distribution, installation
and updates, described in reference [RD9]. The user documentation is available in reference
[RD17]. Otherwise, for Windows-based systems and standard office software, standard IO
practices apply (defined and maintained by the IO Department for Administration, Project
Information System Section).
2.4.22 Software Acceptance Support Process
Purpose:
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
2.4.21). To support acquirer acceptance the CODAC team runs training sessions for the
delivered software (see [RD18] for details). Software problems found in the customer’s
environment are resolved in accordance with the software operation process, described in
section 2.4.23.
Page 15 of 22
2.4.23 Software Operation Process
Purpose:
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 customer’s environment. Support procedures are defined in reference
[RD19].
2.4.24 Software Maintenance Process
Purpose:
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 references [RD7] and [RD20]. The detailed
follow-up is done using Bugzilla (see [RD21]).
2.4.25 Software Disposal Process
Purpose:
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:
Currently this process is not implemented on its own and exists as part of the Software
Installation Process (see section 2.4.21). Knowledge retention and software archive are
implemented as a part of the Software Configuration Management Process (see section 2.4.34).
2.4.26 Software Implementation Process
Purpose:
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.
Page 16 of 22
Implementation:
This is a principal process implemented by CODAC. It is documented in the CODAC software
development plan [RD22].
2.4.27 Software Requirements Analysis Process
Purpose:
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
2.4.26).
2.4.28 Software Architectural Design Process
Purpose:
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
2.4.26).
2.4.29 Software Detailed Design Process
Purpose:
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
2.4.26).
2.4.30 Software Construction Process
Purpose:
The purpose of the Software Construction Process is to produce executable software units that
properly reflect the software design.
Implementation:
This process is a lower-level process of the Software Implementation Process (see section
2.4.26).
2.4.31 Software Integration Process
Purpose:
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
Page 17 of 22
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
2.4.26).
2.4.32 Software Qualification Testing Process
Purpose:
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
2.4.26).
2.4.33 Software Documentation Management Process
Purpose:
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 2.4.13). The software-specific guidelines are given in CODAC
software documentation management plan [RD23]. CODAC software documentation templates
(see chapter 3) are based on general ITER templates.
2.4.34 Software Configuration Management Process
Purpose:
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 2.4.12). The software-specific guidelines are given in the CODAC
software configuration management plan [RD24]. The principal working tool is Subversion.
2.4.35 Software Quality Assurance Process
Purpose:
The purpose of the Software Quality Assurance Process is to provide assurance that work
products and processes comply with predefined provisions and plans.
Implementation:
This process is executed in accordance with the CODAC software quality assurance plan
[RD25]. The principal tracking tool is Bugzilla.
Page 18 of 22
2.4.36 Software Verification Process
Purpose:
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 quality assurance plan
[RD25].
2.4.37 Software Validation Process
Purpose:
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 quality assurance plan
[RD25].
2.4.38 Software Review Process
Purpose:
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
[RD25].
2.4.39 Software Audit Process
Purpose:
The purpose of the Software Audit Process is to independently determine compliance of
selected products and processes with the requirements, plans and agreement, as appropriate.
Implementation:
This process is executed in accordance with the CODAC software quality assurance plan
[RD25].
2.4.40 Software Problem Resolution Process
Purpose:
The purpose of the Software Problem Resolution Process is to ensure that all discovered
problems are identified, analyzed, managed and controlled to resolution.
Implementation:
Page 19 of 22
This process is executed in accordance with the CODAC software quality assurance plan
[RD25].
2.4.41 Domain Engineering Process
Purpose:
The purpose of the Domain Engineering Process is to develop and maintain domain models,
domain architectures and assets for the domain.
Implementation:
The processes 2.4.41, 2.4.42, 2.4.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.
2.4.42 Reuse Asset Management Process
Purpose:
The purpose of the Reuse Asset Management Process is to manage the life of reusable assets
from conception to retirement.
Implementation:
See section 2.4.41.
2.4.43 Reuse Program Management Process
Purpose:
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 2.4.41.
Page 20 of 22
3 PRINCIPAL DOCUMENTATION
The Software Documentation Management Process (see section 2.4.33) defines documentation
to support the CODAC software life cycle. An overview of the documentation is shown in
Figure 3-1.
CODAC-specific
PBS-neutral
DDD-45
(6M58M9)
PCDH
(27LH2V)
Other IO documents
(ADM, SQS, CIE procedures)
ISO/IEC 12207 System Context Processes (SCP)
(annex)
(annex)
ISO/IEC 12207 Software Specific Processes (SSP)
SEQA-45
(2NRS2K)
SSP-45 - Software Specific Processes
DT - Document Templates
SDP-45 (6SLYRM)
SDP-T (6SBM8H)
SRS-T (6SBM8H)
SQAP-45 (6SNDEV)
SQAP-T (6SCS8T)
SADD-T (6S6B8E)
SCMP-45 (6SNQCR)
SCMP-T(6SHDUZ)
STP-T (3PD8H3)
SPMP-45 (6SGJKJ)
SPMP-T(6SLABB)
STR-T (6SBGVY)
SDMP-45 (6SR4UQ)
SDMP-T(6SHSCD)
SUM-T (3QSXSE)
GD-T (33ZDG3)
SDSD-T (6SJPHF)
SDSD – Development Standards
Language Standards
(Java, Python, C, SQL, …)
Development Tool Guidelines
(SVN, Bugzilla, Maven, …)
Device Development Methods
(EPICS, PLC, FPGA, …)
DR-T (6S7242)
Figure 3-1: Software-related documentation
The documentation is organized as follows:
1) SCP-45 – system context processes for CODAC. These include the CODAC DDD
([RD2]), the PCDH ([RD1]) for plant system-specific processes and a number of ITER
Organization documents mentioned in section 2.4.
2) SEQA-45 – this document, summarizing CODAC approach to software engineering
and quality assurance;
3) SSP-45 – supporting documentation for the CODAC software specific processes. These
include in particular:
a. SDP-45 – CODAC software development plan, [RD22] ;
b. SQAP-45 – CODAC software quality assurance plan, [RD25];
c. SCMP-45 – CODAC software configuration management plan, [RD24];
d. SPMP-45 – CODAC software project management plan, [RD10];
e. SDMP-45 – CODAC documentation management plan, [RD23];
4) DT – various document templates, which must be used to implement projects and
processes in the scope of CODAC activities.
5) SDSD – software development standards descriptions. This is a collection of projectindependent manuals, how-to’s and guidelines, intended to describe software
development practices which facilitate development, integration and maintenance of
software.
More information about the documentation is available in the software documentation
management plan [RD23].
Page 21 of 22
4 PROJECT CLASSIFICATION
Projects executed in the scope of CODAC activities are classified using project levels. The aim
of this classification is to apply rigorous quality control procedures for critical projects and to
relieve non-critical projects from unnecessary time-consuming bureaucracy. Three levels of
projects are defined, as shown in Table 4-1; the evaluation depends on project complexity and
confidence in implementation.
Complexity \ Risk
High risk
Medium risk Low risk
Complex
L1
L1
L2
Medium
L1
L2
L3
Easy
L2
L3
L3
Table 4-1: Project classification
Apart from complexity and risk analysis, other factors may influence project classification
(e.g., a fixed level of quality assurance for a given task or contract). Once the project level is
defined, the key development milestones and deliverables are applied as follows (Table 4-2):
Milestones & Deliverables
L1
L2
L3
Software Requirements Review
SRS
SRS
SRS
Preliminary Software Design Review
SADD-β, STP-β
–
–
Final Software Design Review
SADD, STP
SADD, STP
–
Preliminary Software Implementation Review
SRC-β, STR-β, SUM-β
–
–
Final Software Implementation Review and
Acceptance
SRC, STR, SUM
SRC, STR, SUM
SRC, STR, SUM
Table 4-2: Key milestones and deliverables for different project levels
More details on the metrics of project classification are given in the CODAC software project
management plan ([RD10]). With regard to ISO/IEC 12207 processes, the projects executed in
the scope of CODAC activities should rely on and follow the processes described for the
CODAC system (see chapter 2).
Page 22 of 22