cd 15288: information technology - life cycle management -...

ISO/IEC JTC1/SC7Software EngineeringSecretariat: CANADA (SCC)

Address reply to: ISO/IEC JTC1/SC7 SecretariatBell Canada - Quality Engineering & Research

1050 Beaver Hall Hill, 2nd Floor, Montréal (Québec) Canada H2Z 1S4Tel.: +1 (514) 391-8286 Fax: +1 (514) 870-2246

[email protected]

ISO/IEC JTC1/SC7 N2184

1999/07/19

Document Type CD Registration & CD Ballot

Title CD 15288: Information Technology - Life Cycle Management -System Life Cycle Processes.

Source JTC1/SC7 Secretariat

Project 07.38

Status CD Registration & CD Ballot

References N2183

Action ID ACT

Due Date 1999/10/19

Mailing Date 1999/07/19

Distribution SC7_AG

Medium Encoded Acrobat

No. of Pages 53

Note

ISO/IEC JTC1/SC7 CD 15288Date

1999/07/19Reference numberISO/JTC 1/SC 7 N2184

Supersedes document

THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO CHANGE. ITSHOULD NOT BE USED FOR REFERENCE PURPOSES.

ISO/JTC 1/SC 7Committee TitleSoftware Engineering

Secretariat:Standards Council of Canada (SCC)

Circulated to P- and O-members, and to technical committees andorganizations in liaison for:

X voting by (P-members only)

1999/10/19

Please return all votes and comments in electronic form directly to theSC 7 Secretariat by the due date indicated.

ISO/IEC JTC1/SC7

Title: CD 15288: Information Technology - Life Cycle Management - System Life Cycle Processes

Project:

Introductory note: See page ii of the document

Medium: Encoded Acrobat

No. of pages: 11

2

Vote on CD 15288Date of circulation

1999/07/19

Closing date1999/10/19

Reference numberISO/JTC 1/SC 7 N2184

ISO/JTC 1/SC 7Committee TitleSoftware Engineering

Secretariat:Standards Council of Canada (SCC)

Circulated to P-members of the committee for voting

Please return all votes and comments in electronic form directly to theSC 7 Secretariat by the due date indicated.

ISO/IEC JTC1/SC7

Title: CD 15288: Information Technology - Life Cycle Management - System Life Cycle Processes

Project:

Vote:

__ APPROVAL OF THE DRAFT AS PRESENTED

__ APPROVAL OF THE DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED

__ general:

__ technical:

__ editorial:

__ DISAPPROVAL OF THE DRAFT FOR REASONS ON THE ATTACHED

__ Acceptance of these reasons and appropriate changes in the text will change our vote to approval

__ ABSTENTION (FOR REASONS BELOW):

P-member voting:National Body (Acronym)

Date:YYYY-MM-DD

Submitted by:Your Name

ISO/IEC JTC 1/SC 7/WG 7 N02981999-07-09

07N2184.DOC 19 juillet 1999 Page 3 of 54

To: SC 7 Secretariat

Subject: CD Registration ballot of ISO/IEC 15288

Dear Jean-Normand

In accordance with the Resolution passed in Curitiba 1999, ISO/IEC 15288 is hereby submitted for CD Registration & CDBallot.

Please find attached the following documents to support the ballot:

WG 7 N0284 Comment disposition for WG 7 N0253 ISO/IEC 15288 System life cycle processes (WD5)

WG 7 N0285 ISO/IEC 15288 CD 1

WG 7 N0288 WG 7 commenting package - Excel template and instructions

It would be appreciated if you would bring to the attention of National Bodies, a request from WG 7 for comments to besubmitted using the template provided. The templates are imported to a database for comment resolution.

The next meeting of WG 7 is being held in Nantes, France, 25-29 October 1999. I understand that any comments and aballot disposition will be available for that meeting.

Your assistance in meeting this objective is much appreciated.

Regards

Stan Magee

WG 7 Interim Convener

ISO/IEC CD 15288 © ISO/IEC

ISO/IEC JTC 1/SC 7 N 2184Date: 1999-07-19

ISO/IEC CD 15288

ISO/IEC JTC 1/SC 7/WG 7

Secretariat: SCC

Information Technology — Life Cycle Management — System Life Cycle Processes

—

Document type: International StandardDocument subtype: Not applicableDocument stage: (30) CommitteeDocument language: E

C:\WINDOWS\DESKTOP\My Briefcase\SC7 Documents To Issue\07n2184.doc ISOSTD ISO Template Version 3.3 1998-01-12

Table 1 - Revision HistoryDocument code Date Description

WG 7 N121 23 July 1996 Draft outline

WG 7 N131 21 January 1997 Revision of N121 (document code plus date identify revision)

WG 7 N131 23 February 1997 Revision 2 of N131 (document code plus date identify revision)

WG 7 N178 6 November 1997 Working Draft 1 (WD1)

WG 7 N183 6 November 1997 Working Draft 2 (WD2)

WG 7 N217 5 July 1998 Pre-Working Draft 3 (Pre-WD3)

WG 7 N225 6 September 1998 Working Draft 3 (WD3)

WG7 N237 16 February 1999 Working Draft 4 (WD4)

WG7 N253 30 April 1999 Working Draft 5 (WD5)

WG7 N0285 8 July 1999 Committee Draft 1 (CD1)

National Bodies are requested to submit comments using the accompanying Excel template.


ii

Contents

1 Scope......................................................................................................................................................................1

1.1 Purpose..................................................................................................................................................................1

1.2 Field Of Application...............................................................................................................................................1

1.3 Limitations .............................................................................................................................................................1

2 Conformance .........................................................................................................................................................2

2.1 Full Conformance ..................................................................................................................................................2

2.2 Tailored Conformance ..........................................................................................................................................2

2.3 Conformance With An Agreement .......................................................................................................................2

3 Normative Reference(s) ........................................................................................................................................2

4 Term(s) and Definition(s) ......................................................................................................................................2

5 Standard Overview................................................................................................................................................4

5.1 The System ............................................................................................................................................................4

5.2 System Life Cycle Processes ...............................................................................................................................5

5.3 Life Cycle Stages...................................................................................................................................................6

5.4 The Acquisition-Supply model .............................................................................................................................7

5.5 Enterprise, Project and Technical Processes Model. .........................................................................................7

5.6 Life Cycle Dynamics..............................................................................................................................................8

6 System Life Cycle Processes ...............................................................................................................................9

6.1 Agreement Processes...........................................................................................................................................9

6.1.1 Acquisition Process ............................................................................................................................................10

6.1.2 Supply Process....................................................................................................................................................11

6.2 Enterprise Processes..........................................................................................................................................11

6.2.1 Enterprise Management Process .......................................................................................................................12

6.2.2 Investment Management Process......................................................................................................................13

6.2.3 System Life Cycle Processes Management Process .......................................................................................13

6.2.4 Resource Management Process ........................................................................................................................14

6.3 Project Management Processes.........................................................................................................................15

6.3.1 Planning Process ................................................................................................................................................15

6.3.2 Assessment Process ..........................................................................................................................................17

6.3.3 Control Process...................................................................................................................................................18

6.3.4 Decision Management Process..........................................................................................................................19

© ISO/IEC ISO/IEC CD 15288

iii

6.3.5 Risk Management Process................................................................................................................................. 20

6.3.6 Configuration Management Process................................................................................................................. 21

6.3.7 Quality Management Process ............................................................................................................................ 21

6.4 Technical Processes........................................................................................................................................... 22

6.4.1 Stakeholder Needs Definition Process ............................................................................................................. 23

6.4.2 Requirements Analysis Process........................................................................................................................ 24

6.4.3 Architectural Design Process ............................................................................................................................ 26

6.4.4 Implementation Process..................................................................................................................................... 27

6.4.5 Integration Process ............................................................................................................................................ 28

6.4.6 Verification Process............................................................................................................................................ 29

6.4.7 Transition Process.............................................................................................................................................. 30

6.4.8 Validation Process.............................................................................................................................................. 31

6.4.9 Operations Process ............................................................................................................................................ 32

6.4.10 Disposal Process ................................................................................................................................................ 33

7 System Life Cycle Management......................................................................................................................... 34

7.1 Establishing Life Cycle Models And Responsibilities ..................................................................................... 34

7.2 A Life Cycle Example.......................................................................................................................................... 34

7.2.1 Concept Stage..................................................................................................................................................... 34

7.2.2 Development Stage............................................................................................................................................. 35

7.2.3 Production Stage ................................................................................................................................................ 36

7.2.4 Utilization Stage .................................................................................................................................................. 37

7.2.5 Support Stage ..................................................................................................................................................... 38

7.2.6 Retirement Stage ................................................................................................................................................ 38


iv

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form thespecialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in thedevelopment of International Standards through technical committees established by the respective organization to deal withparticular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other internationalorganizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.

In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. DraftInternational Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as anInternational Standard requires approval by at least 75 % of the national bodies casting a vote.


v

Introduction

The composition and nature of present day systems have changed. Almost every modern system contains, ismodelled by, and/or is supported by computer technology. This increasing utilization of the computer andsoftware has led to new opportunities but also to new problems. As a result, the combination of hardware,software and humans has increased system complexities to an unprecedented level. This necessitates a freshviewpoint.

There are several factors contributing to these complexities. Some are due to the inherent differences amonghardware, software and humans. Others are essentially due to a lack of harmonization and integration of theassociated scientific and engineering disciplines. This situation has created difficulties in the management andengineering of systems. There is a definite need for a common framework that can be used to "speak the samelanguage", permitting modern systems to be created, utilized and managed in an integrated, coherent fashion.This International Standard provides such a common framework.

The framework covers the life cycle of systems from the conception of ideas through to the retirement of a system. It providesthe processes for acquiring and supplying system products and services that are configured from hardware, software andhumans. In addition, this framework provides for the assessment and improvement of the life cycle.

The processes in this International Standard form a comprehensive set from which an organization mayconstruct life cycle models appropriate to the product and service types and markets in which they trade in. Anorganization, depending on its purpose, can select and apply an appropriate subset to fulfil that purpose.

This International Standard is designed to be used in one or more of the following modes.

(a) By an organization -- to establish an environment of desired processes that can be supported by aninfrastructure of methods, procedures, techniques, tools and trained personnel. The organization maythen employ this environment to run and control its projects and progress systems through their lifecycle stages. This mode may be used to assess conformance of a declared, established environmentwith this International Standard.

(b) By a project, within an organization -- to select, structure, employ and perform the elements of theestablished environment to provide products and services. This mode may be used also to assessconformance of the project with the declared, established environment.

(c) By an acquirer and a supplier, via an agreement -- to select, agree on and perform the processes andactivities in this International Standard. This mode may also be used to assess conformance of theacquirer’s and the supplier’s performances with the agreement.

COMMITTEE DRAFT © ISO/IEC ISO/IEC CD 15288

1

Information Technology — Life Cycle Management — System LifeCycle Processes

1 Scope

1.1 Purpose

This International Standard establishes a common framework for the life cycle of systems, with well-definedprocesses and terminology. The acquirer organization and the supplier organization may use this frameworkfor acquiring and supplying systems products and services. The processes may be applied throughout thelife cycle for managing and performing the conception, development, production, utilization, support andretirement of systems. The framework provides for a life cycle focus throughout system creation, utilizationand disposal that supports concurrent product development and the required processes. This isaccomplished with the involvement of all interested parties with the ultimate gaol of achieving customersatisfaction.

This International Standard also provides for the definition, control and improvement of the life cycleprocesses used by the acquirer organization and the supplier organization.

This International Standard concerns those systems that are man-made and are configured with hardware,software and humans.

1.2 Field Of Application

This International Standard applies to the conception, development, production, utilization, support, andretirement of systems and to the acquisition and supply of system products and services, whether performedinternally or externally to an organization.

There is a wide variety in man-made systems. Their purpose, complexity, size, novelty, adaptability, quantities, locations, lifespans and evolution introduce an almost limitless variety. This variety is apparent in the detail of the life cycles of systems. Thisstandard is concerned with describing the life cycle of any system and thus applies to one-of-a-kind, mass production and thecustomization of adaptable systems.

The processes in this International Standard may be used as a basis for establishing business environments(methods, techniques and tools). This International Standard may be used by a single party itself in a self-imposed mode or in a multi-party situation. The parties may be from the same organization or from differentorganizations; the situation may range from an informal agreement to a formal contract.

NOTE The processes employed for the components of a system are presumed to be compatible and consistent with the processes usedfor the system.

1.3 Limitations

1.3.1 This International Standard does not prescribe any methods or procedures for meeting the objective and requirementsand for performing the processes.

1.3.1 This International Standard does not prescribe the name, format, explicit content, and recording media of documentation.

1.3.1 This International Standard does not prescribe any life cycle model or any part of a life cycle model.

1.3.1 This International Standard is intended neither to be in conflict with any organization’s policies, procedures, and standardsnor with any National laws and regulations. However, any such conflict needs to be resolved before using this InternationalStandard.


2

2 Conformance

There are three ways to conform or comply with the provisions of this standard. Any claim of conformanceor compliance shall cite only one of the three forms described below:

2.1 Full Conformance

To claim full conformance for a declared set of processes, it shall be demonstrated that the requirements and objectives of thedeclared set of processes have been satisfied.

2.2 Tailored Conformance

When this standard is used as a basis for establishing a set of processes that do not qualify for full conformance, the clauses ofthe standard are selected in accordance with the tailoring process prescribed in Annex A. Tailored conformance means that theselected requirements and outcomes have been satisfied.

2.3 Conformance With An Agreement

When this standard is used for an agreement between an acquirer and a supplier, clauses of the standard are selected forincorporation in the agreement in accordance with the tailoring process prescribed in Annex A. In this case, compliance with theagreement can be claimed, but conformance with the standard cannot be claimed.

3 Normative Reference(s)

ISO9001 : 2000 Quality Management Systems – Requirements

IEC 61508 Parts 1 to 4: 1998 Functional Safety- Safety Related Systems

ISO 13407: 1999 Human-Centred Design Processes for Interactive Systems.

4 Term(s) and Definition(s)

4.1 Acquirer

A party, commonly an organization, that acquires or procures a system or a component of the system from a supplier.

Note - The acquirer could be termed a buyer, customer, owner, user, purchaser.

4.2 Agreement

The mutual acknowledgement of terms and conditions under which a working relationship is conducted.

4.3 Component

An entity, with discrete structure within a system, that interacts with other components of the system,thereby contributing at its lowest level to the system properties and characteristics.

4.4 Enabling system

Systems, other than the system of interest, that complement the system during its life cycle stages but do not contribute directly to itsfunctionality, e.g. when the system enters the production stage, an (enabling) production system is required.

NOTE Each enabling systems has a life cycle of its own, which is initiated by the system of interest’s requirement for it. This Internationalstandard is applicable to each enabling systems when, in its own right, it is treated as the system of interest.

4.5 Enterprise

That part of an organization responsible for meeting the needs of stakeholders in the organization, especially when trading aproduct or service in a competitive environment.

4.6 Facility


3

The physical means or equipment for facilitating the performance of an action, e.g. buildings, instruments, tools.

4.7 Life cycle

The evolution with time of the system from conception to disposal

4.8 Life cycle model

A framework of processes and activities concerned with the life cycle, which also acts as a common reference for communicationand understanding.

4.9 Operator

An individual or an organization who contributes to the functionality of a system and draws on knowledgeand/or procedures to contribute the function.

NOTE 1) The role of operator and the role of user may be vested, simultaneously or sequentially, in the same individual or organization.

NOTE 2) An individual operator combined with knowledge and/or procedures may be considered as a component of the system.

4.10 Process

A system of activities which use resources to transform inputs to outputs. (ISO 9000 :2000)

4.11 Project

The structure of authorities, resources and controls established by an organization to meet agreedrequirements.

4.12 Quality assurance

Part of quality management focused on providing confidence that the relevant quality requirement will befulfilled (ISO 9000 :2000 CD2)

4.13 Stage

The high level life cycle classification used to facilitate management of a system.

NOTE 1 Stages may be overlapping

NOTE 2 Compare with phase groupings of activities and tasks by Project Management during the execution of a project activities.

4.14 Stakeholder

An interested party having a right, share or claim in the system or in its possession of qualities that meettheir needs.

4.15 Subsystem

When viewing the architectural levels of a system, a subsystem is an level that is intermediate between thesystem (top level) and the components (bottom level).

4.16 Supplier

Provider of a product

NOTE 1) The term is synonymous with contractor, producer, seller, or vendor.

NOTE 2) An organization may designate a part of its own organization as supplier.

4.17 System

An object consisting of interrelated or interacting elements (ISO 9000 :2000 CD2).


4

NOTE In practice, a system is ‘in the eye of the beholder’ and the interpretation of its meaning is frequently clarified by the use of anassociative noun, e.g. product system, aircraft system. Alternatively the word system may be substituted simply by a context dependentsynonym, e.g. product, aircraft, though this may then obscure a system principles perspective.

4.18 Trade-off

Decision making actions that select from various requirements and alternative solutions on the basis of net benefit to thestakeholders.

4.19 User

Individual or group who is the intended beneficiary of system use.

NOTE This is commonly considered to include the suppliers and the operators of enabling systems.

4.20 Validation

Confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use arefulfilled. [ISO 9000 :2000]

4.21 Verification

Confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. [ISO9000 :2000]

5 Standard Overview

This Clause highlights the key concepts that may be helpful to the users of this International Standard inunderstanding it, in orienting themselves in it and in applying it judiciously. This Clause does not, however,contain any application guidance.

5.1 The System

The systems considered in this International Standard are man-made, created and utilized for the benefit of all stakeholders. Thesesystems may be composed of hardware, software, materials, data and humans performing procedures. In practice, they will bethought of as products or services.

The definition of a system depends on one's view of the world or one's responsibility. Figure 1 exemplifies differing levels ofperception of a system in the transportation sector. It illustrates :

1) the hierarchical perception of system composition, i.e. architecture

2) the importance of defined boundaries that encapsulate meaningful need and practical solution,

3) that a system comprises a fully integrated, defined set of subordinate systems, termed components

4) the interactions between components that give rise to characteristic properties at the system boundaries.

Whatever the boundaries chosen to define the system, the concepts and models in this International Standard are generic and permita practitioner to correlate or adapt individual instances of life cycles to its system principles.


5

Air trafficcontrol system

Aircraft System

Airframesystem

Propulsionsystem

Fuel system

Life support system

Flight controlsystem

Air Transport System

Fuel distribution system

Airportssystem

Pilot trainingsystem

Transportation System

Ground Transportation System

Maritime Transport System

Navigationsystem

Global positioning

systemDisplay system

Figure 1 — System view of the transportation sector

5.2 System Life Cycle Processes

Every system has a life cycle. The life cycle of a system begins with a concept, progresses through its realization, utilization andevolution, and ends in its retirement. This progression of a system through its life cycle is achieved as the result of processesapplied, performed and managed by people in organizations. These processes, termed life cycle processes, may be applied atany time during the life cycle. The functions they perform are defined in terms of specific purposes and outcomes, and aredescribed in detail by a set of activities which they comprise. Activities may, in turn, be described in terms of the set of tasks whichthey comprise.

The partitioning of the life cycle into processes is based on principles of modularity (maximal cohesiveness of thefunctions of a process and minimal coupling among processes) and of responsibility (a process is under aresponsibility).

The detailed purpose and order of use of these processes throughout the life cycle is influenced by multiple factors, including social,trading, organizational and technical considerations, each of which may vary during the life of a system. An individual system lifecycle is thus, itself, a complex system of processes that will normally possess concurrent, iterative, recursive and time dependentcharacteristics.

Figure 2 introduces the system life cycle process. Since there is no definitive order in the use of the life cycleprocesses, this structure of presentation does not imply any precedence or sequence of application of theprocesses. The grouping reflects underlying models used in the International Standard.


6

ProjectProcesses

Planning Process

Assessment Process

Control Process

Decision Management

Risk Management

Configuration Management

Quality Management

Enterprise Processes

Enterprise Management Process

Investment Management Process

System Life Cycle Management Process

Resource ManagementProcess

AgreementProcesses

Acquisition Process

Supply Process

Technical ProcessesStakeholder Needs Definition Process

Requirements AnalysisProcess

Architectural Design Process

Implementation Process

Integration Process

Verification Process

Transition Process

Validation Process

Operation Process

Disposal Process

Figure 2 — The processes in the system life cycle

5.3 Life Cycle Stages

Each instance of a life cycle differs according to the nature, purpose, use and prevailing circumstance of the system.Nevertheless, despite a necessary and apparently limitless variety in system life cycles, there is an underlying, essential set ofcharacteristic life cycle stages that exists in the complete life cycle of any system. Each stage has a distinct purpose andcontribution to the whole life cycle and should be considered when planning and executing the system life cycle. The stagesprovide a framework within which the detail of the life cycle processes is managed.

The stages describe the major progress and achievement milestones of the system through its life cycle; they give rise to the primarydecision gates of the life cycle. These decision gates are used by organizations to contain the inherent uncertainties and risksassociated with costs, schedule and functionality when they create or utilize a system.


7

LIFE CYCLESTAGES PURPOSE DECISIONS

CONCEPT

Identify stakeholders’ needsExplore conceptsPropose viable solutions

DEVELOPMENTRefine system requirementsDetermine system componentsBuild systemVerify and validate system

PRODUCTION Mass produce systemInspect and test

UTILIZATION Operate system to satisfy users’ needs

SUPPORT Provide sustained system capability

RETIREMENT Retire; archive or dispose the system

--

---

Execute next stageContinue this stageGo to previous stateHold project activityTerminate project

--

---

Execute next stageContinue this stageGo to previous stateHold project activityTerminate project

Figure 3 — Life cycle stages, objectives and decisions

Figure 3 shows a commonly encountered example of life cycle stages. Also shown are the principal purpose of each of these stagesand the possible decision options used to risk manage progression through the life cycle.

Organizations employ stages differently to satisfy contrasting business and risk mitigation strategies. Usingstages concurrently and in different orders can lead to life cycle forms with distinctly different characteristics.Sequential, incremental or evolutionary life cycles forms are frequently used ; alternatively, a suitable hybrid ofthese may be developed. The selection and development of such life cycle forms by an organization depends onseveral factors, including the nature and complexity of the system, the stability of requirements, the technologyopportunities, the need for different system capabilities at different times and the availability of budget andresources.

5.4 The Acquisition-Supply model

This International Standard facilitates trading between organization by employing an acquisition-supply model based on AgreementProcesses. One organization may, acting as an acquirer, task another, acting as a supplier, for products or services using anagreement. This supplier may be an independent organization or be in a different part of the acquiring organization. Generally,organizations act simultaneously and/or successively as both acquirers and suppliers of systems.

Within an organization, the Agreement Processes of the acquisition-supply model may be used with less formality to achieve intra-organization trading between different areas of responsibility (see Figure 4).

5.5 Enterprise, Project and Technical Processes Model.

Organizations are producers and consumers of systems, i.e. they trade products and services. Typically, organizations distinguishdifferent areas of managerial responsibility ; together, these areas contribute to the organization’s overall capability to trade. ThisInternational Standard employs a process model shown in Figure 4 based on three primary organizational areas of responsibility:enterprise, project and technical .

The Enterprise Processes are concerned with ensuring that the needs and expectations of the organization’s interested parties aremet. The enterprise processes are typically concerned with the organization’s business strategy and management of risks incompetitive markets. For many organizations, these processes present a strong enterprise image. Enterprise Processes are relevantto non-profit organizations, which also encounter risk in their undertakings and are accountable to interested parties.

The Project Processes are concerned with managing resources and assets allocated by the enterprise processes and apply them tofulfil the agreements that the organizations enter into. Whilst agreements formalize the inter-organization transactions, there are lessformal relationship between projects in different organizations, or different enterprise areas of the same organization, that have astrong influence on shared achievement and overall system quality. The Project Processes may be employed to manage, at acorporate level, the provision of an organization’s infrastructure, e.g. facilities, services, technology base.

The Technical Processes are concerned with the actions that transform consumer needs first into a product and then apply thatproduct to providing a sustainable service as, when and where needed in order to achieve customer satisfaction. Their use(recursively) to describe an organization’s technical actions at each level of system architecture is a key aspect of the application ofthis International Standard.


8

AGREEMENTPROCESSES

Organization A

Organization B

Organization C

AGREEMENTPROCESSES

ENTERPRISEPROCESSES

PROJECT PROCESSES

TECHNICALPROCESSES

enterprisemanagement

projectmanagement

technicalmanagement

ENTERPRISEPROCESSES

PROJECT PROCESSES

TECHNICALPROCESSES


projectmanagement

technicalmanagement

ENTERPRISEPROCESSES

PROJECT PROCESSES

TECHNICALPROCESSES


projectmanagement

technicalmanagement

Figure 4 — Enterprise, project and technical functions in cooperating organizations

NOTE In Figure 4, the vertical relationship of Organizations A and B may be considered to represent organizations in a supply chain,trading during a stage in a life cycle. The horizontal relationship of Organizations A and C may be considered to represent organizations withsuccessive responsibility for stages in a life cycle.

5.6 Life Cycle Dynamics

A system is synergistic; so is its life cycle. Just as all the components of the system contribute to the system as a whole, so eachstage of the life cycle needs to be considered during any given other stage of the life cycle. As a consequence, the contributingparties need to coordinate and cooperate with each other throughout the life cycle. This synergism in the system, in its life cyclestages and amongst the functional contributors is necessary for successful enterprise, projects, technical actions and, ultimately, forsystems to fully meet needs in a sustainable manner.

The life cycle of a man-made system may be thus seen from two points of view. One view, that of the system itself, sees the actionsand results of the processes progressing the system through its principal characteristic stages. The other view, that of eachorganizational function, sees the life cycle processes as actions harmonized with other functional contributions at any point in thesystem’s lifetime. These two perspectives are shown in Figure 5.


9

Compatibility,Feasibility















Consistency,Viability















Needs,Concepts,Feasibility

Engineering,Solutions,Practicability

Fabrication,Assembly,Verification

Operation,Usage,Validation

Reuse,Archiving,Destruction

Installation,Maintenance,Logistics

LIFE CYCLE STAGES

OR

GA

NIZ

AT

ION

AL

FU

NC

TIO

NS

Contribute to

Personnel

DEVELOPMENT PRODUCTION OPERATION SUPPORT RETIREMENT

CONCEIVERS

DEVELOPERS

PRODUCERS

USERS

SUPPORTERS

RETIRERS

CONCEPT

Figure 5 — Functional views and system stages of the life cycle

The basic theme in Figure 5 is: perform the primary functions of the stage (diagonal, shaded box); coordinate the contributions ofdifferent functional contributors in each life cycle stage (the columns) ; keep in mind the decisions made in past stages and anticipatethe needs of future stages (rows).

6 System Life Cycle Processes

This Clause describes the four groups of life cycle processes. It defines their purposes and outcomes, andthe activities required to achieve them. The processes are conducted selectively to fulfil the objectives of thestages. The four process groups are as follows:

1) Agreement processes

2) Enterprise processes

3) Project management processes

4) Technical processes.

6.1 Agreement Processes

This Subclause specifies the requirements for the establishment of formal and informal agreements betweenorganizational entities (formal for entities external to the organization and informal for entities internal to theorganization). The Agreement Processes consist of :

a) Acquisition Process

b) Supply Process.

These processes define the activities necessary to establish an agreement between two organizations. If theSupply Process is invoked it provides the means for conducting a project in which the result is a product(system, subsystem, component) or a service which is delivered to the acquirer. If the Acquisition Process is


10

invoked it provides the means for conducting business with a supplier of products which are delivered foruse, as an operational system, in support of an operating system, or as an element of the system beingdeveloped by the project.

6.1.1 Acquisition Process

6.1.1.1 Acquisition Process Purpose

The Acquisition Process establishes an agreement to acquire system, product and services, managing the acquirer/supplierrelationship during acquisition and accepts system products and services delivered by a supplier.

6.1.1.2 Acquisition Process Outcomes

1) A selected supplier.

2) An agreement to acquire a system according to specified timescales, cost and performance criteria.

3) A definition of how and by whom responsibility for the acquired system will be assumed.

4) The acceptance of a system that conforms with the agreement.

5) Payment or other agreed consideration.

6.1.1.3 Acquisition Process Activities

This process includes the following activities:

6.1.1.3.1 Plan the Acquisition.

The acquirer shall establish a plan for how the acquisition will be conducted, including reference to the life cycle model, aschedule of milestones, and selection criteria for selecting a suitable supplier.

6.1.1.3.2 Prepare the Request for Proposal.

The acquirer shall prepare a request for proposal which details the products or services to be acquired, the business practiceswhich suppliers are expected to comply with, and the selection criteria for selecting a supplier.

6.1.1.3.3 Solicit Supplier Proposals.

The acquirer shall announce the solicitation to identify potential suppliers. The request for proposal shall be released tointerested suppliers in a manner which fosters a fair competitive environment.

6.1.1.3.4 Evaluate Supplier Proposals.

Once the deadline for proposals submittal is achieved, the proposals shall be evaluated against the established selection criteria.The rationale for rating each proposal shall be documented for the record so that suppliers may be informed why they were notselected.

6.1.1.3.5 Negotiate the Agreement.

An agreement shall be drafted, and negotiated between the acquirer and supplier. This agreement may range in formality from alegal and binding contract to a verbal understanding. Appropriate to the level of formality, the agreement shall establish theproduct or service requirements, development and delivery milestones, acceptance conditions, exception handling procedures,and payment schedules so that both parties of the agreement understand the basis for executing the agreement. Rights andrestrictions associated with technical data, copyrights and patents should be noted in the agreement. The negotiation iscomplete when the terms of an agreement offered by the supplier are accepted by the acquirer.

6.1.1.3.6 Monitor the Agreement.

The acquirer shall monitor the execution of the agreement to ensure that the supplier is performing its duties according to theagreement. Projected cost, performance, or schedule risks shall be monitored, and the impact of undesirable outcomes on theorganization evaluated.


11

6.1.1.3.7 Conclude the Agreement.

The acquirer shall inspect, assess or test the delivered products or services to ensure that they comply with the agreement.When the supplied products or services have satisfied the conditions of the agreement, the acquirer shall conclude theagreement. Exceptions which arise during the conduct of the agreement or with the delivered products or services shall beresolved according to the procedures established in the agreement.

6.1.2 Supply Process

The Supply Process establishes an agreement to supply a system, product or services, manages the supply, and ensures thatthe system, product and services, is acceptable to an acquiring organization.

6.1.2.1 Supply Process Outcomes

1) An acquirer for a system.

2) An agreement for supply of a system according to specified timescales, cost and performance criteria.

3) The delivery of a system product and/or the establishment of a system service that conforms with the agreement.

4) Transfer of responsibility for the acquired system.

5) Receipt of payment or other consideration.

6.1.2.2 Supply Process Activities

This process is defined by the following activities:

6.1.2.2.1 Plan to Respond to Solicitation.

The supplier shall establish a plan for how to respond to a solicitation, including a schedule of milestones, and decision criteriafor submitting a proposal.

6.1.2.2.2 Prepare the Proposal.

The Supplier shall prepare the proposal which satisfies the solicitation, presents a sound plan for achieving the desired productor service performance objectives, is competitively priced, and benefits the Supplier’s interested parties. The plan shall establisha system life cycle model for the product or service being provided.

NOTE The technical processes may need to be appropriately completed to arrive at a satisfactory/feasible concept on which to base theproposal.

6.1.2.2.3 Negotiate the Agreement.

An agreement shall be drafted, and negotiated between the acquirer and supplier. This agreement may range in formality from alegal and binding contract to a verbal understanding. A The Supplier shall ensure that the product or service requirements,development and delivery milestones, and acceptance conditions are achievable, and that exception handling procedures, andpayment schedules are acceptable and establish a basis for executing the agreement without unnecessary risks.

6.1.2.2.4 Execute the Project.

The supplier shall execute and conclude the agreement according to established project plans, and in accordance with thenegotiated agreement.

6.1.2.2.5 Monitor the Agreement.

The acquirer shall monitor the execution on the agreement to ensure that the supplier is performing its duties according to theagreement. Projected cost, performance, or schedule risks shall be monitored, and the impact of undesirable outcomes on theorganization evaluated.

6.2 Enterprise Processes

The Enterprise Processes manage the organization’s capability to acquire and supply system products or services through theinitiation, support and control of projects. They provide the necessary support to projects and ensure the satisfaction oforganizational objectives and established agreements.


12

The Enterprise Processes consist of the following:

1. Enterprise Management Process

2. Investment Management Process

3. System Life Cycle Management Process

4. Resource Management Process

6.2.1 Enterprise Management Process

6.2.1.1 Enterprise Management Purpose

The Enterprise Management Process defines, documents, and maintains the policies and procedures as needed for theorganization’s business with respect to the requirements of this Standard.

6.2.1.2 Enterprise Management Outcomes

1) Strategic and tactical plans and objectives that guide the setting of policies and procedures for implementation of therequirements of this International Standard.

2) Policies and procedures for system life cycle management including quality management, assurance, and control inaccordance with ISO 9001:2000.

3) Roles, responsibilities and authorities to facilitate effective system life cycle management.

6.2.1.3 Enterprise Management Activities

The organization shall implement the following activities in accordance with applicable organization policies and procedures withrespect to the Enterprise Management Process.

6.2.1.3.1 Strategic Planning

Establish the enterprise strategic plans that identify the business objectives to be achieved, the areas of business to be pursued,and the significant goals to be accomplished.

6.2.1.3.2 Tactical Planning

Establish tactical plans for each business area that identify the short term objectives which contribute to achieving strategicobjectives, and the projects that will be done to accomplish the strategic objectives.

6.2.1.3.3 Set System Life Cycle Policy

Preparation of system life cycle policies and procedures that implement the requirements of this Standard and consistent withstrategic and tactical plans.

NOTE The actual range and detail of the system life cycle implementation within a project will be dependent upon the complexity of thework, the methods used, and the skills and training of personnel involved in performing the work. A project is expected to appropriately tailorpolicy and procedure implementation to project requirements.

6.2.1.3.4 Define Life Cycle Responsibility

Appoint a member of the organization’s management who has defined authority for implementation of this InternationalStandard. Define, integrate, and communicate the roles, responsibilities and authorities to facilitate implementation of systemlife cycle processes and effective system life cycle management.

6.2.1.3.5 Enterprise Impact Assessment.

The Enterprise shall assess the impact of strategic and tactical plans to identify how the Enterprise must change in order toachieve its objectives. A plan for effecting the change shall be prepared and assigned to change agents.

6.2.1.3.6 Assess Life Cycles

A schedule of internal audits of the system life cycle and related processes. At defined intervals, the system life cycle policiesand procedures shall be reviewed to ensure their continuing suitability, adequacy and effectiveness and make changes asappropriate.


13

6.2.1.3.7 Enterprise Change Management.

The Enterprise Change Management Plan shall be communicated to all personnel, and implemented to change jobs,infrastructure, work processes, and operating procedures so that the Enterprise may successfully execute the strategic andtactical plans and objectives.

6.2.2 Investment Management Process

6.2.2.1 Investment Management Purpose

The Investment Management Process ensures that sufficient and right projects are won and initiated to sustain an organization’sbusiness and that projects initiated are adequately funded and deserve continuation based on achievement.

6.2.2.2 Investment Management Outcomes

1) Identification and winning of new business.

2) Qualification and selection of the right business opportunities.

3) Initiation of projects based on sound business practices, within the capability of the organization, and with acceptable riskand potential payoff to the organization.

4) Continuance of projects that are meeting agreement and stakeholder requirements.

5) Termination or redirection of projects not meeting agreement or stakeholder requirements.

6) Allocation of organization financial resources for approved projects.

6.2.2.3 Investment Management Activities

The organization shall implement the following activities in accordance with applicable organization policies and procedures withrespect to the Investment Management Process.

1. Establish new business opportunities consistent with strategic and tactical plans of the organization and its business units.

2. Initiate new acquisition projects.

3. Initiate new supply projects.

4. Allocate resources for the achievement of project objectives

5. Identify the expected outcomes of the project

6. Identify any multi-project interfaces which must be managed or supported by the project. This includes the use of enablingsystems used by more than one project and the use of common components by more than one project.

7. Specify the project reporting, and review milestones which will govern the project’s execution.

8. Evaluate ongoing projects to ensure that: a) projects are making progress towards achieving established outcomes; b)projects are complying with Project Directives; c) projects are being conducted according to established plans, andprocedures; and d) projects remain viable in terms of market needs, customer and interested parties needs, and return oninvestment.

9. Cancel projects which no longer offer sufficient return on investment, or whose risks outweigh the ability for continuedinvestments to achieve a successful venture, or whose progress is delayed or whose continued investment is beyond thatwhich the organization can burden.

6.2.3 System Life Cycle Processes Management Process

6.2.3.1 System Life Cycle Processes Management Purpose

The System Life Cycle Processes Management Process ensures that the processes used across projects are consistent andthat there is effective sharing and coordination of resources, information and technologies.


14

6.2.3.2 System Life Cycle Processes Management Outcomes

1) A standard set of processes and related methods and tools to be implemented in projects in accordance with organizationpolicies and procedures.

2) Determination of the effectiveness, strengths, and deficiencies of each standard process as applied by projects.

3) Improvements to enhance effectiveness of implemented standard processes.

4) Sharing of lessons learned among projects with respect to technologies, methods, and tools.

5) Reduced risk exposure of the organization and its individual projects.

6.2.3.3 System Life Cycle Processes Management Activities

The organization shall implement the following activities in accordance with applicable organization policies and procedures withrespect to the System Life Cycle Processes Management Process.

1. Establish standard sets of system life cycle processes for applicable system life cycle stages.

2. Establish acceptable tailoring policies and procedures, with approval requirements.

3. Deploy standard processes to projects through organization standards, guides, manuals, policies and procedures.

4. Establish metrics that determine implemented standard process performance.

5. Monitor process execution, accumulate and analyze process metrics, and identify trends respective to process efficiency oreffectiveness.

6. Determine opportunities for improvement of standard process implementation.

7. Make necessary improvements to processes.

8. Determine and implement multi-project management aids such as: a) communication channels; b) use of existing off-the-shelf products and services in development or improvement projects; and c) convenient and reliable source of productivity-improving information for ongoing projects.

9. Control multi-project management interfaces to resolve schedule conflicts: a) of capacity in organizational infrastructure andsupporting services and resources among ongoing projects and b) from project personnel serving on more than one project.

6.2.4 Resource Management Process

6.2.4.1 Resource Management Purpose

The Resource Management Process provides the services and resources needed to support organization goals and processesand project requirements, while meeting the needs of the organization’s personnel.

6.2.4.2 Resource Management Outcomes

1) Establishment of appropriate resource services needed to establish, implement, and improve the implementation of projects.

2) Supply of educated, trained, and experienced personnel qualified to perform assigned process activities within projects.

6.2.4.3 Resource Management Activities

The organization shall implement the following activities in accordance with applicable organization policies and procedures withrespect to the Resource Management Process.

6.2.4.3.1 Human Resource Management

1. Maintain and manage the pool of personnel necessary to staff ongoing projects, and ensure the requisite training and skillenhancement activities are conducted to provide qualified staff to projects.


15

2. Recruit personnel with experience levels and skills necessary to properly staff projects, when existing staff is not available ornot trainable to meet project needs.

3. Provide projects with appropriate personnel that are competent on the basis of applicable education, skills, training andexperience to accomplish project activities that impact the conformity of system, product and/or service.

4. Provide training and education to improve the skill set of personnel, and support the career paths for technical and projectmanagement personnel.

5. Evaluate the performance of personnel to determine their skill proficiency, their motivation and self-direction, their ability towork in a team environment, their readiness to accept more challenging positions, or their need to be retrained, reassigned,or terminated.

6. Develop and implement reward and advancement mechanisms to motivate personnel performance.

6.2.4.3.2 Other Resource Management

1. Define and maintain current information database in order to implement the requirements of this Standard within theorganization. Procedures for managing information should consider access and protection of information to assure integrityand availability.

2. Determine and provide the resource infrastructure support needed to implement the requirements of this Standard within theorganization and provide project support.

3. Define and implement those human and physical factors of the work environment needed to implement the requirements ofthis Standard within the organization.

6.3 Project Management Processes

The project management processes exist to establish and evolve project plans, to assess progress against the plans and tocontrol execution of the project through to its completion. The plans are developed to accomplish business objectives andproject goals established by the enterprise processes. For large projects, there may be a need to apply the project managementprocess at lower levels. The Project Management Processes consist of the following processes:

a) Planning Process

b) Assessment Process

c) Control Process

d) Decision Management Process

e) Risk Management Process

f) Configuration Management Process

g) Quality Management Process

NOTE 1 The Planning, Assessment and Control Process together are key to all management practise. They correspond to the plan, checkand act steps of the Plan, Do, Check, Act cycle evident in the management of any undertaking, ranging from a complete organization down to(and below) a single life cycle process. In this International Standard, the project has been chosen as the undertaking they are described interms of. Nevertheless, their principles can be applied in any area of an organization’s management (see Figure 4).

NOTE 2 In the project context, the Planning, Assessment and Control Process have a strategic nature and relate to key, usually recurrent,periods in the project’s life. However, decision management, risk management, configuration management and quality management have thenature of management actions continuously present throughout a project and are independently defined in this International Standard.

6.3.1 Planning Process

6.3.1.1 Planning Process Purpose

The Planning Process is applied to scope the project activities, identify work packages, configuration items and deliverables,establish schedules for work package conduct, including technical plans, and allocate resources to accomplish work packages.


16

6.3.1.2 Planning Process Outcomes

1) A project management plan that defines budget and resource allocation, work breakdown structure and achievementschedules.

2) Roles, responsibilities and authorities of project team members.

3) Specification of materials, facilities and enabling system services necessary to achieve the plan.

4) Work directives to team members updated (as necessary) in accordance with project plan.

6.3.1.3 Planning Process Activities

6.3.1.3.1 Identify Project Objectives.

The project objectives and constraints shall be identified in terms of quality, cost, time, organization and stakeholderssatisfaction. Each objective shall be identified in sufficient detail, in order to select, tailor and implement the appropriateprocesses and activities.

6.3.1.3.2 Establish Project Scope And Tasks

The project scope shall be defined on the basis of the stages in the complete system. This activity shall ensure that the projectincludes all the work required to satisfy enterprise decision criteria and complete the project successfully.

It consists of initiating and then evolving with time the scope definition and the related work breakdown structure of the project.The work breakdown structure shall be established and be based on the system architecture. For each subsystem orcomponent of the system architecture, appropriate processes and activities shall be described with a level of detail appropriateto the identified project and product risks

Related tasks in the work breakdown structure should be grouped into work packages. A work package identifies the work itemsbeing developed and/or produced and the associated tasks to be performed.

6.3.1.3.3 Establish Project Schedule

This activity shall ensure timely completion of the project. Based on work estimates, a schedule shall be defines that describesthe duration and the sequence of project activities and tasks.

Life cycle stage decision gates (milestones or reviews), deliveries dates, major dependencies on external inputs or outputs shallbe defined. Time intervals between internal project reviews shall be defined in accordance with organizational policy on issuessuch as business and product criticality, schedule and technical risks.

6.3.1.3.4 Establish Project Costs

This activity shall ensure that the project is completed within the approved budget. It consists of resource planning, costestimating and allocating budget reserves for risk management. Labour estimates, infrastructure costs, procurement items andestimates for acquired services from enabling systems shall be obtained.

6.3.1.3.5 Define Project Team

This activity shall establish the structure of authorities and assign responsibilities for project personnel, ensuring effective use ofhuman resources and drawing on functions that contribute to all stages of the system life cycle. It consists of defining the projectorganization, staff acquisition, development of staff skill and teamworking.

6.3.1.3.6 Define Project Infrastructure

The infrastructure and services required by the project shall be defined. It consists of identifying need for organizationalinfrastructure with defined capacity, negotiating its availability and allocating it to project tasks. This shall include facilities, tools,communications and information technology assets and enabling systems appropriate for the life cycle stage.

6.3.1.3.7 Define Project Acquisitions

The acquisition of materials, goods and enabling system services from outside the performing organization shall be planned.This shall include, as necessary, plans for solicitation, supplier selection, acceptance, contract administration and contractclosure.

6.3.1.3.8 Define Project Communication

This activity shall ensure in a timely manner the appropriate generation, collection, dissemination, storage, and ultimate archivingof project information. It consists of planning for the gathering essential project information from owners, for analyzing,


17

consolidating and filtering this information and for distributing to identified members of the project team, to enterprise functions inthe organization and to customers, as agreed. Due regard shall be payed to the quality, integrity and security of this information.

6.3.2 Assessment Process

6.3.2.1 Assessment Process Purpose

The Assessment Process evaluates periodically and at major events, as defined by the projects plans, the progress andachievements against plans and overall business objectives, assess risks relevant to the achievement of project, and theadherence to practices and procedures. This process includes the conduct of technical reviews.

6.3.2.2 Assessment Process Outcomes

1) Status of technical progress and achievement against schedules.

2) Status of technical progress and achievement against resource utilization

3) Predictions of costs and timescales to complete project tasks/achieve project deliveries

4) Status of performance indicators selected by the project, e.g. response time to changes, overhead labour costs

5) Project reports to enterprise functions.

6) Reports (as agreed) to acquirers

7) Current perception of risks

6.3.2.3 Assessment Process Activities

6.3.2.3.1 Assess Project Scope And Tasks

The continuing consistency and relevance of project plans contents shall be evaluated.

6.3.2.3.2 Assess Project Schedule

Using defined project metrics based on estimated achievement and milestone completion, project progress shall be assessedagainst plans and the terms of agreements. Technical progress shall be assessed against system requirements and designspecifications, using where possible declared and agreed verification and validation criteria.

6.3.2.3.3 Assess Project Costs

Actual or estimated labour, material and services costs shall be collected and evaluated at planned times against project costprofiles .

6.3.2.3.4 Assess Project Team

The effectiveness of the project team roles and structure shall be evaluated using where possible objective measures, e.g.project achievement, efficiency of resource use. The adequacy of team member competencies and skills to satisfy project rolesand accomplish project task shall be assessed. The effectiveness and value of supporting training should be assessed andevaluated.

6.3.2.3.5 Assess Project Infrastructure

The adequacy and availability of the project infrastructure and services shall be evaluated at the required intervals to ensure thatintra-organizational commitments are satisfied.

6.3.2.3.6 Assess Project Acquisitions

The adequacy and availability of acquired goods, materials and enabling system services shall be evaluated.

6.3.2.3.7 Assess Project Communication

The effectiveness of data gathering, processing and dissemination shall be evaluated. The quality of the information and itsvalue to recipients should be assessed periodically.


18

6.3.3 Control Process

6.3.3.1 Control Process Purpose

The Control Process is applied to control project execution against plans, manage intermediate and final configuration items, andmanage risks to successful project completion.

The purpose of Control Process is to provide the redirection of that work to overcome obstacles, to respond to changingcircumstances, or to correct variances. It uses outcomes from the Assessment Process. It determines readiness to proceed tothe next stage of the system’s life cycle.

6.3.3.2 Control Process Outcomes

No project intervention if variances conform acceptably to project plans.

Preventive and/or corrective actions that re-direct the project in order to achieve its objectives.

A requirement for project re-planning when project objectives or constraints have changed or when planning assumptions areshown to be invalid.

Project authorization to progress (or not) from one scheduled milestone or event to the next.

6.3.3.3 Control Process Activities

6.3.3.3.1 Control Project Tasks

Corrective actions and /or preventive actions to achieve technical tasks shall be defined, requested and tracked wheninsufficiencies have been detected by assessments. Measures of action effectiveness shall be defined.

6.3.3.3.2 Control Project Schedule

Corrective actions and /or preventive actions to achieve schedule objective shall be defined, requested and tracked wheninsufficiencies have been detected by assessments.

6.3.3.3.3 Control Project Costs

Corrective actions and /or preventive actions to achieve costs and budgets objective shall be defined, requested and trackedwhen insufficiencies have been detected by assessments.

6.3.3.3.4 Control Project Quality

Corrective actions and /or preventive actions to achieve quality objectives and related tasks shall be defined, requested andtracked when insufficiencies have been detected by assessments. Measures of action effectiveness shall be defined.

6.3.3.3.5 Control Project Team

Re-allocation of tasks to personnel shall be decided when inadequacy or unavailability have been detected by assessments.

6.3.3.3.6 Control Project Infrastructure

Re-deployment of tools, environments, infrastructure shall be decided when inadequacy or unavailability have been detected byassessments.

6.3.3.3.7 Control Project Acquisitions

Re-deployment of goods and service acquisitions shall be decided when inadequacy or unavailability has been detected byassessments.

6.3.3.3.8 Control Communication

Corrective actions and /or preventive actions to disseminate or improve dissemination of information shall be defined, requestedand tracked when insufficiencies have been detected by assessments.


19

6.3.4 Decision Management Process

6.3.4.1 Decision Management Process Purpose

The Decision Management Process is employed to identify, analyze and resolve opportunities or problems, whatever their natureor source, encountered during the life cycle of a system. Its identifies and selects in a timely manner from alternative courses ofaction in order to reach specified or optimized outcomes. It records decisions and their rationale to inform audits, non-conformance analysis and future decision making.

NOTE Decision management is a fundamental aspect of problem resolution and trade-off studies

6.3.4.2 Decision Management Process Outcomes

1) Problems and opportunities identified and recorded

2) Corrective action to resolve problems

3) Optimised courses of action

4) Reports on resolution and decision rationale

5) Record of problem and opportunity trends.

6.3.4.3 Decision Management Process Activities

6.3.4.3.1 Decision Management Planning

Categories of decision should be defined and responsibilities parties identified. A prioritization scheme within andbetween the categories should be defined.

6.3.4.3.2 Problem and Opportunity Statement

Detected problems or opportunities should be promptly and objectively reported, categorized and recorded.Problems or opportunities should be ranked in terms of their adverse or their beneficial impact in order toprioritize responses, select decision making strategies and facilitate subsequent analysis. Problem andopportunity status should be recorded, tracked and reported.

6.3.4.3.3 Cause Analysis

Relevant parties should be informed of the existence of a problem or opportunity in order to draw on experienceand knowledge. From changes, distinguishing or exceptional circumstances, event sequences, associations,experience, etc. the cause for a problem or opportunity shall be isolated and described.

6.3.4.3.4 Decision Resolution

Using an auditable decision strategy, courses of alternative action should be systematically evaluated. Objectiveoutcomes with measurable success criteria should be identified. In the case of problems, corrective actionshould either eliminate the adverse event or reduce its consequences to a level designated to be tolerable bythe party responsible for the decision category. In the case of opportunities, the balance of beneficial andadverse consequences of the alternative actions should be assessed to arrive at an improvement in, or anoptimization of, a current situation.

6.3.4.3.5 Decision Reporting

Dispositions of decisions and resultant actions should evaluate that problems have been effectively resolved,adverse trends have been reversed and opportunities take advantage of. Records of problems and theirdisposition shall be maintained as stipulated in agreements or organizational procedures. Decision recordsshould permit auditing and learning from experience.


20

6.3.5 Risk Management Process

6.3.5.1 Risk Management Purpose

The Risk Management Process is conducted to identify, assess and mitigate hazards resulting from any uncertain event thatmay occur and result in adverse consequences to system stakeholders and organization interested parties.

6.3.5.2 Risk Management Outcomes

1) Risk management plan

2) Risks identified, categorized and prioritized

3) Appropriate risk management strategies defined

4) Action taken to mitigate or avoid the impact of risk

6.3.5.3 Risk Management Activities

6.3.5.3.1 Risk Management Plan

A risk management plan shall be defined and should include the assumptions, responsibilities, review strategy and theauthorizations. Where appropriate, the actions to satisfy the requirements of regulatory bodies shall be planned.

6.3.5.3.2 Define Risks Categories

The risks should be defined in terms of their dimensions, e.g. technical, programmatic, organizational, financial, informationquality . Within these dimensions, the method for expressing risks shall be defined in suitable terms.

6.3.5.3.3 Identify Threats

Threats shall be identified to predict what could go wrong that would adversely affect the system and the organization. Theinitiating events associated with each threat in each risk type should be identified. coupling between other risk sources andtheir interrelationships should be defined. This may be based on project/product histories, checklists, questionnaires and expertanalysis

6.3.5.3.4 Analyze Risks

A frequency analysis of initiating event occurrence shall be conducted to identify the likelihood of threat occurrence. The impactevaluation should define the possible adverse consequences. . The risks should be prioritized in terms of their impact. This maylead to a definition of an integrity level that guides the level of formality with which life cycle processes are performed

6.3.5.3.5 Control Risk

A threshold of tolerability for each risk category should be defined. For each risk, its impact on the system stakeholders,including acquiring and supplying organizations, and from impact tolerability, a response is planned.

Where tolerable, the risk should be accepted and no action taken. Where an avoidance strategy can be identified, and thataction has cost, schedule and performance benefits to the organization, then the avoidance action should be taken. Whereneither of these actions is possible, a risk mitigation strategy should be followed

6.3.5.3.6 Assess Risk Management Effectiveness

Metrics that measure change in risk state shall be defined, e.g. residual financial/legal exposure of organization, and theprogress of risk mitigation actions assessed. When initiating events occur, the level of success shall be evaluated.

6.3.5.3.7 Document Risks

A register of risk should be maintained throughout the life of the system. This should define the current perception of risks,related to actions and budgets. This document records the history of the system risks, in order to assist decisions, and becomesa reference for an evolving design or for future, related systems.


21

6.3.6 Configuration Management Process

6.3.6.1 Configuration Management Process Purpose

The Configuration Management Process is a process of applying throughout the system life cycle administrative and technicalprocedures in order to identify, define, record and baseline the system, its subsystems and components, to control theirmodification and release, record and report the status of modification requests, and ensure their integrity and the integrity of theirdocumentation.

6.3.6.2 Configuration Management Process Outcomes

1) A configuration management plan

2) System, subsystems and components identified, defined and baselined

3) Controlled storage, handling and release of system, subsystems and components

4) Record of modification requests and actions to system, subsystems and components and their status

6.3.6.3 Configuration Management Process Activities

6.3.6.3.1 Configuration Management Planning

Authorities for the deposition of, access to, release of and control of changes to configuration items shall be defined. Thelocations of storage, its environment and, in the case of information, storage media shall be defined. This shall be in accordancewith designated levels of integrity, security and safety. The criteria or events for commencing configuration control andbaselining evolving configurations should be defined. The audit schedule and the responsibilities for ensuring continuousintegrity and security of the configured items should be planned.

6.3.6.3.2 Configuration Identification

The system entities that are subject to configuration control shall be identified. They should be distinguished by unique, durableidentifiers and markings, where appropriate, according to relevant standards and product sector conventions. The configureditems should be unambiguously traceable to their specifications or equivalent, documented descriptions. The configurationsdescriptions should conform, where possible, to product or technology standards.

6.3.6.3.3 Configuration Documentation

The configuration records should be held with a similar level of integrity and security to the configured items. They should permitforwards and backwards traceability to other baselined configuration states. The authorities and permissions relating to thecurrent configuration state of a configured item should be documented with the data identifying and describing the configuration.

6.3.6.3.4 Configuration Change Control

A change control authority shall be established to provide coordinated review, evaluation and disposition of documented andjustified change proposals to configured items. The evolving configuration state(s) of configuration items shall be consolidated toform documented baselines at designated times or under defined circumstances. These records of configuration baseline datashould define the steps of system configuration, the rationale for the baseline and associated authorizations. Configurationrecords should be maintained through the system life cycle and archived according to agreements or relevant legislation.

6.3.6.3.5 Configuration Status Accounting

The recording, retrieval and consolidation of the current configuration status and all preceding configurations, shall be managedto ensure information correctness, timeliness, integrity and security. The quality and correctness of this information should beroutinely audited and, where necessary, corrective actions taken to recover information integrity.

6.3.7 Quality Management Process

6.3.7.1 Quality Management Process Purpose

The Quality Management Process provides a sufficient level of confidence that the system conforms to agreements and meetscustomer satisfaction and that throughout the organization and at all times the life cycle processes are conducted according toagreements, the organization’s policies and procedures and the project’s approved plans.

6.3.7.2 Quality Management Process Outcomes

1) Organization and project quality requirements and commitments


22

2) Effective, workable quality management plans

3) Verified conformance to agreements

4) Customer satisfaction information

5) Quality status reports

6.3.7.3 Quality Management Process Activities

6.3.7.3.1 Establish Quality Management Infrastructure

A quality management system in accordance with ISO 9001 :2000 shall be defined, established, operated and maintained.Where individual project factors require additional local responsibilites, resouces and procedures, these shall be defined,established and managed by the project.

6.3.7.3.2 Establish quality management plans

Quality objectives shall be defined by projects and be consistent with the organization’s quality management system.Management plans should be documented to assure their achievement. These plans should include a definition of the means bywhich agreements are to be met and customer satisfaction achieved.

6.3.7.3.3 Perfomance Assessment

Reviews, audits and inspection against project plans shall be conducted according to defined schedules to demonstrateconformance of actions and outcomes to the quality management plans. Metrics should be defined and data gathered to permitobjective assessment of customer satisfaction.

6.3.7.3.4 Corrective Actions

In the case of non conformance to agreements and/or quality plans by the system product or service, and/or the organization’sexecution of the life cycle processes, preventative and corrective actions shall be taken. These actions shall be documentedand reviewed to confirm their adequacy and timeliness.

6.4 Technical Processes

The Technical Processes provide generic activities and tasks for defining the need for a system, analyzing system requirements,establishing functional designs, conducting studies to optimise solutions and reduce risks, ensuring cost effectiveness of thedesigns, conducting tests and evaluations, addressing safety, security, human factors and environmental issues, and ensuringthat the system is producible, operable, usable and supportable

The Technical Processes consist of the following processes:

a) Stakeholder Needs Definition Process

b) Requirements Analysis Process

c) Architectural Design Process

d) Implementation Process

e) Integration Processes

f) Verification Process

g) Transition Process

h) Validation Process

i) Operation Process

j) Disposal Processes


23

6.4.1 Stakeholder Needs Definition Process

6.4.1.1 Stakeholder Needs Definition Purpose

The Stakeholder Needs Definition Process is performed to define the need for a system that can provide services to users andother stakeholders in a defined environment. This is achieved by developing a model, frequently textual, that concentrates onsystem purpose and behaviour and is described in the context of operational environment and conditions. The stakeholderneeds identify the parties involved with the system throughout its life cycle and express their needs, wants, desires andexpectations, together with the constraints they and the operational environment impose. This involves capturing, clearlyarticulating and managing the requirements of each and every stakeholder, or stakeholder class, in a form that permitscontinuous tracing of decisions to their needs throughout the life cycle. The stakeholder needs are the reference against whichthe resulting operational system services are compared in order to validate that the system fulfils stakeholders needs.

6.4.1.2 Stakeholder Needs Definition Outcomes

1) A definition of the requirements, desires and expectations of the customer and users

2) A definition of the context of use of users and operators including their capabilities, capacities, environments

3) A basis for negotiating and agreeing to supply a system service or product

4) A basis for accepting a system service or product supplied according to an agreement

6.4.1.3 Stakeholder Needs Definition Activities

6.4.1.3.1 Recognize Need or Opportunity

The organization should maintain a technical capability that can recognise the need for a system arising in a market and/or thatcan respond to solicitation opportunities for a system. The organization should be capable of appreciating the system’s contextof need and purpose, its life cycle stages and timescales, and the value of the service it offers to users.

6.4.1.3.2 Identify Stakeholders

This activity identifies the individual stakeholders or stakeholder classes who have a legitimate interest in the system throughoutits life cycle. This includes, but is not limited to, users, supporters, developers, producers, trainers, maintainers, disposers,acquirer and supplier organizations, regulatory bodies and members of society. Where direct contact is not practicable, e.g.consumer products and services, representatives or designated proxy stakeholders are selected, e.g. marketing.

6.4.1.3.3 Needs Elicitation

Stakeholder needs elicitation captures the expressed needs, wants, desires expectations and perceived constraints of each andevery stakeholder or stakeholder class together. Wherever possible this should be associated with their rationale, includingsource solicitation documents or agreements. This includes the needs and constraints imposed by society, the constraintsimposed by an acquiring organization and the capabilities and limiting characteristics of operator staff. All expressions of needexclude unjustified constraints on system solution options. They state the assumptions of stakeholders and the value they placeon the satisfaction of their requirements . Each and every stakeholder need shall be expressed in a way that permits theoperational system performance to be measured and assessed for conformance to them.

NOTE The organization that creates the system is also a stakeholder and their additional stakeholder needs include enterprise andproject constraints and practises, such as business policy and procedures, concept reuse, component reuse, existing design, production,support and retirement enabling system reuse.

6.4.1.3.4 Context Analysis.

Operational sequences shall be defined to identify a complete set of services under different operational scenarios andenvironments. The operation of the system in its intended environment shall be analyzed to derive additional requirements whichmay not have been formally specified by any of the stakeholders. This shall include legal and social obligation not otherwisedefined. The cultural and management environment influences on users and operators that could affect system use or constrainits design shall be analyzed.

6.4.1.3.5 Human Factors Analysis.

The ability of humans to interact with the system shall be analyzed and decisions made that will result in acceptable ease andefficiency of use, and prevent operator or user errors to the extent possible. Applicable standards and accepted professionalpractices should be used. A determination shall be made as to which system requirements should be allocated to individualoperators. The determination shall include the following factors, as a minimum, for most effective, efficient, and reliable humanperformance and human-machine interactions. A complete set of usability requirement shall be derived from this analysis.Applicable standards and practices should be used.

Physical, mental, and learned capabilities;


24

Work place, environment, and facilities;

Normal, unusual, and emergency conditions;

Operator training;

Integration of human performance into system design and operations.

Safety critical human actions and how the consequences of error are addressed

Opportunities for automation to enhance the performance of operators

6.4.1.3.6 Safety Factors Analysis.

System requirements and functions that could impact safety shall be analyzed and specified. These include methods ofoperations and support, environmental influences, and health and safety. Applicable standards and practices should be used.

6.4.1.3.7 Security Factors Analysis.

System requirements and functions that could impact security shall be analyzed and specified. These include access anddamage to protected personnel, properties and information, compromise of sensitive information, denial of approved access toproperty and information. All applicable areas of security shall be addressed: physical, procedural, communications, computers,and emission. Mitigation and containment approaches should be addressed. Applicable standards and practices should beused.

6.4.1.3.8 Resolve Stakeholder Need Conflicts

From the complete set of elicited needs, analysis shall deconflict and resolve the contradictory, ambiguous, inconsistent,incongruous and unverifiable needs. Needs which cannot be realized or are impractical to achieve shall be identified.

6.4.1.3.9 Confirm Stakeholder Needs

The analysed needs shall be fed back to all stakeholders to ensure that they comply with to their intended needs andexpectations. This activity establishes that the Stakeholder Requirements are comprehensible to all originators, that they areexpressed correctly and that the resolution of conflict in the needs has not corrupted or compromised stakeholder intentions.

6.4.1.3.10 Baseline the Stakeholder Needs

The stakeholder needs shall be held in an appropriate information database that permits management of the analysed data setthroughout the life cycle. This should provide access during the whole lifetime of the system and beyond. The stakeholderneeds database should enables changes of need and their origin to be recorded throughout the system life cycle, act as aninformation source for trade-off decisions and, in the case of persistent stakeholder needs, form a source of knowledge forsubsequent system solutions.

6.4.2 Requirements Analysis Process

6.4.2.1 Requirements Analysis Process Purpose

The Requirements Analysis Process transforms the stakeholder, needs-driven view of desired system services into a technical view of arequired system product(s) that could deliver those services. The resulting System Requirement specifies from the developer’sperspective what the system is required to do in order to satisfy stakeholder needs. The objective is to build a representation of a futuresystem product(s) that will meet stakeholder needs and that, as far as constraints permit, avoids implementation issues. The systemrequirements are the basis for tests that verify the conformance of a supplied system to the designers’ intended solution.

NOTE System Requirements depend heavily on abstract representations of proposed system characteristics and may employ multiplemodelling techniques and perspectives to give a sufficiently complete description of the desired system technical requirements.

6.4.2.2 Requirements Analysis Process Outcomes

A defined set of System Requirements that are :

1) A statement of the technical problem that must be solved

2) A basis for establishing the design solution of the system architecture

3) A basis for demonstrating compliance of the realized system with its technical description


25

6.4.2.3 Requirements Analysis Process Activities

6.4.2.3.1 Define System Functional Boundaries

The interface constraints at the boundary of the system should be analyzed and defined, such as mechanical, electrical, mass,thermal, data, procedural, in quantitative terms.

The system boundary should be define in terms of properties and behaviour to be provided by the system. This establishes theexpected interactions at the defined boundary e.g. data flows, stimuli presented to and responses to user and systembehaviours.

6.4.2.3.2 Functional Analysis

Functional analysis should define the circumstances in which each function is performed. These may be grouped and associatedwith different, characteristic modes of operation. Each mode is specified by a particular set of functions and is related to eventswhich cause a transition from one mode to another.

The expected behavioural responses to inputs should be analyzed and defined and how well functions are to be accomplishedshould be quantified.

6.4.2.3.3 Define Performance Measures

Technical performance metrics should be defined by which technical achievement will be assessed.

The critical performance metrics associated with each measure identified in the stakeholder needs, and by which the system willbe deemed successful, should be analyzed and defined; if not met they may represent a project cost, schedule or performancerisk.

6.4.2.3.4 Human Factors

The human factor constraints, such as physical space limits, climatic limits, eye movement, reach, information rates andergonomics, shall be analyzed and defined. They affect operator interactions with other system components and user interfacesto the system throughout the life cycle.

Operator usability factors should also be analyzed.

NOTE Guidance is provided in ISO 6385 :1981

6.4.2.3.5 Safety

Analyze and define safety considerations including those relating to methods of operation and maintenance, environmentalinfluences and personnel injury

Analyze and define safety related risks of hazards and mishaps.

Each safety function and its associated safety integrity, expressed in terms of the necessary risk reduction, shall be specifiedand be allocated to designated safety-related systems.

Applicable standards concerning occupational safety, security and environmental protection shall be used.

6.4.2.3.6 Security

Analyze and define security considerations including those related to compromise and protection of sensitive information, dataand material

Analyze and define security related risks in areas including, but not limited to, administrative, personnel, physical, computer,communication, network, emanations and environmental areas

6.4.2.3.7 Analyze System Requirements Integrity

Check that each system requirement statement is unique, consistent, complete, verifiable, implementable and unambiguous

Identify and resolve conflicts within the set of system requirements

Ensure that the resulting set of system requirements are necessary and sufficient for the design of a system solution.


26

6.4.2.3.8 Requirements tracing

Traceability between the system requirements and the stakeholder requirements shall be demonstrated. The traceability shallbe both forwards and backwards, i.e. all achievable requirements must be met by one or more system requirements, and allsystem requirements must meet or contribute to meeting at least one Stakeholder Requirement. The System Requirementsshall be complete, consistent and achievable given current technologies or knowledge of technological advances.

6.4.2.3.9 Establish Requirement Baseline

The set of system requirements are defined and documented, together with the associated rationale, decisions, andassumptions.

The system requirements should be held in an appropriate information database that permits traceability to stakeholder needsand architecture design.

6.4.3 Architectural Design Process

6.4.3.1 Purpose

Architectural design partitions a system into a set of separate problems of manageable, conceptual and, ultimately, realisableproportions. Architectural design involves identifying and exploring one or more implementation strategies at a level of detailconsistent with the system’s technical and commercial requirements and risks. From this, a design solution is defined in terms ofthe requirements for a complete set of technically and commercially viable components from which the system is configured. Thearchitectural design is also a basis for planning and devising an assembly and test strategy that will detect and diagnose faultsduring the integration steps.

NOTE Architectural design should encapsulate and define areas of solution, hide unnecessary detail and establish a basis fordetection/correction of errors throughout the system life cycle.

NOTE Successive applications of the Architectural Design Process and the Requirements Analysis Process are repeated for subsystemsuntil a component level is identified at which the appropriate component development standard is used

6.4.3.2 Architectural Design Process Outcomes

1) Data that informs the decision to develop, reuse or procure components off-the-shelf.

2) Data that informs how best to employ humans to achieve an optimised system performance.

3) Component requirement documents that specify the configuration of components that comprise an optimized systemdesign.

4) A basis for demonstrating compliance of the configured system, and intermediate build configurations, with its designdescription(s).

6.4.3.3 Architectural Design Process Activities

6.4.3.3.1 Partitioning

Partitioning allocates the system functions identified in Requirements Analysis Process to elements of system architecture. Theresulting architectural design shall be analyzed to establish design criteria for each element, in terms of physical, performance,behavioural, and durability characteristics.

A determination shall be made as to which system requirements should be allocated to operators. The determination shallinclude the following factors, as a minimum, for most effective, efficient, and reliable human performance and human-machineinteractions. Applicable standards and practices should be used.

a) Physical, mental, and learned capabilities;

b) Work place, environment, and facilities;

c) Normal, unusual, and emergency conditions;

d) Operator training for performing the tasks;

e) Integration of human performance into system design and operations.


27

6.4.3.3.2 Produce, Acquire or Re-use Analysis

Identified hardware and software design elements shall be analyzed to determine if off-the-shelf components exist which satisfythe design and interface criteria. Design elements which are not readily available shall be evaluated to determine if an elementshould be developed, or if existing components should be re-used. The costs, schedule, and technical risks associated withthese make-or-buy decisions shall be established.

6.4.3.3.3 Component Definition

6.4.3.3.4 Design Trade-off

Competing designs should be explored at a level of detail that permits them to be compared against the technical specificationsexpressed in the System Requirements and the performance, costs, timescales and risks expressed in the stakeholder needs.By evaluating the system characteristics achieved using different candidate components in the system architecture, the trade-offdecisions lead toward an optimised design.

Trade-off formalises the selection of different, competing solution implementations and results in the definition of a structuredset of existing or realizable components.

6.4.3.3.5 Interface Definitions

Interface control documents should be used to manage the internal interfaces between components and those interfaces that thecomponents present at the system boundary to the environment. Human-system and human-human interfaces should also bedefined and controlled. Interface definition should conform to recognized product sector or international standard where theseexist, e.g. ISO 9241 in the case of human-computer interfaces.

6.4.3.3.6 Review Architectural Design

The review of the architectural design verifies that the selected architecture solution is consistent and complete with respect tothe set of technical requirements and derived technical requirements for which the solution is being engineered or reengineered.

6.4.3.3.7 Specify Components

Each component should be described only in terms of its individual behaviour, its interfaces and unavoidable implementationconstraints. These specifications are the basis of the system solution and an origin for component acquisition agreements. Theyare the basis for defining acceptance/validation of the components, whether produced, reused or acquired.

6.4.3.3.8 Baseline the Architectural Design

The architectural design information should be held in an appropriate information database. This records the structural andfunctional partitioning, interface and control definitions and the design decisions and conclusions.

The architectural design baseline is also the information source from which integration tests are designed.

The architectural design baseline enables review in the event of change throughout the life cycle as well as informing anysubsequent re-use of the architecture.

6.4.4 Implementation Process

6.4.4.1 Implementation Process Purpose

The Implementation Process fulfils an agreement to the supply a component in acquirer’s system by specifying, designing indetail and fabricating a component using a selected technical discipline(s) and implementation technology(ies). The fabricatedcomponent is supplied following its assembly and successful test against the criteria derived from the component characteristicsdefined in the agreement.

NOTE The component may be viewed as a subsystem by the acquirer and/or a system by the supplier

6.4.4.2 Implementation Process Outcomes

1) Delivered component conformant to an agreement for its supply

2) Design, configuration and performance specifications for the component

3) Design, fabrication and test data on the component

4) Qualification data (in the case of regulated products)


28

6.4.4.3 Implementation Process Activities

6.4.4.3.1 Component Specification

The architectural design specifications, together with the relevant constraints, e.g. legal, and the self-imposed supplierconstraints, e.g. common component supply to multiple acquirers, should be analysed to give component requirements that drivethe supply of each of a complete set of components.

6.4.4.3.2 Component Detailed Design

The component shall be designed and documented in detail so that, by employing a selected technical discipline(s) andimplementation technology(ies) it may be implemented. Design decisions shall be recorded, including the techniques andmaterials selected for fabrication. This shall be conducted in accordance with standards that govern their relevantimplementation technology, technical discipline or product sector

1. Hardware Design.

Hardware elements shall be designed in accordance with established procedures, standards, and regulations.

2. Software Design.

Software for digital computers shall be designed in accordance with ISO/IEC 12207.

3. Human Task Design.

Human tasks shall be designed in accordance with established procedures, standards, and regulations.

6.4.4.3.3 Component Fabrication

Where the component is fabricated, that fabrication shall be in accordance with standards that govern their relevantimplementation technology, technical discipline or product sector and take account of applicable safety, security andenvironmental guidelines or legislation. Alternatively, components may be bought off-the-shelf.

a) Hardware Fabrication.

The fabricated elements shall be evaluated to assess their producibility and to derive necessary design modifications basedupon fabrication tolerances and verification uncertainties. Hardware elements shall be fabricated, and certified to establish theirconformance to the design criteria specified in the data package.

a) Software Coding.

Software elements shall be coded, compiled, and inspected to certify their conformance with the design criteria specified in thedata package. ISO/IEC 12207 is applicable.

6.4.4.3.4 Component Integration

The component should, where applicable, be integrated in accordance with standards that govern their relevant implementationtechnology, technical discipline or product sector. The integration strategy should take due regard of the need to identify anddiagnose systematic and/or isolated failures resulting either from design failings or fabrication faults.

6.4.4.3.5 Component Verification

The component shall be verified in accordance with standards that govern their relevant implementation technology, technicaldiscipline or product sector. Where appropriate, qualification of the component shall be conducted according to legal, regulatoryor product sector requirements.

6.4.5 Integration Process

6.4.5.1 Integration Process Purpose

The Integration Process assembles the verified components to create the system product specified in the System Requirements.It informs design actions of the practical constraints and limitations resulting from integration facilities.

6.4.5.2 Integration Process Outcomes

1) A system integration plan


29

2) Specified enabling integration systems

3) The assembled system product capable of being verified against System Requirements

4) Corrective action reports

6.4.5.3 Integration Process Activities

6.4.5.3.1 Integration Planning

An assembly sequence and strategy that minimises system integration risks shall be defined. This strategy may permitverification against a sequence of progressively more complete component configurations and be consistent with a fault isolationand diagnosis strategy. I should define the schedule of component availability and the availability of the verification facilities,including jigs, conditioning facilities, assembly equipment.

6.4.5.3.2 Receive Components

Components should be received from their supplier(s) or withdrawn from storage in accordance with agreed schedules. Theyshould be handled in accordance with relevant health, safety and security considerations.

6.4.5.3.3 Component Acceptance

The components should be verified by inspection or tested against acceptance criteria specified in an agreement and acceptedor rejected accordingly. The conformance/non-conformance data should be documented. Reject components shall be identifiedas such and handled in conformance with defined procedures.

6.4.5.3.4 Integrate components.

The components shall be integrated to establish the interface connections between them. Integration shall be according to thedefined assembly procedures, using specified integration facilities, including jigs, conditioning and disposable assemblymaterials. This should follow an assembly strategy that minimises system integration risk and may progressively buildconfidence in the ultimate conformance of the fully integrated system product. It may give rise to intermediate assemblyconfigurations that exhibit verifiable physical characterisitics, interactions with humans or information/resource flows that mayassist fault isolation and diagnosis.

6.4.5.3.5 Document Integration Data

Integration results shall be recorded in an appropriate information database. This should include non conformance correctiondue to the integration strategy, the integration enabling system(s) or manual assembly errors. The data shall be analysed toenable corrective or improvement actions to the integration strategy and its execution.

6.4.6 Verification Process

6.4.6.1 Verification Process Purpose

The Verification Process confirms, through the provision of objective evidence, that the behaviour and characteristics of thesystem product comply with its requirements. Verification provides the information required to effect the remedial actions thatcorrect failings in the system or the processes that act on it. The Verification Process informs design actions of the practicalconstraints and limitations resulting from verification facilities.

NOTE Verification demonstrates through assessment of the system product that the system, as made, is ‘right’, i.e. fulfils the specifieddesign.

6.4.6.2 Verification Process Outcomes

1) Verification Plans

2) Confirmation that the system product conforms to system requirements.

3) Confirmation that the system requirements describe the required system product.

4) Specified tests derived from system requirements

5) Non conformance reports capable of guiding corrective actions


30

6.4.6.3 Verification Process Activities

6.4.6.3.1 Define Verification Strategy

The strategy for verifying the system product should be defined. The context of each instance of verification should be defined,e.g verifying the design, the ability to build the design correctly, the ability to reproduce the system, the ability to correct a faultarising, the ability to predict failures. The nature and scope of the verification action, e.g. reviews, inspections, audits,comparisons, static tests, dynamic tests, demonstrations (or a combination thereof) ; typically, it will depend on the Life CycleStage, the system novelty, safety and criticality issues, and the agreement and organizational constraints.

6.4.6.3.2 Plan Verification

Verification plans shall be defined and based on system requirements.

The plans should account for the sequence of configurations defined in the integration strategy and, where appropriate, takeaccount of disassemby strategies for fault diagnosis. The schedule should define risk-managed verification steps thatprogressively build confidence in compliance of the fully configured product.

The plans should specify the enabling equipment, facilities and services, together with their acceptance criteria.

6.4.6.3.3 Detection of non conformance and fault

Verification shall be conducted to detect in the realized system product the existence of random and systematic nonconformance to system requirements. Verification should be undertaken in a manner, consistent with organizational constraints,such that uncertainty in the replication of verfication actions, conditions and outcomes is minimized. Objective and authenticatedrecords of verification actions and outcome shall be made.

6.4.6.3.4 Diagnosis of non conformance and Fault

As appropriate to agreement terms or organizational objectives, verification shall be coducted to isolate that part of the systemgiving rise to a non coformance. This may result from the need for corrective action and/or the quality management policy. Faultresolution should be conducted to a level consistent with cost effective remedial action, including re-verification following defectcorrection, or organizational quality improvement actions.

6.4.6.3.5 Fault Reporting and Analysis

Verication data is collected, classified and collated according to criteria defined in the verification strategy. This shouldcatagorize non conformances according to their source and corrective action owner. The verification data should be analyzed todetect essential features such as trends and patterns of failure, evidence of systematic failings, emerging threats to systemservices.

6.4.7 Transition Process

6.4.7.1 Transition Process Purpose

The Transition Process installs the verified system in its operational location(s) according to an agreed schedule, together withthe utilization stage enabling systems, e.g. operating system, support system, operator training system, user training system, asdefined in agreements, in order to establish the capability to provide the system services specified by the stakeholder needs.

6.4.7.2 Transition Process Outcomes

5) The system product installed in its operational location

6) The system capable of being operated at the location(s) and time(s\ stated in terms of stakeholder needs

7) A system service sustainable by enabling systems

NOTE The utilization stage enabling systems ensure continuous service during utilization through, for example, continuous availability ofoperators, adaptable operating procedures, remedial maintenance actions, provisioning of consumable materials, system adaptations.

8) Continuity of service, in the case of changeover from an existing system


31

6.4.7.3 Transition Process Activities

6.4.7.3.1 Plan Transition

Transition plans shall be prepared to ensure the system capability is available in accordance with agreements. These plansshould be communicated to all service providers who enable a sustainable system service during utilization.

6.4.7.3.2 Prepare Operating Site

The site of operation shall be prepared in accordance with installation requirements. Site preparation shall be conducted inaccordance with applicable health, safety, security and environmental regulations.

6.4.7.3.3 Deliver System Product

The system should be delivered for installation at the correct location and time, accounting as necessary for intermediate storageneeds.

6.4.7.3.4 Install System Product

The system shall be installed in its operational location(s) and interfaced to its environement according to its systemspecification.

6.4.7.3.5 Accustom Operators

The competence of operators shall be demonstrated and/or confirmed in accordance with operating procedures and, whereapplicable, health and safety legislation and regulatory body requirements. Trained or certified operators should be made awareof the system in its operational location and state through a defined programme of familiarization.

6.4.7.3.6 Commission system

The system shall be brought into a state of operational readiness. Operators and utilization stage enabling systems shall be fullyfunctioning and their integrated with the system. The system should be demonstrated capable of containing its operational levelof consumable materials.

When the system replaces existing systems that are being retired and where agreed, continuous service capacity and qualityshall be maintained. During a specified period of changeover, concurrent operation and the transfer of services should bemanaged so that continuing conformance to persistent stakeholder needs is achieved.

6.4.7.3.7 Record Installation Results

The installation data should be recorded, including the operational configuration, anomolies detected, actions taken and lessonslearned. Where inconsistencies exist at the interface between the system, its specified operational environment and theutilization stage enabling systems, the deviations shall lead to corrective actions and/or requirement changes.

6.4.8 Validation Process

6.4.8.1 Validation Process Purpose

The Validation Process is conducted to provide objective evidence that the services provided by the system comply with theoperational needs stated by stakeholders and defined an agreement to acquire the system. Where variances are identified,these are recorded and drive corrective actions. Since validation is a comparative assessment against stakeholder needs, it alsoresults in confirmation that stakeholders’, and in particular the users’, needs were correctly identified and requested ; againvariances lead to corrective actions.

NOTE 1 Validation demonstrates through assessment of the system services presented to the stakeholders that the ‘right’ system hasbeen created, i.e. is fit for purpose.

NOTE 2 Validation may also be conducted to confirm that the system not merely satisfies all functional, usability and operationalrequirements, but also satisfies the often less formally expressed, but sometimes overriding, attitudes, experience and subjective test whichcomprise customer satisfaction.

6.4.8.2 Validation Process Outcomes

1) A system validation strategy

2) Specified tests derived from stakeholder needs


32

3) Confirmation that the system services needed by stakeholders are available to them.

4) Confirmation that the stakeholder needs faithfully describe the required system services.

5) Non conformance reports capable of guiding corrective actions

6.4.8.3 Validation Process Activities

6.4.8.3.1 Define Validation Strategy

The strategy for validating the system product should be defined. it will depend on the Life Cycle Stage, the system novelty,safety and criticality issues, and the agreement and organizational constraints.

6.4.8.3.2 Plan Validation

Validation plans shall be defined and based on system requirements. The plans should account for the sequence ofconfigurations defined in the integration strategy and, where appropriate, take account of disassemby strategies for faultdiagnosis. The schedule should define risk-managed validation steps that progressively build confidence in compliance of thefully configured product. The plans should specify the enabling equipment, facilities and services, together with their acceptancecriteria.

6.4.8.3.3 Detection of Non Conformance

Validation shall be conducted to detect in the realized system product the existence of random and systematic non conformanceto system requirements. Validation should be undertaken in a manner, consistent with organizational constraints, such thatuncertainty in the replication of verfication actions, conditions and outcomes is minimized. Objective and authenticated recordsof Validation actions and outcome shall be made.

6.4.8.3.4 Diagnosis of Non Conformance

As appropriate to agreement terms or organizational objectives, validation shall be coducted to isolate that part of the systemgiving rise to a non coformance. This may result from the need for corrective action and/or the quality management policy. Thesources of non conformance may be: incorrect performance of validation tests; incorrect validation test specification; deficientsystem service; or incorrect, outdated or newly discovered stakeholder needs. Fault resolution should be conducted to a levelconsistent with cost effective remedial action, including re-validation following defect correction, or organizational qualityimprovement actions.

6.4.8.3.5 Non Conformance Reporting and Analysis

Verication data is collected, classified and collated according to criteria defined in the Validation strategy. This should catagorizenon conformances according to their source and corrective action owner The Validation data should be analyzed to detectessential features such as trends and patterns of failure, evidence of systematic failings, emerging threats to system services.

6.4.9 Operations Process

6.4.9.1 Operation Process Purpose

Operation involves staffing and training operational personnel, operating the system, monitoring system performance andrecording problems for corrective action.

6.4.9.2 Operation Process Outcomes

1) A sustained system service meeting stakeholder needs

2) System product and service adaptation to changing need

6.4.9.3 Operation Process Activities

6.4.9.3.1 System Application.

The system , integrated as appropriate with operations enabling systems, shall be activated and applied in its intendedoperational context to achieve its intended purpose. This shall be conducted in accordance with health and safety regulationsapplicable to users and operators, security considerations and regulations and with due regard to environmental factors.


33

6.4.9.3.2 Staffing.

Staffing shall be conducted to assign qualified personnel to be system operators. The knowledge and skill requirements foroperators should be used to guide the personnel selection criteria and their accreditation and certification, where relevant.Selection and preparation of instructors to perform training that uses the operational system may be a key component of staffing.

6.4.9.3.3 Training.

Training shall be conducted to enhance operational personnel knowledge of system operations and to enhance their skills.Training should address aspects of system operation, including how to cope with and contain system failures. Training involvesthe conduct of pre-defined training programs and may involve advanced training systems, such as simulations or computer-based training facilities that may be a required mode of the operational system. If the system warrants a separate trainingsystem to enable operator training, then requirement for, and operation of, an enabling system for training should have beenidentified earlier in the system life cycle.

6.4.9.3.4 Operations Management.

Operations Management shall be conducted to ensure that the system is operated in accordance with established operationalprocedures to satisfy business objectives.

6.4.9.3.5 Performance Monitoring.

System operations should be monitored to assess system effectiveness, to determine the useful life of hardware components,and the affects of stress and fatigue on operational personnel. Data collection activities should use analysis to assess systemintegrity (including operational personnel), and determine the need for preventive maintenance, corrective actions, orremediation. System operations should be monitored to ensure that the system is operated in a safe manner, and complies withlegislated guidelines concerning occupational safety and environmental protection.

6.4.9.3.6 Problem Reporting and Analysis.

Problem Reporting and Analysis shall be conducted to identify failure trends which warrant corrective actions. Problem reportsshall be generated, verified, and analyzed to the extent necessary to identify the cause of failure and any contributing factors.Failure analysis can range from simple investigations of circumstances surrounding the failure to a sophisticated laboratoryanalysis of the failed hardware. The level of analysis should be sufficient to provide an understanding of the cause of the failureso that logically derived corrective actions can be developed.

6.4.10 Disposal Process

6.4.10.1 Disposal Process Purpose

The Disposal Process is applied to deactivate and remove the system from operational service, consigning it to a final conditionand returning the environment to its original or an acceptable condition. Serviceable system elements are reuse or recycled;worthless systems or system elements are stored or destroyed.

6.4.10.2 Disposal Process Outcomes

1) The systems and its components reused, stored or destroyed

2) The environment returned to its original or an agreed state

6.4.10.3 Disposal Process Activities

6.4.10.3.1 Deactivation.

The system shall be deactivated to prepare it for removal from operation. Operators Interfaces to other systems (e.g. power, fuel)shall be disconnected and . The System should be broken-down into manageable elements to facilitate its removal for reuse,recycling, reconditioning, overhaul or destruction.

6.4.10.3.2 Removal.

Operating staff shall be withdrawn from the system and relevant operating knowledge recorded. The system or its elements shallbe removed from the operational environment for reuse, recycling, reconditioning, overhaul, or destruction. This shall be inaccordance with relevant safety, security and environmental standards, directives and laws.

6.4.10.3.3 Reuse.

Elements of the systems, which have useful life remaining, may be reused or transferred to other organizations in their currentcondition or following overhaul. Reconditioning of system components, to extend their useful life, my lead to their reuse.


34

6.4.10.3.4 Storage

Where the system or its components are to be stored, then containment facilities and storage locations shall be specified andacceptance criteria defined, in accordance with relevant safety, security and environmental standards, directives and laws.

6.4.10.3.5 Destruction.

Destruction of the system or its elements shall be conducted, as necessary, to reduce the amount of waste treatment or to makethe waste easier to handle. Destruction should define the services required in order to melt, crush, incinerate or demolish thesystems or elements.

6.4.10.3.6 Information Archiving

Information gathered through the lifetime of the system should be archived to permit audits and reviews in the event of legacythreats to health, safety, security and the environment and to permit future system creators and users to build a knowledge basefrom past experiences.

7 System Life Cycle Management

This Clause describes a framework for the detailed modelling of system life cycles using the system life cycleprocesses described in Clause 6.

7.1 Establishing Life Cycle Models And Responsibilities

A life cycle model shall be established. This life cycle model should include one or more stage models, asneeded. The model(s) should be assembled as a sequence that may overlap and/or iterate the life cycle stagesas appropriate for the scope, magnitude and complexity of the system. The processes and activities, asselected, tailored and employed in a stage, shall fulfil the objectives in that stage.

7.2 A Life Cycle Example

Stages are illustrated in this International Standard using a commonly encountered example of life cycle stages. This exampleis partitioned into six stages, which are listed as follows and described in terms of their purpose andobjectives.

1) Concept stage

2) Development stage

3) Production stage

4) Utilization stage

5) Support stage

6) Retirement stage

Different organizations may undertake different stages in the life cycle. However, each stage should be conducted by theorganization responsible for that stage with due consideration of the available information on life cycle plans and decisions madein preceding stages. Similarly, the organization responsible for a stage should record assumptions and decisions maderegarding subsequent stages in the life cycle.

7.2.1 Concept Stage

The Concept Stage begins with initial recognition of a need or a concept for a new system or for themodification to an existing system. This is an initial exploration, fact finding, and planning period, wheneconomic, technical, strategic, and market bases are assessed through customer/market survey, feasibilityanalysis and trade-off studies. One or more alternative solutions to meet the identified need or concept aredeveloped through analyses, feasibility evaluations, estimations (such as of cost, schedule, marketing,


35

intelligence, and logistics), trade-off studies, and experimental or prototype development and demonstration.Customer/user feedback to the need or concept may be solicited. The need for one or more enablingsystems for development, production, operations, support and retirement of the system solution(s) isidentified and candidate solutions included in the evaluation of alternatives in order to arrive at a balanced,life cycle solution . Typical outputs are stakeholder requirements, preliminary systems requirements, outlinedesign solutions in the form of drawings, models, prototypes, etc., and concept plans for enabling systems.Decisions are made whether to continue with the implementation of one promising solution in theDevelopment Stage or cancel further work.

It is presumed that the organization has available the methods, techniques, tools and competent humanresources to undertake market/economic analysis and forecasting, feasibility analysis, trade-off analysis,technical analysis, cost estimation, modelling and simulation, and prototyping.

7.2.1.1 Concept Stage Purpose.

To assess new business opportunities and develop preliminary systems requirements and a viable designsolution.

7.2.1.2 Concept Stage Outcomes.

The objectives in the Concept Stage are listed below:

1) The identification of new system concept which offer new capabilities, enhanced overall performanceor improved life cycle costs.

2) An assessment of feasible system concepts and solutions, including enabling systems throughout thelife cycle.

3) The preparation and baselining of stakeholder requirements and preliminary systems requirements(technical specifications for the selected system concept and usability specifications for theenvisaged human-system interactions).

4) Refinement of the objectives for stages of the System Life Cycle Model.

5) Identification and initial specification of the infrastructure of enabling systems needed throughout thelife of the system.

6) Decision criteria for exiting the next stage.

7) Transition to Development or the next stage in the system life cycle model.

7.2.2 Development Stage

The Development Stage begins with sufficiently detailed technical refinement of the preliminary systemrequirements and the design solution from the Concept Stage and transforms these into one or more viableproducts that enable a service during the Utilization Stage. This stage is the period when the system’shardware, computers, software, personnel, production capability, training, support and facilities aredetermined, analyzed, designed, fabricated, integrated, tested and evaluated. This stage also ensures thatthe aspects of future stages (production, utilization, support, and retirement) are considered and incorporatedinto the design through the involvement of all interested parties . Feedback from stakeholders and thosewho will produce, operate, use, support, and dispose should be solicited. Outputs are a system, or aprototype of the final system, together with the data package and qualification results.

It is presumed that the organization has available, or can establish, the development infrastructure whichconsists of methods, techniques, tools and competent human resources to undertake analysis, modelling andsimulation, prototyping, design, integration, test and documentation. These items are to be developed oracquired during earlier stages in order to be available when needed to support development.


36

7.2.2.1 Development Stage Purpose

To develop the system that closely resembles the Production item and that is producible, operable, supportable, and disposable.

7.2.2.2 Development Stage Outcomes

The objectives in the Development Stage are listed below:

1) Evaluation, refinement, and baseline the system requirements

2) A system architecture comprised of subsystems, hardware components, software components andhumans and their interfaces (internal and external).

3) Confirmation that the system is producible, operable, supportable and capable of retirement andcomplies with applicable health, safety, security and environmental guidelines and regulations.

4) Refined, and baselined requirements for the enabling systems

4) Technical data package, including as appropriate: 1) hardware diagrams, drawing, models, andsimulations; 2) software design documentation; 3) production plans 4)operational and trainingmanuals; and 5) maintenance procedures.

5) Refined objectives for the Production, Utilization, Support, and Retirement stages.

6) Commencement of the development of enabling infrastructure required to execute the next stage inthe life cycle model.


8) Transition to Production or the next stage in the system life cycle model.

7.2.3 Production Stage

The Production Stage begins with the approval to produce the system product for the acquirer or for themarket. The system may be individually produced, assembled, integrated, and tested, as appropriate, or maybe mass produced. Planning for this stage should have begun at the Concept Stage and continuedthroughout the Development Stage. Production may continue throughout the remainder of the system’s lifecycle. During this stage, the product may undergo enhancements or redesigns, and the production toolingand equipment may need to be reconfigured and production staff re-trained in order to continue producing anevolving system.

It is presumed that the organization has available the production infrastructure, consisting of productionequipment, tools, procedures and competent human resource . These items are developed or acquired duringearlier stages in order to be available when needed to enable Production.

This stage may overlap with the Development Stage and with the Utilization and Support Stages.

7.2.3.1 Production Stage Purpose

To produce or manufacture the system products, to produce related supporting and enabling system products as needed, and tostore, deliver, and install these products for the acquirer or the market.

7.2.3.2 Production Stage Outcomes

The objectives in the Production Stage are listed below:

1) Qualification of the production capability.

2) Acquisition of resources, material and components to support the target production quantity goals.


37

3) The system product produced according to approved and qualified production data packages.

4) Packaged product transfer to distribution channels or customers. This may involve installing theproduct in its operational environment, and performing system checkout to ensure that it is capableof providing an operational service.


6) Transition to Utilization or the next stage in the system life cycle model.

7.2.4 Utilization Stage

The Utilization Stage begins with the installation and use of the system products and services resulting fromDevelopment and Production Stages. These items are installed and used at the intended operational sites.Planning for this stage should begin in the Concept Stage and continued through the Development andProduction Stages. This stage ends with the end-of-life retirement of the system, its products or services.

This stage includes those processes related to use of the system products to provide services, as well asmonitoring performance and identifying, classifying and reporting of anomalies, deficiencies, and failures.The response to identified problems includes taking no action; maintenance and minor (low cost/temporary)modification (reference Support Stage); major (permanent) modification and system life extensions (referenceDevelopment and Production Stages), and end-of-life retirement (reference Retirement Stage).

During this stage the system, products or services can evolve giving rise to different configurations. Theuser operates the different configurations and the responsible product supplier manages the status anddescriptions of the various versions and configurations of the system products or services in use.

It is presumed that the organization has available the operational infrastructure which includes facilities,equipment, trained personnel, and instruction manuals and procedures. These items are to be developed oracquired during earlier stages in order to be available when needed to support utilization.

7.2.4.1 Utilization Stage Purpose.

To operate and use the system products and services for intended use within intended environments andensure continued operational effectiveness.

7.2.4.2 Utilization Stage Outcomes.

The objectives in the Utilization Stage are listed below:

1) Trained personnel with the competence to operate or use the system and provide operational services.

2) Organizational interfaces with support and maintenance organizations.

3) A system that is capable of being operated and providing sustainable operational services.

4) System performance monitoring and assessment to ensure conformance to system service objectives.

5) Identification of problems or deficiencies, informing appropriate organization (development,production, or support) of the need for corrective action.


7) Transition to Retirement or the next stage in the system life cycle model.


38

7.2.5 Support Stage

The Support Stage begins with providing maintenance, logistics and other support for the system operationsand use. However, planning for this stage begins with the Concept Stage and continues throughoutDevelopment and Production Stages. This stage is completed with the disposition of the operational systemproducts, decommissioning of support system products, and termination of support services.

This stage includes those processes related to operating the support system and providing support servicesto users of the operational system products and services. This stage also includes monitoring performanceof the support system and services and the identification, classification, and reporting of anomalies,deficiencies, and failures of the support system and services. Actions to be taken as a result of identifiedproblems include maintenance and minor modification of the support system and services, major modificationof the support system or services (reference Development and Production Stages), and end of life dispositionof the support system and services (reference Retirement Stage).

During this stage the support system and services can evolve under different versions or configurations. Thesupport organization operates the different versions or configurations and the responsible product agencymanages the status and descriptions of the various versions and configurations of the support system andservices in use.

It is presumed that the organization has available the support which includes the support sites, facilities,equipment and tools, trained support personnel; and maintenance manuals and procedures. The itemsmaking up the support infrastructure are developed and acquired during earlier system life cycle stages inorder to be ready when needed to support the system.

7.2.5.1 Support Stage Purpose.

To provide logistics, maintenance, and support services which enable continued system operation and asustainable service.

7.2.5.2 Support Stage Objectives.

The objectives in the Support Stage are listed below:

1) Trained personnel who will maintain and provide other support services.

2) Organizational interfaces with the operating and production organizations that ensure problemresolution and corrective actions.

3) Maintained system product and services and the provision of all related support services, includinglogistics, to the operational sites.

4) Provide product and service maintenance and correct design deficiencies.

5) A spare parts inventory sufficient to satisfy operational availability goals.


7) Transition to Retirement or the next stage in the system life cycle model.

7.2.6 Retirement Stage

The Retirement Stage covers withdrawal from service, decommissioning, archiving, disposal and otherrelated functions. This stage begins when a system item is taken out of service. The stage continuesthroughout the active use of the system items within each stage of the life cycle. This stage is completedwith the end of life of the operational system products and, as appropriate, the termination of relatedservices and decommissioning of development, production, operations and support system products.


39

This stage includes those processes related to operating the retirement system and also includes monitoringperformance of the retirement system and the identification, classification, and reporting of anomalies,deficiencies, and failures of the retirement system. Actions to be taken as a result of identified problemsinclude maintenance and minor modification of the retirement system (reference Support Stage), majormodification of the retirement system (reference Development and Production Stages), and end of lifedisposition of the retirement system (reference Retirement Stage).

It is presumed that the organization has available the infrastructure to support retirement, includingretirement facilities, tools and equipment, personnel trained in retirement actions, retirement procedures and,as appropriate, access to recycling, disposal or containment facilities. The items making up the retirementinfrastructure are developed and acquired during earlier system life cycle stages to be ready when needed toperform retirement functions.

This stage is applicable whenever an operational or enabling system product reaches its end of service life.Such end of service life can take the form of replacement by a new system, irreparable wear, catastrophicfailure, no longer useful to the user or operator, or it is not cost effective to continue operating andsupporting the system.

7.2.6.1 Retirement Stage Purpose.

To provide for the removal of a system (or a system item or a by-product) and related operational andsupport services and to operate and support the retirement system itself.

7.2.6.2 Retirement Stage Outcomes.

The objectives in the Retirement Stage are listed below:

1) Trained personnel who will provide retirement services.

2) Required system decommissioning, including disposal, refurbishing, or recycling, in accordance withapplicable laws and regulations.

3) Removal of waste

4) Disposal actions conducted in a manner that complies with applicable health, safety andenvironmental guidelines and regulations,

5) Environment returned to original or agreed state.


40

Annex A(normative)

Tailoring Process

This Annex provides requirements for the tailoring of this International Standard.

This International Standard may be tailored to provide for particular circumstances or factors that:

1) surrounding an organization employing this International Standard in an agreement

2) influencing a project that is required to meet an agreement in which this International Standard is referenced

A.0.1 Identifying Life Cycle Influences

The circumstances that influence tailoring shall be identified. Inputs from all parties affected by tailoring decisions should besolicited. This should include interested parties in organizations’ establishing an agreement, the contributing organizationalfunctions and the system stakeholders.

These influences include, but are not limited to:

1) stability of, and variety in, operational environments

2) risk to the concerns of interested parties

3) system novelty, size and complexity

4) commencement date and duration of utilization

5) criticality of use such as safety, security, usability, availability

6) emerging technology opportunities

7) profile of budget and organization resources available

8) availability of services of enabling systems.

In the case of system critical properties, due account shall be taken of the life cycles structures recommended or mandated bystandards relevant to the dimension of the criticality.

A.0.2 Life Cycle Tailoring

Tailoring this International Standard involves selective application of clauses to establish the desired system life-cycle model.This involves :

a. Establishing and tailoring the outcomes of the Life Cycle Stages, and

b. Tailoring the Processes to be applied within a Life Cycle stage

A.0.2.1 Defining Life Cycle Stages

The example of life cycle stage in the International Standard may be selected to define the identity, purposes, and outcomes ofthe life cycle stages; alternatively, it may be selected and individual Stages may be modified. New Stages should be defined byan identity, purpose and outcomes. The Stages should be assessed as to their contribution to a complete and consistent lifecycle. A life cycle model shall be identified in terms of Stages, their identities, their purposes and the outcomes they accomplishas a result of the application of the life cycle processes within each Stage.

A.0.2.2 Tailoring the Life Cycle Processes

The life cycle processes which require tailoring in order to satisfying the Life Cycle Stage outcomes shall be selected.Additional Life Cycle Processes shall be defined as necessary. The outcomes for tailored Life Cycle Process shall be modified,as necessary, and additional outcomes, as necessary, identified. The activities necessary to accomplish the objectives of eachtailored process should be selected, modified and additional activities identified, as necessary.


41

A.0.3 Tailoring Documentation

Tailoring decisions should be made in accordance with the Decision Management Process and shall be documented.


42

Annex B(informative)

Relationship between ISO/IEC 15288 and ISO/IEC 12207 : 1995

Subsystem Development

Component Development

Stakeholder Needs Definition

Requirements Analysis

Architectural Design Integration

Verification

Transition

Validation

Hardware Development

Software Development

Human-Centred

Quality Management

Configuration Control

Risk Management

Decision Management

Planning Assessement Control

Acquisition

Supply

Management

Investment

System Life Cycle Management

Infrastructure

Figure B.1 — Relationship between ISO/IEC 15288 and ISO/IEC 12207

Figure B.1 illustrates key processes in ISO/IEC 15288 that are found in ISO/IEC 12207. The emphasis and detail differs, but thesystem principles are applied similarly and their description, in terms of processes used to build life cycle models, are alsosimilar. The processes with heavy borders are treated with greater emphasis in ISO/IEC 15288 ; the process with the dottedborder are treated with greater emphasis in ISO/IEC 12207. The other processes have similar levels of treatment in bothInternational Standards.