SEQA-45 - Software Engineering and Quality Assurance for ... - Iter

Change LogTitle (Uid) Version Latest Status Issue Date Description of Changev3.1 Approved 17 Nov2011SEQA-45 - SoftwareEngineering and QualityAssurance for CODAC(2NRS2K_v3_1)SEQA-45 - SoftwareEngineering and QualityAssurance for CODAC(2NRS2K_v3_0)SEQA-45 - SoftwareEngineering and QualityAssurance for CODAC(2NRS2K_v2_1)SEQA-45 - SoftwareEngineering and QualityAssurance for CODAC(2NRS2K_v2_0)SEQA-45 - SoftwareEngineering and QualityAssurance for CODAC(2NRS2K_v1_0)v3.0 In Work 20 Oct2011v2.1 Approved 11 Feb2011The version for the CODAC PDR:- Updated the documentation overview figure;- Implemented comments from J.Poole.Major rewrite in view of ISO/IEC 12207conformance. Version for internal review.Minor corrections after the internal and externalreviews.v2.0 Signed 10 Jan 2011 Updated for the inclusion into the PCDH v6.v1.0 Approved 22 Jul 2009PDF generated on 23-Nov-2011

Table of contents1 INTRODUCTION...................................................................................................................31.1 Purpose ...............................................................................................................................31.2 PCDH Context ...................................................................................................................31.3 DDD-45 Context.................................................................................................................41.4 Scope ...................................................................................................................................41.5 Definitions...........................................................................................................................41.6 References...........................................................................................................................62 CODAC ISO/IEC 12207 CONFORMITY............................................................................72.1 Approach ............................................................................................................................72.2 ISO/IEC 12207 Conformity Statement............................................................................72.3 ISO/IEC 12207 Conformity Matrix .................................................................................82.4 ISO/IEC 12207 Implementation Details ..........................................................................92.4.1 Acquisition Process......................................................................................................102.4.2 Supply Process .............................................................................................................102.4.3 Life Cycle Model Management Process ......................................................................102.4.4 Infrastructure Management Process.............................................................................102.4.5 Project Portfolio Management Process........................................................................112.4.6 Human Resource Management Process.......................................................................112.4.7 Quality Management Process ......................................................................................112.4.8 Project Planning Process..............................................................................................112.4.9 Project Assessment and Control Process .....................................................................122.4.10 Decision Management Process ....................................................................................122.4.11 Risk Management Process ...........................................................................................122.4.12 Configuration Management Process ............................................................................132.4.13 Information Management Process ...............................................................................132.4.14 Measurement Management Process.............................................................................132.4.15 Stakeholder Requirements Definition Process.............................................................132.4.16 System Requirements Analysis Process ......................................................................142.4.17 System Architectural Design Process ..........................................................................142.4.18 Implementation Process ...............................................................................................142.4.19 System Integration Process ..........................................................................................142.4.20 System Qualification Testing Process .........................................................................152.4.21 Software Installation Process.......................................................................................152.4.22 Software Acceptance Support Process.........................................................................152.4.23 Software Operation Process.........................................................................................152.4.24 Software Maintenance Process ....................................................................................162.4.25 Software Disposal Process...........................................................................................162.4.26 Software Implementation Process................................................................................162.4.27 Software Requirements Analysis Process....................................................................162.4.28 Software Architectural Design Process .......................................................................172.4.29 Software Detailed Design Process ...............................................................................172.4.30 Software Construction Process ....................................................................................172.4.31 Software Integration Process .......................................................................................172.4.32 Software Qualification Testing Process.......................................................................182.4.33 Software Documentation Management Process ..........................................................18Page 1 of 22

2.4.34 Software Configuration Management Process.............................................................182.4.35 Software Quality Assurance Process ...........................................................................182.4.36 Software Verification Process......................................................................................182.4.37 Software Validation Process ........................................................................................192.4.38 Software Review Process.............................................................................................192.4.39 Software Audit Process................................................................................................192.4.40 Software Problem Resolution Process .........................................................................192.4.41 Domain Engineering Process.......................................................................................192.4.42 Reuse Asset Management Process...............................................................................202.4.43 Reuse Program Management Process..........................................................................203 PRINCIPAL DOCUMENTATION.....................................................................................214 PROJECT CLASSIFICATION...........................................................................................22Page 2 of 22

1 INTRODUCTION1.1 PurposeThis document describes general rules, practices and recommendations for softwareengineering in the scope of ITER CODAC activities.1.2 PCDH ContextThe 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 andrecaps 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 dedicateddocuments 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 structurePage 3 of 22

1.3 DDD-45 ContextThe Design Description Document for CODAC (DDD-45, [RD2]) describes CODAC designassumptions and candidate solutions for them. Some of these topics are covered in more detailin the annex documents. This document makes a part of the DDD-45 package focusing on thesoftware engineering and QA topic.1.4 ScopeThis document describes general rules, practices and recommendations for softwareengineering 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 CentralSafety Systems (PBS 48) are not addressed yet.This document is primarily focused on the CODAC System (PBS 45). Chapter 2 gives astandard conformity statement for CODAC.Software for control system elements qualified as COTS devices does not have to follow theserules and should follow the engineering and quality assurance guidelines of their respectivemanufacturers and/or maintainers instead. COTS components will be selected in such a waythat their integration does not degrade the overall quality level of CODAC.1.5 DefinitionsMany terms and definitions used in this document are explained in the glossary of the ISO/IEC12207 standard ([RD3]).The ISO/IEC 12207 standard is broken down into two main parts – system engineering andsoftware engineering. By the “system” we understand hereafter a plant system I&C or a centralsystem (central systems are treated as plant systems PBS 45, PBS 46, PBS 47 and PBS 48, withsome special control features). The system includes both hardware and software. Systemengineering in the I&C context is addressed by the PCDH ([RD1]) and this annex document isfocused on software engineering. For some processes the system engineering for I&C followsthe 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):ADMCIECISCODACCOTSCWSD-TDDDADMinistration directorateCentral Integration and Engineering directorateCentral Interlock SystemControl, Data Access and CommunicationCommercial Off-The-ShelfCooling Water SystemDeuterium-TritiumDesign Description DocumentPage 4 of 22

DOORSDRDTEPICSFDISFPGAGDHMIHPNI&CIDMIECIOISOLCCPBSPCDHPISPLCPSPSSQAR&DRDSADDSCCSCMPSCPSDMPSDPSDSDSEQASPMPSQAPSQLSQSSRCSRDSRSSSPDynamic Object Oriented Requirements SystemDocument ReviewDocument TemplatesExperimental Physics and Industrial Control SystemFinal Draft International StandardField Programmable Gate ArrayGeneric DocumentHuman-Machine InterfaceHigh Performance NetworksInstrumentation and ControlITER Document ManagementInternational Electrotechnical CommissionITER OrganizationInternational Standards OrganizationLocal Control CubiclePlant Breakdown StructurePlant Control Design HandbookPlant Interlock SystemProgrammable Logic ControllerPlant SystemPlant Safety SystemQuality AssuranceResearch and DevelopmentReference DocumentSoftware Architecture and Design DescriptionSignal Conditioning CubicleSoftware Configuration Management PlanSystem Context ProcessesSoftware Documentation Management PlanSoftware Development PlanSoftware Development Standards DescriptionSoftware Engineering and Quality AssuranceSoftware Project Management PlanSoftware Quality Assurance PlanStructured Query LanguageSafety, Quality and Security departmentSouRCe codeSystem Requirements DocumentSoftware Requirements SpecificationSoftware Specific ProcessesPage 5 of 22

STPSTRSUMSVNSWTBDSoftware Test PlanSoftware Test ReportSoftware User ManualSubVersioNSoftWareTo Be Defined-T Template-β Beta- or draft versionTable 1-1: Abbreviations1.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.1 Approach2 CODAC ISO/IEC 12207 CONFORMITYCODAC has decided to follow the ISO/IEC 12207 international standard ([RD3]) for itssoftware-related activities. This standard breaks down all the software activities into groups ofprocesses, which are presented in Figure 2-1.Figure 2-1: ISO/IEC 12207 life cycle processesHereafter, “the International Standard” refers to the ISO/IEC 12207, as defined in the reference[RD3].2.2 ISO/IEC 12207 Conformity StatementCODAC claims tailored conformity for all processes defined in the ISO/IEC 12207International Standard, except for the Project Portfolio Management Process.The tailored conformity claim is based on the zero level analysis executed for existing practicesof CODAC and ITER Organization. The ultimate goal of standardization is to go for fullconformity for some of the aforementioned processes, subject to thorough analysis,documentation and adjustment of the existing processes. This will be gradually implemented inthe future.Page 7 of 22

2.3 ISO/IEC 12207 Conformity MatrixThe Table 2-1 summarizes the current conformity level for CODAC. The cell color means thefollowing: green – the process has been implemented (levels 1 to 5 on the process capabilityscale, as defined in Annex B of the Standard ([RD3])); yellow – the process has been partiallyimplemented (level 0 on the process capability scale); red – the process is missing / notimplemented; no color – the process is not applicable. The cell content means the following:“IO” – regular IO procedures apply; “IO + CODAC” – CODAC-specific procedures definedon top of the regular IO procedures; “CODAC” – the procedures defined only in the CODACcontext.№ Process CODAC implementation Details (see section)1 Acquisition Process IO + CODAC 2.4.12 Supply Process IO 2.4.23 Life Cycle Model Management Process CODAC 2.4.34 Infrastructure Management Process CODAC 2.4.45 Project Portfolio Management Process N/A 2.4.56 Human Resource Management Process IO + CODAC 2.4.67 Quality Management Process IO 2.4.78 Project Planning Process IO + CODAC 2.4.89 Project Assessment and Control Process IO + CODAC 2.4.910 Decision Management Process IO 2.4.1011 Risk Management Process IO + CODAC 2.4.1112 Configuration Management Process IO 2.4.1213 Information Management Process IO 2.4.1314 Measurement Management Process IO 2.4.1415 Stakeholder Requirements Definition Process IO 2.4.1516 System Requirements Analysis Process IO 2.4.1617 System Architectural Design Process IO 2.4.1718 Implementation Process IO 2.4.1819 System Integration Process IO 2.4.1920 System Qualification Testing Process IO 2.4.20Page 8 of 22

21 Software Installation Process IO + CODAC 2.4.2122 Software Acceptance Support Process CODAC 2.4.2223 Software Operation Process IO + CODAC 2.4.2324 Software Maintenance Process CODAC 2.4.2425 Software Disposal Process CODAC 2.4.2526 Software Implementation Process CODAC 2.4.2627 Software Requirements Analysis Process CODAC 2.4.2728 Software Architectural Design Process CODAC 2.4.2829 Software Detailed Design Process CODAC 2.4.2930 Software Construction Process CODAC 2.4.3031 Software Integration Process CODAC 2.4.3132 Software Qualification Testing Process CODAC 2.4.3233 Software Documentation Management Process CODAC 2.4.3334 Software Configuration Management Process CODAC 2.4.3435 Software Quality Assurance Process CODAC 2.4.3536 Software Verification Process CODAC 2.4.3637 Software Validation Process CODAC 2.4.3738 Software Review Process CODAC 2.4.3839 Software Audit Process CODAC 2.4.3940 Software Problem Resolution Process CODAC 2.4.4041 Domain Engineering Process CODAC 2.4.4142 Reuse Asset Management Process CODAC 2.4.4243 Reuse Program Management Process CODAC 2.4.43Table 2-1: ISO/IEC 12207 conformity matrix for CODAC2.4 ISO/IEC 12207 Implementation DetailsCODAC implements the ISO/IEC 12207 processes to a different level of completeness and/orrobustness, depending on the current activities and priorities. The following sections provideexplanations of process implementation.Page 9 of 22

2.4.1 Acquisition ProcessPurpose:The purpose of the Acquisition Process is to obtain the product and/or service that satisfy theneed expressed by the acquirer. The process begins with the identification of customer needsand 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 isdefined in reference [RD4].2.4.2 Supply ProcessPurpose:The purpose of the Supply Process is to provide a product or service to the acquirer that meetsthe 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 inreference [RD5].2.4.3 Life Cycle Model Management ProcessPurpose:The purpose of the Life Cycle Model Management Process is to define, maintain, and assureavailability of policies, life cycle processes, life cycle models, and procedures for use by theorganization with respect to the scope of this International Standard.This process provides life cycle policies, processes, and procedures that are consistent with theorganization's objectives, that are defined, adapted, improved and maintained to supportindividual project needs within the context of the organization, and that are capable of beingapplied using effective, proven methods and tools.Implementation:This process is implemented selectively for the most important life cycle models, like the I&Clife cycle, documented in the PCDH ([RD1]). The working instrument for this process is IDM(see [RD6]).2.4.4 Infrastructure Management ProcessPurpose:The purpose of the Infrastructure Management Process is to provide the enabling infrastructureand services to projects to support organization and project objectives throughout the life cycle.This process defines, provides and maintains the facilities, tools, and communications andinformation technology assets needed for the organization’s business with respect to the scopeof this International Standard.Page 10 of 22

Implementation:CODAC has defined a strategy for infrastructure procurement and management which isdescribed in references [RD7] and Error! Reference source not found.. The process issupported by the inventory database [RD8] and is documented in SharePoint [RD9].2.4.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, andsanctions the authorities needed to establish selected projects. It performs continuedqualification of projects to confirm they justify, or can be redirected to justify, continuedinvestment.Implementation:This process is not very applicable in the ITER context. Certain R&D projects could bemanaged under this process.2.4.6 Human Resource Management ProcessPurpose:The purpose of the Human Resource Management Process is to provide the organization withnecessary 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 toperform life cycle processes to achieve organization, project and customer objectives.Implementation:Standard organization practices apply (defined and maintained by the IO Department forAdministration, Human Resources Division). Projected profile of CODAC hiring until theITER D-T phase is available in reference [RD7]. Software management aspects are covered inthe CODAC software project management plan [RD10].2.4.7 Quality Management ProcessPurpose:The purpose of the Quality Management Process is to assure that products, services andimplementations of life cycle processes meet organizational quality objectives and achievecustomer satisfaction.Implementation:Standard IO practices apply (defined and maintained by the IO Department for Safety, Qualityand 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 ProcessPurpose:The purpose of the Project Planning Process is to produce and communicate effective andworkable project plans.This process determines the scope of the project management and technical activities, identifiesprocess 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 CODACsoftware project management plan [RD10].2.4.9 Project Assessment and Control ProcessPurpose:The purpose of the Project Assessment and Control Process is to determine the status of theproject and ensure that the project performs according to plans and schedules, and withinprojected budgets, and that it satisfies technical objectives.This process includes redirecting the project activities, as appropriate, to correct identifieddeviations and variations from other project management or technical processes. Redirectionmay 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 CODACsoftware project management plan [RD10].2.4.10 Decision Management ProcessPurpose:The purpose of the Decision Management Process is to select the most beneficial course ofproject 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 andtheir 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 ProcessPurpose:The purpose of the Risk Management Process is to identify, analyze, treat and monitor the riskscontinuously.Page 12 of 22

The Risk Management Process is a continuous process for systematically addressing riskthroughout the life cycle of a system or software product or service. It can be applied to risksrelated 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 CODACsoftware project management plan [RD10].2.4.12 Configuration Management ProcessPurpose:The purpose of the Configuration Management Process is to establish and maintain theintegrity of all identified outputs of a project or process and make them available to concernedparties.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 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 ofinformation. 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 ProcessPurpose:The purpose of the Measurement Process is to collect, analyze, and report data relating to theproducts developed and processes implemented within the organizational unit, to supporteffective management of the processes and to objectively demonstrate the quality of theproducts.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 ProcessPurpose:The purpose of the Stakeholder Requirements Definition Process is to define the requirementsfor a system that can provide the services needed by users and other stakeholders in a definedenvironment.It identifies stakeholders, or stakeholder classes, involved with the system throughout its lifecycle, and their needs and desires. It analyzes and transforms these into a common set ofstakeholder requirements that express the intended interaction the system will have with itsoperational environment and that are the reference against which each resulting operationalservice 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 ProcessPurpose:The purpose of System Requirements Analysis is to transform the defined stakeholderrequirements into a set of desired system technical requirements that will guide the design ofthe 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 changecontrolled documents, available in reference [RD13]. The tool to manage requirements isDOORS (see [RD14]).2.4.17 System Architectural Design ProcessPurpose:The purpose of the System Architectural Design Process is to identify which systemrequirements 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 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).Page 14 of 22

2.4.19 System Integration ProcessPurpose:The purpose of the System Integration Process is to integrate the system elements (includingsoftware items, hardware items, manual operations and other systems, as necessary) to producea complete system that will satisfy the system design and the customers’ expectationsexpressed 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 ProcessPurpose:The purpose of the Systems Qualification Testing Process is to ensure that the implementationof 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, Qualityand Security, Quality Assurance Division).2.4.21 Software Installation ProcessPurpose:The purpose of the Software Installation Process is to install the software product that meetsthe agreed requirements in the target environment.Implementation:CODAC has defined a specific procedure of software subscription, distribution, installationand updates, described in reference [RD9]. The user documentation is available in reference[RD17]. Otherwise, for Windows-based systems and standard office software, standard IOpractices apply (defined and maintained by the IO Department for Administration, ProjectInformation System Section).2.4.22 Software Acceptance Support ProcessPurpose:The purpose of the Software Acceptance Support Process is to assist the acquirer to achieveconfidence that the product meets requirements.Implementation:CODAC delivers its products in accordance with the software installation process (see section2.4.21). To support acquirer acceptance the CODAC team runs training sessions for thedelivered software (see [RD18] for details). Software problems found in the customer’senvironment are resolved in accordance with the software operation process, described insection 2.4.23.Page 15 of 22

2.4.23 Software Operation ProcessPurpose:The purpose of the Software Operation Process is to operate the software product in itsintended 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 andOperations Division. CODAC contributes to this process by providing conditions for correctoperation of the software in its intended environment. A helpdesk is established to react toproblems encountered in customer’s environment. Support procedures are defined in reference[RD19].2.4.24 Software Maintenance ProcessPurpose:The purpose of the Software Maintenance Process is to provide cost-effective support to adelivered software product.Implementation:The CODAC maintenance process is described in references [RD7] and [RD20]. The detailedfollow-up is done using Bugzilla (see [RD21]).2.4.25 Software Disposal ProcessPurpose:The purpose of the Software Disposal Process is to end the existence of a system’s softwareentity.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 conditionand leaving the environment in an acceptable condition. This process destroys or stores systemsoftware elements and related products in a sound manner, in accordance with legislation,agreements, organizational constraints and stakeholder requirements. Where required, itmaintains records that may be monitored.Implementation:Currently this process is not implemented on its own and exists as part of the SoftwareInstallation Process (see section 2.4.21). Knowledge retention and software archive areimplemented as a part of the Software Configuration Management Process (see section 2.4.34).2.4.26 Software Implementation ProcessPurpose:The purpose of the Software Implementation Process is to produce a specified system elementimplemented as a software product or service.This process transforms specified behavior, interfaces and implementation constraints intoactions that create a system element implemented as a software product or service, otherwiseknown as a "software item." This process results in a software item that satisfies architecturaldesign 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 softwaredevelopment plan [RD22].2.4.27 Software Requirements Analysis ProcessPurpose:The purpose of Software Requirements Analysis Process is to establish the requirements of thesoftware elements of the system.Implementation:This process is a lower-level process of the Software Implementation Process (see section2.4.26).2.4.28 Software Architectural Design ProcessPurpose:The purpose of the Software Architectural Design Process is to provide a design for thesoftware that implements and can be verified against the requirements.Implementation:This process is a lower-level process of the Software Implementation Process (see section2.4.26).2.4.29 Software Detailed Design ProcessPurpose:The purpose of the Software Detailed Design Process is to provide a design for the softwarethat implements and can be verified against the requirements and the software architecture andis sufficiently detailed to permit coding and testing.Implementation:This process is a lower-level process of the Software Implementation Process (see section2.4.26).2.4.30 Software Construction ProcessPurpose:The purpose of the Software Construction Process is to produce executable software units thatproperly reflect the software design.Implementation:This process is a lower-level process of the Software Implementation Process (see section2.4.26).2.4.31 Software Integration ProcessPurpose:The purpose of the Software Integration Process is to combine the software units and softwarecomponents, producing integrated software items, consistent with the software design, thatPage 17 of 22

demonstrate that the functional and non-functional software requirements are satisfied on anequivalent or complete operational platform.Implementation:This process is a lower-level process of the Software Implementation Process (see section2.4.26).2.4.32 Software Qualification Testing ProcessPurpose:The purpose of the Software Qualification Testing Process is to confirm that the integratedsoftware product meets its defined requirements.Implementation:This process is a lower-level process of the Software Implementation Process (see section2.4.26).2.4.33 Software Documentation Management ProcessPurpose:The purpose of the Software Documentation Management Process is to develop and maintainthe recorded software information produced by a process.Implementation:This process is a specialization of the Information Management Process from the ProjectProcess Group (see section 2.4.13). The software-specific guidelines are given in CODACsoftware documentation management plan [RD23]. CODAC software documentation templates(see chapter 3) are based on general ITER templates.2.4.34 Software Configuration Management ProcessPurpose:The purpose of the Software Configuration Management Process is to establish and maintainthe integrity of the software items of a process or project and make them available to concernedparties.Implementation:This process is a specialization of the Configuration Management Process from the ProjectProcess Group (see section 2.4.12). The software-specific guidelines are given in the CODACsoftware configuration management plan [RD24]. The principal working tool is Subversion.2.4.35 Software Quality Assurance ProcessPurpose:The purpose of the Software Quality Assurance Process is to provide assurance that workproducts 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 ProcessPurpose:The purpose of the Software Verification Process is to confirm that each software work productand/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 ProcessPurpose:The purpose of the Software Validation Process is to confirm that the requirements for aspecific 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 ProcessPurpose:The purpose of the Software Review Process is to maintain a common understanding with thestakeholders of the progress against the objectives of the agreement and what should be done tohelp ensure development of a product that satisfies the stakeholders. Software reviews are atboth 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 ProcessPurpose:The purpose of the Software Audit Process is to independently determine compliance ofselected 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 ProcessPurpose:The purpose of the Software Problem Resolution Process is to ensure that all discoveredproblems 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 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 2.4.41, 2.4.42, 2.4.43 have currently only been partially implemented and havenot yet been documented properly; a more formalized approach and better implementation areplanned for the future.2.4.42 Reuse Asset Management ProcessPurpose:The purpose of the Reuse Asset Management Process is to manage the life of reusable assetsfrom conception to retirement.Implementation:See section 2.4.41.2.4.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 2.4.41.Page 20 of 22

3 PRINCIPAL DOCUMENTATIONThe Software Documentation Management Process (see section 2.4.33) defines documentationto support the CODAC software life cycle. An overview of the documentation is shown inFigure 3-1.CODAC-specificPBS-neutralDDD-45(6M58M9)PCDH(27LH2V)Other IO documents(ADM, SQS, CIE procedures)(annex)SEQA-45(2NRS2K)(annex)ISO/IEC 12207 System Context Processes (SCP)ISO/IEC 12207 Software Specific Processes (SSP)SSP-45 - Software Specific ProcessesSDP-45 (6SLYRM)SQAP-45 (6SNDEV)SCMP-45 (6SNQCR)SPMP-45 (6SGJKJ)SDMP-45 (6SR4UQ)DT - Document TemplatesSDP-T (6SBM8H) SRS-T (6SBM8H)SQAP-T (6SCS8T) SADD-T (6S6B8E)SCMP-T(6SHDUZ) STP-T (3PD8H3)SPMP-T(6SLABB) STR-T (6SBGVY)SDMP-T(6SHSCD) SUM-T (3QSXSE)GD-T (33ZDG3) SDSD-T (6SJPHF)DR-T (6S7242)SDSD – Development StandardsLanguage Standards(Java, Python, C, SQL, …)Development Tool Guidelines(SVN, Bugzilla, Maven, …)Device Development Methods(EPICS, PLC, FPGA, …)The documentation is organized as follows:Figure 3-1: Software-related documentation1) 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 ITEROrganization documents mentioned in section 2.4.2) SEQA-45 – this document, summarizing CODAC approach to software engineeringand quality assurance;3) SSP-45 – supporting documentation for the CODAC software specific processes. Theseinclude 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 andprocesses in the scope of CODAC activities.5) SDSD – software development standards descriptions. This is a collection of projectindependentmanuals, how-to’s and guidelines, intended to describe softwaredevelopment practices which facilitate development, integration and maintenance ofsoftware.More information about the documentation is available in the software documentationmanagement plan [RD23].Page 21 of 22

4 PROJECT CLASSIFICATIONProjects executed in the scope of CODAC activities are classified using project levels. The aimof this classification is to apply rigorous quality control procedures for critical projects and torelieve non-critical projects from unnecessary time-consuming bureaucracy. Three levels ofprojects are defined, as shown in Table 4-1; the evaluation depends on project complexity andconfidence in implementation.Complexity \ Risk High risk Medium risk Low riskComplex L1 L1 L2Medium L1 L2 L3Easy L2 L3 L3Table 4-1: Project classificationApart 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 isdefined, the key development milestones and deliverables are applied as follows (Table 4-2):Milestones & Deliverables L1 L2 L3Software Requirements Review SRS SRS SRSPreliminary Software Design Review SADD-β, STP-β – –Final Software Design Review SADD, STP SADD, STP –Preliminary Software Implementation Review SRC-β, STR-β, SUM-β – –Final Software Implementation Review andAcceptanceSRC, STR, SUM SRC, STR, SUM SRC, STR, SUMTable 4-2: Key milestones and deliverables for different project levelsMore details on the metrics of project classification are given in the CODAC software projectmanagement plan ([RD10]). With regard to ISO/IEC 12207 processes, the projects executed inthe scope of CODAC activities should rely on and follow the processes described for theCODAC system (see chapter 2).Page 22 of 22