Difference between revisions of "Planning"
Line 7: | Line 7: | ||
:Purpose | :Purpose | ||
::In general terms the purpose is to improve quality, use, and appreciation of Earth science | ::In general terms the purpose is to improve quality, use, and appreciation of Earth science | ||
− | :: | + | ::Specific terms present prioritized list stating desired progress toward each Goal in [[Media:StrategicPlan FINAL.doc|Strategic Plan 2004-2007]]. |
:Stakeholders (not just users) | :Stakeholders (not just users) | ||
::Primary: Foundation, Federation, Partners | ::Primary: Foundation, Federation, Partners | ||
Line 16: | Line 16: | ||
:Scope | :Scope | ||
::Incremental stages to desired end | ::Incremental stages to desired end | ||
− | :::Which changes do we plan to make in which order why | + | :::(Which changes do we plan to make in which order why?) |
::Planned milestones, benchmarking, and target | ::Planned milestones, benchmarking, and target | ||
− | :::Express targets as | + | :::(Express targets as the tests that would show success) |
==Requirements== | ==Requirements== | ||
Line 36: | Line 36: | ||
==Analysis and Design== | ==Analysis and Design== | ||
− | This step depends on the evolving requirements and will involve managers and the implementors: Atlantic BT, NGDC, ESRI, etc. Budget contingencies be part of the design documentation. | + | This step depends on the evolving requirements and will involve managers and the implementors: Atlantic BT, NGDC, ESRI, etc. Budget contingencies and fund raising efforts should be a specific part of the design documentation. |
==Implementation== | ==Implementation== | ||
Line 43: | Line 43: | ||
<center>Figure 2. Federal Enterprise Architecture Implementation Diagram</center> | <center>Figure 2. Federal Enterprise Architecture Implementation Diagram</center> | ||
<br> | <br> | ||
− | This will involve staged implementation according to a sequencing plan recruiting already-existing components. We expect implementation to involve multiple components, each | + | This will involve staged implementation according to a sequencing plan depending at least initially on heavily recruiting already-existing components. We expect implementation to involve multiple components, each having their own separate implementation state, level-of-effort, and sequencing plan. |
Revision as of 14:52, January 23, 2006
Developing the ESIP Exchange will involve a number of iterations through the following five steps:
Vision Document
The full vision document should list:
- Purpose
- In general terms the purpose is to improve quality, use, and appreciation of Earth science
- Specific terms present prioritized list stating desired progress toward each Goal in Strategic Plan 2004-2007.
- Stakeholders (not just users)
- Primary: Foundation, Federation, Partners
- Secondary: Earth scientists, modelers, decision tool providers, decision makers, education
- Components
- esipfed.org, GOS2, wiki.esipfed.org, GCMD, ECHO, ESG, CLASS, NOMAD
- (What else?)
- esipfed.org, GOS2, wiki.esipfed.org, GCMD, ECHO, ESG, CLASS, NOMAD
- Scope
- Incremental stages to desired end
- (Which changes do we plan to make in which order why?)
- Planned milestones, benchmarking, and target
- (Express targets as the tests that would show success)
- Incremental stages to desired end
Requirements
- Glossary
- Functional Requirements
- Specify and prioritize elements from the various Federation Documents.
- Capture viewpoints of each of the various stakeholders.
- Nonfunctional Requirements
- Performance, Interoperability, Security, Hardware
- Use Cases
- Key scenarios that exemplify the functional and nonfunctional requirements
- Raise each scenario to a family of use cases
- Tests
- Each requirement will be defined in terms of a test that would show success
Analysis and Design
This step depends on the evolving requirements and will involve managers and the implementors: Atlantic BT, NGDC, ESRI, etc. Budget contingencies and fund raising efforts should be a specific part of the design documentation.
Implementation
This will involve staged implementation according to a sequencing plan depending at least initially on heavily recruiting already-existing components. We expect implementation to involve multiple components, each having their own separate implementation state, level-of-effort, and sequencing plan.
Deployment
- Roll out and promotion
- All components are currently deployed with a variety of levels of use. Advertising and marketing the integrated ESIP Exchange will take place for targeted communities based on tests at each stage of integration involving sample audiences. We are essentially “Building our ship at sea”.
- Impact evaluation
- At each stage we will set benchmarks and targets and evaluate performance.
- Continual Redesign
- As the system evolves we expect both evolutionary and revolutionary changes involving coordination and support from initially independent components. We hope to move from aggregates to become and integrated “system” across components and knowledge environments.
(I am using this page to begin a discussion that I hope will become the development plan (and eventual budget) for the ESIP Exchange. As of now, these are the comments of one person. (Howard Burrows 18:09, 20 January 2006 (EST)) This plan is based on a book by Jim Conallen entitled "Building Web Applications with UML Second Edition". In addition, it adopts elements of the Federal Enterprise Architecture (see Guide to FEA and e-Gov Site).)
Eventually, it might be useful to construct the ESIP exchange using a collection of interrelated "reference models" as employed by the US Government in the Federal Enterprise Architecture.
The most important aspects of our development strategy are shown on the left and right of Figure 1. Construction will be driven by the "business" of the Federation as described in our Federation Documents. The result will follow a component-based architecture.
In addition, we will be performance-driven and will design-to-test (DTT).