Engineering processes in SDLC

SDLC: System Development Life Cycle is a software lifecycle management methodology that typically consists of five to seven phases. It most often includes requirements gathering, design, construction/test, implementation and post-implementation support. It guides the software development process and prescribes various documents and deliverables for each phase. Each successive phase of SDLC leverages the documentation and knowledge gained from the previous phases. For instance, the detailed business requirements must be known in order to determine functional design followed by technical design and coding. The tenets of SDLC are not standards per se, but merely guideposts for managing software and systems from cradle to grave.
In today's environment of increasingly complex and integrated systems, engineering methodologies are vitally important for improving the quality and predictability of software development projects. Software engineering is widely viewed as a solution to the chronic crisis of poor software quality, missed deadlines, cost overruns, and abandoned projects. Success as a software engineering professional depends on a high level of competence and confidence in software engineering methodologies.
Described below are the ten phases during which defined IT work products are created or modified. The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap.





1. Initiation Phase
The initiation of a system (or project) begins when a business need or opportunity is identified. A Project Manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins.
Deliverables:
The following deliverables shall be initiated during the Initiation Phase:
1.1 Concept Proposal - This is the need or opportunity to improve business functions. It identifies where strategic goals are not being met or mission performance needs to be improved.
2. System Concept Development Phase
Once a business need is approved, the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires Senior Official approval and funding before beginning the Planning Phase.
Deliverables:
The following deliverables shall be initiated during the System Concept Development Phase:
2.1 System Boundary Document - Identifies the scope of a system (or capability). It should contain the high level requirements, benefits, business assumptions, and program costs and schedules. It records management decisions on the envisioned system early in its development and provides guidance on its achievement.
2.2 Cost-Benefit Analysis - Provides cost or benefit information for analyzing and evaluating alternative solutions to a problem and for making decisions about initiating, as well as continuing, the development of information technology systems. The analysis should clearly indicate the cost to conform to the architectural standards in the Technical Reference Model (TRM).
2.3 Feasibility Study - Provides an overview of a business requirement or opportunity and determines if feasible solutions exist before full life-cycle resources are committed.
2.4 Risk Management Plan - Identifies project risks and specifies the plans to reduce or mitigate the risks.

3. Planning Phase
The concept is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. To ensure the products and /or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment.
Deliverables
3.1 Acquisition Plan
The plan is developed to help insure that needed resources can be obtained and are available when needed.
3.2 Configuration Management Plan
The CM Plan describes the process that will be used to identify, manage, control, and audit the project’s configuration. The plan should also define the configuration management structure, roles, and responsibilities to be used in executing these processes.
3.3 Quality Assurance Plan
The QA Plan documents that the delivered products satisfy contractual agreements, meet or exceed quality standards, and comply with the approved SDLC processes.
3.4 Concept of Operations
The CONOPS is a high level requirements document that provides a mechanism for users to describe their expectations from the system.
3.5 System Security Plan
A formal plan detailing the types of computer security is required for the new system based on the type of information being processed and the degree of sensitivity. Usually, those systems that contain personal information will be more closely safeguarded than most.



4. Requirements Analysis Phase
Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All requirements are defined to a level of detail sufficient for systems design to proceed. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the Initiation Phase.
Deliverables
4.1 Functional Requirements Document
Serves as the foundation for system design and development; captures user requirements to be implemented in a new or enhanced system; the systems subject matter experts document these requirements into the requirements traceability matrix, which shows mapping of each detailed functional requirement to its source. This is a complete, user oriented functional and data requirements for the system which must be defined, analyzed, and documented to ensure that user and system requirements have been collected and documented.
All requirements must include considerations for capacity and growth. Where feasible,
I-CASE tools should be used to assist in the analysis, definition, and documentation. The requirements document should include but is not limited to records and privacy act, electronic record management, record disposition schedule, and components’ unique requirements..
4.2 Test and Evaluation Master Plan
Ensures that all aspects of the system are adequately tested and can be implemented; documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. Unit, integration, and independence acceptance testing activities are performed during the development phase. Unit and integration tests are performed under the direction of the project manager. Independence acceptance testing is performed independently from the developing team and is coordinated with the Quality Assurance (QA) office. Acceptance tests will be performed in a test environment that duplicates the production environment as much as possible. They will ensure that the requirements are defined in a manner that is verifiable. They will support the traceability of the requirements form the source documentation to the design documentation to the test documentation. They will also verify the proper implementation of the functional requirements. The types of test activities discussed in the subsequent sections are identified more specifically in the Integration and Test Phase of the life cycle and are included in the test plan and test analysis report.

• Unit/Module Testing
• Subsystem Integration Testing
• Independent Security Testing
• Functional Qualification Testing
• User Acceptance Testing
• Beta Testing
4.3 Interface Control Document
The Interface Control Document (ICD) provides an outline for use in the specification of requirements imposed on one or more systems, subsystems configuration items or other system components to achieve one or more interfaces among these entities. Overall, an ICD can cover requirements for any number of interfaces between any number of systems.
4.4 Privacy Act Notice/Privacy Impact Assessment
For any system that has been determined to be an official System of Records (in terms of the criteria established by the Privacy Act (PA)), a special System of Records Notice shall be published in the Federal Register. This Notice identifies the purpose of the system; describes its routine use and what types of information and data are contained in its records; describes where and how the records are located; and identifies who the System Manager is. While the Records Management Representatives are responsible for determining if a system is a PA System of Records, it is the Project Managers’ responsibility to prepare the actual Notice for publication in the Federal Register. As with the Records Disposition Schedule, however, it is the Project Manager’s responsibility to coordinate with and assist the System Proponent in preparing the PA Notice.
The System of Records Notice shall be a required deliverable for the Requirements Analysis Phase of system development. The Privacy Impact Assessment is also a deliverable in this Phase. This is a written evaluation of the impact that the implementation of the proposed system would have on privacy.

5. Design Phase
The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.
Deliverables
The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort.
5.1 Security Risk Assessment
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.
5.2 Conversion Plan
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.
5.3 System Design Document
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.
5.4 Implementation Plan
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.
5.5 Maintenance Manual
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.
5.6 Operations Manual or Systems Administration 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.
5.7 Training Plan
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.
5.8 User Manual
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.

6. Development Phase
The detailed specifications produced during the design phase are translated into hardware, communications, and executable software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.
Deliverables
The content of these deliverables may be expanded or abbreviated depending on the size, scope, and complexity of the corresponding systems development effort. The following deliverables shall be initiated during the Development Phase:
6.1 Contingency Plan
The Contingency Plan contains emergency response procedures; backup arrangements, procedures, and responsibilities; and post-disaster recovery procedures and responsibilities.
It is an emergency response plan, developed in conjunction with application owners and maintained at the primary and backup computer installation to ensure that a reasonable continuity of support is provided if events occur that could prevent normal operations. Contingency plans shall be routinely reviewed, updated, and tested to enable vital operations and resources to be restored as quickly as possible and to keep system downtime to an absolute minimum. A Contingency Plan is synonymous with a disaster plan and an emergency plan. If the system/subsystem is to be located within a facility with an acceptable contingency plan, system-unique contingency requirements should be added as an annex to the existing facility contingency plan.
6.2 Software Development Document
Contains documentation pertaining to the development of each unit or module, including the test cases, software, test results, approvals, and any other items that will help explain the functionality of the software
6.3 System (Application) Software
This is the actual software developed. It is used for the Test and Integration Phase and finalized before implementation of the system. Include all the disks (or other medium) used to store the information.
6.4 Test Files/Data
All the information used for system testing should be provided at the end of this phase. Provide the actual test data and files used.
6.5 Integration Document
The Integration Document explains how the software components, hardware components, or both are combined and the interaction between them.

7. Integration and Test Phase
The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities.
Deliverables
The following deliverables shall be initiated during the Integration and Test Phase:
7.1 Test Analysis Report
This report documents each test - unit/module, subsystem integration, system, user acceptance and security.
7.2 Test Analysis Approval Determination
Attached to the test analysis report as a final result of the test reviews and testing levels above the integration test; briefly summarizes the perceived readiness for migration of the software.
7.3 Test Problem Report
Document problems encountered during testing; the form is attached to the test analysis reports.
7.4 IT Systems Security Certification & Accreditation
The documents needed to obtain certification and accreditation of an information system before it becomes operational. They include: System Security Plan; Rules of Behavior; Configuration Management Plan, Risk Assessment; Security Test & Evaluation; Contingency Plan; Privacy Impact Assessments; and the certification and accreditation memorandums. The Systems Security Plan and certification/accreditation package should be approved prior to implementation.

8. Implementation Phase
The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.
Deliverables
The following deliverables are initiated during the Implementation Phase:
8.1 Delivered System
After the Implementation Phase Review and Approval Certification is signed by the Project Manager and the System Proponent representative, the system - including the production version of the data repository - is delivered to the customer for the Operations and Maintenance Phase.
8.2 Change Implementation Notice
A formal request and approval document for changes made during the Implementation Phase.
8.3 Version Description Document
The primary configuration control document used to track and control versions of software released to the operational environment. It is a summary of the features and contents for the software build and identifies and describes the version of the software being delivered.
8.4 Post-Implementation Review
The review is conducted at the end of the Implementation Phase. A post-implementation review shall be conducted to ensure that the system functions as planned and expected; to verify that the system cost is within the estimated amount; and to verify that the intended benefits are derived as projected. Normally, this shall be a one-time review, and it occurs after a major implementation; it may also occur after a major enhancement to the system. The results of an unacceptable review are submitted to the System Proponent for its review and follow-up actions. The System Proponent may decide it will be necessary to return the deficient system to the responsible system development Project Manager for correction of deficiencies.
9. Operations and Maintenance Phase
The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and needed system modifications are incorporated. The operational system is periodically assessed through In-Process Reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs. When modifications or changes are identified as necessary, the system may reenter the planning phase.

Deliverables
9.1 In-Process Review Report
The In-Process Review (IPR) occurs at predetermined milestones usually quarterly, but at least once a year. The performance measures should be reviewed along with the health of the system. Performance measures should be measured against the baseline measures. Ad hoc reviews should be called when deemed necessary by either party. Document the results of this review in the IPR Report.
9.2 User Satisfaction Review Report
User Satisfaction Reviews can be used as a tool to determine the current user satisfaction with the performance capabilities of an existing application or initiate a proposal for a new system. This review can be used as input to the IPR Report.

10. Disposition Phase
The disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particular emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.
Deliverables
The following deliverables are initiated and finalized during the Disposition Phase

10.1 Disposition Plan
The objectives of the plan are to end the operation of the system in a planned, orderly manner and to ensure that system components and data are properly archived or incorporated into other systems. This will include removing the active support by the operations and maintenance organizations. The users will need to play an active role in the transition. All concerned groups will need to be kept informed of the progress and target dates. The decision to proceed with Disposition will be based on
Recommendations and approvals from an In-Process Review or based on a date (or time period) specified in the System Boundary Document (SBD).
This plan will include a statement of why the application is no longer supported, a description of replacement / upgrade, list of tasks/activities (transition plan) with estimated dates of completion and the notification strategy. Additionally, it will include the responsibilities for future residual support issues such as identifying media alternatives if technology changes; new software product transition plans and alternative support issues (once the application is removed); parallel operations of retiring and the new software product; archiving of the software product, associated documentation, movement of logs, code; and accessibility of archive, data protection identification, and audit applicability.
10.2 Post-Termination Review Report
A report at the end of the process that details the findings of the Disposition Phase review. It includes details of where to find all products and documentation that has been archived.
10.3 Archived System
The packaged set of data and documentation containing the archived application.

DOCUMENTATION
The life cycle methodology specifies which documentation shall be generated during each phase.
Some documentation remains unchanged throughout the systems life cycle while others evolve continuously during the life cycle. Other documents are revised to reflect the results of analyses performed in later phases. Each of the documents produced are collected and stored in a project file. Care should be taken, however, when processes are automated. Specifically, components are encouraged to incorporate a long-term retention and access policy for electronic processes.
The table below shows the life of a document through different phases: