DOE G 200.1-1 Ch 3, Planning Stage

Software Engineering Methodology Chapter 3.0 Planning Stage Table of Contents Chapter Page 3.0 Planning Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.0-1 3.1 Analyze User Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1-1 3.2 Define Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2-1 3.3 Define Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3-1 3.4 Develop High-Level Project Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4-1 3.5 Establish Communication With Functional Areas . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5-1 3.6 Determine Project Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-1 3.6.1 Investigate Software Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-3 3.6.2 Investigate Hardware Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-7 3.6.3 Formulate Platform Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-8 3.6.4 Conduct Feasibility Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-9 3.6.5 Conduct Analysis of Benefits and Costs . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-11 3.6.6 Conduct Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-12 3.6.6.1 Analyze the alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6-14 3.6.6.2 Determine feasibility recommendations . . . . . . . . . . . . . . . . . 3.6-15 3.6.6.3 Develop feasibility study document . . . . . . . . . . . . . . . . . . . . 3.6-16 3.7 Develop Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7-1 3.8 Develop Software Quality Assurance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8-1 3.9 Conduct In-Stage Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9-1 3.10 Conduct Planning Stage Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10-1 DOE G 200.1-1 Planning Stage 5-21-97 Chapter 3.0 Date: March 1996 Planning Stage Page Rev Date: 3.0-1 Chapter: 3.0 Planning Stage Description: This is the first stage in the lifecycle of a software engineering project. In this stage, the users' environment is analyzed, the project objectives and scope are defined, the high-level requirements are estimated, the feasibility of the project is determined, and the initial Project Plan is developed and approved. This stage is initiated when a project manager/team responds to a DOE-approved task assignment with a Management Plan and related materials. The preparation of the Management Plan and related materials involves several critical planning issues such as the identification of preliminary requirements; staff, schedule, and cost estimates; and potential risks associated with the project. This information is reviewed in the Planning Stage and forms the foundation for all subsequent planning activities.

During this stage, the system owner and users are interviewed to: identify their business needs and expectations for the product; gain a common understanding of the task assignment; and determine how the project supports the DOE and organizational missions and long-range information resource management plans. The system owner is the organizational unit that is funding the project, and users are the DOE employees and contractors who will use the product. In this stage, the project team should be focused on identifying what the project will automate, and whether developing an automated solution makes sense from business, cost, and technical perspectives. If the project is feasible, time, cost, and resource estimates must be formulated for the project, and risk factors must be assessed. It is important for the project team to work closely with representatives from all functional areas that will be involved in providing resources, information, or support services for the project. The information gathered in this stage is used to plan and manage the project throughout its lifecycle. Input: The following items provide input to this stage. Task Assignment (Statement of Work) Management Plan and related materials DOE G 200.1-1 Planning Stage 5-21-97 Chapter 3.0 Date: March 1996 Planning Stage Page Rev Date: 3.0-2 High-Level Activities: The remainder of this chapter is divided into sections that describe specific high- level activities performed during this stage. These activities represent the minimum requirements for a large software engineering effort. Notes are provided, as applicable, to assist in customizing these lifecycle stage requirements to accommodate different sizes of software engineering efforts. The high-level activities are presented in the sections listed below. 3.1 Analyze User Environment 3.2 Define Project Objectives 3.3 Define Project Scope 3.4 Develop High-Level Project Requirements 3.5 Establish Communications With Functional Areas 3.6 Determine Project Feasibility 3.7 Develop Project Plan 3.8 Develop Software Quality Assurance Plan 3.9 Conduct In-Stage Assessment 3.10 Conduct Planning Stage Exit Output: Several work products are developed during this stage. The work products listed below are the minimum requirements for a large software project. Deviations in the content and delivery of these work products are determined by the size and complexity of a project. Explanations of the work products are provided under the applicable activities described in the remainder of this chapter. Project File Description of user environment Statement of project objectives Statement of project scope Statement of high-level project requirements Functional area contact list and project profile Summary of platform options Statement of project feasibility Analysis of Benefits and Costs Report Feasibility Study Document Project Plan Software Quality Assurance Plan A matrix showing the work products associated with each high-level activity is provided in Exhibit 3.0-1, Planning Stage Activities and Work Products by Project Size. The matrix also shows which work products are deliverables and whether they are required or optional for small, medium, and large projects. DOE G 200.1-1 Planning Stage 5-21-97 Chapter 3.0 Date: March 1996 Planning Stage Page Rev Date: 3.0-3

Review Process: Structured walkthroughs are necessary during this stage to validate work products. The activities that are appropriate for structured walkthroughs are identified throughout the chapter. The time and resources needed to conduct the walkthroughs should be reflected in the project resources, schedule, and work breakdown structure. Reference: Appendix C, Conducting Structured Walkthroughs, provides a procedure and sample forms that can be used for structured walkthroughs. Bibliography: The following materials were used in the preparation of the Planning Stage chapter. 1. The Institute of Electrical and Electronics Engineers, Inc., IEEE Standard for Developing Software Life Cycle Processes, IEEE Std 1074-1991, New York, 1992. 2. U.S. Department of Energy, Analysis of Benefits and Costs (ABC's) Guideline: Volume 1, A Manager's Guide to Analysis of Benefits and Costs, DOE/MA-0342, June 1988. 3. U.S. Department of Energy, Analysis of Benefits and Costs (ABC's) Guideline: Volume 2, An Analyst's Handbook for Analysis of Benefits and Costs, DOE/MA-0343, June 1988. 4. U.S. Department of Energy, Software Management Guide, DOE/AD-0028, 1992. 5. U.S. Department of Energy, DOE/NV Software Management Plan, Nevada Operations Office, May 1991. DOE G 200.1-1 Planning Stage 5-21-97 Chapter 3.0 Exhibit 3.0-1. Planning Stage Activities and Work Products by Project Size Size: L = Large Minimum Requirements: R = Required I = Input to other deliverables M = Medium A = As Appropriate = Completed by reviewer1 S = Small N = Not Applicable Date: March 1996 Planning Stage Page Rev Date: 3.0-4 Work Activity Size Work Product Deliverables Project Scheduled L M S L M S 3.1 Analyze User Environment R R R Description of user environment I I I Project File N N N 3.2 Define Project Objectives R R R Statement of project objectives I I I 3.3 Define Project Scope R R R Statement of project scope I I I 3.4 Develop High-Level Project Requirements R R R Statement of high-level requirements I I I 3.5 Establish Communication With Functional Areas R R A Functional area contact list and project profile N N N 3.6 Determine Project Feasibility R R R Summary of platform options I I A Statement of feasibility R R A Analysis of Benefits and Costs Report A A A Feasibility Study Document A A A 3.7 Develop Project Plan R R A Project Plan R R A 3.8 Develop Software Quality Assurance Plan R R R Software Quality Assurance Plan R R R 3.9 Conduct In-Stage Assessment R R A ISA Report Form N N N1 3.1 Conduct Planning Stage Exit R R A Stage Exit Meeting Summary N N N DOE G 200.1-1 Planning Stage 5-21-97 3.1 Analyze User Environment Date: March 1996 Planning Stage Page Rev Date: 3.1-1 Activity: 3.1 Analyze User Environment Responsibility: Project Manager/Team Description: A thorough understanding of the current users' environment is necessary to define the objectives, scope, and high-level requirements of the project. Analyze the users' manual procedures or automated processes to understand what users do, how they do it, and what improvements are desired or needed. This includes gaining an understanding of the functions performed, identifying information flows within the processes, and listing process inputs and outputs. Use appropriate data collection techniques such as user surveys, interviews, and document inspections to gather data and analyze the user environment.

Types of Information: The following list provides samples of the type of information that should be considered. Mission - Describe the mission of the primary user organization(s) and how the organizational mission fits into the Departmental mission and strategic plans. Work Processes - Analyze the work processes or tasks that are performed by the users. Identify the relationships and priority of the processes. Workload - Describe the volume of work currently being performed. For automated processes include processing time for batch operations, response times, peak number of simultaneous users of interactive systems, and number of transactions. Processing/Data Flow - Analyze the major processing/data flow for the work processes. Include the flow of data between different user groups, manual and automated processes, and different user sites. Integration/Interfaces - Identify interactions and interfaces that the users' current automated systems share with other automated systems. Users - Identify the skill levels and number of personnel at both Headquarters and field sites who operate, maintain, and use current manual procedures or automated processes. Types of Information, DOE G 200.1-1 Planning Stage 5-21-97 3.1 Analyze User Environment Date: March 1996 Planning Stage Page Rev Date: 3.1-2 continued: Costs - Itemize costs incurred in operating the users' current manual or automated systems. Equipment - Identify equipment used in the current manual or automated systems and relate equipment to the function it supports in the systems. Software - Identify software packages that are being used. Work Products: A substantial amount of information that may be useful in later stages in the software engineering process is gathered during the Planning Stage. Create a centrally maintained Project File that can be used as the repository for all project information gathered during the Planning Stage and for all work products developed throughout the project lifecycle. The Project Manager should verify that all pertinent project information and documentation are placed in the Project File on a timely basis. Develop a description of the user environment and place a copy in the Project File. The description will be incorporated into future work products such as the Project Plan and the Requirements Specifications. DOE G 200.1-1 Planning Stage 5-21-97 3.2 Define Project Objectives Date: March 1996 Planning Stage Page Rev Date: 3.2-1 Activity: 3.2 Define Project Objectives Responsibility: Project Manager/Team Description: Use the information gathered during the analysis of the current user environment to define the objectives of the project. The objectives should identify what the project is intended to accomplish and why it is being undertaken (e.g., to resolve problems or to satisfy statutory requirements). Include a description of any deficiencies in the current manual and automated processes, the severity and impact of any problems, and the solutions and benefits that will result from implementing the project. The objectives should be identified in measurable terms. Sample Questions: The following list provides sample questions that can be used to help define the project objectives. Even though the users' answers to some questions might be tentative, partial answers will be useful at this stage of the lifecycle. These questions can be revisited during the Requirements Definition Stage to help develop the project requirements.

What is the general intent of the product? What organizational or Departmental functions will the product support? What are the major functional components of the product? Will the product produce any files or reports or provide data for other Government agencies, organizations, applications? Will the product use any data, files, or reports generated by other Government agencies, organizations, applications? What Departmental mission(s) will the product support? What Departmental strategic goal(s) will the product support? Will the product be aligned with the Departmental IRM plans? Will the product satisfy statutory or regulatory requirements? What are the anticipated benefits of the product? DOE G 200.1-1 Planning Stage 5-21-97 3.2 Define Project Objectives Date: March 1996 Planning Stage Page Rev Date: 3.2-2 Work Product: Develop a formal statement of project objectives. This statement will be incorporated into the Project Plan. If a feasibility study is conducted, the statement of project objectives should be included in the Feasibility Study Document. Place a copy of the project objectives in the Project File. Sample Statement of Project Objectives: The Human Resources organization needs a reliable means for tracking information about all of the personnel for whom it is responsible. This will be accomplished with the development of a new automated administrative information application called the Human Resources Information System (HRIS). The high-level objectives of the HRIS project are to develop an application that will: Provide a central local area network repository for personnel data. Ensure accuracy and timeliness of all personnel data. Enable access to the data by the Human Resources staff as well as Training, Salary Administration, and other organizations as required. Generate a series of basic reports. Provide the capability to produce ad hoc reports in the event existing reports do not satisfy the users' reporting requirements. DOE G 200.1-1 Planning Stage 5-21-97 3.3 Define Project Scope Date: March 1996 Planning Stage Page Rev Date: 3.3-1 Activity: 3.3 Define Project Scope Responsibility: Project Manager/Team Description: The project scope details what user processes, organizations, and functions will be affected by the product. It also identifies the anticipated changes to current automated and manual processes. A thorough understanding of the scope of the project is necessary to determine whether the project is feasible. The scope may need to be downsized to remain feasible within the constraints of resources, budget, and time negotiated with the system owner. Sample Questions: The following list provides sample questions that can be used to help determine the project scope. Even though the users' answers to some questions might be tentative, partial answers will be useful at this stage of the lifecycle. How many Government/contractor employees will use the product? What are the locations of the employees who will use the product? What tasks will be performed using the product? What will be the operating schedule for the product? How many and what types of reports will be needed? How and when will reports be distributed? Who receives the reports? What query capabilities are needed? Are major changes in requirements anticipated in the next few years? Are major changes in level of use anticipated in the next few years? What is the estimated life expectancy of the product?

What are the security requirements for the product? Will the product be mission-essential to DOE or mission-critical for the system owner? Will the product contain vital records? DOE G 200.1-1 Planning Stage 5-21-97 3.3 Define Project Scope Date: March 1996 Planning Stage Page Rev Date: 3.3-2 Sample Questions, continued: What are the disaster recovery requirements for the product? Will the product require telecommunications? Work Product: Develop a formal statement of project scope. This statement will be incorporated into the Project Plan. If a feasibility study is conducted, the statement of project scope should be included in the Feasibility Study Document. Place a copy of the project scope in the Project File. Sample Statement of Project Scope: Once personnel information is stored on the local area network, the HRIS application can be used as the reliable source of personnel information for all other Human Resources administrative systems. The use of HRIS by other systems is dependent on the implementation of a client/server environment. This is outside the scope of the HRIS project. It is outside the scope of HRIS to make electronic feeds to the PERSONA system. The PERSONA and EXMIS extract programs will have to be modified to extract historical information. Once the HRIS data base is established, EXPATS will need to be redesigned to utilize the HRIS personnel data. Any redesign of EXPATS is outside the scope of the HRIS project. Users requiring Windows installation or training will be identified; however, the actual installation and training is outside the scope of the HRIS project. DOE G 200.1-1 Planning Stage 5-21-97 3.4 Develop High-Level Project Requirements Date: March 1996 Planning Stage Page Rev Date: 3.4-1 Activity: 3.4 Develop High-Level Project Requirements Responsibility: Project Manager/Team Description: High-level requirements should be of sufficient detail to make a preliminary determination about the feasibility of the project, to estimate the resources that are needed, to assess hardware and software requirements, and to estimate the need for equipment or software training. The current and anticipated needs of all user groups must be identified. Users in different organizational units or geographic locations may have diverse or unique requirements that must be incorporated into the project requirements. Sample Requirements: Organize high-level project requirements into categories of related data. The following list provides samples of the types of data that should be considered. Inputs - Identify source documents and data that will be used as input to the processes. Provide descriptive information about data such as the type, volume, condition (e.g., edited or unedited), organization, and frequency. Include inputs such as records or batch files from other systems that will be downloaded or migrated. Outputs - Identify outputs such as reports, display screens, documents, and data files. Data bases - Estimate the high-level contents, purpose, use, format, organization, and update frequency of data bases that will be used by the product. Identify other existing or planned data bases that would interface with the product as a provider or recipient of information. Processing/Data Flow - Describe the major processing/data flow for the product. Include flow of data from the product to other systems and vice versa.

Data Communications - Estimate the major data communications resources required to support the product. Include requirements for networks, dial-up access, and other communication configurations to support data access and retrieval requirements. Sample DOE G 200.1-1 Planning Stage 5-21-97 3.4 Develop High-Level Project Requirements Date: March 1996 Planning Stage Page Rev Date: 3.4-2 Requirements, continued: Interfaces - Identify any systems with which the product must interface. Describe factors that may impact the design of the product. Security, Privacy, and Control - State requirements for ensuring the integrity of the data, for safeguarding against unauthorized access to the data bases, and for other user access controls. Training - Identify the type of training required to ensure efficient operation of the software product. Provide estimates of the number of personnel to be trained by type and frequency of training. Workload - Estimate the volume of work to be handled at slow, normal, and peak periods. Identify dates associated with each period. Include processing time for batch systems, response times, peak number of simultaneous users of interactive systems, and number of transactions. Costs - Estimate initial development costs and expected operating cost savings over the expected lifetime of the software product. Equipment - Estimate new equipment that might need to be acquired or manufactured and current equipment that would continue to be used. Software - Estimate software and firmware packages that might need to be acquired and any updates needed for existing software. Work Product: Develop a formal statement of the high-level project requirements. This statement will be incorporated into the Project Plan. If a feasibility study is conducted, the statement of requirements should be included in the Feasibility Study Document. The high-level requirements will serve as the foundation for the software requirements developed during the Requirements Definition Stage. Place a copy of the high-level requirements in the Project File. Reference: The system owner organization's information resource management long-range plan provides useful planning information for consideration when developing the requirements. DOE G 200.1-1 Planning Stage 5-21-97 3.4 Develop High-Level Project Requirements Date: March 1996 Planning Stage Page Rev Date: 3.4-3 Sample Statement of High-Level Requirements: The following are the high-level access requirements for the HRIS project. Allow any user to access the application and enter an access request. Have an interface to verify and maintain user information. Design system to verify user access levels. Allow for electronic authorizations for request verification. Allow for the entry, query, and maintenance of application data based on the user access levels. Provide for the capture and tracking of request data for the following request types: - requesting initial computer access - adding access levels to an existing logon identification code - reinstating a suspended computer access - deleting an existing computer access - suspending an existing computer access Provide for the entry, query, and maintenance of the following information: - computer systems - applications - user logon identification codes Allow users to view and maintain their own address information Provide a means for the system owner and security officers to review and change current user access information

DOE G 200.1-1 Planning Stage 5-21-97 3.5 Establish Communication With Functional Areas Date: March 1996 Planning Stage Page Rev Date: 3.5-1 Activity: 3.5 Establish Communication With Functional Areas Responsibility: Project Manager Description: Early contact with the functional areas that will provide input to, or support for, the project is necessary for developing accurate estimates of the project scope, cost, resources, and schedule. Representatives of these functional areas should be involved in all stages of the project lifecycle and are participants in the Stage Exit process. Develop a brief profile about the software project. Provide enough information so that the points-of-contact in each functional area will be able to estimate support requirements and resource allocations for the project. A sample project profile form is provided at the end of this section. Develop a list of all functional areas and points-of-contact who will provide input to, or support the project. Send each point-of-contact the project profile and request input from all recipients. Note: This activity is not necessary for small software engineering projects that do not require input from other functional areas. Work Products: Place a copy of the project profile in the Project File. Update the project profile as needed to maintain an accurate description of the software product. Keep the list of functional area contacts current and maintain a copy in the Project File. Use this list as the starting point when functional areas need to be contacted about involvement in project activities such as Stage Exits. Software Project Profile Software Name/Identification: Acronym: Contract Number: Task Number: Project Manager: Telephone: E-mail Address: DOE Organization: POC: Telephone: Size of effort (as defined by Software Engineering Methodology): Large Medium Small Purpose and scope of software product: 1. Software processing platform(s) (check all that apply) Mainframe Minicomputer LAN Server: Microcomputer Type: IBM compatible Macintosh Other: (specify) 2. The software will run under the following operating environments (check all that apply) VM DOS Windows Novell MVS OS/2 Windows N/T Unix CICS Macintosh Windows 95 Sun Other (specify) 3. The software will support the following printers (check all that apply) Workstation printer LAN-shared Mainframe/minicomputer addressable 4. The following programming languages(s), data base management system, or file system are being considered. Programming Language: Data Base Management System: File System: (more) 5. The software will interface with the following software or data sources (sharing, receiving, or sending data). 6. The following mechanisms are planned for providing these interfaces (e.g., Internet, TCP/IP, LAN). 7. The users of the software are at the following locations (check all that apply) DOE Headquarters DOE Operations Office National Lab Other (specify): 8. Software/Data Sensitivity: Classified Unclassified Sensitive Unclassified 9. The data is critical to the mission of the organization. Yes No

10. The data is essential to the mission of DOE and must be available at all times. Yes No 11. The following training support services are anticipated to develop and install the software product. Consultation Classroom Self-Study Computer-Based 12. The following documentation support services are anticipated to complete the project. Writing Editing Graphics Production Additional comments: Planning Stage DOE G 200.1-1 3.6 Determine Project Feasibility5-21-97 Date: March 1996 Planning Stage Page Rev Date: 3.6-1 Activity: 3.6 Determine Project Feasibility Responsibility: Project Manager/Team Description: In this stage, the feasibility of successfully developing and implementing the project is determined. Project feasibility leads to a "go" or "no go" decision about the project. Determining project feasibility is an interactive process of collecting and analyzing data and searching for cost-effective, viable technical solutions. Use the project objectives, scope, and high-level requirements as the basis for determining project feasibility. Work with the user organization and functional area representatives to address technical issues and risks. Conduct research and investigate documents and other resources. Note: Feasibility may not be an issue for some small software development projects. A Feasibility Review is not required when feasibility is obvious. Sample Questions: The following is a list of sample questions that can be used to help determine the feasibility of a project. Can the users needs/problems best be satisfied with a manual process, automated process, or combination? Is it cost-effective to develop an automated process? Is the scope of the project feasible within time, resource, and hardware and software constraints and limitations? Is there at least one technically feasible automated solution for the project? - If a project is well defined and has no automation issues, a single straightforward automated solution may sufficiently demonstrate cost and technical feasibility. - Where automation issues have been identified, technical alternatives should be associated with each proposed solution. Planning Stage DOE G 200.1-1 3.6 Determine Project Feasibility5-21-97 Date: March 1996 Planning Stage Page Rev Date: 3.6-2 Tasks: The following tasks are involved in determining project feasibility. 3.6.1 Investigate Software Alternatives 3.6.2 Investigate Hardware Alternatives 3.6.3 Formulate Platform Options 3.6.4 Conduct Feasibility Review 3.6.5 Conduct Analysis of Benefits and Costs 3.6.6 Conduct Feasibility Study Planning Stage DOE G 200.1-1 3.6 Determine Project Feasibility5-21-97 Date: March 1996 Planning Stage Page Rev Date: 3.6-3 Task: 3.6.1 Investigate Software Alternatives Description: When the software to be used for the project has not been predetermined by the system owner's existing computing environment, software available within the Department and the commercial marketplace should be investigated. In the Planning Stage, the investigation of software alternatives is geared to determining project feasibility. Unless the cost effectiveness of developing custom-built software to meet mission needs is clear and documented, all sources of reusable code, applications, and commercial off-the-shelf software must be investigated on a site and Departmentwide basis prior to making a decision to custom-build code for the project. This practice ensures the most cost-effective and efficient use of resources, and will decrease the number of duplicative and overlapping software systems. The choice to develop a customized application should be balanced against the availability of other solutions; and the project cost, resources, and time constraints.

Software Alternatives: Information on software products or modules can be obtained by notifying field sites, DOE Headquarters, other Government agencies, and private industry via Internet. The following is a list of software alternatives that should be considered. Adapt existing software in use within the Department. Adapt existing software in use within other Government agencies. Adapt mainframe or minicomputer source code obtained from Departmental Computer Center repositories. Purchase commercial off-the-shelf software. Reuse existing modules of code. Adapt reusable code to fit the new application. Develop a custom-built software product. Exhibit 3.6-1, Checklist for Investigating Software Alternatives, provides a checklist for investigating existing software resources. Planning Stage DOE G 200.1-1 3.6 Determine Project Feasibility5-21-97 Date: March 1996 Planning Stage Page Rev Date: 3.6-4 Note: Medium and small software engineering efforts are often restricted to the system owner's existing software. This should not preclude the potential cost savings of reengineering existing software modules rather than custom building the entire software system. DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-5 Exhibit 3.6-1. Checklist for Investigating Software Alternatives Software Resource Contact Special Considerations Review Headquarters software repositories If the requirements are met by reusable software obtained from including: MASL, SRIS, or SASREPS, then adapting that software may -Microcomputer and local area network -MASL similar to the target application, was developed to standards, applications in the Microcomputer Application Coordinator and includes documentation, this can be a very attractive Systems Library (MASL) alternative to a custom-built application. Reusable code may be -Applications in the Systems Review Inventory -Administrative System (SRIS) Computer Center SRIS listing on HR- 01 LAN provide the best solution. If the source application is very customized to meet specific requirements. Review field site software repositories Field site repository owner/coordinator Review the Department of Commerce MASL Coordinator Interagency Survey of Administrative Systems at DOE Reporting System (SASREPS) Headquarters Contact other project teams working on similar Project managers projects Exhibit 3.6-1. Checklist for Investigating Software Alternatives DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Software Resource Contact Special Considerations Date: March 1996 Planning Stage Page Rev Date: 3.6-6 Investigate off-the-shelf commercial software Software vendors Request and evaluate vendor-supplied demonstrations of software products that may satisfy project requirements. Commercial software may offer a macro language or program code that can be modified by the developer, which can significantly decrease development time. Some disadvantages to commercial software include procurement lead time, developer and user learning curves, and interfaces with existing hardware and software. Determine software libraries available for Mainframe software Reusable code can be either modules of code that are used as particular software languages administrators written, or units of code that are reengineered to perform a

Microcomputer development language are numerous, this alternative may be software more attractive than modifying an application that will need development groups considerable customization. similar function. If the reusable tools for the particular Reuse modules of code or software libraries Task leaders and Some software engineering teams develop modules of reusable developed within your functional area other programmers code that are language specific and perform functions such as screen formats, data validation, error-handling, data access, and other frequently used routines. Once developed, tested, and refined, these routines become reliable building blocks for the rapid development of other applications. Date: March 1996 Planning Stage Page Rev Date: 3.6-7 DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Task: 3.6.2 Investigate Hardware Alternatives Description: When the hardware to be used for the project has not been predetermined by the system owner's existing computing environment, investigate hardware available within the Department and through the commercial marketplace. In the Planning Stage, the investigation of hardware is geared to determining project feasibility. Factors to Consider: The following is a list of factors that should be considered when identifying hardware alternatives. Availability and cost of hardware - Shareable hardware - Government excess - New procurement Current and future telecommunications needs Computer security requirements of the system Volume of data Importance of data to the Departmental mission Importance of data to the user organization's mission and to job performance Potential growth of the software to serve more users Potential growth of the software to serve more locations Potential for interface to other systems or organizations Conformance to Government standards such as networking and open systems Note: Medium and small software engineering efforts are often restricted to the system owner's or user sites' existing hardware. Task: 3.6.3 Formulate Platform Options DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-8 Description: Use the information collected about software and hardware alternatives to formulate preliminary platform options. The purpose of identifying platform options early in the project lifecycle is to assure that at least one technically feasible and cost-effective approach exists to satisfy the project objectives. If more than one platform option is feasible, identify the benefits, costs, assumptions, constraints, dependencies, and risks associated with each option. No platform decisions are made at this time. Detailed technical solutions are premature prior to defining the product requirements. The platform alternatives information gathered in the Planning Stage is revisited in the Functional Design Stage, at which time a final recommendation is developed by the project team and presented to the system owner. The system owner is responsible for making the final platform decision. Work Product: Develop a summary of platform options for use in the Feasibility Review or Feasibility Study. Place a copy of the platform option information in the Project File. Review Process: Conduct a structured walkthrough to ensure that the most viable platform options have been identified. DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility

Date: March 1996 Planning Stage Page Rev Date: 3.6-9 Task: 3.6.4 Conduct Feasibility Review Description: A Feasibility Review is an informal meeting to determine whether the software project can be accomplished with the available resources, system owner and users' computing environment, and technological constraints. The Feasibility Review meeting also provides an opportunity for project management to obtain feedback from other project managers and the functional area representatives who will be providing input to, or supporting, the project throughout the lifecycle. The project objectives, scope, high-level requirements, and preliminary platform options should be shared with the review meeting participants prior to the meeting date. The participants are expected to evaluate the project information and risks, and make a recommendation about project feasibility. Feasibility Factors: The following are some typical factors that should be considered when determining the feasibility of a project. Project scope and objectives Users' computing environment High-level requirements Assumptions, constraints, and limitations Platform options Security and recovery objectives Risk factors Technological factors Available resources and budget Future growth needs Expected long-term benefits Compliance with long-range information resource management plans Recommendations: After all of the pertinent feasibility factors have been considered, the review meeting participants should make one of the following recommendations: Proceed with the project without performing a Feasibility Study Prepare an Analysis of Benefits and Costs Conduct a Feasibility Study, which includes an Analysis of Benefits and Costs Stop the project DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-10 Work Products: Generate a record of the Feasibility Review meeting to serve as verification that the review occurred, to record feasibility factors that were considered and the recommendation(s) generated during the meeting, and to provide background information if a Feasibility Study or Analysis of Benefits and Costs is required. The project manager uses the recommendations from the Feasibility Review meeting to develop a formal statement of feasibility. A typical statement of feasibility is a short declaration describing whether or not it is feasible to develop the project within the known constraints. When major risks are involved in the feasibility decision, it may be necessary to expand the statement of feasibility to describe the risk factors and their consequences. Depending on the factors that must be considered for each project, the statement of feasibility may contain the following information. Project objectives Summary of issues concerning: - development and implementation - assumptions, constraints, and limitations - project scope Results of research on hardware and software alternatives Significant risk factors Feasibility recommendation(s) The project manager decides on the final recommendation and reports the findings to the system owner for review and approval. Sample Feasibility Statement: The following is a sample feasibility statement for a low-risk project that would use the hardware/software platform currently available within the users' organization.

The client organization, Project Management Officer, and project manager agree that the XYZ project will be written in {programming language} and use {operating system and/or DBMS} on {hardware configuration}, all of which are currently in place and can easily absorb the impact of XYZ. This will be a custom-built product since a search of software repositories did not reveal any reusable or existing software that would satisfy the project requirements. DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-11 Task: 3.6.5 Conduct Analysis of Benefits and Costs (as appropriate) Description: An Analysis of Benefits and Costs (ABC) is a useful tool in any stage of the software lifecycle. In the Planning Stage, the results of an ABC help to determine the feasibility of a project and the return on investment. For example, an ABC can be conducted to determine if changing the users' current business processes or computing environment will improve efficiency or reduce overhead expenditures enough to justify the cost of the project, and when the system owner can expect to recoup the costs of the project in benefits. An ABC is used to identify and compare the benefits and costs associated with all of the hardware or software alternatives. Any advantage to a particular alternative is considered a benefit, and any loss or penalty is considered a cost. Costs can also include the purchase price of supplies, equipment, software, personnel time or charge rate, and system downtime. The results of the ABC indicate the most cost-effective alternative. When a totally manual process is being automated, the benefits of automating the process may be obvious. If the system owner has restricted the platform, then an ABC can be an appropriate way to document these decisions and the benefits and costs associated with the limitations. When a Feasibility Study is performed, an ABC is a mandatory requirement of the study. When a Feasibility Study is not performed, the ABC is an optional process. Work Product: Develop a report that describes the results of the ABC. When a Feasibility Study is performed, the results of the ABC will be incorporated into the Feasibility Study Document. Review Process: An informal peer review or a structured walkthrough is recommended to validate the ABC process used and the results obtained. Reference: The following Department documents provide guidance on conducting an Analysis of Benefits and Costs. Analysis of Benefits and Costs (ABC's) Guideline: Volume 1, A Manager's Guide to Analysis of Benefits and Costs Analysis of Benefits and Costs (ABC's) Guideline: Volume 2, An Analyst's Handbook for Analysis of Benefits and Costs DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-12 Task: 3.6.6 Conduct Feasibility Study (as appropriate) Description: When a project has decisions or issues that require a more detailed investigation than is possible with a Feasibility Review or Analysis of Benefits and Costs, a Feasibility Study must be performed to obtain the necessary information for making an informed decision about project feasibility. An Analysis of Benefits and Costs (ABC) is a required process in a Feasibility Study. In cases where the platform is limited or restricted, the Feasibility Study may be abbreviated to evaluate only the technical solutions for the areas that have some flexibility.

Use the information identified in the Feasibility Review and the Analysis of Benefits and Costs as the basis for the Feasibility Study. Consider any preliminary solutions that were formulated and identify the alternative ways to resolve the problems or issues. Evaluate all of the available feasibility factors to determine if the project is technically feasible and cost effective. Sometimes a Feasibility Study for a similar project has already been conducted. An existing Feasibility Study can be used if the information is current, relevant to the new project, and technically correct. The following are examples of cases where a Feasibility Study must be performed. There is uncertainty or disagreement on the boundaries of the project. There is uncertainty over the cost justification or technical feasibility of a project. There is a lack of agreement about the goals or approach for building the software product. The proposed size or complexity of the software product indicates a high degree of risk. The software product will automate functions that currently are not being performed either automatically or manually. DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-13 Work Product: The results of the Feasibility Study are reported in a document that describes the process that was used to determine feasibility, the alternatives that were considered, and the results of the Analysis of Benefits and Costs. The Feasibility Study results determine the feasibility recommendation for the project. Subtasks: The following subtasks are involved in conducting and documenting a Feasibility Study. 3.6.6.1 Analyze the alternatives 3.6.6.2 Determine feasibility recommendation 3.6.6.3 Develop feasibility study document Note: New software products can be limited to the system owner's and users' existing hardware and software environment, and may not require a Feasibility Study. Review Process: An informal peer review or a structured walkthrough is recommended to validate the Feasibility Study process used and the results obtained. DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-14 Subtask: 3.6.6.1 Analyze the alternatives Description: Alternatives for developing and implementing a project are derived from the high-level project requirements, the results of the Feasibility Review and the Analysis of Benefits and Costs, and the preliminary platform options. The analysis of the alternatives forms the basis for determining project feasibility. The analysis of the alternatives should consider the following types of information. The ability of each alternative to achieve the project objectives. The ability of each alternative to meet the users' requirements and expectations. How well each alternative accommodates the system owner's current processes and resources. How cost-effective and technically feasible each alternative is compared to the existing automated or manual process. How well each alternative fits with the hardware and software limitations imposed by the system owner. Analysis of the alternatives may include the following activities. Research current computer industry periodicals to obtain articles and reviews about software and hardware alternatives. Interview software and hardware vendors to obtain up-to-date information about product releases and future upgrades, capabilities, vendor support, developer training, product demonstrations, multiuser license arrangements, current users, and costs.

Interview current users of the product to obtain information about user satisfaction, ease-of-use, satisfaction of user expectations, productivity, and product limitations. DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-15 Subtask: 3.6.6.2 Determine feasibility recommendations Description: The results of the Feasibility Study are used to determine project feasibility. The feasibility recommendations must be substantiated by the results of the Analysis of Benefits and Costs (ABC). The feasibility recommendations should include the following types of information. The recommended alternative for each of the project automation issues. The feasibility to develop the project. The most technically sound alternative with the most long-range benefits to the Department. The most cost-effective configuration for the project based on the ABC. The estimated total lifecycle costs based on the recommended technical solution and the ABC. DOE G 200.1-1 Planning Stage 5-21-97 3.6 Determine Project Feasibility Date: March 1996 Planning Stage Page Rev Date: 3.6-16 Subtask: 3.6.6.3 Develop feasibility study document Description: The Feasibility Study Document provides the following types of information. The process that was used to determine project feasibility. The alternative approaches that were analyzed for achieving the project objectives. The results of the Analysis of Benefits and Costs. The recommendations for a specific approach to meet the system owners' and users' project objectives, automation needs, and expectations. Work Product: The Feasibility Study Document should contain enough information to enable the system owner to make a decision to either continue or terminate the project. Review Process: An informal peer review or a structured walkthrough is recommended to validate the Feasibility Study Document and feasibility recommendations. The completion of the Feasibility Study is an appropriate time to schedule an In- Stage Assessment (ISA). The In-Stage Assessment Process Guide provides a description and instructions for conducting an ISA. A copy of the guide is provided in Appendix D. DOE G 200.1-1 Planning Stage 5-21-97 3.7 Develop Project Plan Date: March 1996 Planning Stage Page Rev Date: 3.7-1 Activity: 3.7 Develop Project Plan Responsibility: Project Manager Description: The purpose of the Project Plan is to establish reasonable plans for performing the software engineering activities and for managing and tracking the software project. The following project management activities must be performed before a Project Plan document is developed. Define the management approach for the project including project tracking and oversight activities Formulate the technical approach for the project Develop the project estimates Establish the project development team The results of these project management activities and the lifecycle activities described in this volume will provide input for the Project Plan. Note: A Project Plan is an effective management tool that is recommended for all projects regardless of size. The plan can be consolidated for small projects.

Work Product: Develop a Project Plan that provides detail for the Planning and Requirements Definition Stages and high-level information for the other lifecycle stages. At the conclusion of each stage, the Project Plan will be reviewed to determine if the project estimates for resources, cost, and schedule need to be revised for either the current stage or subsequent stages. In addition, the Project Plan will be expanded to provide detailed estimates of resources, costs, and hours for the next stage. A Project Plan Example document template is accessible online to use as a guide in developing the Project Plan. Project models containing lifecycle stages and deliverables that can be used as is or tailored for any software development or maintenance project are accessible online. The files can be downloaded for use with Microsoft Project. Review Process: Conduct a structured walkthrough to ensure that the Project Plan reflects the project objectives and scope; identifies and mitigates project risks, and adequately estimates the project resources, costs, and schedule. DOE G 200.1-1 Planning Stage 5-21-97 3.8 Develop Software Quality Assurance Plan Date: March 1996 Planning Stage Page Rev Date: 3.8-1 Activity: 3.8 Develop Software Quality Assurance Plan Responsibility: Project Manager and Quality Assurance Manager Description: The purpose of quality assurance is to assure the production and operation of high quality products on schedule, within budget, and within the constraints specified by the system owner and user. The software quality assurance program is initiated at the beginning of a project and is conducted throughout the software engineering lifecycle. The software quality assurance program is the joint responsibility of the project manager and quality assurance manager with direct support and involvement from the quality assurance practitioners assigned to the project. Work Product: The quality assurance manager or designated representative assists the project manager with the development of a plan that clearly defines the project's quality assurance policies and procedures. The Software Quality Assurance Plan addresses the following types of responsibilities. Establishing the applicability of published standards and procedures and determining the scope of the project standards and procedures. Monitoring the software product and enforcement of compliance with all standards and procedures to facilitate the early detection of problems that could affect the reliability, maintainability, availability, integrity, safety, security, or usability of the software product. Inspecting hardware and software items and documenting for compliance to specifications and standards before their release to the test team or the system owner. Certifying deliverable items before their release to the system owner as compliant with all provisions of the project statement of work and contract, if applicable. Coordinating the project's technical problem reporting system and corrective action program to assure resolution of observed discrepancies. Measuring the quantitative and auditable progress of the project based on cost, schedule status, and quality status. DOE G 200.1-1 Planning Stage 5-21-97 3.8 Develop Software Quality Assurance Plan Date: March 1996 Planning Stage Page Rev Date: 3.8-2 Work Product, continued: Assuring consistent management and technical practices and the integrity of the software product.

Provide enough information in the plan so that compliance can be monitored by means of project records. Whenever feasible, acquire automated tools to check compliance with project standards. For example, many CASE (computer-aided software engineering) tools can check compliance with standards, while checking the validity and consistency of requirements, design, and logic diagrams. Review Process: Conduct a structured walkthrough to validate that the quality assurance policies and procedures are appropriate and adequate for the project. DOE G 200.1-1 Planning Stage 5-21-97 3.9 Conduct In-Stage Assessment Date: March 1996 Planning Stage Page Rev Date: 3.9-1 Activity: 3.9 Conduct In-Stage Assessment Responsibility: Project Manager and Independent Reviewer Description: An In-Stage Assessment (ISA) is an independent review of the work products and deliverables developed or revised during each stage of the project lifecycle. The independent reviewer is typically a member of the Quality Assurance Team who is assigned to the software project and conducts all of the ISAs for the project. An ISA does not require meetings with, or extra work by, the project team. All of the work products and deliverables needed for the review should be readily available in the Project File. Schedule at least one ISA prior to the Planning Stage Exit process. Additional ISAs can be performed during the stage, as appropriate. An ISA is recommended after the completion of the Feasibility Study. Provide the reviewer with copies of all work products developed or revised during the Planning Stage including the Project Plan. The reviewer assesses the work products and deliverables to verify the following: The project is complying with the site's software engineering standards/best practices. Sound project management practices are being used. The project risks are identified and mitigated. A description of the ISA process and the ISA report form are provided in the In- Stage Assessment Process Guide. A copy of the guide is provided in Appendix D. Note: An ISA is an effective project management tool that is recommended for all projects regardless of size. Work Product: An ISA report form is prepared by the independent reviewer and is used to identify open issues that need to be resolved in this stage. The report is delivered to the project manager and a copy should be placed in the Project File. Planning StageDOE G 200.1-1 3.10 Conduct Planning Stage Exit5-21-97 Date: March 1996 Planning Stage Page Rev Date: 3.10-1 Activity: 3.10 Conduct Planning Stage Exit Responsibility: Project Manager Description: The Stage Exit is a process for ensuring that projects are on target, within budget, on schedule, and meet the DOE and project standards identified in the Project Plan. The goal of a Stage Exit is to secure the approval of designated key individuals to continue with the project and to move forward into the next lifecycle stage. Schedule the Stage Exit as the last activity of the Planning Stage. It is the responsibility of the project manager to notify the appropriate participants when a project is ready for the Stage Exit process and to schedule the Stage Exit meeting. All functional areas and the Quality Assurance representative involved with the project should receive copies of the work products and deliverables produced in this stage.

During the Stage Exit meeting, participants discuss open issues that will impact the Project Plan. The project manager should ensure that an acceptable action plan is developed for handling all open issues. At the conclusion of the meeting, concurrence is needed from the designated approvers to begin the next stage. A description of the Stage Exit process is provided in the Stage Exit Process Guide. A copy of the guide is provided in Appendix E. Note: A Stage Exit is an effective project management tool that is recommended for all software projects regardless of size. For small software projects, stages can be combined and addressed during one Stage Exit. Work Product: A summary of the Stage Exit meeting is prepared by the project manager or a designee and distributed to the meeting attendees. The summary identifies any issues and action items needed to obtain concurrence prior to proceeding to the Requirements Definition Stage.