ISO/IEC 12207

ISO/IEC/IEEE 12207 Systems and software engineering – Software life cycle processes[1] is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

Revision history

ISO/IEC/IEEE 12207:2017 is the newest version, published in November 2017.[1] The IEEE Computer Society joined directly with the International Organization for Standardization (ISO) in the editing process for this version. A significant change is that it adopts a process model identical to the ISO/IEC/IEEE 15288:2015 process model (there is one name change, the 15288 "System Requirements Definition" process is renamed to the "System/Software Requirements Definition" process). This harmonization of the two standards led to the removal of separate software development and software reuse processes, bringing the total number of 12207 processes from 43 down to the 30 processes defined in 15288. It also caused changes to the quality management and quality assurance process activities and outcomes. Additionally, the definition of "audit" and related audit activities were updated.[2][3][4] Annex I of ISO/IEC/IEEE 12207:2017 provides a process mapping between the 2017 version and the previous version, including the primary process alignments between the two versions; this is intended to enable traceability and ease transition for users of the previous version.

Prior versions include:

  • ISO/IEC 12207:2008, which was published in February 2008[5]
  • ISO/IEC 12207:1995/Amd 2:2004, an amended version of the prior, published in November 2004[6]
  • ISO/IEC 12207:1995/Amd 1:2002, an amended version of the prior, published in May 2002[7]
  • ISO/IEC 12207:1995, the first iteration, published in July 1995[8]; originally was divided into five primary processes (acquisition, supply, development, operation, and maintenance), with eight supporting and four organizational life cycle processes[9]

IEEE versions

Prior to the IEEE Computer Society formally joining the editing process (becoming a major stakeholder) for the 2017 release, the IEEE maintained its own versions of ISO/IEC 12207, initially with modifications made jointly with the Electronic Industries Alliance (EIA).[10][11][12] With the 2008 update came a "shared strategy of ISO/IEC JTC 1/SC 7 and the IEEE to harmonize their respective collections of standards," resulting in identical standards thereon, but with slightly different names.[12] Those IEEE versions included:

  • IEEE Std. 12207-2008: "integrates ISO/IEC 12207:1995 with its two amendments and was coordinated with the parallel revision of ISO/IEC 15288:2002 (System life cycle processes) to align structure, terms, and corresponding organizational and project processes"[13]; superseded by ISO/IEC/IEEE 12207:2017
  • IEEE/EIA 12207.2-1997: "provides implementation consideration guidance for the normative clauses of IEEE/EIA 12207.0"[14]; superseded/made obsolete by IEEE Std. 12207-2008, which was then superseded by ISO/IEC/IEEE 12207:2017
  • IEEE/EIA 12207.1-1997: "provides guidance for recording life cycle data resulting from the life cycle processes of IEEE/EIA 12207.0"[15]; superseded by ISO/IEC/IEEE 15289:2011, which was then superseded by ISO/IEC/IEEE 15289:2017
  • IEEE/EIA 12207.0-1996: "consists of the clarifications, additions, and changes [to ISO/IEC 12207:1995 for industry implementation] accepted by the Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Alliance (EIA) as formulated by a joint project of the two organizations"[10]; superseded by IEEE Std. 12207-2008, which was then superseded by ISO/IEC/IEEE 12207:2017

It's also worth noting that IEEE/EIA 12207 officially replaced MIL-STD-498 (released in December 1994[11]) for the development of DoD software systems on May 27, 1998.[9][11]

Processes not stages

The standard establishes a set of processes for managing the lifecycle of software. The standard "does not prescribe a specific software life cycle model, development methodology, method, modelling approach, or technique."[1]. Instead, the standard (as well as ISO/IEC/IEEE 15288) distinguishes between a "stage" and "process" as follows:

  • stage: "period within the life cycle of an entity that relates to the state of its description or realization". A stage is typically a period of time and ends with a "primary decision gate".
  • process: "set of interrelated or interacting activities that transforms inputs into outputs". The same process often recurs within different stages.

Stages (aka phases) are not the same as processes, and this standard only defines specific processes - it does not define any particular stages. Instead, the standard acknowledges that software life cycles vary, and may be divided into stages (also called phases) that represent major life cycle periods and give rise to primary decision gates. No particular set of stages is normative, but it does mention two examples:

  • The system life cycle stages from ISO/IEC TS 24748-1 could be used (concept, development, production, utilization, support, and retirement).
  • It also notes that a common set of stages for software is concept exploration, development, sustainment, and retirement.

The life cycle processes the standard defines are not aligned to any specific stage in a software life cycle. Indeed, the life cycle processes that involve planning, performance, and evaluation "should be considered for use at every stage". In practice, processes occur whenever they are needed within any stage.

Processes

ISO/IEC/IEEE 12207:2017 divides software life cycle processes into four main process groups: agreement, organizational project-enabling, technical management, and technical processes.[1][4] Under each of those four process groups are a variety of sub-categories, including the primary activities of acquisition and supply (agreement); configuration (technical management); and operation, maintenance, and disposal (technical).[1][16]

Agreement processes

Here ISO/IEC/IEEE 12207:2017 includes the acquisition and supply processes[1][2][16], which are activities related to establishing an agreement between a supplier and acquirer. Acquisition covers all the activities involved in initiating a project. The acquisition phase can be divided into different activities and deliverables that are completed chronologically. During the supply phase a project management plan is developed. This plan contains information about the project such as different milestones that need to be reached.

Organizational project-enabling processes

Detailed here are life cycle model management, infrastructure management, portfolio management, human resource management, quality management, and knowledge management processes.[1][2][16] These processes help a business or organization enable, control, and support the system life cycle and related projects. Life cycle mode management helps ensure acquisition and supply efforts are supported, while infrastructure and portfolio management supports business and project-specific initiatives during the entire system life cycle. The rest ensure the necessary resources and quality controls are in place to support the business' project and system endeavors. If an organization does not have an appropriate set of organizational processes, a project executed by the organization may apply those processes directly to the project instead.[1]

Technical management processes

ISO/IEC/IEEE 12207:2017 places eight different processes here[1][2][16]:

These processes deal with planning, assessment, and control of software and other projects during the life cycle, ensuring quality along the way.

Technical processes

The technical processes of ISO/IEC/IEEE 12207:2017 encompass 14 different processes[1][2][16], some of which came from the old software-specific processes that were phased out from the 2008 version.[2]

The full list includes[1][2][16]:

These processes involve technical activities and personnel (information technology, troubleshooters, software specialists, etc.) during pre-, post- and during operation. The analysis and definition processes early on set the stage for how software and projects are implemented. Additional processes of integration, verification, transition, and validation help ensure quality and readiness. The operation and maintenance phases occur simultaneously, with the operation phase consisting of activities like assisting users in working with the implemented software product, and the maintenance phase consisting of maintenance tasks to keep the product up and running. The disposal process describes how the system/project will be retired and cleaned up, if necessary.[1]

Conformance

Clause 4 describes the document's intended use and conformance requirements. It is expected that particular projects "may not need to use all of the processes provided by this document." In practice, conforming to this standard normally involves selecting and declaring the set of suitable processes. This can be done through either "full conformance" or "tailored conformance".

"Full conformance" can be claimed in one of two ways. "Full conformance to tasks" can be claimed if all requirements of the declared processes' activities and tasks are met. "Full conformance to outcomes" can be claimed if all required outcomes of the declared processes are met. The latter permits more variation.

"Tailored conformance" may be declared when specific clauses are selected or modified through the tailoring process also defined in the document.

See also

References

  1. ^ a b c d e f g h i j k l "ISO/IEC/IEEE 12207:2017". Standards catalogue. International Organization for Standardization. November 2017. Retrieved 21 June 2018.
  2. ^ a b c d e f g Reilly, A. (27 June 2017). "New or Improved! Software Engineering Standards for Quality". American Society for Quality. Retrieved 21 June 2018.
  3. ^ Bach, C. (12 December 2017). "ISO/IEC 12207 Updated and Renumbered as ISO/IEC/IEEE 12207". Standards Forum. Document Center, Inc. Retrieved 22 June 2018.
  4. ^ a b Reilly, A. (March 2018). "INCITS/SSE - Software and Systems Engineering Annual Report - April 2017 to March 2018" (PDF). INCITS. Retrieved 22 June 2018. The cornerstone standards of ISO/IEC JTC 1/SC 7, ISO/IEC/IEEE 12207:2017 and ISO/IEC/IEEE 15288:2015, have recently completed revision to reflect a unified model set of acquisition, organizational, technical management, and technical processes for systems and software.
  5. ^ "ISO/IEC 12207:2008". Standards catalogue. International Organization for Standardization. February 2008. Retrieved 21 June 2018.
  6. ^ "ISO/IEC 12207:1995/Amd 2:2004". Standards catalogue. International Organization for Standardization. November 2004. Retrieved 21 June 2018.
  7. ^ "ISO/IEC 12207:1995/Amd 1:2002". Standards catalogue. International Organization for Standardization. May 2002. Retrieved 21 June 2018.
  8. ^ "ISO/IEC 12207:1995". Standards catalogue. International Organization for Standardization. July 1995. Retrieved 21 June 2018.
  9. ^ a b "Overview of IEEE/EIA 12207: Standard for Information Technology". SSC San Diego Process Asset Library. 30 July 1998. Archived from the original on 30 December 2008. Retrieved 22 June 2018.
  10. ^ a b "IEEE 12207.0-1996 - Standard for Information Technology - Software Life Cycle Processes". IEEE Standards Association. March 1998. Retrieved 22 June 2018.
  11. ^ a b c "ISO/IEC 12207:2008, IEEE Std 12207-2008 Systems and Software Engineering — Software Life Cycle Processes" (PDF). SemanticScholar.org. 7 December 2009. Retrieved 22 June 2018.
  12. ^ a b "1SO/IEC 12207:2008(en) Systems and software engineering — Software life cycle processes: IEEE Introduction". Online Browsing Platform. International Organization for Standardization. February 2008. Retrieved 22 June 2018.
  13. ^ "IEEE Std. 12207-2008 - Systems and software engineering -- Software life cycle processes". IEEE Standards Association. January 2008. Retrieved 22 June 2018.
  14. ^ "IEEE 12207.2-1997 - Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations". IEEE Standards Association. April 1998. Retrieved 22 June 2018.
  15. ^ "IEEE 12207.1-1997 - Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data". IEEE Standards Association. April 1998. Retrieved 22 June 2018.
  16. ^ a b c d e f Peñalvo, F.J.; Holgado, A.G. (2017). "Proceso: Ingeniería de Software I" (PDF). Universidad de Salamanca. p. 39. Retrieved 21 June 2018.CS1 maint: Multiple names: authors list (link)
Acquisition initiation (ISPL)

Acquisition Initiation is the initial process within the Information Services Procurement Library (ISPL) and is executed by a customer organization intending to procure Information Services. The process is composed of two main activities: the making of the acquisition goal definition and the making of the acquisition planning. During the acquisition initiation, an iterative process arises in which questions about the goal of the acquisition are usually asked. In response to these questions the Library provides details of the requirements, covering areas such as cost, feasibility and timelines. An example of such requirements is the "planning of the acquisition", a component that may also lead to more questions about the acquisition goal (thus, it is reasonable to state that a relationship exists between the acquisition goal and the acquisition planning).

The process-data model shown in the following section displays the acquisition initiation stages. It shows both the process and the data ensuing from the process, and parts of the image will also be used as references in the body of this article. The concepts and data found in the model are explained in separate tables which can be found in the section immediately following the model. A textual, and more thorough, explanation of the activities and concepts that make up the Acquisition Initiation process can be found in the remainder of this article.

Application Lifecycle Framework

Application Lifecycle Framework (ALF) was an Eclipse Foundation project to develop an open framework for system integration and interoperability for application lifecycle management tools. The project failed to gain the support of significant vendors and was terminated in 2008.

DO-178B

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO-178C.

The FAA applies DO-178B as the document it uses for guidance to determine if the software will perform reliably in an airborne environment, when specified by the Technical Standard Order (TSO) for which certification is sought. In the United States, the introduction of TSOs into the airworthiness certification process, and by extension DO-178B, is explicitly established in Title 14: Aeronautics and Space of the Code of Federal Regulations (CFR), also known as the Federal Aviation Regulations, Part 21, Subpart O.

It was jointly developed by the safety-critical working group RTCA SC-167 of RTCA and WG-12 of EUROCAE. RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B.

ISO/IEC 15288

The ISO/IEC 15288 is a systems engineering standard covering processes and lifecycle stages. Initial planning for the ISO/IEC 15288:2002(E) standard started in 1994 when the need for a common systems engineering process framework was recognized. The previously accepted standard MIL STD 499A (1974) was cancelled after a memo from SECDEF prohibited the use of most United States Military Standards without a waiver. The first edition was issued on 1 November 2002. Stuart Arnold was the editor and Harold Lawson was the architect of the standard. In 2004 this standard was adopted as IEEE 15288. ISO/IEC 15288 has been updated 1 February 2008 as well as on 15 May 2015.ISO/IEC 15288 is managed by ISO/IEC JTC1/SC7, which is the ISO committee responsible for developing ISO standards in the area of Software and Systems Engineering. ISO/IEC 15288 is part of the SC 7 Integrated set of Standards, and other standards in this domain include:

ISO/IEC TR 15504 which addresses capability

ISO/IEC 12207 and ISO/IEC 15288 which address lifecycle and

ISO 9001 & ISO 9000-3 which address quality

ISO/IEC 15504

ISO/IEC 15504 Information technology – Process assessment, also termed Software Process Improvement and Capability Determination (SPICE), is a set of technical standards documents for the computer software development process and related business management functions. It is one of the joint International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standards, which was developed by the ISO and IEC joint subcommittee, ISO/IEC JTC 1/SC 7.ISO/IEC 15504 was initially derived from process lifecycle standard ISO/IEC 12207 and from maturity models like Bootstrap, Trillium and the Capability Maturity Model (CMM).

ISO/IEC 15504 has been revised by: ISO/IEC 33001:2015 Information technology – Process assessment – Concepts and terminology as of March, 2015 and is no longer available at ISO.

ISO/IEC 42010

ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.

ISO/IEC JTC 1/SC 7

ISO/IEC JTC 1/SC 7 Software and systems engineering is a standardization subcommittee of the Joint Technical Committee ISO/IEC JTC 1 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), that develops and facilitates standards within the field of engineering of software products and systems. The international secretariat of ISO/IEC JTC 1/SC 7 is the Bureau of Indian Standards (BIS) located in India.

ISO 29110

ISO/IEC 29110: Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs) International Standards (IS) and Technical Reports (TR) are targeted at Very Small Entities (VSEs). A Very Small Entity (VSE) is an enterprise, an organization, a department or a project having up to 25 people. The ISO/IEC 29110 is a series of international standards and guides entitled "Systems and Software Engineering — Lifecycle Profiles for Very Small Entities (VSEs)". The standards and technical reports were developed by working group 24 (WG24) of sub-committee 7 (SC7) of Joint Technical Committee 1 (JTC1) of the International Organization for Standardization and the International Electrotechnical Commission.

Industries around the world have agreed that there are certain ways of working that produce predictable results. Companies that agree to use these agreed methods and then to have their compliance measured are called ISO certificated. Some ISO-certificated organizations require that their vendors also be ISO certificated. The general standard for software development, ISO/IEC/IEEE 12207, is appropriate for medium and large software development efforts. Similarly, the general standard for system development, ISO/IEC/IEEE 15288, is appropriate for medium and large system development efforts. Systems, in the context of ISO/IEC 29110, are typically composed of hardware and software components. Things work differently in a small organisations; ISO 29110 reflects that.

Index of software engineering articles

This is an alphabetical list of articles pertaining specifically to software engineering.

Information Services Procurement Library

The Information Services Procurement Library (ISPL) is a best practice library for the management of Information Technology related acquisition processes (derived from Euromethod). It helps both the customer and supplier organization to achieve the desired quality using the corresponded amount of time and money by providing methods and best practices for risk management, contract management, and planning. ISPL focuses on the relationship between the customer and supplier organization: It helps constructing the request for proposal, it helps constructing the contract and delivery plan according to the project situation and risks, and it helps monitoring the delivery phase. ISPL is a unique Information Technology method because where most other Information Technology methods and frameworks focus on development (e.g. DSDM, RUP), ISPL focuses purely on the procurement of information services. The target audience for ISPL consists of procurement managers, acquisition managers, programme managers, contract managers, facilities managers, service level managers, and project managers in the IT (Information Technology) area. Because of ISPL's focus on procurement it is very suitable to be used with ITIL (for IT Service Management) and PRINCE2 (for Project Management).

List of International Organization for Standardization standards, 24000-25999

This is a list of published International Organization for Standardization (ISO) standards and other deliverables. For a complete and up-to-date list of all the ISO standards, see the ISO catalogue.The standards are protected by copyright and most of them must be purchased. However, about 300 of the standards produced by ISO and IEC's Joint Technical Committee 1 (JTC1) have been made freely and publicly available.

Long-term support

Long-term support (LTS) is a product lifecycle management policy in which a stable release of computer software is maintained for a longer period of time than the standard edition. The term is typically reserved for open-source software, where it describes a software edition that is supported for months or years longer than the software's standard edition.

Short term support (STS) is a term that distinguishes the support policy for the software's standard edition. STS software has a comparatively short life cycle, and may be afforded new features that are omitted from the LTS edition to avoid potentially compromising the stability or compatibility of the LTS release.

Monitoring Maintenance Lifecycle

The Monitoring Maintenance Lifecycle (MML) is a monitoring development process to reduce maintenance costs and increase reliability of IT infrastructure concerning service recovery related problems. It is based on the classical Waterfall model.

Monitoring Maintenance Lifecycle are methods and standards for improving and mastering maintenance processes, supporting processes and management processes throughout the monitoring lifecycle.

The quest for the optimized mix of processes has resulted in different standards throughout the history. One of the latest which was published is the ISO/IEC 12207 standard. This standard was proposed in 1988 and published in August 1995. It was created to establish a common international framework to acquire, supply, develop, operate, and maintain.

ISO/IEC 12207 consists of three types of processes:

Primary lifecycle processes;

Supporting lifecycle processes;

Organizational lifecycle processes.

Outline of software engineering

The following outline is provided as an overview of and topical guide to software engineering:

Software engineering – application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software.

Quality management

Quality management ensures that an organization, product or service is consistent. It has four main components: quality planning, quality assurance, quality control and quality improvement. Quality management is focused not only on product and service quality, but also on the means to achieve it. Quality management, therefore, uses quality assurance and control of processes as well as products to achieve more consistent quality.

What a customer wants and is willing to pay for it determines quality. It is written or unwritten commitment to a known or unknown consumer in the market . Thus, quality can be defined as fitness for intended use or, in other words, how well the product performs it's intended function

Software architecture

Software architecture refers to the high level structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.Software architecture is about making fundamental structural choices which are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of software. For example, the systems that controlled the space shuttle launch vehicle had the requirement of being very fast and very reliable. Therefore, an appropriate real-time computing language would need to be chosen. Additionally, to satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.

Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.

Software development process

In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.

Some people consider a life-cycle "model" a more general term for a category of methodologies and a software development "process" a more specific term to refer to a specific process chosen by a specific organization. For example, there are many specific software development processes that fit the spiral life-cycle model. The field is often considered a subset of the systems development life cycle.

Software verification and validation

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high level requirements?"

TickIT

TickIT is a certification program for companies in the software development and computer industries, supported primarily by the United Kingdom and Swedish industries through UKAS and SWEDAC respectively. Its general objective is to improve software quality.

ISO standards by standard number
1–9999
10000–19999
20000+
IEC standards
ISO/IEC standards
Related
Current
802 series
Proposed
Superseded

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.