BS ISO-IEC-IEEE 15288-2015 PDF
Document Details
Uploaded by GentleJadeite2110
2015
Tags
Summary
This document is a British Standard for the Systems and software engineering — System life cycle processes from 2015. It covers the key concepts, norms and references for the international standards.
Full Transcript
BS ISO/IEC/IEEE 15288:2015 BSI Standards Publication Systems and software engineering — System life cycle processes BS ISO/IEC/IEEE 15288:2015 BRITISH STANDARD National foreword...
BS ISO/IEC/IEEE 15288:2015 BSI Standards Publication Systems and software engineering — System life cycle processes BS ISO/IEC/IEEE 15288:2015 BRITISH STANDARD National foreword This British Standard is the UK implementation of ISO/IEC/IEEE 15288:2015. It supersedes BS ISO/IEC 15288:2002 which is withdrawn. The UK participation in its preparation was entrusted to Technical Committee IST/15, Software and systems engineering. A list of organizations represented on this committee can be obtained on request to its secretary. This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. © The British Standards Institution 2015. Published by BSI Standards Limited 2015 ISBN 978 0 580 89613 2 ICS 35.080 Compliance with a British Standard cannot confer immunity from legal obligations. This British Standard was published under the authority of the Standards Policy and Strategy Committee on 30 June 2015. Amendments issued since publication Date Text affected BS ISO/IEC/IEEE 15288:2015 INTERNATIONAL ISO/IEC/ STANDARD IEEE 15288 First edition 2015-05-15 Systems and software engineering — System life cycle processes Ingénierie des systèmes et du logiciel — Processus du cycle de vie du système Reference number ISO/IEC/IEEE 15288:2015(E) © ISO/IEC 2015 © IEEE 2015 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat, the IEC Central Office and IEEE do not accept any liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies and IEEE members. In the unlikely event that a problem relating to it is found, please inform the ISO Central Secretariat or IEEE at the address given below. COPYRIGHT PROTECTED DOCUMENT © ISO/IEC 2015 © IEEE 2015 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from ISO, IEC or IEEE at the respective address below. ISO copyright office IEC Central Office Institute of Electrical and Electronics Engineers, Inc. Case postale 56 3, rue de Varembé 3 Park Avenue, New York CH-1211 Geneva 20 CH-1211 Geneva 20 NY 10016-5997, USA Tel. + 41 22 749 01 11 Switzerland E-mail [email protected] Fax + 41 22 749 09 47 E-mail [email protected] Web www.ieee.org E-mail [email protected] Web www.iec.ch Web www.iso.org Published in Switzerland © ISO/IEC 2015 – All rights reserved ii © IEEE 2015 – All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Contents Page Introduction....................................................................................................................................................... vii 1 Overview................................................................................................................................................. 1 1.1 Scope...................................................................................................................................................... 1 1.2 Purpose.................................................................................................................................................. 1 1.3 Field of application................................................................................................................................ 1 1.4 Limitations............................................................................................................................................. 2 2 Conformance......................................................................................................................................... 2 2.1 Intended usage...................................................................................................................................... 2 2.2 Full conformance................................................................................................................................... 3 2.2.1 Full conformance to outcomes............................................................................................................ 3 2.2.2 Full conformance to tasks.................................................................................................................... 3 2.3 Tailored conformance........................................................................................................................... 3 3 Normative references............................................................................................................................ 3 4 Terms, definitions, and abbreviated terms......................................................................................... 3 4.1 Terms and definitions........................................................................................................................... 3 4.2 Abbreviated terms............................................................................................................................... 10 5 Key concepts and application of this International Standard........................................................ 11 5.1 Introduction.......................................................................................................................................... 11 5.2 System concepts................................................................................................................................. 11 5.2.1 Systems................................................................................................................................................ 11 5.2.2 System structure................................................................................................................................. 11 5.2.3 Enabling systems................................................................................................................................ 12 5.3 Organization and project concepts................................................................................................... 13 5.3.1 Organizations....................................................................................................................................... 13 5.3.2 Organization and project-level adoption........................................................................................... 14 5.4 Life cycle concepts............................................................................................................................. 14 5.4.1 System life cycle model...................................................................................................................... 14 5.4.2 System life cycle stages..................................................................................................................... 14 5.5 Process concepts................................................................................................................................ 15 5.5.1 Criteria for processes......................................................................................................................... 15 5.5.2 Description of processes................................................................................................................... 15 5.5.3 General characteristics of processes............................................................................................... 15 5.5.4 Tailoring............................................................................................................................................... 15 5.6 Processes in this standard................................................................................................................. 15 5.6.1 Introduction.......................................................................................................................................... 15 5.6.2 Agreement processes......................................................................................................................... 17 5.6.3 Organizational project-enabling processes..................................................................................... 17 5.6.4 Technical management processes.................................................................................................... 17 5.6.5 Technical processes........................................................................................................................... 17 5.7 Process application............................................................................................................................. 18 5.8 Process reference model.................................................................................................................... 19 6 System life cycle processes............................................................................................................... 19 6.1 Agreement processes......................................................................................................................... 19 6.1.1 Acquisition process............................................................................................................................ 19 6.1.2 Supply process.................................................................................................................................... 21 6.2 Organizational project-enabling processes..................................................................................... 23 6.2.1 Life cycle model management process............................................................................................ 23 6.2.2 Infrastructure management process................................................................................................. 25 6.2.3 Portfolio management process.......................................................................................................... 26 6.2.4 Human resource management process............................................................................................ 27 6.2.5 Quality management process............................................................................................................ 28 6.2.6 Knowledge management process..................................................................................................... 30 6.3 Technical management processes.................................................................................................... 31 © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved iii BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 6.3.1 Project planning process....................................................................................................................32 6.3.2 Project assessment and control process.........................................................................................34 6.3.3 Decision management process..........................................................................................................36 6.3.4 Risk management process.................................................................................................................38 6.3.5 Configuration management process.................................................................................................39 6.3.6 Information management process.....................................................................................................42 6.3.7 Measurement process.........................................................................................................................44 6.3.8 Quality assurance process.................................................................................................................45 6.4 Technical processes...........................................................................................................................47 6.4.1 Business or mission analysis process.............................................................................................48 6.4.2 Stakeholder needs and requirements definition process...............................................................51 6.4.3 System requirements definition process..........................................................................................54 6.4.4 Architecture definition process..........................................................................................................57 6.4.5 Design definition process...................................................................................................................61 6.4.6 System analysis process....................................................................................................................64 6.4.7 Implementation process.....................................................................................................................65 6.4.8 Integration process..............................................................................................................................68 6.4.9 Verification process............................................................................................................................70 6.4.10 Transition process...............................................................................................................................72 6.4.11 Validation process...............................................................................................................................74 6.4.12 Operation process...............................................................................................................................77 6.4.13 Maintenance process..........................................................................................................................80 6.4.14 Disposal process.................................................................................................................................83 Annex A (normative) Tailoring Process...........................................................................................................86 A.1 Introduction..........................................................................................................................................86 A.2 Tailoring process.................................................................................................................................86 A.2.1 Purpose.................................................................................................................................................86 A.2.2 Outcomes.............................................................................................................................................86 A.2.3 Activities and tasks.............................................................................................................................86 Annex B (informative) Example process information items..........................................................................88 B.1 Introduction..........................................................................................................................................88 Annex C (informative) Process reference model for assessment purposes...............................................90 C.1 Introduction..........................................................................................................................................90 C.2 Conformance with ISO/IEC 15504-2...................................................................................................90 C.2.1 General..................................................................................................................................................90 C.2.2 Requirements for process reference models...................................................................................90 C.2.3 Process descriptions..........................................................................................................................91 C.3 The process reference model.............................................................................................................91 Annex D (informative) Process integration and process constructs............................................................92 D.1 Introduction..........................................................................................................................................92 D.2 Process constructs and their usage..................................................................................................92 Annex E (informative) Process views...............................................................................................................94 E.1 Introduction..........................................................................................................................................94 E.2 The process view concept..................................................................................................................94 E.3 Process viewpoint...............................................................................................................................94 E.4 Process view for specialty engineering............................................................................................95 E.5 Process view for interface management...........................................................................................97 Annex F (Informative) Architecture modeling............................................................................................ 100 F.1 Introduction....................................................................................................................................... 100 F.2 Viewpoints, views and model kinds used in architecture............................................................ 100 F.3 Logical and physical models........................................................................................................... 100 F.3.1 Functional model.............................................................................................................................. 100 F.3.2 Behavioural model............................................................................................................................ 100 F.3.3 Temporal model................................................................................................................................ 101 F.3.4 Structural model............................................................................................................................... 101 F.3.5 Mass model....................................................................................................................................... 101 F.3.6 Layout model..................................................................................................................................... 101 F.3.7 Network model.................................................................................................................................. 101 F.3.8 Other model considerations............................................................................................................ 101 Annex G (Informative) Application of system life cycle processes to a system of systems................ 102 iv © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) G.1 Introduction........................................................................................................................................ 102 G.2 SoS characteristics and types......................................................................................................... 102 G.3 SE processes applied to systems of systems............................................................................... 103 G.3.1 General............................................................................................................................................... 103 G.3.2 Agreement processes....................................................................................................................... 103 G.3.3 Organizational project enabling processes.................................................................................... 103 G.3.4 Technical management processes.................................................................................................. 104 G.3.5 Technical processes......................................................................................................................... 104 Bibliography.................................................................................................................................................... 106 © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved v BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus development process, approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information contained in its standards. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of ISO/IEC JTC 1 is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is called to the possibility that implementation of this standard may require the use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. ISO/IEEE is not responsible for identifying essential patents or patent claims for which a license may be required, for conducting inquiries into the legal validity or scope of patents or patent claims or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance or a Patent Statement and Licensing Declaration Form, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from ISO or the IEEE Standards Association. ISO/IEC/IEEE 15288 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems engineering, in cooperation with the IEEE Computer Society Systems and Software Engineering Standards Committee, under the Partner Standards Development Organization cooperation agreement between ISO and IEEE. This first edition of ISO/IEC/IEEE 15288 cancels and replaces the ISO/IEC 15288:2008 (second edition), which has been technically revised. Changes in this revision of ISO/IEC/IEEE 15288 were developed in conjunction with a corresponding revision of ISO/IEC/IEEE 12207, Systems and software engineering – Software life cycle processes. The purpose of these revisions is to accomplish the harmonization of the structures and contents of the two International Standards, while supporting the requirements of the assessment community. This International Standard was developed with the following goals: provide a common terminology between the revision of the ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, where applicable, provide common process names and process structure between the revision of the ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, enable the user community to evolve towards fully harmonized standards, while maximizing backward compatibility. This revision is intended to achieve a fully harmonized view of the system and software life cycle processes. vi © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Introduction The complexity of man-made systems has increased to an unprecedented level. This has led to new opportunities, but also to increased challenges for the organizations that create and utilize systems. These challenges exist throughout the life cycle of a system and at all levels of architectural detail. This International Standard provides a common process framework for describing the life cycle of systems created by humans, adopting a Systems Engineering approach. Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining stakeholder needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem. It integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. It considers both the business and the technical needs of all stakeholders with the goal of providing a quality product that meets the needs of users and other applicable stakeholders. This life cycle spans the conception of ideas through to the retirement of a system. It provides the processes for acquiring and supplying systems. It helps to improve communication and cooperation among the parties that create, utilize and manage modern systems in order that they can work in an integrated, coherent fashion. In addition, this framework provides for the assessment and improvement of the life cycle processes. The processes in this International Standard form a comprehensive set from which an organization can construct system life cycle models appropriate to its products and services. An organization, depending on its purpose, can select and apply an appropriate subset to fulfill that purpose. This International Standard can be used in one or more of the following modes: By an organization — to help establish an environment of desired processes. These processes can be supported by an infrastructure of methods, procedures, techniques, tools and trained personnel. The organization may then employ this environment to perform and manage its projects and progress systems through their life cycle stages. In this mode this International Standard is used to assess conformance of a declared, established environment to its provisions. By a project — to help select, structure and employ the elements of an established environment to provide products and services. In this mode this International Standard is used in the assessment of conformance of the project to the declared and established environment. By an acquirer and a supplier — to help develop an agreement concerning processes and activities. Via the agreement, the processes and activities in this International Standard are selected, negotiated, agreed to and performed. In this mode this International Standard is used for guidance in developing the agreement. By process assessors — to serve as a process reference model for use in the performance of process assessments that may be used to support organizational process improvement. © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved vii BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) IEEE Introduction This introduction is not part of IEEE Std 15288™-2015, Systems and Software Engineering — Systems Life Cycle Processes. This standard replaces ISO/IEC/IEEE Std 15288™-2008, Systems and software engineering—System life cycle processes. That standard replaced IEEE Std 15288™-2004, Adoption of ISO/IEC 15288:2002, Systems and software engineering—System life cycle processes. The original ISO/IEC 15288 was published in November 2002 and was the first international standard to provide a comprehensive set of life cycle processes for systems. This new revision of ISO/IEC/IEEE 15288 is the product of a coordinated effort by IEEE and ISO/IEC JTC 1/SC 7. The base document for the revision is the ISO/IEC/IEEE standard. Development of this revision was carefully coordinated with the parallel revision of ISO/IEC/IEEE 12207:2015 to align structure, terms, and corresponding organizational and project processes. This revised standard is a step in the SC7 harmonization strategy to achieve a fully integrated suite of system and software life cycle processes and guidance for their application. It is also an important step in the shared strategy of ISO/IEC JTC 1/SC 7 and the IEEE to harmonize their respective collections of standards. Notice to users Errata Errata, if any, for this and all other standards can be accessed at the following URL: http:// standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for errata periodically. Interpretations Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/ index.html. viii © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Systems and software engineering — System life cycle processes 1 Overview 1.1 Scope This International Standard establishes a common framework of process descriptions for describing the life cycle of systems created by humans. It defines a set of processes and associated terminology from an engineering viewpoint. These processes can be applied at any level in the hierarchy of a system’s structure. Selected sets of these processes can be applied throughout the life cycle for managing and performing the stages of a system's life cycle. This is accomplished through the involvement of all stakeholders, with the ultimate goal of achieving customer satisfaction. This International Standard also provides processes that support the definition, control and improvement of the system life cycle processes used within an organization or a project. Organizations and projects can use these processes when acquiring and supplying systems. This International Standard concerns those systems that are man-made and may be configured with one or more of the following system elements: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials and naturally occurring entities. When a system element is software, the software life cycle processes in ISO/IEC/IEEE 12207:2015 may be used to implement that system element. The two standards are harmonized for concurrent use on a single project or in a single organization. 1.2 Purpose The purpose of this International Standard is to provide a defined set of processes to facilitate communication among acquirers, suppliers and other stakeholders in the life cycle of a system. This International Standard applies to organizations in their roles as both acquirers and suppliers. It can be used by a single organization in a self-imposed mode or in a multi-party situation. Parties can be from the same organization or from different organizations and the situation can range from an informal agreement to a formal contract. The processes in this International Standard can be used as a basis for establishing business environments, e.g., methods, procedures, techniques, tools and trained personnel. Annex A provides normative direction regarding the tailoring of these system life cycle processes. 1.3 Field of application This International Standard applies to the full life cycle of systems, including conception, development, production, utilization, support and retirement of systems, and to the acquisition and supply of systems, whether performed internally or externally to an organization. The life cycle processes of this International Standard can be applied concurrently, iteratively and recursively to a system and incrementally to its elements. There is a wide variety of systems in terms of their purpose, domain of application, complexity, size, novelty, adaptability, quantities, locations, life spans and evolution. This International Standard describes the processes that comprise the life cycle of man-made systems. It therefore applies to one-of-a-kind systems, mass-produced systems and customized, adaptable systems. It also applies to a complete stand-alone system and to systems that are embedded and integrated into larger more complex and complete systems. This International Standard provides a process reference model characterized in terms of the process purpose and the process outcomes that result from the successful execution of the activity tasks. Annex B lists examples of artifacts and information items that may be associated with various processes. This International Standard can therefore be used as a reference model to support process assessment as specified in ISO/IEC © ISO/IEC 2015 All rights reserved 1 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 15504-2:2003. Annex C provides information regarding the use of the system life cycle processes as a process reference model. Annex D describes the process constructs for use in the process reference model. 1.4 Limitations This International Standard does not prescribe a specific system life cycle model, development methodology, method, model or technique. The users of this International Standard are responsible for selecting a life cycle model for the project and mapping the processes, activities, and tasks in this International Standard into that model. The parties are also responsible for selecting and applying appropriate methodologies, methods, models and techniques suitable for the project. Although this International Standard does not establish a management system, it is intended to be compatible with the quality management system provided by ISO 9001, the service management system provided by ISO/IEC 20000-1:2011 (IEEE Std 20000-1-2013), and the information security management system provided by ISO/IEC 27000. This International Standard does not detail information items in terms of name, format, explicit content and recording media. ISO/IEC/IEEE 15289 addresses the content for life cycle process information items (documentation). 2 Conformance 2.1 Intended usage The requirements in this International Standard are contained in Clause 6 and Annex A. This International Standard provides requirements for a number of processes suitable for usage during the life cycle of a system or product. It is recognized that particular projects or organizations may not need to use all of the processes provided by this International Standard. Therefore, implementation of this International Standard typically involves selecting and declaring a set of processes suitable to the organization or project. There are two ways that an implementation can be claimed to conform to the provisions of this International Standard – full conformance and tailored conformance. There are two criteria for claiming full conformance. Achieving either criterion suffices for conformance, although the chosen criterion (or criteria) is to be stated in the claim. Claiming “full conformance to tasks” asserts that all of the requirements of the activities and tasks of the declared set of processes are achieved. Alternatively, claiming “full conformance to outcomes” asserts that all of the required outcomes of the declared set of processes are achieved. Full conformance to outcomes permits greater freedom in the implementation of conforming processes and may be useful for implementing processes to be used in the context of an innovative life cycle model. NOTE 1 Options for conformance are provided for needed flexibility in the application of this International Standard. Each process has a set of objectives (phrased as “outcomes”) and a set of activities and tasks that represent one way to achieve the objectives. NOTE 2 Users who implement the activities and tasks of the declared set of processes can assert full conformance to tasks of the selected processes. Some users, however, might have innovative process variants that achieve the objectives (i.e., the outcomes) of the declared set of processes without implementing all of the activities and tasks. These users can assert full conformance to the outcomes of the declared set of processes. The two criteria—conformance to task and conformance to outcome—are necessarily not equivalent since specific performance of activities and tasks may require, in some cases, a higher level of capability than just the achievement of outcomes. NOTE 3 When this International Standard is used to help develop an agreement between an acquirer and a supplier, clauses of this International Standard can be selected for incorporation in the agreement with or without modification. In this case, it is more appropriate for the acquirer and supplier to claim compliance with the agreement than conformance with this International Standard. NOTE 4 An organization (for example, national, industrial association, company) imposing this International Standard as a condition of trade can specify and make public the minimum set of required processes, outcomes, activities, and tasks, which constitute suppliers' compliance with the conditions of trade. NOTE 5 Requirements of this International Standard are marked by the use of the verb "shall". Recommendations are marked by the use of the verb "should". Permissions are marked by the use of the verb "may". However, despite the verb that is used, the requirements for conformance are selected as described previously. © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 2 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 2.2 Full conformance 2.2.1 Full conformance to outcomes A claim of full conformance declares the set of processes for which conformance is claimed. Full conformance to outcomes is achieved by demonstrating that all of the outcomes of the declared set of processes have been achieved. In this situation, the provisions for activities and tasks of the declared set of processes are guidance rather than requirements, regardless of the verb form that is used in the provision. NOTE One intended use of this International Standard is to facilitate process assessment and improvement. For this purpose, the objectives of each process are written in the form of 'outcomes' compatible with the provisions of ISO/IEC 15504-2 and ISO/IEC 33002. Those standards provide for the assessment of the processes of this International Standard, providing a basis for improvement. Users intending process assessment and improvement may use the process outcomes written in this International Standard as the "process reference model" required by ISO/IEC 15504-2 and ISO/IEC 33002. 2.2.2 Full conformance to tasks A claim of full conformance declares the set of processes for which conformance is claimed. Full conformance to tasks is achieved by demonstrating that all of the requirements of the activities and tasks of the declared set of processes have been achieved. In this situation, the provisions for the outcomes of the declared set of processes are guidance rather than requirements, regardless of the verb form that is used in the provision. NOTE A claim of full conformance to tasks may be appropriate in contractual situations where an acquirer or a regulator requires detailed understanding of the suppliers‘ processes. 2.3 Tailored conformance When this International Standard is used as a basis for establishing a set of processes that do not qualify for full conformance, the clauses of this International Standard are selected or modified in accordance with the tailoring process prescribed in Annex A. The tailored text, for which tailored conformance is claimed, is declared. Tailored conformance is achieved by demonstrating that the outcomes, activities, and tasks, as tailored, have been achieved. 3 Normative references None. 4 Terms, definitions, and abbreviated terms 4.1 Terms and definitions For the purposes of this document, the following terms and definitions apply. NOTE Definitions for other terms typically can be found in ISO/IEC/IEEE 24765, available at. 4.1.1 acquirer stakeholder that acquires or procures a product or service from a supplier Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser or internal/organizational sponsor. 4.1.2 acquisition process of obtaining a system, product or service © ISO/IEC 2015 All rights reserved 3 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 4.1.3 activity set of cohesive tasks of a process 4.1.4 agreement mutual acknowledgement of terms and conditions under which a working relationship is conducted EXAMPLE Contract, memorandum of agreement. 4.1.5 architecture fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [SOURCE: ISO/IEC/IEEE 42010:2011] 4.1.6 architecture framework conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders EXAMPLE 1 Generalized Enterprise Reference Architecture and Methodologies (GERAM) [ISO 15704] is an architecture framework. EXAMPLE 2 Reference Model of Open Distributed Processing (RM-ODP) [ISO/IEC 10746] is an architecture framework. [SOURCE: ISO/IEC/IEEE 42010:2011] 4.1.7 architecture view work product expressing the architecture of a system from the perspective of specific system concerns [SOURCE: ISO/IEC/IEEE 42010:2011] 4.1.8 architecture viewpoint work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns [SOURCE: ISO/IEC/IEEE 42010:2011] 4.1.9 audit independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria [SOURCE: ISO 24765:2010] 4.1.10 baseline formally approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item's life cycle [SOURCE: IEEE Std 828-2012] 4.1.11 concept of operations verbal and/or graphic statement, in broad outline, of an organization’s assumptions or intent in regard to an operation or series of operations © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 4 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Note 1 to entry: The concept of operations frequently is embodied in long-range strategic plans and annual operational plans. In the latter case, the concept of operations in the plan covers a series of connected operations to be carried out simultaneously or in succession. The concept is designed to give an overall picture of the organization operations. See also operational concept. Note 2 to entry: It provides the basis for bounding the operating space, system capabilities, interfaces and operating environment. [SOURCE: ANSI/AIAA G-043A-2012e] 4.1.12 concern interest in a system relevant to one or more of its stakeholders Note 1 to entry: A concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences. [SOURCE: ISO/IEC/IEEE 42010:2011] 4.1.13 configuration item item or aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process [SOURCE: ISO/IEC/IEEE 24765:2010, modified to include “item”] 4.1.14 customer organization or person that receives a product or service EXAMPLE Consumer, client, user, acquirer, buyer, or purchaser. Note 1 to entry: A customer can be internal or external to the organization. [SOURCE: ISO 9000:2005, modified – added ‘service’] 4.1.15 design, verb to define the architecture, system elements, interfaces, and other characteristics of a system or system element [SOURCE: ISO/IEC/IEEE 24765:2010, modified – changed 'components' to 'system elements] 4.1.16 design, noun result of the process in 4.1.15 Note 1 to entry: Information, including specification of system elements and their relationships, that is sufficiently complete to support a compliant implementation of the architecture. Note 2 to entry: Design provides the detailed implementation-level physical structure, behavior, temporal relationships, and other attributes of system elements. [SOURCE: ISO/IEC/IEEE 24765:2010] 4.1.17 design characteristic design attributes or distinguishing features that pertain to a measurable description of a product or service [SOURCE: ISO/IEC/IEEE 24765:2010] © ISO/IEC 2015 All rights reserved 5 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 4.1.18 enabling system system that supports a system-of-interest during its life cycle stages but does not necessarily contribute directly to its function during operation EXAMPLE When a system-of-interest enters the production stage, a production-enabling system is required. Note 1 to entry: Each enabling system has a life cycle of its own. This International Standard is applicable to each enabling system when, in its own right, it is treated as a system-of-interest. 4.1.19 environment context determining the setting and circumstances of all influences upon a system [ISO/IEC/IEEE 42010:2011] 4.1.20 facility physical means or equipment for facilitating the performance of an action, e.g., buildings, instruments, tools 4.1.21 incident anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of a project, product, service, or system 4.1.22 information item separately identifiable body of information that is produced, stored, and delivered for human use [SOURCE: ISO/IEC/IEEE 15289:2011] 4.1.23 life cycle evolution of a system, product, service, project or other human-made entity from conception through retirement 4.1.24 life cycle model framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding 4.1.25 operational concept verbal and graphic statement of an organization’s assumptions or intent in regard to an operation or series of operations of a system or a related set of systems Note 1 to entry: The operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization’s operational environment from the users’ and operators’ perspective. See also concept of operations. [SOURCE: ANSI/AIAA G-043A-2012e] 4.1.26 operator individual or organization that performs the operations of a system Note 1 to entry: The role of operator and the role of user can be vested, simultaneously or sequentially, in the same individual or organization. Note 2 to entry: An individual operator combined with knowledge, skills and procedures can be considered as an element of the system. © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 6 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Note 3 to entry: An operator may perform operations on a system that is operated, or of a system that is operated, depending on whether or not operating instructions are placed within the system boundary. 4.1.27 organization group of people and facilities with an arrangement of responsibilities, authorities and relationships EXAMPLE Company, corporation, firm, enterprise, institution, charity, sole trader, association, or parts or combination thereof. Note 1 to entry: An identified part of an organization (even as small as a single individual) or an identified group of organizations can be regarded as an organization if it has responsibilities, authorities and relationships. A body of persons organized for some specific purpose, such as a club, union, corporation, or society, is an organization. [SOURCE: ISO 9000:2005, modified – Note 1 to entry has been added] 4.1.28 party organization entering into an agreement Note 1 to entry: In this International Standard, the agreeing parties are called the acquirer and the supplier. 4.1.29 problem difficulty, uncertainty, or otherwise realized and undesirable event, set of events, condition, or situation that requires investigation and corrective action 4.1.30 process set of interrelated or interacting activities that transforms inputs into outputs [SOURCE: ISO 9000:2005] 4.1.31 process purpose high level objective of performing the process and the likely outcomes of effective implementation of the process Note 1 to entry: The purpose of implementing the process is to provide benefits to the stakeholders. 4.1.32 product result of a process Note 1 to entry: There are four agreed generic product categories: hardware (e.g., engine mechanical part); software (e.g., computer program); services (e.g., transport); and processed materials (e.g., lubricant). Hardware and processed materials are generally tangible products, while software or services are generally intangible. [SOURCE: ISO 9000:2005] 4.1.33 project endeavour with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements Note 1 to entry: A project is sometimes viewed as a unique process comprising co-coordinated and controlled activities and composed of activities from the Project Processes and Technical Processes defined in this International Standard. 4.1.34 quality assurance part of quality management focused on providing confidence that quality requirements will be fulfilled [SOURCE: ISO 9000:2005] © ISO/IEC 2015 All rights reserved 7 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 4.1.35 quality characteristic inherent characteristic of a product, process, or system related to a requirement Note 1 to entry: Critical quality characteristics commonly include those related to health, safety, security, assurance, reliability, availability and supportability. [SOURCE: ISO 9000:2005, modified – Note 1 to entry added] 4.1.36 quality management coordinated activities to direct and control an organization with regard to quality [SOURCE: ISO 9000:2005] 4.1.37 requirement statement that translates or expresses a need and its associated constraints and conditions [SOURCE: ISO/IEC/IEEE 29148:2011] 4.1.38 resource asset that is utilized or consumed during the execution of a process Note 1 to entry: Includes diverse entities such as funding, personnel, facilities, capital equipment, tools, and utilities such as power, water, fuel and communication infrastructures. Note 2 to entry: Resources include those that are reusable, renewable or consumable. 4.1.39 retirement withdrawal of active support by the operation and maintenance organization, partial or total replacement by a new system, or installation of an upgraded system 4.1.40 risk effect of uncertainty on objectives Note 1 to entry: An effect is a deviation from the expected — positive or negative. A positive effect is also known as an opportunity. Note 2 to entry: Objectives can have different aspects (such as financial, health and safety, and environmental goals) and can apply at different levels (such as strategic, organization-wide, project, product and process). Note 3 to entry: Risk is often characterized by reference to potential events and consequences, or a combination of these. Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated likelihood of occurrence. Note 5 to entry: Uncertainty is the state, even partial, of deficiency of information related to understanding or knowledge of an event, its consequence, or likelihood. [SOURCE: ISO Guide 73:2009, definition 1.1] 4.1.41 security protection against intentional subversion or forced failure. A composite of four attributes – confidentiality, integrity, availability, and accountability – plus aspects of a fifth, usability, all of which have the related issue of their assurance. [SOURCE: NATO AEP-67] © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 8 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 4.1.42 service performance of activities, work, or duties Note 1 to entry: A service is self contained, coherent, discrete, and can be composed of other services. Note 2 to entry: A service is generally an intangible product. 4.1.43 stage period within the life cycle of an entity that relates to the state of its description or realization Note 1 to entry: As used in this International Standard, stages relate to major progress and achievement milestones of the entity through its life cycle. Note 2 to entry: Stages often overlap. 4.1.44 stakeholder individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations EXAMPLE End users, end user organizations, supporters, developers, producers, trainers, maintainers, disposers, acquirers, supplier organizations and regulatory bodies. Note 1 to entry: Some stakeholders can have interests that oppose each other or oppose the system. 4.1.45 supplier organization or an individual that enters into an agreement with the acquirer for the supply of a product or service Note 1 to entry: Other terms commonly used for supplier are contractor, producer, seller or vendor. Note 2 to entry: The acquirer and the supplier sometimes are part of the same organization. 4.1.46 system combination of interacting elements organized to achieve one or more stated purposes Note 1 to entry: A system is sometimes considered as a product or as the services it provides. Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g., aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym, e.g., aircraft, though this potentially obscures a system principles perspective. Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs, firmware, technical documentation, services and personnel required for operations and support to the degree necessary for self-sufficient use in its intended environment. 4.1.47 system element member of a set of elements that constitute a system EXAMPLE Hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities or any combination. Note 1 to entry: A system element is a discrete part of a system that can be implemented to fulfill specified requirements. 4.1.48 system-of-interest system whose life cycle is under consideration in the context of this International Standard © ISO/IEC 2015 All rights reserved 9 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 4.1.49 systems engineering interdisciplinary approach governing the total technical and managerial effort required to transform a set of stakeholder needs, expectations, and constraints into a solution and to support that solution throughout its life 4.1.50 task required, recommended, or permissible action, intended to contribute to the achievement of one or more outcomes of a process 4.1.51 trade-off decision-making actions that select from various requirements and alternative solutions on the basis of net benefit to the stakeholders 4.1.52 user individual or group that interacts with a system or benefits from a system during its utilization Note 1 to entry: The role of user and the role of operator are sometimes vested, simultaneously or sequentially, in the same individual or organization. [SOURCE: ISO/IEC 25010:2011] 4.1.53 validation confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled Note 1 to entry: A system is able to accomplish its intended use, goals and objectives (i.e., meet stakeholder requirements) in the intended operational environment. The right system was built. [SOURCE: ISO 9000:2005, modified – Note 1 to entry has been added] 4.1.54 verification confirmation, through the provision of objective evidence, that specified requirements have been fulfilled Note 1 to entry: Verification is a set of activities that compares a system or system element against the required characteristics. This includes, but is not limited to, specified requirements, design description and the system itself. The system was built right. [SOURCE: ISO 9000:2005, modified – Note 1 to entry has been added] 4.2 Abbreviated terms CM Configuration Management CCB Configuration Control Board COTS Commercial-Off-The-Shelf FCA Functional Configuration Audit NDI Non-developmental Items PCA Physical Configuration Audit QA Quality Assurance SDP Software Development Plan © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 10 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) SEMP Systems Engineering Management Plan SOI System of Interest SoS System of Systems 5 Key concepts and application of this International Standard 5.1 Introduction This clause is included to highlight and to help explain essential concepts on which this International Standard is based. Further elaboration of these concepts can be found in the ISO/IEC TR 24748-1 (IEEE Std 24748-1- 2011) and 24748-2 (IEEE Std 24748-2-2012) guides on the application of life cycle management. 5.2 System concepts 5.2.1 Systems The systems considered in this International Standard are man-made, created and utilized to provide products or services in defined environments for the benefit of users and other stakeholders. These systems may be configured with one or more of the following system elements: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials and naturally occurring entities. As viewed by the user, they are thought of as products or services. The perception and definition of a particular system, its architecture and its system elements depend on a stakeholder's interests and responsibilities. One stakeholder's system-of-interest can be viewed as a system element in another stakeholder's system-of-interest. Furthermore, a system-of-interest can be viewed as being part of the environment for another stakeholder's system-of-interest. The following are key points regarding the characteristics of the systems-of-interest: a) defined boundaries encapsulate meaningful needs and practical solutions; b) there is a hierarchical or other relationship between system elements; c) an entity at any level in the system-of-interest can be viewed as a system; d) a system comprises an integrated, defined set of subordinate system elements; e) humans can be viewed as both users external to a system and as system elements (i.e., operators) within a system; f) a system can be viewed in isolation as an entity, i.e., a product; or as a collection of functions capable of interacting with its surrounding environment, i.e., a set of services. Whatever the boundaries chosen to define the system, the concepts in this International Standard are generic and permit a practitioner to correlate or adapt individual instances of life cycles to its system principles. 5.2.2 System structure The system life cycle processes in this International Standard are described in relation to a system (see Figure 1) that is composed of a set of interacting system elements, each of which can be implemented to fulfill its respective specified requirements. Responsibility for the implementation of any system element may therefore be delegated to another party through an agreement. © ISO/IEC 2015 All rights reserved 11 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Figure 1 — System and system element relationship The relationship between the system and its complete set of system elements can typically be represented in a hierarchy for the simplest of systems-of-interest. For more complex systems-of-interest, a prospective system element may itself need to be considered as a system (that in turn is comprised of system elements) before a complete set of system elements can be defined with confidence (see Figure 2). In this manner, the appropriate system life cycle processes are applied recursively to a system-of-interest to resolve its structure to the point where understandable and manageable system elements can be implemented (made, bought, or reused). While Figures 1 and 2 imply a hierarchical relationship, in reality there are an increasing number of systems that, from one or more aspects, are not hierarchical, such as networks and other distributed systems. Annex G discusses the concept of a system of systems (SoS). Figure 2 — System-of-interest structure 5.2.3 Enabling systems Throughout the life cycle of a system-of-interest, essential services are required from systems that are not directly a part of the operational environment of the system-of interest, e.g., mass-production system, training system, maintenance system. Each of these systems enables a part, e.g., a stage of the life cycle of the system-of-interest to be conducted. Termed "enabling systems", they facilitate progression of the system-of- interest through its life cycle. The relationship between the services delivered to the operational environment by the system-of-interest and the services delivered by the enabling systems to the system-of-interest are shown in Figure 3. Enabling systems can be seen to contribute indirectly to the services provided by the system-of-interest. The interrelationships between the system-of-interest and the enabling systems can be bi-directional or a one-way relationship. In addition to interacting with enabling systems, the system-of-interest may also interact with other systems in the operating environment, shown as Systems A, B, and C. Requirements for interfaces with enabling systems and other systems in the operational environment will need to be included in the requirements for the system-of-interest. © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 12 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Figure 3 — System-of-interest, its operational environment and enabling systems During a stage in the system life cycle, the relevant enabling systems and the system-of-interest are considered together. Since they are interdependent, they can also be viewed as a system. When a suitable enabling system does not already exist, the project that is responsible for the system-of-interest can also be directly responsible for creating and using the enabling system. Creating the enabling systems can be viewed as a separate project and subsequently another system-of-interest. Further elaboration of these concepts can be found in the ISO/IEC/IEEE TR 24748 guides, on the application of life cycle processes. 5.3 Organization and project concepts 5.3.1 Organizations When an organization, as a whole or a part, enters into an agreement, it is sometimes called a “party” to the agreement. Parties may be from the same organization or from separate organizations. An organization may be as small as a single individual, if the individual is assigned responsibilities and authorities. In informal terms, the organization that is responsible for executing a process is sometimes referred to by the name of that process. For example, the organization executing the Acquisition process is sometimes called the “acquirer”. Other examples include supplier, implementer, maintainer, and operator. A few other terms are applied to organizations in this standard: "user" can be the organization that benefits from the utilization of the product or service; "customer" refers to the user and acquirer collectively; and "stakeholder" refers to an individual or organization with an interest in the system. The processes and organizations are only related functionally. The standard does not dictate or imply a structure for an organization, nor does it specify that particular processes are to be executed by particular parts of the organization. It is the responsibility of the organization that implements the standard to define a suitable structure for the organization and assign appropriate roles for the execution of processes. The processes in this standard form a comprehensive set to serve various organizations. An organization, small or large, depending on its business purpose or its acquisition strategy, can select an appropriate set of the processes (and associated activities and tasks) to fulfill that purpose. An organization may perform one process or more than one process. © ISO/IEC 2015 All rights reserved 13 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) This standard is intended to be applied by an organization internally or externally by two or more organizations. When applied internally, the two agreeing parties typically act under the terms of an agreement that may vary in formality under different circumstances. When applied externally, the two agreeing parties typically act under the terms of a contract. This standard uses the term “agreement” to apply to either situation. For the purpose of this standard, any project is assumed to be conducted within the context of an organization. This is important because a project is dependent upon various outcomes produced by the business processes of the organization, e.g., employees to staff the project and facilities to house the project. For this purpose, this standard provides a set of “Organizational Project-Enabling” processes. These processes are not assumed to be adequate to operate a business; instead the processes, considered as a collection, are intended to state the minimum set of dependencies that the project places upon the organization. 5.3.2 Organization and project-level adoption Modern businesses strive to develop a robust set of life cycle processes that are applied repeatedly to the projects of the business. Therefore, this standard is intended to be useful for adoption at either the organization level or at the project level. An organization would adopt the standard and supplement it with appropriate procedures, practices, tools and policies. A project of the organization would typically conform to the organization's processes rather than conform directly to this standard. In some cases, projects may be executed by an organization that does not have an appropriate set of processes adopted at the organizational level. Such a project may apply the provisions of this standard directly to the project. 5.4 Life cycle concepts 5.4.1 System life cycle model Every system has a life cycle. A life cycle can be described using an abstract functional model that represents the conceptualization of a need for the system, its realization, utilization, evolution and disposal. A system progresses through its life cycle as the result of actions, performed and managed by people in organizations, using processes for execution of these actions. The detail in the life cycle model is expressed in terms of these processes, their outcomes, relationships and sequence. This International Standard does not prescribe any particular life cycle model. Instead it defines a set of processes, termed life cycle processes, that can be used in the definition of the system's life cycle. Also, this International Standard does not prescribe any particular sequence of processes within the life cycle model. The sequence of the processes is determined by project objectives and by selection of the system life cycle model. 5.4.2 System life cycle stages Life cycles vary according to the nature, purpose, use and prevailing circumstances of the system. Each stage has a distinct purpose and contribution to the whole life cycle and is considered when planning and executing the system life cycle. The stages represent the major life cycle periods associated with a system and they relate to the state of the system description or the system itself. The stages describe the major progress and achievement milestones of the system through its life cycle. They give rise to the primary decision gates of the life cycle. These decision gates are used by organizations to understand and manage the inherent uncertainties and risks associated with costs, schedule and functionality when creating or utilizing a system. The stages thus provide organizations with a framework within which organization management has high-level visibility and control of project and technical processes. Per ISO/IEC TR 24748-1 (IEEE Std 24748-1-2011), the typical system life cycle stages include concept, development, production, utilization, support, and retirement. Organizations employ stages differently to satisfy contrasting business and risk mitigation strategies. Using stages concurrently and in different orders can lead to life cycle forms with distinctly different characteristics. Further elaboration of these concepts can be found in the ISO/IEC/IEEE TR 24748 guides, on the application of life cycle management. © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 14 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 5.5 Process concepts 5.5.1 Criteria for processes The determination of the life cycle processes in this International Standard is based upon three basic principles: Each life cycle process has strong relationships among its outcomes, activities and tasks. The dependencies among the processes are reduced to the greatest feasible extent. A process is capable of execution by a single organization in the life cycle. 5.5.2 Description of processes Each process of this standard is described in terms of the following attributes: The title conveys the scope of the process as a whole; The purpose describes the goals of performing the process; The outcomes express the observable results expected from the successful performance of the process; The activities are sets of cohesive tasks of a process; The tasks are requirements, recommendations, or permissible actions intended to support the achievement of the outcomes. Additional detail regarding this form of process description can be found in ISO/IEC TR 24774. 5.5.3 General characteristics of processes In addition to the basic attributes described in the previous subclause, processes may be characterized by other attributes common to all processes. ISO/IEC 15504-2 identifies common process attributes that characterize six levels of achievement within a measurement framework for process capability. Annex C of this International Standard includes the list of process attributes that contribute to the achievement of higher levels of process capability as defined in ISO/IEC 15504-2 5.5.4 Tailoring Annex A, which is normative, defines the basic activities needed to perform tailoring of this International Standard. Note that tailoring may diminish the perceived value of a claim of conformance to this standard. This is because it is difficult for other organizations to understand the extent to which tailoring may have deleted desirable provisions. An organization asserting a single-party claim of conformance to this standard may find it advantageous to claim full conformance to a smaller list of processes rather than tailored conformance to a larger list of processes. 5.6 Processes in this standard 5.6.1 Introduction This International Standard groups the activities that can be performed during the life cycle of a system into four process groups. Each of the life cycle processes within those groups is described in terms of its purpose and desired outcomes and lists activities and tasks to be performed to achieve those outcomes. The four process groups and the processes included in each group are depicted in Figure 4. The processes described in this International Standard are not intended to preclude or discourage the use of additional processes that organizations find useful. A description of each process group is provided in the four subclauses that follow. © ISO/IEC 2015 All rights reserved 15 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) Figure 4 — System life cycle processes © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 16 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 5.6.2 Agreement processes Organizations are producers and users of systems. One organization (acting as an acquirer) can task another (acting as a supplier) for products or services. This is achieved using agreements. Generally, organizations act simultaneously or successively as both acquirers and suppliers of systems. The Agreement Processes can be used with less formality when the acquirer and the supplier are in the same organization. Similarly, they can be used within the organization to agree on the respective responsibilities of organization, project and technical functions. Figure 4 lists the processes contained in this process group. 5.6.3 Organizational project-enabling processes The Organizational Project-Enabling Processes are concerned with providing the resources needed to enable the project to meet the needs and expectations of the organization’s interested parties. The Organizational Project-Enabling Processes are typically concerned at a strategic level with the management and improvement of the organization’s business or undertaking, with the provision and deployment of resources and assets, and with its management of risks in competitive or uncertain situations. The Organizational Project-Enabling Processes establish the environment in which projects are conducted. The organization establishes the processes and life cycle models to be used by projects; establishes, redirects, or cancels projects; provides resources required, including human and financial; and sets and monitors the quality measures for systems and other deliverables that are developed by projects for internal and external customers. The Organizational Project-Enabling Processes create a strong business image for many organizations and imply commercial and profit-making motives. Nevertheless, the Organizational Project-Enabling Processes are equally relevant to non-profit organizations, since they are also accountable to stakeholders, are responsible for resources and encounter risk in their undertakings. This International Standard can be applied to non-profit organizations as well as to profit-making organizations. Figure 4 lists the processes contained in this process group. 5.6.4 Technical management processes The Technical Management Processes are concerned with managing the resources and assets allocated by organization management and with applying them to fulfill the agreements into which the organization or organizations enter. The Technical Management Processes relate to the technical effort of projects, in particular to planning in terms of cost, timescales and achievements, to the checking of actions to help ensure that they comply with plans and performance criteria, and to the identification and selection of corrective actions that recover shortfalls in progress and achievement. They are used to establish and perform technical plans for the project, manage information across the technical team, assess technical progress against the plans for the system products or services, control technical tasks through to completion, and to aid in the decision-making process. NOTE 1 Technical management is ‘the application of technical and administrative resources to plan, organize and control engineering functions’ (ISO/IEC/IEEE 24765:2010). Typically several projects will co-exist in any one organization. The Technical Management Processes can be employed at a corporate level to meet internal needs. Figure 4 lists the processes contained in this process group. NOTE 2 Technical Management Processes are applied during the performance of each Technical Process. 5.6.5 Technical processes The Technical Processes are concerned with technical actions throughout the life cycle. Technical Processes transform the needs of stakeholders into a product and service. By applying that product or operating that service, technical processes provide sustainable performance, when and where needed, in order to meet the stakeholder requirements and achieve customer satisfaction. The Technical Processes are applied in order to create and use a system, whether it is in the form of a model or is a finished product. The Technical Processes apply at any level in a hierarchy of system structure and at any stage in the life cycle. Figure 4 lists the processes contained in this process group. © ISO/IEC 2015 All rights reserved 17 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 5.7 Process application The life cycle processes defined in this International Standard can be used by any organization when acquiring, using, creating, or supplying a system. They can be applied at any level in a system’s hierarchy and at any stage in the life cycle. The functions these processes perform are defined in terms of specific purposes, outcomes and the set of activities and tasks that constitute the process. Each life cycle process in Figure 4 can be invoked, as required, at any time throughout the life cycle. The order that the processes are presented in this standard does not imply any prescriptive order in their use. However, sequential relationships are introduced by the definition of a life cycle model. The detailed purpose and timing of use of these processes throughout the life cycle are influenced by multiple factors, including social, trading, organizational and technical considerations, each of which can vary during the life of a system. An individual system life cycle is thus a complex system of processes that will normally possess concurrent, iterative, recursive and time dependent characteristics. Concurrent use of processes can exist within a project (e.g., when design actions and preparatory actions for building a system are performed at the same time), and between projects (e.g., when system elements are designed at the same time under different project responsibilities). When the application of the same process or set of processes is repeated on the same system, the application is referred to as iterative. The iterative use of processes is important for the progressive refinement of process outputs, e.g., the interaction between successive verification actions and integration actions can incrementally build confidence in the conformance of the product. Iteration is not only appropriate but also expected. New information is created by the application of a process or set of processes. Typically this information takes the form of questions with respect to requirements, analyzed risks or opportunities. Such questions should be resolved before completing the activities of a process or set of processes. The recursive use of processes, i.e., the repeated application of the same process or set of processes applied to successive levels of system elements in a system’s structure, is a key aspect of the application of this International Standard. The outputs of processes at any level, whether information, artifacts or services, are inputs to the processes used at the level below (e.g., during top down design) or level above (e.g., during system realization). The outcomes from one application are used as inputs to the next lower (or higher) system in the system structure to arrive at a more detailed or mature set of outcomes. Such an approach adds value to successive systems in the system structure. The changing nature of the influences on the system (e.g., operational environment changes, new opportunities for system element implementation, modified structure and responsibilities in organizations) requires continual review of the selection and timing of process use. Process use in the life cycle can be dynamic, responding to the many external influences on the system. The life cycle approach also allows for incorporating the changes in the next stage. The life cycle stages assist the planning, execution and management of life cycle processes in the face of this complexity in life cycles by providing comprehensible and recognizable high-level purpose and structure. The set of processes within a life cycle stage are applied with the common goal of satisfying the exit criteria for that stage or the entry criteria of the formal progress reviews within that stage. The discussion in this section on iterative and recursive use of the system life cycle processes is not meant to imply any specific hierarchical, vertical, or horizontal structure for the system-of-interest, enabling system, organization, or project. Where justified by product quality risks, detailed descriptions of process instances in the context of the specific product may also be created. Instantiation of processes involves identifying specific success criteria for a process instance, derived from the product requirements, and identifying the specific activities and tasks needed to achieve the success criteria, derived from the activities and tasks identified in this standard. Creating detailed descriptions of process instances enables better management of product quality risks by establishing the link between the process and the specific product requirements. Further elaboration of these concepts can be found in the ISO/IEC/IEEE TR 24748 guides, on the application of life cycle processes. © ISO/IEC 2015 All rights reserved © IEEE 2015 – All rights reserved 18 BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) 5.8 Process reference model Annex C defines a Process Reference Model (PRM) at a level of abstraction higher than that of the detailed requirements contained in Clause 6 of this International Standard. The PRM is applicable to an organization that is assessing its processes in order to determine the capability of these processes. The purpose and outcomes are a statement of the goals of the performance of each process. This statement of goals permits assessment of the effectiveness of the processes in ways other than simple conformity assessment. NOTE In this International Standard, the term “Process Reference Model” is used with the same meaning as ISO/IEC 15504-2. 6 System life cycle processes 6.1 Agreement processes This subclause specifies the requirements for the establishment of agreements with organizational entities external and internal to the organization. The Agreement Processes consist of the following: a) Acquisition process – used by organizations for acquiring products or services; b) Supply process – used by organizations for supplying products or services. These processes define the activities necessary to establish an agreement between two organizations. If the Acquisition process is invoked, it provides the means for conducting business with a supplier. This may include products that are supplied for use as an operational system, services in support of operational activities, or elements of a system being provided by a supplier. If the Supply process is invoked, it provides the means for an agreement in which the result is a product or service that is provided to the acquirer. NOTE Security is an increasing concern in systems engineering. See ISO/IEC 27036, Security techniques — Information security for supplier relationships, for requirements and guidance for suppliers and acquirers on how to secure information in supplier relationships. Specific aspects of information security supplier relationships are addressed in Parts 3 and Part 4. 6.1.1 Acquisition process 6.1.1.1 Purpose The purpose of the Acquisition process is to obtain a product or service in accordance with the acquirer's requirements. NOTE As part of this process, the agreement is modified when a change request is agreed to by both the acquirer and supplier. 6.1.1.2 Outcomes As a result of the successful implementation of the Acquisition process: a) A request for supply is prepared. b) One or more suppliers are selected. c) An agreement is established between the acquirer and supplier. d) A product or service complying with the agreement is accepted. e) Acquirer obligations defined in the agreement are satisfied. 6.1.1.3 Activities and tasks The acquirer shall implement the following activities and tasks in accordance with applicable organization policies and procedures with respect to the Acquisition process. © ISO/IEC 2015 All rights reserved 19 © IEEE 2015 All rights reserved BS ISO/IEC/IEEE 15288:2015 ISO/IEC/IEEE 15288:2015(E) NOTE The activities and resulting agreement from this process often apply to suppliers in the supply chain, including subcontracted suppliers. a) Prepare for the acquisition. This activity consists of the following tasks: 1) Define a strategy for how the acquisition will be conducted. NOTE This strategy describes or references the life cycle model, risks and issues mitigation, a schedule of milestones, and selection criteria if the supplier is external to the acquiring organization. It also includes key drivers and characteristics of the acquisition, such as responsibilities and liabilities; specific models, methods, or processes; level of criticality; formality; and priority of relevant trade factors. 2) Prepare a request for the supply of a product or service that includes the requirements. NOTE 1 If a supplier is external to the organization, then the request includes the business practices with which a supplier is expected to comply and the criteria for selecting a supplier. NOTE 2 A definition of requirements is provided to one or more suppliers. The requirements are the stakeholder or the system requirements, depending on the type of acquisition approach, through the associated requirements definition process. NOTE 3 The acquirer develops the requirements by itself or retains a supplier to develop them. If the acquirer retains a supplier to develop requirements, the acquirer retains approval authority for the requirements developed by the supplier. b) Advertise the acquisition and select the supplier. This activity consists of the following tasks: 1) Communicate the request for the supply of a product or service to potential suppliers. 2) Select one or more suppliers. NOTE To obtain competitive solicitations, proposals to supply are evaluated and compared against the selection criteria and ranked. The justification for rating each proposal is declared and suppliers are informed why they were or were not selected. c) Establish and maintain an agreement. This activity consists of the following tasks: NOTE Project cost, schedule, and performance are monitored through the Project Assessment and Control process. Any identified issues that require agreement modifications are referred to this activity. Any proposals for changes to system elements or information are controlled through the Change Management activity of the Configuration Management process. 1) Develop an agreement with the supplier that includes acceptance criteria. NOTE 1 This agreement ranges in formality from a written contract to a verbal agreement. Appropriate to the level of formality, the agreement establishes requirements, development and delivery milestones, verification, validation and acceptance conditions, exception-handling procedures, agreement change management procedures and payment schedules, so that both parties of the agreement understand the basis for executing the agreement. Rights and restrictions associated with technica
