The "Master Plan for Software Engineering Standards (MPSE)" has been prepared to promote discussion of the future direction of software engineering and its standards.

At the 1991 IEEE Computer Society Fourth Software Engineering Standards Application Workshop in San Diego, California, a session was held on: Future of Software Engineering Standards. Twenty-two persons from Canada, Italy, Singapore, the United Kingdom, and the United States participated. The session addressed issues about the status of current software engineering standards and improvement of the software engineering process. The need for a study group to advance these issues was identified. The study group was formed in May 1991.

The mission of the study group is to advance software engineering as a discipline through the implementation of effective standards which will be consistent and compatible in content and purpose. To accomplish its mission the study group will: (1) identify the long-range development and harmonization requirements for software engineering standards and (2) prepare and coordinate a strategic plan for meeting the requirements.

This document is a result of (1) the SESAW 4 meeting, (2) the study group's meetings, Nashville (October 29, 1991), San Francisco (February 1992), Huntsville (March 1992), Washington, D.C., (June 1992), Minneapolis (November 1992), San Francisco (February 1993), and Pittsburgh (May 1993) and (3) the input of many people.

A companion document to this document is "Survey of Existing and In-progress Software Engineering Standards."

Members of the Study Group include:

Send comments to:

The following persons were on the balloting committee that approved this document.

This plan supports the mission of improving the effectiveness and efficiency of the software engineering process in producing software of prescribed quality while meeting customer needs within cost and schedule constraints that are economically viable.

For this plan, the purpose of software engineering (SE) is to:.

The achievement of the mission will be through the combination of several factors including: better trained people, new and innovative technical solutions, improved processes, better tools, and synergistic relationships of the above. Standards for processes, tools, and data plays a role in achieving the mission. The focus of this plan is to to assure that standards fulfill their role in the mission defined above.

The purpose of this plan is to document a statement of direction for the improvement of software engineering standards for a 10 year period. The specific goals of the plan are to:

The goals of this plan will be achieved through a series of supporting plans.

1.2 Scope

This plan applies to software engineering standards for the IEEE. It is also applicable to international software engineering standards within the IEEE's area of interest. The plan is not restricted to any type of software. The plan defines statements of direction for standards development, but does not describe specific development projects.

1.3 Audience

This plan applies applies to three types of individuals: planner of standards development, standards developer, and standards user.

(1) The planner has the need to define specific project to meet the needs of the user of standards.

(2) The developer has the need to understand the overall needs of the user and be able to relate the specific project needs.

(3) The user has the need to be able to relate his/her specific needs with the needs of a broader set of users.

1.8 Document Overview

The document consists of the following chapters and appendicies.

Master Plan Overview - this chapter provides a summary of plan including the plan update process, the plan strategy, areas for tactical planning, the plan framework, groundrules for software engineering standards, allocation of objectives and expectations to planning areas, and forecast and priorites of standards development.

Action Plans - this chapter defines the process and provide guidelines for developing action plans. Action plans provide the specifics on standards improvement, consolidation and development.

User Expectations - this chapter provides from various users their expectations on what software engineering standards should do for them.

Objectives for Software Engineering Processes - this chapter defines a set of objectives for each software engineering process identified in this plan. The purpose of the objectives is to define the intent for the process.

General Requirements and Constraints for Software Engineering Standards - this chapter specifies both the general requirements for all software engineering standards and the specific requirements by type of standard. The types of standards are process, product, resource, and notation.

Topics for Future Software Engineering Standards - this chapter contains a tentative list of standards that could be developed. To become a reality, there must be a valid need and persons willing to develop the proposed standard.

Background - this appendix provides a brief history of the IEEE software engineering standards activity.

Definitions - this appendix contains a list of terms defined for use in the plan.

References - this appendix provides a list of articles and books used to compile this plan.

Acronyms and Abbreviations - this appendix contains a list of the acronyms and abbreviation along with an explanation for each.

Generation of Topics for Potential Standards - this appendix provides several schemes for generating ideas for new standards.

A master plan is a framework and guidelines for addtional planning. This chapter provides an overview of the plan. The chapter consists of the following sections:

Master Plan Update Process - the plan uses a 10 year planning period. Due to the dynamic nature of software engineering, it is anticipated that the Master Plan will undergo regular updates. This section describes a process for updating the plan.

Software Engineering Standards Master Plan Strategy -the strategy is built on five goals with the specific stated in the supporting objectives. The goals deal with upgrades, expansion, syncretization, cooperation and reuse, and harmonization.

Areas for Tactical Planning - the planning areas are an empirically developed list to the organize the tactical planning. The list is descriptive. It is expected to be changed without much notice.

Master Plan Framework - the plan can be thought of in two conceptual parts: user of standards view and the standards developer's view. Each view has a scheme to represent its information. The user view is based on a set of 18 user types. The standards developer view is based on a descriptive list of software engineering processes.

Software Engineering Standards Groundrules - the groundrules provide the guiding principles for the formulation of standards for software engineering.

Objectives and Expectations by Planning Area - for each planning area the corresponding objectives and expectations have been identified. This provides a point of departure for detailed definition of requirements for a standard.

Development Priorities - priorities are presented for a 2 year period, a 5 year period, and a 10 year period.

The components of the plan are presented in Figure 2-1.

Figure 2-1 Master Plan Components

3.0 [Removed]

4.0 [Removed]

5.0 [Removed]

6.0 [Removed]

7.0 [Removed]

APPENDIX A -- Background

The discipline of software engineering emerged in the 1960s. The first use of the term was in 1968[5]. According to [7], software engineering is; "(1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software. (2) The study of approaches as in (1)." The increasing maturity of the software engineering discipline can be measured by the number of standards available.

In this context, a standard can be: (1) an object or measure of comparison that defines or represents the magnitude of a unit; (2) a characterization that establishes allowable tolerances or constraints for categories of items; and (3) a degree or level of required excellence or attainment. Standards are definitional by nature, established either to further understanding and interaction, or to acknowledge observed (or desired) norms of exhibited characteristics or behavior.

To date software engineering standards have been motivated by the desire to establish levels of excellence or definitional aspects of software. Software engineering standards tend to address the process by which the software is being developed rather than specifying characteristics of the completed software product. Usually software engineering standards have been developed to specify procedures or disciplines for a particular phase of development (e.g., requirements specification standard) or an associated aspect of software development (e.g., documentation standard).[1]

During the 1970s, several software engineering standards were developed. Three examples are presented in this paper. The examples represent: (1) an ADP community of a large organization (i.e., U.S. Government), (2) a procurement organization (i.e., U.S. Navy) and (3) a volunteer organization (i.e., IEEE).

In 1973, the National Bureau of Standards established the Federal Information Processing Standard (FIPS) Task Group 14, consisting of approximately 20 members representing the the U.S. Government ADP community to develop a FIPS publication for use by the Federal Government. FIPS Task Group 14 collected and analyzed available standards from both the public and private sectors. Responses to inquiries made by the task group members about documentation standards indicated that standards were feasible and could be implemented.[4]

In 1976, FIPS Publication 38, "Guidelines for Documentation of Computer Programs and Automated Data Systems," was published by the Government Printing Office. FIPS 38 is organized around 10 documents: functional requirements, data requirements, system/subsystem specification, program specification, data base specification, user manual, operations manual, program maintenance manual, test plan, and test analysis report.

In 1974, the U.S. Navy started the development of Mil-Std 1679, "Weapon System Software Development." It was the result of a task to develop internal Navy regulations and/or instructions on the usage, control, and management of embedded computer resources. The purpose of the document was to define software development requirements for a contractor. The document was developed during the first half of 1975. It took 3 and 1/2 years to finish the document. [3]

In 1976, a subgroup under the auspices of the IEEE was formed to develop a software quality assurance standard. The result of the subgroup was IEEE Std 730, "Standard for a Quality Assurance Plan." The standard was first published as a trial use standard in 1980. It was approved as a full-use standard in 1981. The document was organized around the plan outline: (1) purpose, (2) reference documents, (3) management, (4) documentation, (5) standards, practices, and conventions, (6) reviews and audits, (7) configuration management, (8) problem reporting and corrective action, (9) tools, techniques, and methodologies, (10) code control, (11) media control, (12) supplier control, and (13) records collection, maintenance, and retention. [2]

In the 1980s, a series of workshops were conducted to promulgate the development and application of software engineering standards. The first workshop, Software Engineering Standards Application Workshop (SESAW) was held in San Francisco in August 1981. Approximately 90 individuals attended. Twenty-two papers were presented. The second workshop was held in San Francisco during May 1983. The focus of the workshop was to promote the continuous improvement of software engineering standards. Approximately 110 people attended the workshop. One of the results of the workshops was the initiation of several software metric working groups. These working groups should be finished in 1992. The third workshop was held October 1984. The focus was standards in a competitive world. 190 people from 20 countries attended the workshop. There was a track on software engineering standards in the Computer Standards Conference in May 1986. The fourth workshop was held in May 1991. Approximately 100 people attended. The workshop was replaced by a symposium in 1993. The symposium titled "Software Engineering Standards Symposium" was held in September 1993 in Brighton, U.K.

1. Naur, P. et al., (eds) Software Engineering: Concepts and Techniques, Petrocelli/Charter, New York 1976.

2. IEEE Std 610.12-1990, Standard Glossary of Software Engineering Terminology

3. Branstad, M. "Software Engineering Standards: Motives and Mechanisms," Proceedings of SESAW II, 1983, pp. 83-86.

4. Kurihara, T. , et al., "Observations on Documentation Standards Revision: FIPS Pub after Four Years, Proceedings of SESAW, 1981, pp. 70-76.

5. Cooper, J. , "Development of Mil-Std 1679," Proceedings of SESAW, 1981, pp. 139-143.

6. Buckley, F.J. "A Standard for Software Quality Assurance Plans: A Status Report," Proceedings of SESAW, 1981, pp. 87-90.

7. Survey of Existing and In-Process Software Engineering Standards, V1.0, December 1, 1993. Available upon request from L.Tripp.

8. ISO/IEC(JTC1)-SC7, Information Technology -- Software Life-Cycle Process, 30 August 1991 Draft.

9. ISO/IEC 9126, Information technology -- Software product evaluation -- Quality characteristics and guidelines for their use., 1991-12-15.

10 IEEE Std 1002-1987, Standard Taxonomy for Software Engineering Standards.

11. AS 3563.1-1991, Australian Standard, Software quality management system, Part 1: Requirements.

12. Humprey, W.S., Managing the Software Process, Addison-Wesley, 1989.

13. Paulk, M.C., et al, "Capability Maturity Model for Software, Version 1.1," SEI-93-TR-24, February 1993.

14. Zachman, J.A., "A framework for information systems architecture," IBM Systems Journal, Vol. 26, NO. 3, 1987, pp. 276-292.

15. IEEE Standards Manual, September 1991.

16. IEEE Standards Style Manual, August 1992.

17. Jones, C., "CASE's missing elements," IEEE Spectrum, June 1992, pp. 38-41.

18. Shriver, B. et al., IEEE Computer Strategic Plan, October 1991.

19. Baumert, J.H., and M.S. Mc Whinney, "Software Measurement and Capability Maturity Model," SEI-92-TR-25, September 1992.

20. Sowa, J.F. and J.A. Zachman, "Extending and formalizing the framework for information systems architecture," IBM Systems Journal, Vol. 31, NO. 3, 1992, pp 590-616.

21. ISO 9000, "Quality Management and Quality Assurance Standard -- Guidelines for Selection and Use, 1987.

22. IEEE Std 1074-1991, Standard for Developing Software Life Cycle Processes.

23. Fenton, N and S. Page, "Towards the Evaluation of Software Engineering Standards," Proceedings of 1993 IEEE Software Engineering Standards Symposium, pp. 100-107.

Appendix D [Removed]

Appendix E [Removed]