Florida Department of Financial Services Division of Information Systems Information Systems Development Methodology (ISDM) Version 1.10 Department of Financial Services - Information Systems Development Methodology 2 TABLE OF CONTENTS WHAT IS IT REALLY? .................................................................................................................... 1 WHAT IS THE DFS ISDM? ............................................................................................................. 1 DFS ISDM PHASES & REVIEW POINTS ....................................................................................... 4 PHASE 1: CUSTOMER BUSINESS NEEDS ANALYSIS ....................................................................................... 6 Roles & Responsibilities ................................................................................................................... 6 Description-Purpose .......................................................................................................................... 6 Inputs. .................................................................................................................................................. 6 Process ................................................................................................................................................ 6 Outputs ................................................................................................................................................ 6 PHASE 2: SCOPE DEFINITION ....................................................................................................................... 6 Roles & Responsibilities ................................................................................................................... 6 Description-Purpose .......................................................................................................................... 6 Inputs ................................................................................................................................................... 6 Process ................................................................................................................................................ 6 Outputs ................................................................................................................................................ 6 PHASE 3: REQUIREMENTS ANALYSIS ............................................................................................................ 7 Roles & Responsibilities ................................................................................................................... 7 Description-Purpose .......................................................................................................................... 8 Inputs ................................................................................................................................................... 7 Processs .............................................................................................................................................. 7 Outputs. ............................................................................................................................................... 7 PHASE 4: DESIGN........................................................................................................................................ 7 Roles & Responsibilities ................................................................................................................... 7 Description-Purpose .......................................................................................................................... 7 Inputs ................................................................................................................................................... 7 Process ................................................................................................................................................ 7 Outputs ................................................................................................................................................ 7 PHASE 5: DEVELOPMENT ............................................................................................................................. 8 Roles & Responsibilities ................................................................................................................... 8 Description-Purpose .......................................................................................................................... 8 Inputs ................................................................................................................................................... 8 Process ................................................................................................................................................ 8 Outputs ................................................................................................................................................ 8 PHASE 6: INTEGRATION, TEST, ACCEPTANCE ............................................................................................... 8 Roles & Responsibilities ................................................................................................................... 8 Description-Purpose .......................................................................................................................... 8 Inputs ................................................................................................................................................... 8 Process ................................................................................................................................................ 9 Outputs ................................................................................................................................................ 9 PHASE 7: IMPLEMENTATION-DEPLOYMENT ................................................................................................... 9 Roles & Responsibilities ................................................................................................................... 9 Description-Purpose .......................................................................................................................... 9 Inputs ................................................................................................................................................... 9 Process ................................................................................................................................................ 9 Outputs ................................................................................................................................................ 9 MAINTENANCE ............................................................................................................................................ 9 APPENDIX A - GLOSSARY .......................................................................................................... 10 APPENDIX B – APPLICABLE SYSTEM DEVELOPMENT STANDARDS .................................. 11 APPENDIX C – APPLICABLE OPERATING PROCEDURES ..................................................... 12 Department of Financial Services - Information Systems Development Methodology 4 Department of Financial Services - Information Systems Development Methodology What is it really? Methodologies guide development consistencies for efficient and effective system development projects and products/solutions by defining the associated requirements. These defined requirements assist with accomplishing proper documentation, identifying deliverables, conducting risk assessments, allowances for process improvements, critical checkpoints for reviews, approvals and similarly related processes during solution development lifecycles. To maintain productive system development practices, it is essential to follow an ISDM in all development projects, regardless of size. An effective ISDM incorporates predefined concepts such as style guides for naming conventions, common coding practices, interface development standards, code templates, project tracking, change management, prototyping, and staged delivery. When the appropriate methodology is designed and applied, properly balanced flexible options remain available while still providing an effective framework for efficient system delivery. Efficiently designed methodologies offer multiple development routing paths based upon the development itself, operate toolindependent, are easily adaptable, and most importantly remain flexible enough to be customized to the business requirements of the owner/user. Improperly designed methodologies are usually inflexible, over demanding, difficult to comprehend and usually impossible to follow through an entire development lifecycle. This ISDM is considered adopted by the Department of Financial Services; It is officially referenced as the DFS ISDM, and will be used in all system development projects undertaken by DFS and all contracted vendors. What is the DFS ISDM? The DFS ISDM is a formally documented methodology outlining specifically defined stages/phases in the systems development lifecycle associated with all systems development efforts. The DFS ISDM phases are customer needs analysis, scope definition, requirements analysis, design, development, integration/test/acceptance, and implementation-deployment. Specific checkpoints are built into the ISDM to ensure that quality and progress reviews are performed throughout the lifecycle of the project. The DFS ISDM philosophy centers upon a staged delivery method of software development, recommending that systems be delivered in incremental versions throughout the project. The key to the DFS ISDM philosophy is identification, prioritization, development and release of all modules. Put very simply, systems are developed quickly in smaller, more manageable modules and therefore released rapidly for the owner/user to utilize. This approach is a standard philosophy and practice throughout the Information Technology industry. Software development companies in the private industry usually release a preliminary or Beta version of software first. These Beta releases often contain the core features required for the software. Subsequent releases contain additional features as the related project evolves. Final version releases usually contain all (or most) of the features originally defined at the beginning of the project. After what is considered a full version release, the software is considered delivered and functionality changes are not allowed until the next version. Updates or software patches are generally provided to correct bugs that may appear after the original release. Any new functionality requirements are strictly minimized and enforced through change control processes until the next official version of the software is released. Identifying project scope/business requirements is essential and a critical component of the DFS ISDM. Along with this identification process, a solution analysis is conducted and change controls established to properly determine solution deliverables, project duration, and staffing resources for the project. Establishing the scope at the onset of a project allows the solution team to focus their development work directly upon the important or mission-critical functionality. Properly assessing and prioritizing risk factors throughout the life of the project eliminates the potential for problems and scope creep. 1 Department of Financial Services - Information Systems Development Methodology Rapid Prototyping is a technique that requires close owner/user involvement. The greater the commitment of time and effort by the owner/user, the more the end product will satisfy the scope and shorten the delivery time of a system. By using agile techniques such as storyboarding and automated prototyping early in the development lifecycle, the owner/user can begin to see the system take shape early on rather than waiting until the very end to discover problems. The earlier the correction or change is detected, the easier it is to modify the system. Prototyping begins with very elementary, nonautomated representations, and gradually becomes more automated until it finally takes the shape of usable system modules. The DFS ISDM is designed to provide a consistent, repeatable process for developing systems. By referencing, utilizing and applying the techniques within this methodology, development teams have a standard framework necessary to efficiently and effectively scope a project, conduct analysis, define and design the solution, create the system modules and evaluate the system after its implementation. Put very simply, the DFS ISDM is a roadmap to successful systems development. The DFS ISDM is a living document with a built-in anticipation of continued growth and evolution parallel to the changing industry practices. This methodology will be properly enforced, and is intended for all new systems development efforts, excluding mainframe applications or sun-setting systems such as FLAIR. Methodologies for those areas will be maintained outside of this document. It is important to be aware, and knowledgeable, of all DFS ISDM related standards and procedures. All development teams are required to read all applicable development standards and operational procedures prior to initiating an information systems development project. ISDM related standards and operational procedures are available in the ISDM Toolkit, as are all ISDM Deliverable Templates. Please refer to the ISDM Usage Guidance document for additional information about the ISDM. 2 Department of Financial Services - Information Systems Development Methodology 3 Department of Financial Services - Information Systems Development Methodology DFS ISDM Phases & Review Points 4 Department of Financial Services - Information Systems Development Methodology 5 Department of Financial Services - Information Systems Development Methodology Phase 1: Customer Business Needs Analysis Roles & Responsibilities BRC and Customer Define Business Need and Business Requirements in Initial Scope Statement Document; Review Team determines quality of outputs (deliverables) for this phase and required deliverables for next phase. Description-Purpose In the first phase of the ISDM, the BRC and Customer identify problems, opportunities, objectives, and requirements from a business perspective. Inputs Statutes, Rules, Policies, business documentation related to the Need. Process Perform Business Needs Analysis Outputs Remedy Change Request, Project Classification Matrix, Initial Scope Statement Document; All additional deliverables determined by the business needs review team. Phase 2: Scope Definition Roles & Responsibilities Solution Provider and Customer Define the recommended solution, work packages, resource requirements, and overall risk rating for the project; Review Team determines quality of outputs (deliverables) for this phase and required deliverables for next phase. Description-Purpose In the second phase of the ISDM, the Solution Provider and Customer define the scope of the solution (or product to be developed). Inputs All outputs from previous phase. Process Perform Scope Definition Outputs Completed Scope Statement Document Required; All additional deliverables determined by the scope definition review team. . 6 Department of Financial Services - Information Systems Development Methodology Phase 3: Requirements Analysis Roles & Responsibilities Solution Provider and Customer Define the detailed system requirements including detailed system feature, user experience, logical condition, and process flow requirements; Review Team determines quality of outputs (deliverables) for this phase and required deliverables for next phase. Description-Purpose In the third phase of the ISDM, the Solution Provider and Customer elaborate on, and refine, the requirements gathered from the earlier phases to produce concise and complete system requirements for use in the product (solution) design phase. Inputs All outputs from previous phase. Process Perform Requirements Analysis Outputs: All ISDM and Project Management Deliverables are determined by the review team, with input from solution provider, in phase 2 (scope definition phase). Phase 4: Design Roles & Responsibilities Solution Provider designs the system including system features, data model, logical conditions, process flow, and user experience; Review Team determines quality of outputs (deliverables) for this phase and required deliverables for next phase. Description-Purpose In the fourth phase of the ISDM, the Solution Provider designs the system and obtains continuous feedback from the customer using methods such as functional design prototyping. Inputs All outputs from previous phase. Process Design System Outputs As determined by the review team at the end of the scope definition phase. 7 Department of Financial Services - Information Systems Development Methodology Phase 5: Development Roles & Responsibilities Solution Provider builds the product, including the bulk of the programming code. Solution Provider also conducts initial unit testing (of each module) during this phase; Review Team determines quality of outputs (deliverables) for this phase and required deliverables for next phase; assurance by the review team that the solution meets DFS development standards is critical during this phase-review. Description-Purpose In the fifth phase of the ISDM, the Solution Provider completes the development and documentation of the system and prepares for transition to the integration, test, and acceptance phase.. Inputs All outputs from previous phase. Process Development System Outputs As determined by the review team at the end of the scope definition phase. Phase 6: Integration, Test, Acceptance Roles & Responsibilities Solution Provider completes the programming, integration and system testing of all modules; Review Team determines quality of outputs (deliverables) for this phase and required deliverables for next phase; assurance (sign off) by the customer that the solution meets the requirements and passes user acceptance testing (UAT) is critical during this phase-review. Description-Purpose In the sixth phase of the ISDM, the Solution Provider integrates all system modules and provides the test group with at test plan; the solution provider works with the customer to ensure that UAT is completed and all known issues are documented. The solution provider ensures that all source code is version controlled. Inputs All outputs from previous phase. 8 Department of Financial Services - Information Systems Development Methodology Process Integrate and Test System Outputs As determined by the review team at the end of the scope definition phase. Phase 7: Implementation-Deployment Roles & Responsibilities Solution Provider works with the change manager, environment support teams, and customer to ensure successful implementation of system to production . Description-Purpose In the final phase of the ISDM, the solution is deployed to the production environment. The Solution Provider, Environment Support Teams, and Customer all confirm the system is functioning as expected in production. All users are notified and all appropriate system and user support documentation is distributed. Inputs All outputs from previous phase. Process Implement – Deploy System Outputs As determined by the review team at the end of the scope definition phase. Maintenance Maintenance is defined as the ongoing process of maintaining a system through deployment of defect fixes, implementation of scheduled enhancement releases, and daily support activities. DIS recommends that a Service Level Agreement (SLA) be completed at least annually to define the scheduled maintenance releases and agreed upon maintenance support resources for each existing system; the SLA should be signed by the customer and the Solution Provider (maintenance support) Manager. Maintenance releases are not considered ISDM Projects, and are not subject to ISDM deliverables and reviews. However, all maintenance releases must adhere to ISDM procedures and standards. 9 Department of Financial Services - Information Systems Development Methodology APPENDIX A - GLOSSARY BRC – Business Relationship Consultant. Each DFS (division or office) organizational area has a BRC representative within DIS. Customer – The primary stakeholder and typically the business owner of the solution. CM – Change Manager DIS – Division of Information Systems Environment Support Team (EST) – Production deployment teams. IRMAG – Resource and Project requestor (customer representative) ISDM – Information System Development Methodology. The incorporation of the seven SDLC phases, deliverables, templates, tools, and standards into an accepted, flexible, and repeatable framework. Module – Solution components broken into logical, manageable portions. Project – A time-limited undertaking to deliver a unique product, service or outcome. PM – Project Manager Quantitative Risk Analysis – The process of numerically analyzing the effect on overall project objectives of identified risks. SDLC – System development lifecycle; a seven-phase approach to systems analysis and design that holds that systems are best developed through the use of a specific cycle of analyst and user activities. Please see the ISDM Lifecycle checklist (spreadsheet) for an outline of the seven phases and associated deliverables. Solution Provider – The team, organization, or entity that has agreed to provide a system or product to meet customer’s needs. Work Package – The lowest hierarchical level of the work breakdown structure. Work packages represent deliverables on the project and should be small enough to estimate for cost and duration. 10 Department of Financial Services - Information Systems Development Methodology APPENDIX B – Applicable System Development Standards Application Development Standards Crystal Reports Development Standards Database Design and Coding Standards Platform/Environment Standards 11 Department of Financial Services - Information Systems Development Methodology APPENDIX C – Applicable Operating Procedures DIS 010 Database Change Request Procedures DIS 015 DIS Change Management Procedures Deployment & Source Control Procedures 12