Friday, August 1, 2008

IEEE Software Engineering Standards Useful for Certification exams

IEEE Software Engineering Standards

IEEE: Institute of Electrical and Electronics Engineers

A transnational organization founded in 1884, IEEE consists of dozens of specialized societies within geographical regions throughout the world. Software testing standards are developed within the technical committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board.

These standards are created through a process of obtaining the consensus of practicing professionals. This consensus process, which includes careful discussion and debate among members of the various committees who serve voluntarily, is one of the fundamental themes of the standards process. Another key theme is to provide standards in a timely manner, from project approval to standard approval is approximately 3 years.

The following standards are those a tester should be aware of, and include a short abstract about each one:

610.12-1990: IEEE Standard Glossary of Software Engineering Terminology

Topics covered include addressing; assembling, compiling, linking, loading, computer performance evaluation, configuration management, data types; errors, faults, and failures; evaluation techniques; instruction types; language types; libraries; microprogramming; operating systems; quality attributes; software documentation; software and system testing; software architectures; software development process; software development techniques; and software tools. This standard promotes clarity and consistency in the vocabulary of software engineering and associated fields.


730-1998: IEEE Standard for Software Quality Assurance Plans

The purpose of this standard is to provide uniform, minimum acceptable requirements for preparation and content of SQAPs (Software Quality Assurance Plans).

The plan includes the following sections:

Purpose: Defines purpose and scope

Reference Documents: Complete list of documents referenced within SQAP

Management: Describes organization, tasks, responsibilities

Documentation:Identifies the documentation governing development, verification and validation, use, and maintenance of the software.

Documents include: Software Requirements Specification (SRS), Software Design Description (SDD), Software Verification and Validation Plan (SVVP), Software Verification and Validation Report (SVVR), User documentation, Software Configuration Management Plan (SCMP), Software Development Plan, Standards and procedures manual, software project management plan, software maintenance manual.

Standards, practices, conventions, and metrics: Identifies the standards, practices, conventions and metrics to be applied, and states how compliance with these items is to be monitored and assured.

Reviews and audits: Defines the technical and managerial reviews and audits to be conducted, states how the reviews and audits are to be accomplished, and states what further actions are required and how they are to be implemented and verified.

Test: Identifies all the tests not included in the SVVP for the software covered by the SQAP and states what methods are to be used.

Problem reporting and corrective action: Describes the practices and procedures to be followed for reporting, tracking, and resolving problems identified in both software items and the software development and maintenance process

Tools, techniques, and methodologies: Identifies the special software tools, techniques, and methodologies that support SQA, state their purposes, and describe their use.

Code control: Defines the methods and facilities used to maintain, store, secure, and document controlled versions of the identified software during all phases of the software life cycle.

Media control: Identifies the media for each computer product and the documentation required to store the media, including the copy and restore process, and protects the computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle.

Supplier control: States the provisions for assuring that software provided by suppliers meets established requirements. Also states the methods that will be used to assure that the software supplier receives adequate and complete requirements. This section also states the methods to be employed to assure that the developers comply with the requirements of this standard.

Records collection, maintenance, and retention: Identifies the SQA documentation to be retained; states the methods and facilities to be used to assemble, safeguard, and maintain this documentation, and designates the retention period.

Training: Identifies the training activities necessary to meet the needs of the SQAP

Risk management: Specifies the methods and procedures employed to identify, assess, monitor, and control areas of risk arising during the portion of the software life cycle covered by the SQAP.

828-1998: IEEE Standard for Software Configuration Management Plans

This standard establishes the minimum required contents of a software configuration (SCM) plan. It is supplemented by 1042-1987 (which provides approaches to good software configuration management planning). This standard applies to the entire life cycle of critical software. The plan documents what SCM activities are to be done, how they are to be done, who is responsible for doing specific activities, when they are to happen, and what resources are required.

829-1998: IEEE Standard for Software Test Documentation

This standard describes a set of basic test documents that are associated with the dynamic aspects of software testing. The standard defines the purpose, outline, and content of each basic document. Documents included:

§ Test Plan

§ Test Design Specification

§ Test Case Specification

§ Test Procedure Specification

§ Test Item Transmittal Report (a document identifying test items)

§ Test Log

§ Test Incident Report

§ Test Summary Report

830-1998: IEEE Recommended Practice for Software Requirements Specifications

This standard describes the recommended approaches for the specification of software requirements. It describes the content and qualities of a good software requirements specification (SRS), and includes several sample SRS outlines.

1008-1987 (R1993): IEEE Standard for Software Unit Testing (ANSI)

This standard defines an integrated approach to systematic and documented unit testing. The approach uses unit design and unit implementation information, in addition to unit requirements, to determine the completeness of the testing. The standard describes a testing process composed of a hierarchy of phases, activities, and tasks. Further, it defines a minimum set of tasks for each activity, although additional tasks may be added to any activity.

1012-1998: IEEE Standard for Software Verification and Validation

The purpose of this standard is to:

1. Establish a common framework for V&V processes, activities, and tasks in support of all software life cycle processes, including acquisition, supply, development, operation, and maintenance processes.

2. Define the V&V tasks, required inputs, and required outputs

3. Identify the minimum V&V tasks corresponding to software integrity levels using a four-level scheme

4. Define the content of a software V&V Plan (SVVP)

1012a-1998: IEEE Standard for Software Verification and Validation (Supplement to 1012-1998 – Content Map to IEEE 12207.1)

The 2 requirements (1012 and 12207.1) place requirements on plans for verification of software and validation of software. The purpose of this annex is to explain the relationship between the two sets of requirements, so that users producing documents intended to comply with both standards may do so.

1016-1998: IEEE Recommended Practice for Software Design Descriptions

This is a recommended practice for describing software designs. It specifies the necessary information content, and recommended organization for a Software Design Description (SDD). An SDD is a representation of a software system that is used as a medium for communicating software design information.

1028-1997: IEEE Standard for Software Reviews

The purpose of this standard is to define systematic reviews applicable to software acquisition, supply, development, operation, and maintenance. This standard describes how to carry out a review. Other standards or local management define the context within which a review is performed, and the use made of the results of the review. Software reviews can be used in support of the objectives of project management, system engineering, verification and validation, configuration management, and QA. Different types of reviews reflect differences in the goals of each review type. Systematic reviews are described by their defined procedures, scope, and objectives.

1044-1993: IEEE Standard Classification for Software Anomalies (ANSI)

(Anomaly: any condition that departs from the expected. The expectation can come from documentation or someone’s perceptions or experiences). The methodology of this standard is based on a process (sequence of steps) that pursues a logical progression from the initial recognition of an anomaly to its final disposition. Each step interrelates with and supports the other steps.

1045-1992: IEEE Standard for Software Productivity Metrics (ANSI)

This standard describes the data collection process and calculations for measuring software productivity.

1058-1998: IEEE Standard for Software Project Management Plans

This standard prescribes the format and content of Software Project Management Plans (SPMPs). An SPMP is the controlling document for managing a software project; it defines the technical and managerial processes necessary to develop software work products that satisfy the product requirements.

1058.1-1987(R1993): IEEE Standard for Software Project Management Plans (ANSI)

Explains the relationship between 1058 standard and 12207.1 standard, so that users producing documents intended to comply with both standards may do so.

1061-1998: IEEE Standard for Software Quality Metrics Methodology

Scope: Provides a methodology for establishing quality requirements and identifying, implementing, analyzing, and validating process and product software quality metrics. This methodology applies to all software at all phases of any software life cycle.

Framework: Software Quality is the degree to which Software possesses a desired combination of quality attributes. The purpose of Software Metrics is to make assessments throughout the Software Life cycle as to whether the Software Quality requirements are being met. The use of software metrics reduces subjectivity in the assessment and control of software quality by providing a quantitative basis for making decisions about software quality. However the use of Software Metrics does not eliminate the need for human judgment in Software assessments. The use of software metrics within an organization or project is expected to have a beneficial effect by making software quality more visible.

Other External Standards

The use of standards simplifies communication, promotes consistency and uniformity, and eliminates the need to invent yet another (often different and even incompatible) solution to the same problem. Standards, whether ‘official’ or merely agreed upon, are especially important when we’re talking to customers and suppliers, but it’s easy to underestimate their importance when dealing with different departments and disciplines within an organization. They also provide vital continuity so that we are within our own organization. They also provide vital continuity so that we are not forever reinventing the wheel. They are a way of preserving proven practices above and beyond the inevitable staff changes within organizations.

Some standards are particularly important to the testing practitioner. They can provide a benchmark for writing documents like requirements, so that testers and others doing verification have a framework for what they can expect to find. More specifically, standards tell us what to put into key test documents, such as a test plan.

Standards are not only practical from the development point of view, but they are increasingly the basis for contracts and therefore also, when things go wrong, for litigation. One of the issues that arise in litigation is whether the software was developed according to known standards that are prevalent in the industry today. This means we need to know not only what the standards are, but to also see that they are applied.

ISO – International Organization for Standards

ISO 9000: addresses the quality management system of an organization.

ISO 9001: the base international standard for quality management

ISO 9000-3: Guidebook on how ISO 9000 applies to software.

TickIt: UK scheme for certifying organizations producing software according to ISO 9001.

SPICESoftware Process Improvement and Capability Determination

WG10: Software Process Assessment working group for the ISO. SPICE was created to develop a suite of related standards and guidebooks. The purpose is to create a consistent standard for software process assessment that can be used by different nations and different sectors. The SEI (Software Engineering Institute) has worked closely with this group, including providing the CMM (Capability Maturity Model) as input to the effort.

NIST – National Institute of Standards and Technology

A non-regulatory federal agency within the Commerce Department’s Technology Administration. NIST's mission is to promote economic growth by working with industry to develop and apply technology, measurements, and standards. NIST carries out its mission through four interwoven programs: NIST Laboratories, Baldrige National Quality Program, Manufacturing Extension Partnership, and Advanced Technology Program. NIST programs are helping improve the quality and capabilities of software used by businesses, research institutions, and consumers. As a result of our programs (described below), many software packages are more efficient and can exchange data with each other. More info at: http://www.nist.gov/

DoD – Department of Defense

As the DoD Executive Agent for Information Standards, CFS (Center for Standards) influences, adopts, develops, promulgates, and maintains standards for OSD, CINCs, Services, Agencies and the international defense community. CFS leads DoD's IT standards activities, performs interoperability assessments, and facilitates the interoperability of customer IT systems.

GOALS

  • Identify, consolidate, and coordinate requirements for information technology standards.
  • Advocate DoD requirements in standards bodies to permit DoD adoption of commercial standards versus development of military standards.
  • Actively pursue forming partnerships with technology providers to promote timely delivery of products supporting approved standards.
  • Develop a framework and provide guidance for applying information technology standards through updating and publishing the Joint Technical Architecture (JTA).
  • Automate processes to the greatest extent possible in all standardization efforts to expedite development and coordination of standards and guidance.
  • Facilitate their use by program managers and engineers.

No comments: