Difference between revisions of "Key Standards"

From EITBOK
Jump to: navigation, search
m
 
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
<h2>Purpose of This Standards Guide</h2>
+
<table border="3">
−
<p>This guide is designed for software producers, as well as producers of systems with embedded software. The purpose of this guide is to help informatics practitioners ensure that developed and deployed systems and software have the following characteristics:</p>
+
<tr><td>
 +
<table>
 +
<tr>
 +
<td width="60%"><font color="#246196">'''Welcome to the initial version of the EITBOK wiki. Like all wikis, it is a work in progress and may contain errors. We welcome feedback, edits, and real-world examples. [[Main_Page#How to Make Comments and Suggestions|Click here]] for instructions about how to send us feedback.''' </font></td>
 +
<td width="20%">[[File:Ieee logo 1.png|100px|center]]</td>
 +
<td width="20%">[[File:Acm_logo_3.png|175px|center]]</td></tr></table>
 +
</td></tr></table>
 +
<p>&nbsp;</p>
 +
<h2>Purpose of this Standards Guide</h2>
 +
<p>This standards guide is designed for software producers, as well as producers of systems with embedded software. The purpose of this guide is to help informatics practitioners ensure that developed and deployed systems and software have the following characteristics:</p>
 
<ul>
 
<ul>
 
<li>They can be and are verified and validated.</li>
 
<li>They can be and are verified and validated.</li>
 
<li>They meet the purpose for which they are intended.</li>
 
<li>They meet the purpose for which they are intended.</li>
−
<li>They are robust, reliable and resilient enough to consistently perform to their intended use.</li>
+
<li>They are robust, reliable, and resilient enough to consistently perform to their intended use.</li>
 
</ul>
 
</ul>
−
<p>IEEE System and Software Engineering Standards are as critical to industry as they have been to space exploration. This guide introduces you to the core subset of S2ESC’s portfolio of standards.</p>
+
<p>IEEE system and software engineering standards are as critical to industry as they have been to space exploration. This guide introduces you to the core subset of the Software and Systems Engineering Standards Committee (S2ESC) portfolio of standards.</p>
−
<h3>The Value of System and Software Standards to Industry</h3>
+
<h3>Value of System and Software Standards to Industry</h3>
−
<p>The aggressive transition to technology-based information is successful only if software and software-intensive systems &mdash; which encompass myriad products and processes in complex ways &mdash; seamlessly collect, aggregate, share, analyze, and present dynamic information in a timely manner.</p>
+
<p>The aggressive transition to technology-based information is successful only if software and software-intensive systems—which encompass myriad products and processes in complex ways—seamlessly collect, aggregate, share, analyze, and present dynamic information in a timely manner.</p>
 
<p>For example, the anticipated human and economic benefits from the present rapid transition to health information technologies demand that software and systems developers of medical devices, digital medical records, and administrative, financial, and regulatory systems (e.g., public health, service/healthcare providers, and payers) design, develop, and deliver interoperable products, processes, and services that are safe, secure, reliable, and robust. </p>
 
<p>For example, the anticipated human and economic benefits from the present rapid transition to health information technologies demand that software and systems developers of medical devices, digital medical records, and administrative, financial, and regulatory systems (e.g., public health, service/healthcare providers, and payers) design, develop, and deliver interoperable products, processes, and services that are safe, secure, reliable, and robust. </p>
−
<p>The application of IEEE S2ESC systems and software standards helps software producers by ''simplifying product development processes'', ''avoiding the pitfalls that have overcome many software projects'', and thus ''reduces non-value-adding efforts and costs''. Adoption and implementation of the core software and systems engineering standards across companies that produce or tailor information systems and devices ''increases their development organization’s ability to deliver robust software in shorter time frames''. Even more important, the consistent use of these IEEE standards lowers the risks of delivering faulty products.</p>
+
<p>The application of IEEE standards helps software producers by ''simplifying product development processes'', ''avoiding the pitfalls that have overcome many software projects'', and thus ''reduces non-value-adding efforts and costs''. Adoption and implementation of the core software and systems engineering standards across companies that produce or tailor information systems and devices ''increases their development organization's ability to deliver robust software in shorter time frames.'' Even more important, the consistent use of these IEEE standards lowers the risks of delivering faulty products.</p>
−
<p>Standards for Software and Systems Engineering encompass the full software and systems life cycles, from concept and development to delivery and maintenance, and even the reuse of software components. </p>
+
<p>Standards for software and systems engineering encompasses the full software and systems lifecycles, from concept and development to delivery and maintenance, and even the reuse of software components. </p>
−
<h3>Standards Essential To Informatics Technology Producers</h3>
+
<h3>Standards Essential to Informatics Technology Producers</h3>
−
<p>Ensuring that delivered software meets its purpose and consistently performs to its intended use is vital to effective information delivery. As fundamental building blocks for international systems and software development, IEEE Software and Systems Engineering Standards help producers ensure interconnectivity, interoperability and verification of new informatics products and systems enabling the rapid implementation and trusted use of medical technologies.</p>
+
<p>Ensuring that delivered software meets its purpose and consistently performs to its intended use is vital to effective information delivery. As fundamental building blocks for international systems and software development, IEEE software and systems engineering standards helps producers ensure interconnectivity, interoperability, and verification of new informatics products and systems enabling the rapid implementation and trusted use of medical technologies.</p>
−
<p>The essential set [[#One|[1]]] of IEEE System and Software Standards that are key to the development and delivery of robust software are listed in the table below.</p>
+
<p>The essential set [[#One|[1]]] of IEEE standards that are key to the development and delivery of robust software and systems are listed in the table below.</p>
−
<p>'''Table 1. Essential Standards'''</p>
+
<table cellpadding="5" border="1">
−
<table border="1" cellpadding="10">
+
<tr valign="top"><th width="20%" style="background-color: #58ACFA"><font color="white">Number</font></th>
−
<tr valign="top"><td width="20%" style="background-color: #58ACFA;"><font color="white">'''Number'''</font></td><td width="20%" style="background-color: #58ACFA;"><font color="white">'''Official Designation'''</font></td><td style="background-color: #58ACFA;"><font color="white">'''Name'''</font></td></tr>
+
<th width="20%" style="background-color: #58ACFA;"><font color="white">Official Designation</font></th>
 +
<th style="background-color: #58ACFA;"><font color="white">Name</font></th></tr>
 +
<tr valign="top"><td>730</td><td>IEEE Std 730</td>
 +
<td>IEEE Standard for Software Quality Assurance Plans</td></tr>
 +
<tr valign="top"><td>828</td>
 +
<td>IEEE Std 828</td>
 +
<td>IEEE Standard for Software Configuration Management</td></tr>
 +
<tr valign="top"><td>830</td>
 +
<td>IEEE Std 830</td>
 +
<td>IEEE Recommended Practice for Software Requirements Specifications. This standard was contributed to ISO and is now replaced by ISO/IEC/IEEE 29148.</td></tr>
 +
<tr valign="top"><td>1008</td>
 +
<td>IEEE Std 1008</td>
 +
<td>IEEE Standard for Software Unit Testing. This standard was contributed to ISO and is now replaced by ISO/IEC/IEEE 29119-4.</td></tr>
 +
<tr valign="top"><td>1012</td>
 +
<td>IEEE Std 1012</td>
 +
<td>IEEE Standard for System and Software Verification and Validation</td></tr>
 +
<tr valign="top"><td>1016</td>
 +
<td>IEEE Std 1016</td><td>IEEE Recommended Practice for Software Design Descriptions</td></tr>
 +
<tr valign="top"><td>1028</td><td>IEEE Std 1028</td>
 +
<td>IEEE Standard for Software Reviews and Audits</td></tr>
 +
<tr valign="top"><td>1058</td>
 +
<td>IEEE Std 1058</td>
 +
<td>IEEE Standard for Software Project Management Plans. This standard is inactive, but contributed to ISO/IEC/16326.</td></tr>
 +
<tr valign="top"><td>1063</td>
 +
<td>IEEE Std 1063</td>
 +
<td>IEEE Standard for Software User Documentation. This standard was contributed to ISO and is now superseded by ISO/IEC/IEEE 26514 Systems and Software Engineering—Requirements for designers and developers of user documentation.</td></tr>
 +
<tr valign="top"><td>1074</td>
 +
<td>IEEE Std 1074</td>
 +
<td>IEEE Standard for Developing a Software Project Life-cycle Process. This standard was contributed to ISO. It has not been superseded, but ISO/IEC/IEEE 24774 presents guidelines for the elements used most frequently in describing a process: the title, purpose, outcomes, activities, task and information item</td></tr>
 +
<tr valign="top"><td>12207</td>
 +
<td>ISO/IEC/IEEE 12207</td>
 +
<td>Systems and Software Engineering—life-cycle processes</td></tr>
 +
<tr valign="top"><td>14764</td>
 +
<td>IEEE Std 14764</td>
 +
<td>Software Engineering—System Life-cycle Processes—Maintenance</td></tr>
 +
<tr valign="top"><td>15288</td>
 +
<td>ISO/IEC/IEEE 15288</td>
 +
<td>Systems and Software Engineering—Systems life-cycle processes</td></tr>
 +
<tr valign="top"><td>12207</td>
 +
<td>ISO/IEC/IEEE 20000-1</td>
 +
<td>Information Technology—Service management—Part 1: Service Management System requirements</td></tr>
 +
</table>
 +
<p>Additional important standards are listed in the table below.</p>
 +
<table cellpadding="5" border="1">
 +
<tr valign="top"><th width="20%" style="background-color: #58ACFA;"><font color="white">Number</font></th><th width="20%" style="background-color: #58ACFA;"><font color="white">Official Designation</font></th><th style="background-color: #58ACFA;"><font color="white">Name</font></th></tr>
 +
<tr valign="top"><td>829</td><td>IEEE Std 829</td><td>IEEE Standard for Software and System Test Documentation was contributed to ISO and is superseded by ISO/IEC/IEEE 29119-3</td></tr>
 +
<tr valign="top"><td>1044</td><td>IEEE Std 1044</td><td>IEEE Standard Classification for Software Anomalies</td></tr>
 +
<tr valign="top"><td>1062</td><td>IEEE Std 1062</td><td>IEEE Recommended Practice for Software Acquisition</td></tr>
 +
<tr valign="top"><td>1233</td><td>IEEE Std 1233</td><td>IEEE Guide for Developing System Requirements Specifications was contributed to ISO and is superseded by ISO/IEC/IEEE 29148</td></tr>
 +
<tr valign="top"><td>1362</td><td>IEEE Std 1362</td><td>IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document was contributed to ISO and superseded by ISO/IEC/IEEE 29148</td></tr>
 +
<tr valign="top"><td>15939</td><td>ISO/IEC/IEEE Std 15939</td><td>Systems and Software Engineering—Measurement Process</td></tr>
 
<tr valign="top">
 
<tr valign="top">
−
<td>730</td><td>IEEE Std 730-2002</td><td>IEEE Standard for Software Quality Assurance Plans</td></tr>
+
</table>
−
<tr valign="top">
+
<h2>Short Descriptions of a Sampling of the Standards</h2>
−
<td>828</td><td>IEEE Std 828-1998 (R2005)</td><td>IEEE Standard for Software Configuration Management</td></tr>
+
<p>Note that many EIT-relevant standards can be downloaded for free at http://standards.iso.org/ittf/PubliclyAvailableStandards.</p>
−
<tr valign="top">
+
<h3>IEEE Std 730: Software Quality Assurance Plans</h3>  
−
<td>830</td><td>IEEE Std 830-1998</td><td>IEEE Recommended Practice for Software Requirements Specifications</td></tr>
+
−
<tr valign="top">
+
−
<td>1008</td><td>IEEE Std 1008-1987(R2002) </td><td>IEEE Standard for Software Unit Testing</td></tr>
+
−
<tr valign="top">
+
−
<td>1012</td><td>IEEE Std 1012-2004 </td><td>IEEE Standard for System and Software Verification and Validation</td></tr>
+
−
<tr valign="top">
+
−
<td>1016</td><td>IEEE Std 1016-1998(R2009)</td><td>IEEE Recommended Practice for Software Design Descriptions</td></tr>
+
−
<tr valign="top">
+
−
<td>1028</td><td>IEEE Std 1028-2008 </td><td>IEEE Standard for Software Reviews and Audits</td></tr>
+
−
<tr valign="top">
+
−
<td>1058</td><td>IEEE Std 1058-1998</td><td>IEEE Standard for Software Project Management Plans</td></tr>
+
−
<tr valign="top">
+
−
<td>1063</td><td>IEEE Std 1063-2001 (R2007)</td><td>IEEE Standard for Software User Documentation</td></tr>
+
−
<tr valign="top">
+
−
<td>1074</td><td>IEEE Std 1074-2006</td><td>IEEE Standard for Developing a Software Project Life-cycle Process</td></tr>
+
−
<tr valign="top">
+
−
<td>12207</td><td>ISO/IEC/IEEE 12207: 2008</td><td>Systems and Software Engineering &mdash; life-cycle processes</td></tr>
+
−
<tr valign="top">
+
−
<td>14764</td><td>IEEE Std 14764-2006 </td><td>Software Engineering &mdash; System Life-cycle Processes &mdash; Maintenance</td></tr></table>
+
−
<p>In addition, HITSP may wish to examine these additional S2ESC standards. </p>
+
−
<p>'''Table 2. Additional Standards'''</p>
+
−
<table border="1" cellpadding="10">
+
−
<tr valign="top"><td width="20%" style="background-color: #58ACFA;"><font color="white">'''Number'''</font></td><td width="20%" style="background-color: #58ACFA;"><font color="white">'''Official Designation'''</font></td><td style="background-color: #58ACFA;"><font color="white">'''Name'''</font></td></tr>
+
−
<tr valign="top">
+
−
<td>829</td><td>IEEE Std 829-2008 (March 27)</td><td>IEEE Standard for Software and System Test Documentation</td></tr>
+
−
<tr valign="top">
+
−
<td>1044</td><td>IEEE Std 1044-2002 </td><td>IEEE Standard Classification for Software Anomalies</td></tr>
+
−
<tr valign="top">
+
−
<td>1062</td><td>IEEE Std 1062-2002 </td><td>IEEE Recommended Practice for Software Acquisition</td></tr>
+
−
<tr valign="top">
+
−
<td>1233</td><td>IEEE Std 1233-1998 (R2002)</td><td>IEEE Guide for Developing System Requirements Specifications</td></tr>
+
−
<tr valign="top">
+
−
<td>1362</td><td>IEEE Std 1362-1998 (R2007)</td><td>IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document</td></tr>
+
−
<tr valign="top">
+
−
<td>14143-1</td><td>ISO/IEC/IEEE14143-1</td><td>Implementation Note for IEEE Adoption of ISO/IEC<br />14143-1:2007 Information Technology &mdash; Software Measurement &mdash; Function Size Measurement Part I: Definition of Concepts</td></tr>
+
−
<tr valign="top">
+
−
<td>15288</td><td>ISO/IEC/IEEE 15288(2008)</td><td>Systems and Software Engineering &mdash; System Life-cycle Processes</td></tr></table>
+
−
<h2>Short Descriptions of the Standards</h2>
+
−
<h3>IEEE Std 730-2002: Software Quality Assurance Plans</h3>
+
 
<p>'''Abstract:''' The standard specifies the format and content of software quality-assurance plans. It meets the IEEE/EIA 12207.1 requirements for such plans.</p>
 
<p>'''Abstract:''' The standard specifies the format and content of software quality-assurance plans. It meets the IEEE/EIA 12207.1 requirements for such plans.</p>
−
<p>The SQA plan defines the means to ensure that software developed for a specific product satisfies the user’s requirements and is of the highest quality possible within project constraints. To do so, it must first ensure that the quality target is clearly defined and understood. It must consider management, development, and maintenance plans for the software. [[#Two|[2]]]</p>
+
<p>The SQA plan defines the means to ensure that software developed for a specific product satisfies user requirements and is of the highest quality possible within project constraints. To do so, it must first ensure that the quality target is clearly defined and understood. It must consider management, development, and maintenance plans for the software.</p>
−
<h3>IEEE Std 828-2005: Software Configuration Management</h3>
+
<h3>IEEE Std 828: Software Configuration Management</h3>
−
<p>'''Abstract:''' The minimum required contents of a software configuration management (SCM) plan are established via this standard. The application of this standard is not restricted to any form, class, or type of software. This standard applies to the entire life cycle of critical software (e.g., where failure would impact safety or cause large financial or social losses), as well as to noncritical software and to software already developed. A new version of this standard that defines the individual processes that make up software configuration management is currently underway, and expected to be published in 2010.</p>
+
<p>'''Abstract:''' This standard explains CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as software builds and release engineering. It addresses what CM activities are to be done, when they are to happen in the lifecycle, and what planning and resources are required. It also describes the content areas for a CM plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminology in ISO/IEC/IEEE Std 24765 and the information item requirements of IEEE Std 15939.</p>
−
<h3>IEEE Std 829-2008: Software and System Test Documentation</h3>
+
<h3>IEEE Std 1012: System and Software Verification and Validation</h3>
−
<p>'''Abstract:''' Test processes determine whether the development products of a given activity conform to the requirements of that activity and whether the system and software satisfies its intended use and user needs. Testing process tasks are specified for different integrity levels. These process tasks determine the appropriate breadth and depth of test documentation. The documentation elements for each type of test documentation can then be selected. The scope of testing encompasses software-based systems, computer software, hardware, and their interfaces. This standard applies to software-based systems being developed, maintained, or reused (legacy, commercial off-the-shelf, non-developmental items). The term “software” also includes firmware, microcode, and documentation. Test processes can include inspection, analysis, demonstration, verification, and validation of software and software-based system products.</p>
+
<p>'''Abstract:''' Software verification and validation (V&V) processes determine whether the development products of a given activity conform to the requirements of that activity and whether the software satisfies its intended use and user needs. Software V&V lifecycle process requirements are specified for different software integrity levels. The scope of V&V processes encompasses software-based systems, computer software, hardware, and interfaces. This standard applies to software being developed, maintained, or reused (legacy, commercial off-the-shelf (COTS), non-developmental items). The term software also includes firmware, microcode, and documentation. Software V&V processes include analysis, evaluation, review, inspection, assessment, and testing of software products.</p>
−
<h3>IEEE Std 830-1998: Software Requirements Specifications</h3>
+
<h3>IEEE Std 1016: Software Design Descriptions</h3>
−
<p>'''Abstract:''' The content and qualities of a good software requirements specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products. It is very useful for development teams to use as a checklist to remember all the different types of requirements (functional, derived, operational, quality, etc.) that must be provided to the development team.</p>
+
<p>'''Abstract:''' The necessary information content and recommendations for an organization for software design descriptions (SDDs) are described. An SDD is a representation of a software system that is used as a medium for communicating software design information. This recommended practice is applicable to paper documents, automated databases, design description languages, and other means of description.</p>
−
<h3>IEEE Std 1008-1987: Software Unit Testing</h3>
+
<h3>IEEE Std 1028: Software Reviews and Audits</h3>
−
<p>Unit testing verifies the functioning in isolation of software pieces that are separately testable. Depending on the context, these could be the individual subprograms or a larger component made of tightly related units. A test unit is defined more precisely in the IEEE Standard for Software Unit Testing (IEEE1008-87), which also describes an integrated approach to systematic and documented unit testing. Typically, unit testing occurs with access to the code being tested and with the support of debugging tools, and might involve the programmers who wrote the code. [[#Three|[3]]] Test cases should be under the control of software configuration management and include the expected results for each test. [[#Four|[4]]]</p>
+
−
<p>Key aspects of test planning include coordination of personnel, management of available test facilities and equipment (which may include magnetic media, test plans, and procedures), and planning for possible undesirable outcomes. If more than one baseline of the software is being maintained, then a major planning consideration is the time and effort needed to ensure that the test environment is set to the proper configuration. [[#Five|[5]]]</p>
+
−
<h3>IEEE Std 1012-2004: System and Software Verification and Validation</h3>
+
−
<p>'''Abstract:''' Software verification and validation (V&V) processes determine whether the development products of a given activity conform to the requirements of that activity and whether the software satisfies its intended use and user needs. Software V&V life-cycle process requirements are specified for different software integrity levels. The scope of V&V processes encompasses software-based systems, computer software, hardware, and interfaces. This standard applies to software being developed, maintained, or reused (legacy, commercial off-the-shelf (COTS), non-developmental items). The term software also includes firmware, microcode, and documentation. Software V&V processes include analysis, evaluation, review, inspection, assessment, and testing of software products.</p>
+
−
<h3>IEEE Std 1016-2009: Software Design Descriptions</h3>
+
−
<p>'''Abstract:''' The necessary information content and recommendations for an organization for software design descriptions (SDDs) are described. An SDD is a representation of a software system that is used as a medium for communicating software design information. This recommended practice is applicable to paper documents, automated databases, design description languages, or other means of description.</p>
+
−
<h3>IEEE Std 1028-2008: Software Reviews and Audits</h3>
+
 
<p>'''Abstract:''' Five types of software reviews and audits, together with procedures required for the execution of each type, are defined in this standard. This standard is concerned only with the reviews and audits; procedures for determining the necessity of a review or audit are not defined, and the disposition of the results of the review or audit is not specified. Types included are management reviews, technical reviews, inspections, walk-throughs, and audits. </p>
 
<p>'''Abstract:''' Five types of software reviews and audits, together with procedures required for the execution of each type, are defined in this standard. This standard is concerned only with the reviews and audits; procedures for determining the necessity of a review or audit are not defined, and the disposition of the results of the review or audit is not specified. Types included are management reviews, technical reviews, inspections, walk-throughs, and audits. </p>
−
<h3>IEEE Std 1044-1993(R2002): Classification for Software Anomalies</h3>
+
<h3>IEEE Std 1044: Classification for Software Anomalies</h3>
−
<p>'''Abstract:''' A uniform approach to the classification of anomalies found in software and its documentation is provided. The processing of anomalies discovered during any software life-cycle phase are described, and comprehensive lists of software anomaly classifications and related data items that are helpful to identify and track anomalies are provided. This standard is not intended to define procedural or format requirements for using the classification scheme. It does identify some classification measures and does not attempt to define all the data supporting the analysis of an anomaly. </p>
+
<p>'''Abstract:''' A uniform approach to the classification of anomalies found in software and its documentation is provided. The processing of anomalies discovered during any software lifecycle phase are described, and comprehensive lists of software anomaly classifications and related data items that are helpful to identify and track anomalies are provided. This standard is not intended to define procedural or format requirements for using the classification scheme. It identifies some classification measures but does not attempt to define all the data supporting the analysis of an anomaly.</p>
−
<h3>IEEE Std 1058-1998: Software Project Management Plans</h3>
+
<h3>IEEE Std 1058/ISO/IEC/IEEE 16326: Software Project Management </h3>
−
<p>'''Abstract:''' The format and contents of software project management plans, applicable to any type or size of software project, are described. The elements that should appear in all software project management plans are identified. This standard has recently been merged into ISO/IEC 16326.</p>
+
<p>'''Abstract:''' This international standard specifies the required content of the project management plan (PMP). It also quotes the extracted purpose and outcome statements from the project processes of ISO/IEC 12207:2008 (IEEE Std 12207-2008) and ISO/IEC 15288:2008 (IEEE Std 15288-2008), and adds detailed guidance for managing projects that use these processes for software products and software-intensive systems.</p>
−
<h3>IEEE Std 1062-1998(R2002): Software Acquisition</h3>
+
<h3>IEEE Std 1062: Software Acquisition</h3>
 
<p>'''Abstract:''' This standard provides a set of useful quality practices for use during one or more steps in a software acquisition process. This recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, but is more suited for use on modified-off-the-shelf software and fully developed software.</p>
 
<p>'''Abstract:''' This standard provides a set of useful quality practices for use during one or more steps in a software acquisition process. This recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, but is more suited for use on modified-off-the-shelf software and fully developed software.</p>
−
<h3>IEEE Std 1063-2001(R2007): Software User Documentation</h3>
+
<h3>IEEE Std 1074: Developing a Software Project Life-cycle Process [Inactive]</h3>
−
<p>'''Abstract:''' This standard provides the minimum requirements for the structure, information content, and format of user documentation, including both printed and electronic documents used in the work environment by users of systems containing software. </p>
+
<p>'''Abstract:''' This standard provides a process for creating a software project lifecycle process (SPLCP). It is primarily directed at the process architect for a given software project. IEEE Std 1074 is unique in that it specifies, for any activity, what inputs are needed from previous activities, so that activities can be chained together. It also provides activities for ensuring that security is built in throughout the software lifecycle.</p>
−
<h3>IEEE Std 1074-2006: Developing a Software Project Life-cycle Process</h3>
+
<p>This standard requires selection of a user's software project lifecycle model (SPLCM) based on the organization's mission, vision, goals, and resources. It does not impose, define, or imply a particular software lifecycle model or methodology. </p>
−
<p>'''Abstract:''' This standard provides a process for creating a software project life-cycle process (SPLCP). It is primarily directed at the process architect for a given software project. IEEE Std 1074-2006 is unique in that it provides activities for ensuring building in security throughout the software life cycle.</p>
+
−
<p>IEEE Std 1074 is a standard for establishing the process to be used in a software development, maintenance, or other type of software project, including disposal/withdrawal of the product. This standard requires selection of a user’s software project life-cycle model (SPLCM) based on the organization’s mission, vision, goals, and resources. EIT does not impose, define, or imply a particular software life-cycle model or methodology. This standard describes the individual activities that are to be used within the selected model and provides examples of mapping them onto typical SPLCMs. </p>
+
 
<p>This standard may also be used to develop organizational processes to support software development and maintenance or to develop special, single-function processes within a project.</p>
 
<p>This standard may also be used to develop organizational processes to support software development and maintenance or to develop special, single-function processes within a project.</p>
−
<h3>IEEE Std 1233-1998(R2002): Developing System Requirements Specifications</h3>
+
<h3>IEEE Std 12207: Systems and Software Engineering—Software Life-cycle Processes</h3>
−
<p>'''Abstract:''' This standard provides guidance for the development of the set of requirements, system requirements specification (SyRS), to satisfy an expressed need. Developing an SyRS includes the identification, organization, presentation, and modification of the requirements. Also addressed are the conditions for incorporating operational concepts, design constraints, and design configuration requirements into the specification. This guide also covers the necessary characteristics and qualities of individual requirements and the set of all requirements.</p>
+
<p>'''Abstract:''' This international standard establishes a common framework for software lifecycle processes, with well-defined terminology, that can be referenced by the software industry. It applies to the acquisition of systems and software products and services, to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system, whether performed internally or externally to an organization. Those aspects of system definition needed to provide the context for software products and services are included. Software includes the software portion of firmware. This revision integrates ISO/IEC 12207 with its two amendments and was coordinated with the parallel revision of ISO/IEC 15288 (system lifecycle processes) to align structure, terms, and corresponding organizational and project processes. This standard may be used stand alone or jointly with ISO/IEC 15288, and supplies a process reference model that supports process capability assessment in accordance with ISO/IEC 15504-2 (process assessment). </p>
−
<h3>IEEE Std 1362-1998(R2007): Information Technology &mdash; System Definition &mdash; Concept of Operations (ConOps) Document</h3>
+
<h3>IEEE Std 14764: Standard for Software Engineering—Software Lifecycle Processes—Maintenance</h3>
−
<p>'''Abstract:''' The format and contents of a concept of operations (ConOps) document are described. A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users’ viewpoint. The ConOps document is used to communicate overall quantitative and qualitative system characteristics to the user, buyer, developer, and other organizational elements (for example, training, facilities, staffing, and maintenance). It is used to describe the user organizations, missions, and organizational objectives from an integrated systems point of view. </p>
+
−
<h3>IEEE Std 12207-2008: Systems and Software Engineering &mdash; Software Life-cycle Processes</h3>
+
−
<p>'''Abstract:''' This international standard establishes a common framework for software life-cycle processes, with well-defined terminology, that can be referenced by the software industry. It applies to the acquisition of systems and software products and services, to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system, whether performed internally or externally to an organization. Those aspects of system definition needed to provide the context for software products and services are included. Software includes the software portion of firmware. This revision 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. This standard may be used stand alone or jointly with ISO/IEC 15288, and supplies a process reference model that supports process capability assessment in accordance with ISO/IEC 15504-2 (process assessment). An annex provides support for IEEE users and describes relationships of this international standard to IEEE standards. </p>
+
−
<h3>IEEE Std 14143.1-2007: Information technology &mdash; software measurement &mdash; functional size measurement. Part 1: definition of concepts</h3>
+
−
<p>'''Abstract:''' This standard defines the concepts of functional size measurement (FSM). The concepts of FSM are designed to overcome the limitations of earlier methods of sizing software by shifting the focus away from measuring how the software is implemented to measuring size in terms of the functions required by the user. </p>
+
−
<h3>IEEE Std 14764-2006: Software Engineering &mdash; System Life-cycle Processes &mdash; Maintenance</h3>
+
 
<p>'''Abstract:''' The process for managing and executing software maintenance activities is described.</p>
 
<p>'''Abstract:''' The process for managing and executing software maintenance activities is described.</p>
−
<p>IEEE Std 14764:2006 describes in greater detail management of the maintenance process described in IEEE Std 12207, including amendments. It also establishes definitions for the various types of maintenance. IEEE Std 14764:2006 provides guidance that applies to planning, execution and control, review and evaluation, and closure of the maintenance process. The scope includes maintenance for multiple software products with the same maintenance resources. In IEEE Std 14764:2006, ''maintenance'' means software maintenance unless otherwise stated.</p>
+
<p>IEEE Std 14764 describes in greater detail the management of the maintenance process described in IEEE Std 12207, including amendments. It also establishes definitions for the various types of maintenance. IEEE Std 14764 provides guidance that applies to planning, execution and control, review and evaluation, and closure of the maintenance process. The scope includes maintenance for multiple software products with the same maintenance resources.</p>
−
<p>IEEE Std 14764:2006 provides the framework within which generic and specific software maintenance plans may be executed, evaluated, and tailored to the maintenance scope and magnitude of given software products. It provides the framework, precise terminology, and processes to allow the consistent application of technology (tools, techniques, and methods) to software maintenance.</p>
+
<p>IEEE Std 14764 provides guidance for the maintenance of software. The basis for the maintenance process and its activities comes from the definitions of IEEE Std 12207. It defines the activities and tasks of software maintenance, and provides maintenance planning requirements. It does not address the operation of software and the operational functions, such as backup, recovery, and system administration. </p>
−
<p>IEEE Std 14764:2006 provides guidance for the maintenance of software. The basis for the maintenance process and its activities comes from the definitions of IEEE Std 12207. It defines the activities and tasks of software maintenance, and provides maintenance planning requirements. It does not address the operation of software and the operational functions, such as backup, recovery, and system administration, which are normally performed by those who operate the software.</p>
+
<h3>ISO/IEC/IEEE Std 15288: Systems and Software Engineering—Software Life-cycle Processes</h3>
−
<p>IEEE Std 14764:2006 is written primarily for maintainers of software and additionally for those responsible for development and quality assurance. It may also be used by acquirers and users of systems containing software who may provide inputs to the maintenance plan. </p>
+
<p>'''Abstract:''' This international standard establishes a common process framework for describing the lifecycle of man-made systems. It defines a set of processes and associated terminology for the full lifecycle, including conception, development, production, utilization, support, and retirement. This standard also supports the definition, control, assessment, and improvement of these processes. These processes can be applied concurrently, iteratively, and recursively to a system and its elements throughout the lifecycle of a system.</p>
−
<h3>IEEE Std 15288-2008: Systems and Software Engineering &mdash; Software Life-cycle Processes</h3>
+
<h3>ISO/IEC/IEEE 29148: Systems and software engineering—Lifecycle processes—Requirements engineering </h3>
−
<p>'''Abstract:''' This international standard establishes a common process framework for describing the life cycle of man-made systems. It defines a set of processes and associated terminology for the full life cycle, including conception, development, production, utilization, support, and retirement. This standard also supports the definition, control, assessment, and improvement of these processes. These processes can be applied concurrently, iteratively, and recursively to a system and its elements throughout the life cycle of a system.</p>
+
<p>'''Abstract:''' This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998. ISO/IEC/IEEE 29148:2011 contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the lifecycle. It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes throughout the lifecycle.</p>
−
<h3>The IEEE Software Engineering Body of Knowledge (SWEBOK)</h3>
+
<h3>IEEE Software Engineering Body of Knowledge (SWEBOK)</h3>
−
<p>In this guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge for the field of software engineering, and the work partially fulfills the Society’s responsibility to promote the advancement of both theory and practice in this field. In so doing, the Society has been guided by the experience of disciplines with longer histories but was not bound either by their problems or their solutions.</p>
+
<p>In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge for the field of software engineering, and the work partially fulfills the society's responsibility to promote the advancement of both theory and practice in this field. </p>
−
<p>It should be noted that this guide does not purport to define the body of knowledge but rather to serve as a compendium and guide to the body of knowledge that has been developing and evolving over the past four decades. Furthermore, this body of knowledge is not static. The guide must, necessarily, develop and evolve as software engineering matures. Nevertheless, it constitutes a valuable element of the software engineering infrastructure. [[#Six|[6]]]</p>
+
<p>It should be noted that this Guide does not purport to define the body of knowledge, but rather to serve as a compendium and guide to the evolving body of knowledge that continues to develop. </p>
−
<p>The purpose of the ''Guide to the Software Engineering Body of Knowledge'' is to provide a consensually validated characterization of the bounds of the software engineering discipline and to provide a topical access to the body of knowledge supporting that discipline. The body of knowledge is subdivided into ten software engineering knowledge areas (KAs) plus an additional chapter providing an overview of the KAs of strongly related disciplines. The descriptions of the KAs are designed to discriminate among the various important concepts, permitting readers to find their way quickly to subjects of interest. Upon finding a subject, readers are referred to key papers or book chapters selected because they succinctly present the knowledge.</p>
+
<p>The body of knowledge is subdivided into ten software engineering knowledge areas (KAs) plus an additional chapter providing an overview of the KAs of strongly related disciplines. </p>
−
<p>This guide is oriented toward a variety of audiences, all over the world. It serves public and private organizations in need of a consistent view of software engineering for defining education and training requirements, classifying jobs, developing performance evaluation policies, or specifying software development tasks. It also addresses practicing, or managing, software engineers and the officials responsible for making public policy regarding licensing and professional guidelines. In addition, professional societies and educators defining the certification rules, accreditation policies for university curricula, and guidelines for professional practice benefit from SWEBOK, as well as the students learning the software engineering profession and educators and trainers engaged in defining curricula and course content. [[#Seven|[7]]]</p>
+
 
<h2>References</h2>
 
<h2>References</h2>
 
<div id="One"></div><p>[1] This set is available from IEEE on the ''Essentials'' CD. </p>
 
<div id="One"></div><p>[1] This set is available from IEEE on the ''Essentials'' CD. </p>
−
<div id="Two"></div><p>[2] Guide to SWEBOK 2004. 2.1.</p>
 
−
<div id="Three"></div><p>[3] Guide to SWEBOK 2004. 2.1.1.</p>
 
−
<div id="Four"></div><p>[4] Guide to SWEBOK 2004. 5.2.2.</p>
 
−
<div id="Five"></div><p>[5] Guide to SWEBOK 2004. 5.2.1.</p>
 
−
<div id="Six"></div><p>[6] Guide to SWEBOK 2004. Foreword.</p>
 
−
<div id="Seven"></div><p>[7] Guide to SWEBOK 2004. Preface.</p>
 

Latest revision as of 02:33, 23 December 2017

Welcome to the initial version of the EITBOK wiki. Like all wikis, it is a work in progress and may contain errors. We welcome feedback, edits, and real-world examples. Click here for instructions about how to send us feedback.
Ieee logo 1.png
Acm logo 3.png

 

1 Purpose of this Standards Guide

This standards guide is designed for software producers, as well as producers of systems with embedded software. The purpose of this guide is to help informatics practitioners ensure that developed and deployed systems and software have the following characteristics:

  • They can be and are verified and validated.
  • They meet the purpose for which they are intended.
  • They are robust, reliable, and resilient enough to consistently perform to their intended use.

IEEE system and software engineering standards are as critical to industry as they have been to space exploration. This guide introduces you to the core subset of the Software and Systems Engineering Standards Committee (S2ESC) portfolio of standards.

1.1 Value of System and Software Standards to Industry

The aggressive transition to technology-based information is successful only if software and software-intensive systems—which encompass myriad products and processes in complex ways—seamlessly collect, aggregate, share, analyze, and present dynamic information in a timely manner.

For example, the anticipated human and economic benefits from the present rapid transition to health information technologies demand that software and systems developers of medical devices, digital medical records, and administrative, financial, and regulatory systems (e.g., public health, service/healthcare providers, and payers) design, develop, and deliver interoperable products, processes, and services that are safe, secure, reliable, and robust.

The application of IEEE standards helps software producers by simplifying product development processes, avoiding the pitfalls that have overcome many software projects, and thus reduces non-value-adding efforts and costs. Adoption and implementation of the core software and systems engineering standards across companies that produce or tailor information systems and devices increases their development organization's ability to deliver robust software in shorter time frames. Even more important, the consistent use of these IEEE standards lowers the risks of delivering faulty products.

Standards for software and systems engineering encompasses the full software and systems lifecycles, from concept and development to delivery and maintenance, and even the reuse of software components.

1.2 Standards Essential to Informatics Technology Producers

Ensuring that delivered software meets its purpose and consistently performs to its intended use is vital to effective information delivery. As fundamental building blocks for international systems and software development, IEEE software and systems engineering standards helps producers ensure interconnectivity, interoperability, and verification of new informatics products and systems enabling the rapid implementation and trusted use of medical technologies.

The essential set [1] of IEEE standards that are key to the development and delivery of robust software and systems are listed in the table below.

Number Official Designation Name
730IEEE Std 730 IEEE Standard for Software Quality Assurance Plans
828 IEEE Std 828 IEEE Standard for Software Configuration Management
830 IEEE Std 830 IEEE Recommended Practice for Software Requirements Specifications. This standard was contributed to ISO and is now replaced by ISO/IEC/IEEE 29148.
1008 IEEE Std 1008 IEEE Standard for Software Unit Testing. This standard was contributed to ISO and is now replaced by ISO/IEC/IEEE 29119-4.
1012 IEEE Std 1012 IEEE Standard for System and Software Verification and Validation
1016 IEEE Std 1016IEEE Recommended Practice for Software Design Descriptions
1028IEEE Std 1028 IEEE Standard for Software Reviews and Audits
1058 IEEE Std 1058 IEEE Standard for Software Project Management Plans. This standard is inactive, but contributed to ISO/IEC/16326.
1063 IEEE Std 1063 IEEE Standard for Software User Documentation. This standard was contributed to ISO and is now superseded by ISO/IEC/IEEE 26514 Systems and Software Engineering—Requirements for designers and developers of user documentation.
1074 IEEE Std 1074 IEEE Standard for Developing a Software Project Life-cycle Process. This standard was contributed to ISO. It has not been superseded, but ISO/IEC/IEEE 24774 presents guidelines for the elements used most frequently in describing a process: the title, purpose, outcomes, activities, task and information item
12207 ISO/IEC/IEEE 12207 Systems and Software Engineering—life-cycle processes
14764 IEEE Std 14764 Software Engineering—System Life-cycle Processes—Maintenance
15288 ISO/IEC/IEEE 15288 Systems and Software Engineering—Systems life-cycle processes
12207 ISO/IEC/IEEE 20000-1 Information Technology—Service management—Part 1: Service Management System requirements

Additional important standards are listed in the table below.

NumberOfficial DesignationName
829IEEE Std 829IEEE Standard for Software and System Test Documentation was contributed to ISO and is superseded by ISO/IEC/IEEE 29119-3
1044IEEE Std 1044IEEE Standard Classification for Software Anomalies
1062IEEE Std 1062IEEE Recommended Practice for Software Acquisition
1233IEEE Std 1233IEEE Guide for Developing System Requirements Specifications was contributed to ISO and is superseded by ISO/IEC/IEEE 29148
1362IEEE Std 1362IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document was contributed to ISO and superseded by ISO/IEC/IEEE 29148
15939ISO/IEC/IEEE Std 15939Systems and Software Engineering—Measurement Process

2 Short Descriptions of a Sampling of the Standards

Note that many EIT-relevant standards can be downloaded for free at http://standards.iso.org/ittf/PubliclyAvailableStandards.

2.1 IEEE Std 730: Software Quality Assurance Plans

Abstract: The standard specifies the format and content of software quality-assurance plans. It meets the IEEE/EIA 12207.1 requirements for such plans.

The SQA plan defines the means to ensure that software developed for a specific product satisfies user requirements and is of the highest quality possible within project constraints. To do so, it must first ensure that the quality target is clearly defined and understood. It must consider management, development, and maintenance plans for the software.

2.2 IEEE Std 828: Software Configuration Management

Abstract: This standard explains CM, including identifying and acquiring configuration items, controlling changes, reporting the status of configuration items, as well as software builds and release engineering. It addresses what CM activities are to be done, when they are to happen in the lifecycle, and what planning and resources are required. It also describes the content areas for a CM plan. The standard supports ISO/IEC/IEEE 12207:2008 and ISO/IEC/IEEE 15288:2008 and adheres to the terminology in ISO/IEC/IEEE Std 24765 and the information item requirements of IEEE Std 15939.

2.3 IEEE Std 1012: System and Software Verification and Validation

Abstract: Software verification and validation (V&V) processes determine whether the development products of a given activity conform to the requirements of that activity and whether the software satisfies its intended use and user needs. Software V&V lifecycle process requirements are specified for different software integrity levels. The scope of V&V processes encompasses software-based systems, computer software, hardware, and interfaces. This standard applies to software being developed, maintained, or reused (legacy, commercial off-the-shelf (COTS), non-developmental items). The term software also includes firmware, microcode, and documentation. Software V&V processes include analysis, evaluation, review, inspection, assessment, and testing of software products.

2.4 IEEE Std 1016: Software Design Descriptions

Abstract: The necessary information content and recommendations for an organization for software design descriptions (SDDs) are described. An SDD is a representation of a software system that is used as a medium for communicating software design information. This recommended practice is applicable to paper documents, automated databases, design description languages, and other means of description.

2.5 IEEE Std 1028: Software Reviews and Audits

Abstract: Five types of software reviews and audits, together with procedures required for the execution of each type, are defined in this standard. This standard is concerned only with the reviews and audits; procedures for determining the necessity of a review or audit are not defined, and the disposition of the results of the review or audit is not specified. Types included are management reviews, technical reviews, inspections, walk-throughs, and audits.

2.6 IEEE Std 1044: Classification for Software Anomalies

Abstract: A uniform approach to the classification of anomalies found in software and its documentation is provided. The processing of anomalies discovered during any software lifecycle phase are described, and comprehensive lists of software anomaly classifications and related data items that are helpful to identify and track anomalies are provided. This standard is not intended to define procedural or format requirements for using the classification scheme. It identifies some classification measures but does not attempt to define all the data supporting the analysis of an anomaly.

2.7 IEEE Std 1058/ISO/IEC/IEEE 16326: Software Project Management

Abstract: This international standard specifies the required content of the project management plan (PMP). It also quotes the extracted purpose and outcome statements from the project processes of ISO/IEC 12207:2008 (IEEE Std 12207-2008) and ISO/IEC 15288:2008 (IEEE Std 15288-2008), and adds detailed guidance for managing projects that use these processes for software products and software-intensive systems.

2.8 IEEE Std 1062: Software Acquisition

Abstract: This standard provides a set of useful quality practices for use during one or more steps in a software acquisition process. This recommended practice can be applied to software that runs on any computer system regardless of the size, complexity, or criticality of the software, but is more suited for use on modified-off-the-shelf software and fully developed software.

2.9 IEEE Std 1074: Developing a Software Project Life-cycle Process [Inactive]

Abstract: This standard provides a process for creating a software project lifecycle process (SPLCP). It is primarily directed at the process architect for a given software project. IEEE Std 1074 is unique in that it specifies, for any activity, what inputs are needed from previous activities, so that activities can be chained together. It also provides activities for ensuring that security is built in throughout the software lifecycle.

This standard requires selection of a user's software project lifecycle model (SPLCM) based on the organization's mission, vision, goals, and resources. It does not impose, define, or imply a particular software lifecycle model or methodology.

This standard may also be used to develop organizational processes to support software development and maintenance or to develop special, single-function processes within a project.

2.10 IEEE Std 12207: Systems and Software Engineering—Software Life-cycle Processes

Abstract: This international standard establishes a common framework for software lifecycle processes, with well-defined terminology, that can be referenced by the software industry. It applies to the acquisition of systems and software products and services, to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system, whether performed internally or externally to an organization. Those aspects of system definition needed to provide the context for software products and services are included. Software includes the software portion of firmware. This revision integrates ISO/IEC 12207 with its two amendments and was coordinated with the parallel revision of ISO/IEC 15288 (system lifecycle processes) to align structure, terms, and corresponding organizational and project processes. This standard may be used stand alone or jointly with ISO/IEC 15288, and supplies a process reference model that supports process capability assessment in accordance with ISO/IEC 15504-2 (process assessment).

2.11 IEEE Std 14764: Standard for Software Engineering—Software Lifecycle Processes—Maintenance

Abstract: The process for managing and executing software maintenance activities is described.

IEEE Std 14764 describes in greater detail the management of the maintenance process described in IEEE Std 12207, including amendments. It also establishes definitions for the various types of maintenance. IEEE Std 14764 provides guidance that applies to planning, execution and control, review and evaluation, and closure of the maintenance process. The scope includes maintenance for multiple software products with the same maintenance resources.

IEEE Std 14764 provides guidance for the maintenance of software. The basis for the maintenance process and its activities comes from the definitions of IEEE Std 12207. It defines the activities and tasks of software maintenance, and provides maintenance planning requirements. It does not address the operation of software and the operational functions, such as backup, recovery, and system administration.

2.12 ISO/IEC/IEEE Std 15288: Systems and Software Engineering—Software Life-cycle Processes

Abstract: This international standard establishes a common process framework for describing the lifecycle of man-made systems. It defines a set of processes and associated terminology for the full lifecycle, including conception, development, production, utilization, support, and retirement. This standard also supports the definition, control, assessment, and improvement of these processes. These processes can be applied concurrently, iteratively, and recursively to a system and its elements throughout the lifecycle of a system.

2.13 ISO/IEC/IEEE 29148: Systems and software engineering—Lifecycle processes—Requirements engineering

Abstract: This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998. ISO/IEC/IEEE 29148:2011 contains provisions for the processes and products related to the engineering of requirements for systems and software products and services throughout the lifecycle. It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and recursive application of requirements processes throughout the lifecycle.

2.14 IEEE Software Engineering Body of Knowledge (SWEBOK)

In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge for the field of software engineering, and the work partially fulfills the society's responsibility to promote the advancement of both theory and practice in this field.

It should be noted that this Guide does not purport to define the body of knowledge, but rather to serve as a compendium and guide to the evolving body of knowledge that continues to develop.

The body of knowledge is subdivided into ten software engineering knowledge areas (KAs) plus an additional chapter providing an overview of the KAs of strongly related disciplines.

3 References

[1] This set is available from IEEE on the Essentials CD.

Retrieved from "http://eitbokwiki.org/index.php?title=Key_Standards&oldid=1930"