INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity Task/Subtasks Potential Deliverables Lifecycle Definition This version of an Incremental Release Lifecycle Model is a combination of Traditional Waterfall and Spiral Development. The Business Requirements and Conceptual Design are established for the entire system. Based on the Implementation Strategy each System Function (Product Component) is cycled through Functional Design, Construction, and Implementation. When all Functions for a Release are complete, the system is assembled and following successful Acceptance Tests by the customers is moved into Production. Implementation Cycles overlap and the process is improved through each iteration. This model was intentionally created to be consistent with the other DHS OIS lifecycle models. Note: The numbering starts at 3 to enable integration into the project management lifecycle Execution Phase which is the third of five project phases. The following activities, tasks and deliverables should be reviewed for each project on a case-by-case basis. Projects may utilize this model and adapt or tailor to the specific needs of the project. This means that not all activities and tasks are necessary for every project, and that additional activities and tasks may need to be included. Specific deliverables depend on the tools and techniques used by the development staff and on the existing documentation. The deliverables listed are examples of possible deliverables. 3. Execution

3.1 Feasibility Study Note: Requirements definition is an extension of the process started in the Feasibility Study. Please see the Feasibility Lifecycle model to determine if all or some of the steps are necessary. 3.2 Define Requirements The purpose of this phase is to establish a common understanding between the customers and the software project of the customers requirements that will be addressed by the software project. All system development work should be traceable to the various levels of requirements, i.e. product description, project objectives, hi-level requirements. Changes to the Requirements should be managed according to their impact on the projects cost, schedule, and quality (scope). Note: Requirements definition is an extension of the process started in the feasibility study, if one was performed. 3.2.1 Identify Refine the Feasibility Study with Updates Feasibility and describe the increasing detail to: Study business area(s) to be Identify additional Stakeholders Updated affected by the new groups impacted by the system Requirements system development. Traceability Matrix or Stakeholder List Define the current business processes Context Diagram Define the current technology infrastructure, applications and Procedure flow databases diagrams Define the external system interfaces and primary data exchanges. Identify the sources and destinations of each primary data exchange. Identify and prioritize candidates for procedural change and automation. Descriptions of existing reports and documents Candidates for procedural change Business Rules Business Use Cases Business Actors 3.2.2 Develop Follow the projects requirement Requirements
1 Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc

INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity Task/Subtasks Potential Deliverables Business Requirements management plan to: Gather stakeholder needs from all stakeholders. Synthesize and Prioritize. Define Requirements transform stakeholder needs into well-defined high-level requirements. Validate Requirements evaluate each requirement and determine relative priority. Analyze Requirements refine and categorize high-level requirements with greater precision and detail. Categories include: functional, data, use, performance, security, business and technical standards, operational, legal. 3.2.3 Reevaluate initial development approach, impact analysis, costs and benefits The following bullets must be done in collaboration with NDS, T&S, CRM, DRM and ISE. Refine the Feasibility Study with increasing detail to: Ensure that the development approach recommended in the Feasibility Study is still valid. Ensure that OIS cross-sections agree and can support the technical solution and development. Ensure that cost benefits assumptions are still valid. Ensure that external interfaces (projects and systems) are accurately stated. 3.2.4 Conduct walkthrough Ensure that requirements are clear, complete, and comprehensive Collect concurrence agreements from Major OIS Sections and Business Issues, resolutions, changes, etc OIS Sections and Business Sign-off(s) indicating concurrence Formal acceptance of the Project Plan & Requirements Updated Project Plan, Schedule, & Budget Updated Cost Benefit Analysis (feasibility study) Detailed plan for the next phase(s) OIS Approved Exception Request Traceability Matrix Glossary Use Cases Requirements Document Requirements Baseline

3.2.5 Obtain formal user and sponsor concurrence

Decision point for the Steering Committee: For approval of the work completed To authorize continued work on the project.

3.3 Conceptual Design The purpose of this phase is to develop the high-level Conceptual Design and Implementation Strategy. The Conceptual Design is developed based on applicable standards and best practices and is used to incorporate the business requirements into the system design. The Implementation Strategy identifies the potential release strategies for the Steering Committee decision on how to deliver the system. 3.3.1 Develop the Conceptual Design Identify best practices for the system being developed Define the systems basic functionality
Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc

Conceptual Data Model Conceptual Process

2

INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity Task/Subtasks Potential Deliverables and information exchanges Identify the inputs, outputs, and triggers for each system function Work with CRM, ISE and T&S identify the hardware and software to develop and operate the new system. Work with NDS to determine the network(s) that will support the application. 3.3.2 Define application standards (i.e., determine how functions and data will be distributed, screen formats, common software functions, etc) Identify how system functions will be distributed geographically and technically (across platforms). Define the application tiers (i.e, presentation, business logic, database) in terms of technology and function Describe standards for each application tier (i.e., Presentation tier will use Secure Sockets Layer (SSL), Cascading Style Sheets, error handling, naming conventions, ODBC vs. JDBC, etc) Identify the security features of the system. Create contingency plan and/or revise existing contingency plans. Plan back-up and recovery processes. 3.3.4 Define audit and control functions (error control, control totals, etc.) Identify and describe the controls to be built into the system and used to ensure that data integrity is maintained. Description of distribution strategy Description of alternatives considered Application Design Standards Model Technology Architecture Use Cases (refined) Storyboards

3.3.3 Define environmental controls (e.g., security, contingency planning, restart recovery)

Specifications for security, contingency and back-up/restart requirements Use Case definition Audit and control specifications Audit trail capture and reporting requirements Use Case definition Common routine/ software tool specifications Identification of existing reusable code to use Product delivery plan Implementation Strategy Release Strategy Hardware and communications resource acquisition requirements. Updates to Technology
3

3.3.5 Define common software functions

Identify the requirements to be automated Identify the software functions that will be developed as common routines or software tools. Identify the functions to be delivered in the planned versions of the system. Note: This activity is included for use in large development efforts in which there is need to deliver the product in phases or versions instead of as the result of a single project. Determine the impact of processing and storage volumes on the hardware (data storage, processor capacity) and on communications resources. Note: If the system requires the acquisition of new hardware and

3.3.6 Create product delivery plan (for phased delivery)

3.3.7 Estimate storage, telecommunications and/or processor impacts

Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc

INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity Task/Subtasks Potential Deliverables network resources (as opposed to increased capacity) see the Hardware and LAN Acquisition/Installation project type. 3.3.8 Reevaluate development approach, impact analysis, costs and benefits Ensure that the approach recommended in the Feasibility Study is still valid, given the design results. Ensure that cost benefits assumptions are still valid. Ensure that impacts on other projects and systems are accurately stated. Revise approach and cost benefits statements as appropriate. 3.3.9 Prepare a Conceptual Design Report 3.3.10 Conduct walkthrough Compile and summarize the previous deliverables into a comprehensive report. Ensure that the various aspects of the design fulfill the requirements and comply with standards. Conceptual Design Report Issues, resolutions, changes, etc Sign-off(s) indicating concurrence Formal approval of Conceptual Design Report and Implementation Strategy OIS Sections and Business Sign-off(s) indicating concurrence Architecture

Updates to previous deliverables (i.e., Plan, Schedule, Cost/Benefit, etc)

3.3.11 Obtain formal user, technical and sponsor concurrence

Decision point for the Steering Committee: For approval of the work completed Conceptual Design Report & Implementation Strategy Collect concurrence agreements from Major OIS Sections and Business To authorize continued work on the project.

3.4 Functional Design The purpose of this phase is to define the detailed functional and technical design aspects of a release. The work completed in this phase should be sufficiently detailed to provide the construction team with specific information for how the application should work. It is essential that business customers define the necessary detail for system functionality rather than relying on the technical teams interpretation of how to implement the business requirements. Object Oriented Analysis & Design Tasks & Deliverables are used in the rest of this model. Structured Analysis & Design techniques can be used in place of these, with minor changes to descriptions. Note: The use of prototyping and Joint Application Design (JAD) are recommended for the design of reports, screens and documents. See the RAD template to use activities related to prototyping. 3.4.1 Plan for Develop Business Reengineering Plan Business Implementation to plan for and guide the changes in Reengineering Plan business processes that are necessary to Implementation Plan implement the system/release. Security Model Define the Implementation Plan that specifically describe how the Support Plan system/release will be transitioned into Production (i.e., training, data conversion, switchover) Define the post production user support (Help Desk, etc.).
Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc 4

INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity Task/Subtasks Potential Deliverables Develop the Security Model compile all security information into a comprehensive plan over the life of the development project. 3.4.2 Build/acquire/ prepare the development environment (hardware and software) Acquire hardware and system software resources Ensure that the development environment is ready for use. Note: Hardware/software acquisition may require long lead times; therefore, initiate the acquisition process as early as possible. If there is a need to acquire hardware, system software, and/or network software, use the Development with Hardware and LAN Acquisition/Installation lifecycle activity list to identify those activities that are relevant to this project. 3.4.3 Develop test strategy Define the process for validation and verification for the system/release. Test objectives Levels of testing(conceptual, functional, unit, system, integration acceptance) Roles and responsibilities for testing 3.4.4 Identify subsystems, their data requirements and interfaces Package the new system's functions into subsystems and map the flow of data between them. Identify files and/or databases. Identify the media (screen, paper, electronic file, document, etc.) for each data flow. 3.4.5 Interfaces Design User Storyboard Interfaces to describe basic flow of the screens and scenarios Create Prototypes with sample screens and basic functionality for customer input. 3.4.6 Design Application Logic Identify Candidate Classes with attributes, operations, methods, relationships, and semantics. Create Design Classes to refine the Candidate Classes with additional detail. Refactor Design Classes to identify commonality in the system to achieve
Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc

Installed hardware and software ready for use in the development process.

Systems flow diagrams Updates to Use Cases

System prototypes Screen designs Form designs Report designs Design Model (that describes the realization of the Use Cases) UML Diagrams, Class Diagrams, Activity Diagrams,

INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity Task/Subtasks Potential Deliverables maximum reuse and a consistent design. 3.4.7 Design External Interfaces 3.4.8 Develop System Test Plan Design the Functions of the External Interfaces ?

Define test cases (started early so that during Test Cases the development of the use case the each test Installed hardware and case is being defined). software ready for use in Ensure that the test environment is ready for the test process. use Identify the data required to support the system functionality. Normalize the data model. Identify data segments or records based on the way data will be used in the system. Logical Data Model fully attributed with relationships, roles, cardinality, and optionality. Physical data base design

3.4.9 Refine the Conceptual Data Model into a logical, application data model

3.4.10 Design physical data base and/or files

Map the logical data base design to the specific data base or file management system(s) to be used. Describe the data as it will be stored on the physical media.

3.4.11 Update previous work

Update Conceptual Design data, process, and technology Update Project Plan, Schedule, Budget Reevaluate technical infrastructure storage utilization, capacity estimates, hardware acquisition

Documented Changes, Issues, Risks Updates to Requirements Traceability Matrix

3.4.12 Prepare for Implementation

Plan for file/database conversions identify conversion requirements and the programs and controls required for conversion. Identify required user, support staff and/or operator documentation and training

Updates to Implementation Plan data conversion plan and schedule, training plan and schedule Issues, Risks, Defects, Change Requests

3.4.13 Conduct walkthrough

Validate the designs (logical and physical) to ensure that they adequately fulfill requirements. Validate that all requirements have been addressed

3.4.14 Obtain formal user, technical, and sponsor concurrence

Decision point for the Steering Committee: For approval of the work completed To authorize continued work on the project. To confirm commitment of the implementation plan by all effected groups.

Formal acceptance of the System Design and Implementation Plan

3.5 System Construction The purpose of this phase is to build and unit test the system components application code, database definition language (DDL), user procedures, and test plans. 3.5.1 Build Test Define test cases, create test data, identify System Test Plans Environment test criteria include platforms and data validation. 3.5.2 Write System Documentation Write on-line help files Write user procedures, compile into user Operator Manual Administrator Manual
6

Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc

INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity Task/Subtasks Potential Deliverables manual Create the training material, curriculum 3.5.3 Build Application Develop program code and perform unit tests. Build user interfaces Create database to implement the schema, triggers, and stored procedures 3.5.4 Conduct walkthrough Code Review Test Plan Review Issues, Risks, Change Requests Application Module Physical Database

Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc

INCREMENTAL DEVELOPMENT LIFECYCLE

Phase/Activity 3.6 Implementation The purpose of this phase is to validate the system, train the users, and transition the system/release into production. 3.6.1 System Validate the Conduct Functional Tests (black box) to ensure system performs desired functionality. Once each Function is tested then assemble into a build. Conduct System Tests to ensure the system performs as expected under volume and exception conditions Conduct Acceptance Tests to validate the system meets the customers expectations. Note: testing may include parallel test, usability test, Beta Test, or other tests. It may be performed in a special test environment. 3.6.2 Train users, operators, and support staff 3.6.3 Obtain formal user and sponsor concurrence 3.6.4 Prepare for transition to production Ensure that all users, operators and support staff are able to use the system. Trained users, operators, and support staff Test Report Change Requests, Issues, Risks Task Deliverables

Decision point for the Steering Committee: For approval of the work completed To authorize continued work on the project. Ensure that the production environment (including users, operations personnel, and support staff) is prepared for the start of production. Install required new hardware, system software, and communications systems. Perform data conversions Perform environment tests Note: For applications to be run by computer operations all forms must be filled out and submitted, as required by current procedures.

Formal acceptance of the system release

Operations schedules (batch schedule and online availability) Programs transferred to production libraries Production job control or command lists available New or changed security data (passwords, etc.) in the proper tables Users and support staff of systems that may be effected by the new system advised of the transition System in Production

3.6.5 System

Deploy

Move system into production use Performance tune application/database as necessary Evaluate project performance Evaluate system performance to measure how well it meets user expectations

3.6.6 Evaluate System/Release

Updates to Project Plan, Schedule, and all previous work Lessons Learned

Incremental Development /var/www/apps/conversion/current/tmp/scratch27207/95340241.doc