Welcome to our new site version. Your web page bookmarks may have changed, please search for pages by title to update them. Having problems ? Please try clearing your web browser cache and hard-reloading your web page first before contacting our webmaster.

software development

IEEE Std 1209-1992 - IEEE Recommended Practice for the Evaluation and Selection of CASE Tools [Draft]

Body

From IEEE Software Engineering Standards Collection:

This recommended practice provides individuals and organisations a process for the evaluation and selection of computer-aided software engineering (CASE) tools. The recommended practice addresses the evaluation and selection of tools supporting software engineering processes including project management processes, development processes and integral processes.

IEEE Std 1074 - IEEE Standard for Developing a Software Project Life Cycle Process

Body

From IEEE Software Engineering Standards Collection:

IEEE Std 1074. This standard defines the set of activities that constitute the processes that are mandatory for the development and maintenance of software. The management and support processes that continue throughout the entire life cycle, as well as all aspects of the software life cycle from concept exploration through retirement, are covered. Associated input and output information is also provided. Utilisation of the processes and their component activities maximises the benefits to the user when the use of this standard is initiated early in the software life cycle. This standard requires definition of a user’s software life cycle and shows its mapping into typical software life cycles. It is not intended to define or imply a software life cycle of its own.

Defined by

IEEE Std 982.1 - IEEE Standard Dictionary of Measures to Produce Reliable Software

Body

From IEEE Software Engineering Standards Collection:

IEEE Std 982.1. This standard provides definitions of selected measures. The measures are intended for use throughout the software development life cycle in order to produce reliable software. The standard does not specify or require the use of any of the measures. Its intent is to describe the individual measures and their use.

Defined by

MIL-STD-498 - Software development and documentation

Body

List of Data Item Descriptions (DIDs):

Defined by
Defining documents
Document title Document identifier Document date File size File
MIL-STD-498 - Software development and documentation (PDF) MIL-STD-498 667.77 KB   DOWNLOAD!

MIL-STD-498 (Military-Standard-498) was a United States military standard whose purpose was to "establish uniform requirements for software development and documentation." It was released Nov. 8, 1994, and replaced DOD-STD-2167A, DOD-STD-7935A, and DOD-STD-1703. It was meant as an interim standard, to be in effect for about two years until a commercial standard was developed.

,

[...]
it was cancelled on May 27, 1998 and replaced by J-STD-016 and IEEE 12207.
[...]

,

A key component of the standard is 22 Data Item Descriptions (DIDs). Each DID generically describes the required content of a data item, a "document" that describes the software or some aspect of the software life-cycle. These documents could take many forms, from source code, to installation scripts, to various electronic and paper reports, and the contracting party (e.g., the government) is encouraged to specify acceptable formats. The set of data item descriptions, once tailored for a specific contract, then become Contract Data Requirement List items ("CDRLs") that represent the deliverable items of a contract. Depending on the nature of the project, not all data items may be required.

The terms "DOD-STD-2167" and "DOD-STD-2168" (often mistakenly referred to as "MIL-STD-2167" and "MIL-STD-2168" respectively) are the official specification numbers for superseded U.S. DoD military standards describing documents and procedures required for developing military computer systems. (These specifications were superseded by MIL-STD-498 in 1994). Specifically:

* DOD-STD-2167 described the necessary project documentation to be delivered when developing a computer software system using the waterfall model

* DOD-STD-2168 was the DoD's software quality assurance standard, titled "Defense System Software Quality Program".

On December 5th, 1994, the standards DOD-STD-2167A and DOD-STD-2168 were superseded by MIL-STD-498, and that document merged DOD-STD-2167A, DOD-STD-7935A, and DOD-STD-2168 into a single document, and incorporated changes to address vendor criticisms.

IDEF4 Object-Oriented Design

Defined by
Defining documents
Document title Document identifier Document date File size File
Information Integration for Concurrent Engineering (IICE) IDEF4 Object-Oriented Design Method Report WPAFB OH 45433-6573 1.6 MB   DOWNLOAD!

IDEF4, officially named Integrated DEFinition for Object-Oriented Design, is an object-oriented design modeling language for the design of component-based client/server systems. It has been designed to support smooth transition from the application domain and requirements analysis models to the design and to actual source code generation. It specifies design objects with sufficient detail to enable source code generation.

This method is part of the IDEF family of modeling languages in the field of systems and software engineering.

The IDEF3 method provides modes to represent both

  • Process Flow Descriptions to capture the relationships between actions within the context of a specific scenario, and
  • Object State Transition to capture the description of the allowable states and conditions.

This method is part of the IDEF family of modeling languages in the field of systems and software engineering.

,

IDEF4 method is a graphically oriented methodology for the design of object oriented software systems. The object oriented programming paradigm provides the developer with an abstract view of his program as composed of a set of state maintaining objects which define the behavior of the program by the protocol of their interactions. An object consists of a set of local state defining attributes and a set of methods (procedures) that define the behavior of that particular object and its relationship to the other objects that make up the system.

,

The development of IDEF4 came from the recognition that the modularity, maintainability and code reusability that results from the object oriented programming paradigm can be realized in traditional data processing applications. The proven ability of the object oriented programming paradigm to support data level integration in large complex distributed systems is also a major factor in the widespread interest in this technology from the traditional data processing community.

,

IDEF4 was developed as a design tool for software designers who use object-oriented languages such as the Common LISP Object System, Flavors, C++, SmallTalk, Objective C and others. Since effective usage of the object-oriented paradigm requires a different thought process than used with conventional procedural or database languages, standard methodologies such as structure charts, data flow diagrams, and traditional data design models (hierarchical, relational, and network) are not sufficient. IDEF4 seeks to provide the necessary facilities to support the object-oriented design decision making process.

ISO/IEC 12207 - Software Lifecycle Processes

Defined by
Document title Sort descending Document identifier Document date File size File
ISO/IEC 12207 SW LC Processes - 12207 Description UNKNOWN 77.63 KB   DOWNLOAD!
ISO/IEC 12207 SW LC Processes - 12207 Tutorial 1999-04-26 793.5 KB   DOWNLOAD!

ISO 12207 is an ISO standard for software lifecycle processes. It aims to be 'the' standard that defines all the tasks required for developing and maintaining software.

The ISO 12207 standard establishes a process of lifecycle for software, including processes and activities applied during the acquisition and configuration of the services of the system. Each Process has a set of outcomes associated with it. There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes (the new "ISO/IEC 12207:2008 Systems and software engineering -- Software life cycle processes" defines 43 system and software processes).

The standard has the main objective of supplying a common structure so that the buyers, suppliers, developers, maintainers, operators, managers and technicians involved with the software development use a common language. This common language is established in the form of well defined processes. The structure of the standard was intended to be conceived in a flexible, modular way so as to be adaptable to the necessities of whoever uses it. The standard is based on two basic principles: modularity and responsibility. Modularity means processes with minimum coupling and maximum cohesion. Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved.

The set of processes, activities and tasks can be adapted according to the software project. These processes are classified in three types: basic, for support and organizational. The support and organizational processes must exist independently of the organization and the project being executed. The basic processes are instantiated according to the situation.

Software Assurance Technology Center (SATC)

Body

From http://satc.gsfc.nasa.gov/:

The Software Assurance Technology Center (SATC) was established in 1992 as part of the Systems Reliability and Safety Office at NASA Goddard Space Flight Center (GSFC). The SATC was founded with the intent to become a center of excellence in software assurance, dedicated to making measurable improvement in both the quality and reliability of software developed for NASA at GSFC. SATC is self-supported with internal funding coming from research and application of current software engineering techniques and tools. Research funding primarily originates at NASA headquarters and is administered by it's Software IV&V Facility in Fairmont, WV. Other support comes directly from development projects for direct collaboration and technical support.

Systems and Software Consortium, Inc (SSCI)

Body

From Transition Organization
Systems and Software Consortium, Inc (SSCI)
:

Systems and Software Consortium, Inc (SSCI) (previously Software Productivity Consortium), a non-profit organization of more than 100 companies, government agencies, and universities, develops processes, methods, tools, and supporting services that help its members and affiliates to build high-integrity, software-intensive systems. Consortium products and services support the entire development lifecycle, from requirements analysis and systems design through component-based development, automated testing, and the integration of object-oriented and commercial off-the-shelf (COTS) technologies.

The Consortium program integrates systems and software process improvement and measurement activities with proven lifecycle development and management methods for systems and software engineering. We are the leading providers of CMM®- and CMMISM-based assessments and evaluations of software and systems engineering maturity, and increasingly help our members to leverage their investments in these frameworks to also comply with ISO, Six Sigma, and other quality guidelines.

The Consortium’s measurement products and services provide guidance and support to organizations involved in measurement programs at all levels of process maturity. From the initial stages of defining and collecting cost and schedule metrics to the establishment of a quantitative management and ROI assessment program, the Consortium can provide technologies, training, and consulting expertise to help organizations achieve business objectives through a robust measurement program.

ISO 9000

Body

From ISO 9000 essentials:

The ISO 9000 family of standards represents an international consensus on good quality management practices. It consists of standards and guidelines relating to quality management systems and related supporting standards.

ISO 9001:2008 is the standard that provides a set of standardized requirements for a quality management system, regardless of what the user organization does, its size, or whether it is in the private, or public sector. It is the only standard in the family against which organizations can be certified – although certification is not a compulsory requirement of the standard.

The other standards in the family cover specific aspects such as fundamentals and vocabulary, performance improvements, documentation, training, and financial and economic aspects.

From Wikipedia: ISO 9000:

ISO 9000 is a family of standards for quality management systems. ISO 9000 is maintained by ISO, the International Organization for Standardization and is administered by accreditation and certification bodies. The rules are updated, as the requirements motivate changes over time.

Some of the requirements in ISO 9001:2008 (which is one of the standards in the ISO 9000 family) include

* a set of procedures that cover all key processes in the business;
* monitoring processes to ensure they are effective;
* keeping adequate records;
* checking output for defects, with appropriate and corrective action where necessary;
* regularly reviewing individual processes and the quality system itself for effectiveness; and
* facilitating continual improvement

A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is "ISO 9001 certified" or "ISO 9001 registered". Certification to an ISO 9001 standard does not guarantee any quality of end products and services; rather, it certifies that formalized business processes are being applied.

Although the standards originated in manufacturing, they are now employed across several types of organizations. A "product", in ISO vocabulary, can mean a physical object, services, or software.

DOD-STD-2167 - Defense Systems Software Development

Defined by
Document title Sort descending Document identifier Document date File size File
DOD-STD-2167 DOD-STD-2167 1985-06-04 none
Defining documents
Document title Document identifier Document date File size File
DOD-STD-2167 DOD-STD-2167 none

DOD-STD-2167A (Department of Defense Standard 2167A), titled "Defense Systems Software Development", was a United States defense standard, published on February 29, 1988, which updated the less well known DOD-STD-2167 published 4 June 1985. This document established "uniform requirements for the software development that are applicable throughout the system life cycle." It was designed to be used with MIL-STD-2168, "Defense System Software Quality Program".

On December 5th, 1994 it was superseded by MIL-STD-498, which merged DOD-STD-2167A, DOD-STD-7935A, and DOD-STD-2168 into a single document, and addressed some vendor criticisms.

The terms "DOD-STD-2167" and "DOD-STD-2168" (often mistakenly referred to as "MIL-STD-2167" and "MIL-STD-2168" respectively) are the official specification numbers for superseded U.S. DoD military standards describing documents and procedures required for developing military computer systems. (These specifications were superseded by MIL-STD-498 in 1994). Specifically:

* DOD-STD-2167 described the necessary project documentation to be delivered when developing a computer software system using the waterfall model

* DOD-STD-2168 was the DoD's software quality assurance standard, titled "Defense System Software Quality Program".

On December 5th, 1994, the standards DOD-STD-2167A and DOD-STD-2168 were superseded by MIL-STD-498, and that document merged DOD-STD-2167A, DOD-STD-7935A, and DOD-STD-2168 into a single document, and incorporated changes to address vendor criticisms.