Information Systems Development Methodology

advertisement
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
Download