Software Engineering Management Knowledge Area

While it is true to say that in one sense it should be possible to manage software engineering in the same way as any other (complex) process, there are aspects particular to software products and the software engineering process that complicate effective management. There are three sub-areas for software engineering management.

The first is organizational management, comprising policy management, personnel management, communication management, portfolio management and procurement management.

The second sub-area is process/project management, including initiation and scope definition, planning, enactment, review and evaluation and closure.

The third and last sub-area is software engineering measurement, where general principles about software measurement are covered. The first topics presented are the goals of a measurement program, followed by measurement selection, measuring software and its development, collection of data, and software metric models.

The above summary was adapted from the Introduction to the IEEE Computer Society's SWEBOK Guide. For more information on the Software Requirements Knowledge Area, read Chapter 8 of the SWEBOK Guide.

Standards

Standard:

Title:

Abstract:

IEEE Std 730™-2002

IEEE Standard for Software Quality Assurance Plans

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

IEEE Std 828™-1998

IEEE Standard for Software Configuration Management Plans

The minimum required contents of a Software Configuration Management Plan (SCMP) are established, and the specific activities to be addressed and their requirements for any portion of a software product's life cycle are defined.

IEEE Std 982.1™-1988

IEEE Standard Dictionary of Measures to Produce Reliable Software

This standard provides a set of measures indicative of software reliability that can be applied to the software product as well as to the development and support processes. It was motivated by the need of software developers and users who are confronted with a plethora of models, techniques, and measures. There is a need for measures that can be applied early in the development process that may be indicators of the reliability of the delivered product. This standard provides a common, consistent definition of a set of measures that may meet those needs.

IEEE Std 1028™-1997

IEEE Standard for Software Reviews

This standard defines five types of software reviews, together with procedures required for the execution of each review type. This standard is concerned only with the reviews; it does not define procedures for determining the necessity of a review, nor does it specify the disposition of the results of the review. Review types include management reviews, technical reviews, inspections, walk-throughs, and audits.

IEEE Std 1044™-1993

IEEE Standard Classification for Software Anomalies

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.

IEEE Std 1045™-1992

IEEE Standard for Software Productivity Metrics

A consistent way to measure the elements that go into computing software productivity is defined. Software productivity metrics terminology are given to ensure an understanding of measurement data for both source code and document production. Although this standard prescribes measurements to characterize the software process, it does not establish software productivity norms, nor does it recommend productivity measurements as a method to evaluate software projects or software developers. This standard does not measure the quality of software. This standard does not claim to improve productivity, only to measure it. The goal of this standard is for a better understanding of the software process, which may lend insight to improving it.

IEEE Std 1058™-1998

IEEE Standard for Software Project Management Plans

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.

IEEE Std 1061™-1998

IEEE Standard for a Software Quality Metrics Methodology

A methodology for establishing quality requirements and identifying, implementing, analyzing, and validating the process and product software quality metrics is defined. The methodology spans the entire software life cycle.

IEEE Std 1062™, 1998 Edition

IEEE Recommended Practice for Software Acquisition

A set of useful quality practices that can be selected and applied during one or more steps in a software acquisition process is described. 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.

IEEE Std 1219™-1998

IEEE Standard for Software Maintenance

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

IEEE Std 1228™-1994

IEEE Standard for Software Safety Plans

The minimum acceptable requirements for the content of a software safety plan are established. This standard applies to the software safety plan used for the development, procurement, maintenance, and retirement of safety-critical software. This standard requires that the plan be prepared within the context of the system safety program. Only the safety aspects of the software are included. This standard does not contain special provisions required for software used in distributed systems or in parallel processors.

IEEE Std 1490™-1998

IEEE Guide—Adoption of PMI Standard—A Guide to the Project Management Body of Knowledge

The subset of the Project Management Body of Knowledge that is generally accepted is identified and described in this guide. "Generally accepted" means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness. It does not mean that the knowledge and practices should be applied uniformly to all projects without considering whether they are appropriate.

IEEE Std 1540™-2001

IEEE Standard for Software Life Cycle Processes—Risk Management

A process for the management of risk in the life cycle of software is defined. It can be added to the existing set of software life cycle processes defined by the IEEE/EIA 12207 series of standards, or it can be used independently.

IEEE Std 14143.1™-2000

IEEE Adoption of ISO/IEC 14143-1:1998 Information Technology—Software Measurement—Functional Size Measurement—Part 1: Definition of Concepts

This part [volume] of ISO/IEC 14143 defines the fundamental concepts of Functional Size Measurement (FSM) and describes the general principles for applying an FSM Method. This part of ISO/IEC 14143 does NOT provide detailed rules on how to:

  • Measure Functional Size of software using a particular method;

  • Use the results obtained from a particular method;

  • Select a particular method.

This part of ISO/IEC 14143 is applicable when determining if a method for sizing software is an FSM Method. It does not prevent the development of various methods, but rather provides a basis for assessing whether a particular method conforms to FSM. Implementation notes that relate to the IEEE interpretation of ISO/IEC 14143-1:1998 are provided.

About IEEE standard numbers.