DOE G 200.1-1 Ch 1, Introduction

Software Engineering Methodology Chapter 1.0 Introduction Table of Contents Chapter Page 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.0-1 1.1 Implementation of Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1-1 1.2 Submitting Change Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2-1 DOE G 200.1-1 Introduction 5-21-97 Chapter 1.0 Date: March 1996 Introduction Page Rev Date: 1.0-1 Chapter: 1.0 Introduction Description: The Department of Energy Software Engineering Methodology provides guidance for software engineering, project management, and quality assurance practices and procedures. The primary purpose of the methodology is to promote the development of reliable, cost-effective, computer-based software products while making efficient use of resources. Use of the methodology will also aid in the status tracking, management control, and documentation efforts of the project. This software engineering methodology is consistent with other methodologies used in the Government and private industry. It complies with Departmental policy on project management, configuration management, security, and records management. Significant input for the methodology was obtained from software management programs at sites and organizations throughout the Department. The methodology integrates Departmental best practices and focuses on the quality of both the software engineering process and the work products generated from the process. The software engineering methodology is derived from the principles and standards advocated by software quality industry leaders, such as The Institute of Electrical and Electronics Engineers and the Carnegie-Mellon Software Engineering Institute (SEI). This methodology is designed to enable project teams to fully achieve Level 2 maturity on the SEI Capability Maturity Model. Some Level 3 key process areas are also incorporated into the methodology. Software quality assurance is integrated into the software engineering methodology, making quality the responsibility of all project team manager(s) and members. To assure the development of quality software products, the methodology prescribes reviews, inspections, and audits for the lifecycle processes and technical work products. To protect the integrity of the software, the methodology also prescribes configuration controls over software, data, and technical documentation. The software engineering methodology encompasses all aspects of the software lifecycle from project planning through production and maintenance, and integrates the following basic lifecycle management concepts. Implementation of software engineering preferred practices using a graded approach based on the level of effort, complexity, and degree of external impact of the software product. Description, DOE G 200.1-1 Introduction 5-21-97 Chapter 1.0 Date: March 1996 Introduction Page Rev Date: 1.0-2 continued: Implementation of a project management methodology including quality assurance, configuration management, and a comprehensive testing approach that is adaptable to the individual site environments. Application of a complete documentation approach supporting both lifecycle and project management activities, to assure an effective method for managing, tracking, and evaluating software engineering activities.

The software engineering methodology is intended to be used by individuals, project teams, and managers who are responsible for developing a new computer- based software product or make changes to an existing system. The methodology will be reviewed on a regular basis and modified as needed to keep pace with the changing needs of the Departmental software engineering environment and the continuing technical advances in the information systems industry. The following sections provide additional information about using this software engineering methodology. 1.1 Implementation of Methodology 1.2 Submitting Change Requests DOE G 200.1-1 Introduction 5-21-97 1.1 Implementation of Methodology Date: March 1996 Introduction Page Rev Date: 1.1-1 Section: 1.1 Implementation of Methodology Description: This methodology integrates software engineering, project management, and quality assurance practices and is designed to be flexible. It can be adapted to accommodate the specific needs of any software project and all computing platforms used in the Department including standalone and networked mainframes, minicomputers, and microcomputers. Projects that were initiated prior to the publication of this document should plan to implement the methodology at the earliest feasible stage or the next release of the product. If a Project Plan already exists, make the revisions necessary to integrate the software engineering, project management, and quality assurance practices, as appropriate. If a Project Plan does not exist, develop a plan that summarizes the activities and deliverables of the previous stages and incorporates the methodology activities and products into the subsequent stages. The software engineering methodology presented here does not supersede, replace, or override more stringent requirements that may apply to specific projects such as scientific and technical practices, and security and safety issues associated with the Nuclear Weapons Complex. Since the methodology does not provide specific guidance for every software engineering situation, suggestions for adapting the methodology to accommodate projects of varying size, complexity, or criticality are provided in Chapter 2.0, Lifecycle Model. Questions: If specific questions are generated concerning the interpretation or applicability of portions of the methodology, the project team should attempt to resolve them during the project review activities built into the stages of the lifecycle. The system owner/user(s) and other project stakeholders must concur with any adaptations that are made. When questions about interpretation or applicability of the guidance to a specific project cannot be resolved by the project team, the issue should be submitted to the site authority for software engineering, such as the site Information Resources Management or Information Management organization, for resolution. For Headquarters projects, the Office of Information Management is the site authority. DOE G 200.1-1 Introduction 5-21-97 1.1 Implementation of Methodology Date: March 1996 Introduction Page Rev Date: 1.1-2 Questions, continued: Questions and issues will be analyzed by the site Information Management Division and a response will be made in one of the following ways. An immediate solution is determined and will be provided to the project team. The issue will be submitted to personnel who are considered experts in the area in question. Once a solution is reached, it will be provided to the project team.

It is important to also submit questions of interpretation or applicability and the site-specific resolution to the Headquarters Office of Information Management. The Office will determine if a modification to the Software Engineering Methodology is needed to clarify processes or to provide additional adaptation suggestions. A central clearinghouse for all questions and resolutions will ensure that needed changes to the methodology can be identified and implemented in a timely and consistent manner. DOE G 200.1-1 Introduction 5-21-97 1.2 Submitting Change Requests Date: March 1996 Introduction Page Rev Date: 1.2-1 Section: 1.2 Submitting Change Requests Description: The Departmental software engineering environment is continuously changing as emerging technologies are integrated into projects, system owner/user requirements are expanded, and organizational needs evolve. The software engineering methodology will be expanded and revised, as needed, to reflect changes in the environment, improvements suggested through user feedback, and the maturation of software engineering capabilities. Users of the methodology are encouraged to submit suggestions for improving its content and to report any practices that are difficult to understand or create an implementation problem for a project team. Suggestions and problems should be submitted on the Change Request Form that is provided at the end of this section. If the form is not available or does not accommodate the type of request being made, submit a memo that describes the suggestion or problem. The Change Request Form or memo should be submitted to the Office of Information Management at Headquarters in Germantown, Maryland. The Change Request should be submitted through the site's Information Management organization. All requests will be evaluated and the originator of the request will be notified of the action taken. Some requests will be handled immediately while others may require investigation by an ad hoc Working Group of knowledgeable personnel. In some cases, a request may not be appropriate for the current environment, but will be retained for future consideration. Software Engineering Methodology Change Request Form To be completed by Requestor To be completed by Analyst Name: Name: Phone: Phone: Location: Location: Date: Date Assigned: Document Section: Request Number: Requested Change and Justification: Change Classification Data (check one) Class I Change ___ Class II Change ___ Class III Change ___ Check if additional pages are attached ___ Check if additional pages are attached ___ Summary of Impact: Change Impacts Change Impacts Section Number: ____________________ Section Number: ____________________ Pages: ____________________ Pages: ____________________ Working Group Actions Approval/Disapproval Reason(s): Date ____________________ Additional Comments: Software Engineering Methodology Change Request Instructions Requestor's Section Instructions Name: Fill in your name, telephone number, location and date. Phone: Location: Date: Document Section: List the document section where you want to make a change. Requested Change and State the change that you want to incorporate and state your reasons for the change. Justification: Attach additional pages as needed. Change Impacts: List any section numbers and pages that will be affected by the proposed change.

**Send the completed Change Request Form to the Headquarters Office of Information Management, Systems Engineering Group, Engineering Services Team, HR-433, Germantown, Maryland. Analyst's Section Instructions Name: Fill in your name, telephone number, location, and date you received the assignment. Phone: Location: Date Assigned: Request Number: Obtain the sequential number that will be used to track the request from the Headquarters Office of Information Management, Systems Engineering Group, Engineering Services Team, HR-433. Change Classification Data: Class I Changes in policy, procedures, required actions, or deliverables are defined by Government units (Congress, Office of Management and Budget), or by DOE policies, procedures, and administrative requirements. These changes must be reviewed and approved by HR-433 and incorporated into the methodology with the next update. Class II Changes in technology or development methodology are descriptions of innovations in the way software products are developed. These changes require review and concurrence by a Working Group and must be approved by HR-433. Changes in required deliverables may be implemented by HR-433 or recommended by a Working Group. The impact on the remainder of the methodology when such changes are incorporated require review and concurrence by a Working Group and approval by HR-433. Class III Changes in factual information (security requirements), wording, or corrections of typographical errors will be implemented as soon as possible to keep the methodology accurate and current. Corrections of typographical errors are implemented without review. All other changes require review and approval by HR- 433. Summary of Impact: State what effect the proposed change would have on other sections of the document or the methodology. Change Impacts: List any section numbers and pages that will be affected by the proposed change. Working Group Instructions Approval/Disapproval State whether the proposed change should be approved or disapproved. Give Reasons: reasons for the decision. Indicate date of approval/disapproval.