Water Use Tracking Project

COMPREHENSIVE WATERSHED MANAGEMENT WATER USE TRACKING PROJECT

Development Case

Southwest Florida Water Management District 2379 Broad Street Brooksville, FL 34604-6899

Date Revision Description Author 4/20/2004 1.0 Final Approved Version Plato Consulting Development Case

1 Introduction The vision of the Water Use Tracking (WUT) System, as captured during the Executive Stakeholders Workshop, defines the system as:

“A GIS-based system that allows District employees and external customers to spatially and temporally track and analyze key Regulatory and Resource Management data.”

This system will support Southwest Florida Water Management District’s (SWFWMD) activities defined in the Southern Water Use Caution Area (SWUCA) Management Plan and to validate and assess the results of the SWUCA II Rules. Although this system is being built to support the efforts within the SWUCA, it will support the same functionality for anywhere within the District.

The purpose of this Development Case is to provide specific guidance for the software development of the WUT System. It outlines exactly:  which artifacts, or deliverables, will be produced,  what tools or templates will be used,  when the artifacts will be produced, and  with what level of formality they will be produced.

2 Overview of Development Process The WUT Project will follow IBM’s Rational Unified Process (RUP), a software development approach that is iterative, architecture-centric, and use-case driven. The RUP is a configurable software development process platform that delivers proven best practices and a configurable architecture. The RUP enables the software development team to select and deploy only the process components they need for each stage of the project. This customization of the RUP is outlined within this Development Case. The scope of this development case applies to all the RUP Phases (Inception, Elaboration, Construction, and Transition) of the WUT Project.

3 Phases The RUP provides a structured approach to iterative development, dividing a project into four phases: Inception, Elaboration, Construction, and Transition. Each of these phases will contain one or more iterations, which focus on producing the technical deliverables necessary to achieve the business objectives of that phase. Each iteration should be focused only on what is needed to achieve the business goals.

1 Water Use Tracking Project – April 20, 2004 Development Case 3.1 Inception Inception is the first phase of the RUP lifecycle. This phase is all about understanding what needs to be built including determining a vision of the project, the scope of the system, and its boundaries. It is also important to identify who wants the system and what it is worth to them. During this phase, the key system functionality is identified including the identification of the most critical aspects of the system. A high-level schedule, called the Project Plan, is produced during this time. The schedule gives an overview of the timeframe in which the project will be executed and when artifacts will be delivered.

Workshops are held during this phase of the project to gather the user’s requirements to the system and to identify the risks of the project. The stakeholders for the project are categorized into four categories: Executive Staff, Technical Staff, Science Business Staff, and Regulatory Staff. Workshops are held for each of these groups with follow-up one-on-one interviews to clarify or refine requirements. The agenda for each of these workshops is tailored to each of these groups. For example, the Executive Staff meeting is more focused on the vision of the project. The Technical Staff meeting is more focused on the technical risks of the project. The remaining two groups, mostly made up of the power-users of the system, concentrates on the actual requirements of the system.

Several artifacts are produced from these workshops. All the requirements gathered during these workshops are stored in the Requirements Traceability Matrix. Based on these requirements, a Use Case Model and accompanying Use Cases are developed. Non-functional requirements, those that cannot be included in a use case (e.g., system response time, background color, etc.), are included in a Supplementary Specification document.

It is also very important to determine the possible risks associated with this project. One of the benefits of an iterative approach is that risks can be identified and addressed early on in the project. If risks are left unaddressed, there is a potential in investing in a faulty architecture or a non-optimal set of requirements. Risks are important enough that they should be addressed at each iteration. However, not all risks will be addressed. Most of the effort will be in trying to mitigate the highest priority risks. The project risks and mitigation strategies are included in the Risk Assessment and Management Plan.

At the end of the Inception Phase of the project, an Iteration Plan is developed. The Iteration Plan is, in essence, a more detailed Project Plan and is a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration. The plan also includes the number of iterations to be executed for each phase. The WUT Project will include only one Iteration Phase.

3.1.1 Inception Phase Artifacts Artifact Tools Used Formal Deliverable Vision Document Microsoft Word Yes Project Glossary Microsoft Word Yes Supplementary Specification Microsoft Word Yes

2 Water Use Tracking Project – April 20, 2004 Development Case Artifact Tools Used Formal Deliverable Use Case Model and Use Cases Enterprise Architect / Yes Microsoft Word Requirements Traceability Matrix Microsoft Word Yes Development Case Microsoft Word Yes Storyboards Visual Studio .NET No Software Requirements Specification Microsoft Word Yes User Interface Prototypes Visual Studio .NET No Change Management Plan Microsoft Word Yes Risk Assessment and Management Plan Microsoft Word Yes Issues List Microsoft Word No Project Plan/Iteration Plan Microsoft Project Yes Programming Guidelines Microsoft Word Yes

3.2 Elaboration The second phase of the RUP lifecycle is the Elaboration Phase. The key aspects of the Elaboration Phase are the addressing of key risks to the project, the building of the skeleton architecture of the system, and refining of the Project Plan/Iteration Plan developed during Inception. Also during this phase, the project development team gets a more detailed understanding of the requirements for the project. Understanding the requirements allows for the chosen architecture to be validated.

Several new artifacts are created during the Elaboration Phase, as well as, the updating of a few created during the Inception Phase. A comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system, is documented in the Software Development Plan. Critical design decisions made during this time include the selection of technologies, main components, and their interfaces.

Another important artifact of this phase is the creation of Programming Guidelines. These guidelines are used during the development of the WUT software. Any programming standards provided to the project development team by SWFWMD will be followed. Any items not addressed by the given guidelines are outlined in the WUT Programming Guidelines.

The Elaboration Phase is where the idea of iterations becomes apparent. Documents created during the Inception Phase are updated. Major risks are addressed and included in an updated Risk Assessment and Management Plan. Most of these risks are addressed as a result of the detailing of the requirements, and the designing, implementing, and testing of the architecture. The Project Plan/Iteration Plan is also updated during this phase based on having a better understanding of the requirements. New and more refined requirements are also reflected in an updated Requirements Traceability Matrix.

3.2.1 Elaboration Phase Artifacts Artifact Tools Used Formal Deliverable Software Architecture Document Microsoft Word Yes

3 Water Use Tracking Project – April 20, 2004 Development Case Artifact Tools Used Formal Deliverable Architectural Proof of Concept Visual Studio .NET No Deployment Model Enterprise Architect Yes Design Model Enterprise Architect Yes Navigation Map Microsoft Word No Test Plan Microsoft Word Yes Test Cases Microsoft Word Yes Test Evaluation Summary Microsoft Word Yes

3.3 Construction The third phase of the RUP lifecycle is the Construction Phase. The goal of the Construction Phase is on clarifying the remaining requirements and completing the development of the system based upon the baselined architecture. The tasks of completing the analysis, design, development, and testing of all the required functionality is completed. Software builds, the actual executable software, and the Release Notes, describing each build, are the artifacts delivered during this phase. These tasks are completed iteratively and incrementally to develop a complete product.

3.3.1 Construction Phase Artifacts Artifact Tools Used Formal Deliverable Software Builds Visual Studio .NET Yes Release Notes Microsoft Word Yes Training Material RoboHelp / Microsoft Yes Word

3.4 Transition The final phase of the RUP lifecycle is the Transition Phase. The focus of the Transition Phase is to ensure that software is available to the end users. This phase will span several iterations and includes testing of the software in preparation for its release. Minor adjustments are made based on user feedback. These adjustments must focus on fine-tuning the software and not major structural issues, which should have been worked out earlier in the project lifecycle.

3.4.1 Transition Phase Artifacts No artifacts are started in the Transition Phase. Since the RUP is iterative, however, the fine- tuning and delivery of many of the artifacts are completed during this phase.

4 Disciplines A discipline is a collection of related activities that are related to a major area of concern within the overall project. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule. The artifacts listed previously for each phase are listed again in this section. Viewing the deliverables in this fashion is more of a roles,

4 Water Use Tracking Project – April 20, 2004 Development Case or skill set, based grouping of artifacts. The following sections describe the nine disciplines of the RUP and the artifacts produced for each discipline.

4.1 Business Modeling No business modeling, in a traditional sense, will be performed for the WUT Project. This is due to the fact that this software is not replacing a current business process. The software will be used, however, to assist the stakeholders in completing tasks associated with other business processes. Requirements for the WUT system to interact with any of these systems will be determined through the requirements gathering process. Business modeling will be done on an as-needed basis if the stakeholders do not have a clear vision of the process.

4.1.1 Business Modeling Artifacts No Business Modeling artifacts have been identified at this time.

4.2 Requirements The purpose of the Requirements discipline is to establish and maintain agreement with the stakeholders on what the system should do and to provide the project development team with a better understanding of the system requirements. Also, the boundaries of the system are established based on the requirements providing the basis to plan the iterations of the project, as well as, estimating a cost and the time required to develop the system.

4.2.1 Requirements Artifacts Artifact Tools Used Formal Deliverable Vision Document Microsoft Word Yes Project Glossary Microsoft Word Yes Supplementary Specification Microsoft Word Yes Use Case Model and Use Cases Enterprise Architect / Yes Microsoft Word Requirements Traceability Matrix Microsoft Word Yes Storyboards Visual Studio .NET No Software Requirements Specification Microsoft Word Yes

4.3 Analysis and Design The purpose of the Analysis and Design discipline is to transform the requirements that are gathered into a design for the system to be built. This is also the time to evolve the architecture the system will be built upon.

4.3.1 Analysis and Design Artifacts Artifact Tools Used Formal Deliverable Software Architecture Document Microsoft Word Yes Architectural Proof of Concept Visual Studio .NET No Deployment Model Enterprise Architect Yes Design Model Enterprise Architect Yes

5 Water Use Tracking Project – April 20, 2004 Development Case Artifact Tools Used Formal Deliverable User Interface Prototypes Visual Studio .NET No Navigation Map Microsoft Word No

4.4 Implementation The purpose of the Implementation discipline is to define the organization of the code, in terms of implementation subsystems organized into layers, and to implement the design elements. This discipline also includes the unit testing of the components and the integration of the individual components into an executable system.

4.4.1 Implementation Artifacts Artifact Tools Used Formal Deliverable Software Builds Visual Studio .NET Yes

4.5 Test The Test discipline acts as a service provider to the other disciplines. Testing focuses mainly on evaluating product quality and documenting any defects found in the software. Testing also allows for the validation of the assumptions made during design and to determine that the requirements are implemented properly.

4.5.1 Test Artifacts Artifact Tools Used Formal Deliverable Test Plan Microsoft Word Yes Test Cases Microsoft Word Yes Test Evaluation Summary Microsoft Word Yes

4.6 Deployment The Deployment discipline describes the activities associated with ensuring that the software product is available for its end users. Although deployment activities peak in the Transition Phase, some of the activities occur in earlier phases to plan and prepare for deployment.

4.6.1 Deployment Artifacts Artifact Tools Used Formal Deliverable Release Notes Microsoft Word Yes Training Material RoboHelp / Microsoft Yes Word

4.7 Configuration and Change Management The Configuration and Change Management discipline controls change to, and maintains the integrity of, a project’s artifacts. This involves identifying configuration items, restricting changes to those items, auditing changes to those items, and managing configurations of those items. Configuration and Change Management is an essential and integral part of the overall development process.

6 Water Use Tracking Project – April 20, 2004 Development Case 4.7.1 Configuration and Change Management Artifacts Artifact Tools Used Formal Deliverable Change Management Plan Microsoft Word Yes

4.8 Project Management The goal of Project Management discipline is to provide a framework for managing the software project by planning, staffing, executing, and monitoring the project. Managing risks is one of the key aspects of this discipline. Also, the planning of the project through a Project Plan/Iteration Plan is important.

4.8.1 Project Management Artifacts Artifact Tools Used Formal Deliverable Risk Assessment and Management Plan Microsoft Word Yes Issues List Microsoft Word No Project Plan/Iteration Plan Microsoft Project Yes

4.9 Environment The Environment discipline focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organization with the software development environment—both processes and tools—that will support the development team.

4.9.1 Environment Artifacts Artifact Tools Used Formal Deliverable Development Case Microsoft Word Yes Programming Guidelines Microsoft Word Yes

7 Water Use Tracking Project – April 20, 2004 Development Case