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.