Table of Contents | Chapter 6 | Chapter 8
7.0 OBJECTIVE
7.1 TASKS AND
ACTIVITIES
7.1.1
Establish the Application Environment
7.1.2
Design the Application
7.1.3
Develop Maintenance Manual
7.1.4
Develop Operations Manual
7.1.5
Conduct Preliminary Design Review
7.1.6
Design Human Performance Support (Training)
7.1.7
Design Conversion/Migration/Transition Strategies
7.1.8
Conduct Security Risk Assessment
7.1.9
Conduct Critical Design Review
7.1.10
Revise Previous Documentation
7.2 ROLES AND RESPONSIBILITIES
7.3 DELIVERABLES
7.3.1
Security Risk Assessment
7.3.2
Conversion Plan
7.3.3 System
Design Document
7.3.4
Implementation Plan
7.3.5. Maintenance
Manual
7.3.6
Operations Manual or System Administration Manual
7.3.7 Training
Plan
7.3.8 User
Manual
7.4 ISSUES FOR
CONSIDERATION
7.4.1
Project Decision Issues
7.4.2
Security Issues
The objective of the Design Phase is to transform the detailed, defined requirements into complete, detailed specifications for the system to guide the work of the Development Phase. The decisions made in this phase address, in detail, how the system will meet the defined functional, physical, interface, and data requirements. Design Phase activities may be conducted in an iterative fashion, producing first a general system design that emphasizes the functional features of the system, then a more detailed system design that expands the general design by providing all the technical detail.
The following tasks are performed during the Design Phase. The tasks and activities actually performed depend on the nature of the project. Guidelines for selection and inclusion of tasks for the Design Phase may be found in Chapter 13, Alternate SDLC Work Patterns.
Identify/specify the target, the development and the design and testing environment. How and where will the application reside. Describe the architecture where this application will be developed and tested and who is responsible for this activity.
In the system design, first the general system characteristics are defined. The data storage and access for the database layer need to be designed. The user interface at the desktop layer needs to be designed. The business rules layer or the application logic needs to be designed.
Establish a top-level architecture of the system and document it. The architecture shall identify items of hardware, software, and manual-operations. All the system requirements should be allocated among the hardware configuration items, software configuration items, and manual operations.
Transform the requirements for the software item into an architecture that describes its top-level structure and identifies the software components. Ensure that all the requirements for the software item are allocated to its software components and further refined to facilitate detailed design. Develop and document a top-level design for the interfaces external to the software item and between the software components of the software item.
Develop the maintenance manual to ensure continued operation of the system once it is completed.
Develop the Operations Manual for mainframe systems/applications and the System Administration Manual for client/server systems/applications.
This is an ongoing interim review of the system design as it evolves through the Design Phase. This review determines whether the initial design concept is consistent with the overall architecture and satisfies the functional, security, and technical requirements in the Functional Requirements Document.
Identify the users and how they will be trained on the new system. Be sure to address the Americans with Disabilities Act (ADA) requirements to ensure equal access to all individuals.
If current information needs to be converted/migrated/transitioned to the new system, plans need to be designed for those purposes, especially if converting means re-engineering existing processes.
Conduct a security risk assessment by addressing the following components: assets, threats, vulnerabilities, likelihood, consequences and safeguards. The risk assessment evaluates compliance with baseline security requirements, identifies threats and vulnerabilities, and assesses alternatives for mitigating or accepting residual risks.
The Project Manager and System Proponent conduct the critical design review and approve/disapprove the project into the Development Phase. This review is conducted at the end of the Design Phase and verifies that the final system design adequately addresses all functional, security, and technical requirements and is consistent with the overall architecture.
Review documents from the previous phases and assess the need to revise them during the Design Phase. The updates should by signed off by the Project Manager.
The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort.
The purpose of the risk assessment is to analyze threats to and vulnerabilities of a system to determine the risks (potential for losses), and using the analysis as a basis for identifying appropriate and cost-effective measures. Appendix C-17 provides a template for the Security Risk Assessment.
The Conversion Plan describes the strategies involved in converting data from an existing system to another hardware or software environment. It is appropriate to re-examine the original system’s functional requirements for the condition of the system before conversion to determine if the original requirements are still valid. Appendix C-18 provides a template for the Conversion Plan.
Describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, human-machine interface, detailed design, processing logic, and external interfaces. It is used in conjunction with the Functional Requirements Document (FRD), which is finalized in this phase, to provide a complete system specification of all user requirements for the system and reflects the user’s perspective of the system design. Includes all information required for the review and approval of the project development. The sections and subsections of the design document may be organized, rearranged, or repeated as necessary to reflect the best organization for a particular project. Appendix C-19 provides a template for the System Design Document.
The Implementation Plan describes how the information system will be deployed and installed into an operational system. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, the overall resources needed to support the implementation effort (such as hardware, software, facilities, materials, and personnel), and any site-specific implementation requirements. This plan is updated during the Development Phase; the final version is provided in the Integration and Test Phase and used for guidance during the Implementation Phase. Appendix C-20 provides a template for the Implementation Plan.
The Maintenance Manual provides maintenance personnel with the information necessary to maintain the system effectively. The manual provides the definition of the software support environment, the roles and responsibilities of maintenance personnel, and the regular activities essential to the support and maintenance of program modules, job streams, and database structures. In addition to the items identified for inclusion in the Maintenance Manual, additional information may be provided to facilitate the maintenance and modification of the system. Appendices to document various maintenance procedures, standards, or other essential information may be added to this document as needed. Appendix C-21 provides a template for the Maintenance Manual.
For mainframe systems, the Operations Manual provides computer control personnel and computer operators with a detailed operational description of the information system and its associated environments, such as machine room operations and procedures. The Systems Administration Manual serves the purpose of an Operations Manual in distributed (client/server) applications. Appendix C-22 provides a template for the Operations Manual and appendix C-23 provides a template for the Systems Administration Manual.
The Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when training users on the new or enhanced information system. The plan presents the activities needed to support the development of training materials, coordination of training schedules, reservation of personnel and facilities, planning for training needs, and other training-related tasks. Training activities are developed to teach user personnel the use of the system as specified in the training criteria. Includes the target audience and topics on which training must be conducted on the list of training needs. It includes, in the training strategy, how the topics will be addressed and the format of the training program, the list of topics to be covered, materials, time, space requirements, and proposed schedules. Appendix C-24 provides a template for the Training Plan.
The User Manual contains all essential information for the user to make full use of the information system. This manual includes a description of the system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use. Appendix C-25 provides a template for the User Manual.
The decisions of this phase re-examine in greater detail many of the parameters addressed in previous phases. The design prepared in this phase will be the basis for the activities of the Development Phase. The overall objective is to establish a complete design for the system. The pre-requisites for this phase are the Project Plan, Functional Requirements Document, and Test Plan. A number of project approach, project execution, and project continuation decisions are made in this phase.
Project approach decisions include
Project execution decisions include
Project continuation decisions include
The system user community shall be included in the Design Phase actions as needed. It is also in the Design Phase that new or further requirements might be discovered that are necessary to accommodate individuals with disabilities. If so, these requirements shall be added to the FRD.
The developer shall obtain the requirements from the System Security Plan and the FRD and allocate them to the specific modules within the design for enforcement purposes. For example, if a requirement exists to audit a specific set of user actions, the developer may have to add a work flow module into the design to accomplish the auditing.
Detailed security requirements provide users and administrators with instructions on how to operate and maintain the system securely. They should address all applicable computer and telecommunications security requirements, including: system access controls; marking, handling, and disposing of magnetic media and hard copies; computer room access; account creation, access, protection, and capabilities; operational procedures; audit trail requirements; configuration management; processing area security; employee check-out; and emergency procedures. Security operating procedures may be created as separate documents or added as sections or appendices to the User and Operations Manuals. This activity should be conducted during the Design Phase.
Upon completion of all Design Phase tasks and receipt of resources for the next phase, the Project Manager, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address: (1) Design Phase activities status, (2) planning status for all subsequent life cycle phases (with significant detail on the next phase, to include the status of pending contract actions), (3) resource availability status, and (4) acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy.