Project Proposal

Document Sample
Project Proposal Powered By Docstoc
					Statement of Work
    Version 2.0


December 13, 2004




                    Pandora Team




                    Averett, Grant
                    Gurson, Adam
                    Nguyen, Minh
                    O’Hara, Richard
                                 Statement of Work

Document Revisions

Revision   Date       Contributor        Comments
0.1        9/20/04    Richard O’Hara     Created initial draft of Statement of Work.
0.2        9/28/04    Grant Averett      Review, added change management section
0.3        9/30/04    Grant Averett      Review, reformatted into Pandora template
0.4        9/30/04    Grant Averett      Reformatted the document
0.5        10/04/05   Richard O’Hara     Framework task, deliverables, customer
                                         furnished information. Turned off
                                         hyphenation format.
0.6        10/17/04   Richard O’Hara     Modifications from 10/15 meeting
0.7        10/20/04   Richard O’Hara     Per-MOSP Draft Version
1.0        10/21/04   Richard O’Hara     MOSP Draft Version
           11/16/04   Richard O’Hara     Added use cases as a deliverable
2.0a       12/6/04    Richard O’Hara     End of semester update
2.0        12/13/04   Richard O’Hara     Final version with customer’s changes




Pandora SOW                        Page 2 of 9
                                                          Statement of Work

                                                       Table of Contents


1     BACKGROUND ....................................................................................................... 4
2     SCOPE ....................................................................................................................... 4
3     TASKS ....................................................................................................................... 5
    3.1       FRAMEWORK ....................................................................................................... 5
      3.1.1      Parsers ....................................................................................................................... 5
      3.1.2      Accessors ................................................................................................................... 5
      3.1.3      Models ....................................................................................................................... 5
      3.1.4      Correlators ................................................................................................................ 6
    3.2       DEMONSTRATION CAPABILITY ............................................................................ 6
      3.2.1      Data Parsers .............................................................................................................. 6
      3.2.2      Data Generation ........................................................................................................ 6
      3.2.3      First demonstration scenario ..................................................................................... 6
      3.2.4      Second demonstration scenario ................................................................................. 7
      3.2.5      Integration into visualization environment ................................................................ 7
    3.3       MANAGEMENT TASKS .......................................................................................... 7
    3.4       SOFTWARE PROCESS DEFINITION .......................................................................... 7
4     DELIVERABLES ..................................................................................................... 7
5     CHANGE CONTROL .............................................................................................. 8
6     PERIOD OF PERFORMANCE .............................................................................. 8
7     CUSTOMER FURNISHED ITEMS ....................................................................... 9




Pandora SOW                                                  Page 3 of 9
                                      Statement of Work


1 Background

IAI has had great successes in the software realm with projects that have a large
visualization component, especially in the area of geospatial analysis. We have thrived in
creating an easy-to-use web-based suite of tools that provides capabilities such as
mapping, targeting, and tracking.

To better allow us to handle the dynamic needs of our many customers, we have created a
visualization coding toolkit called Planet3. Planet3 is a set of JAVA components that can
be easily extended to meet the needs of the specific data sets and user preferences for
with a given customer. It is the standard front-end solution for IAI visualization.

While IAI has secured a front-end toolkit, it does not yet have an internal toolkit that can
be used on the back-end of a system for handling the parsing, automated analysis, and
user notification associated with various data sets. The ultimate goal of the IAI MSE
Studio Team to create a back-end analysis framework that can become the IAI standard
code base for data analysis.

Planet3 is not a customer deliverable, itself. When a new customer approaches IAI with
data visualization needs, the Planet3 toolkit is extended as necessary to build a solution
specific to the individual needs of that customer. In an analogous fashion, the analysis
framework to be built by the IAI Studio Team will not be designed to be a customer
deliverable by itself. Its purpose is to be a development toolkit from which analysis
solutions of new data types can be rapidly generated.

The analysis framework will likely consist of a set of components such as parsers,
correlators, and digital models that will be extensible to meet the needs of a specific data
analysis problem. These components will reside within a communication system that can
be easily integrated with any visualization solution (including Planet3) to create a fully
user-interactive tool. For more information on the concept of this framework, see the
Analysis Framework PowerPoint brief.

Since a framework is not easily testable and demo-able by itself, the IAI Studio Team has
chosen to implement the framework by creating a solution to a specific business problem.
The framework and the demonstration capability will compose project Pandora.

2 Scope

The Pandora project is not a traditional IAI project, but rather the group studio project
required as part of Carnegie Mellon University’s (CMU) Master of Software Engineering
(MSE) program. The goal of the studio program is to allow the MSE students to apply
skills learned in the classroom under the supervision of CMU mentors to real work
problems.


The MSE team consists of Grant Averett, Adam Gurson, Minh Nguyen, and Richard
O’Hara. All tasks under this contract performed by the MSE team will be within the


Pandora SOW                             Page 4 of 9
                                     Statement of Work

project hours assigned to the MSE studio program. The studio program consists of four
consecutive semesters of work starting with the fall 2004 semester. 12 hours are
allocated per week per student for the fall 2004 and spring 2005 semester. 30 hours per
week are allocated for the summer 2005 session and 18 hours per week for the fall 2005
semester. Initial operating capability will be reached by the end of the summer session
and the fall 2005 session will primarily consist of lessons learned and system
maintenance. As part of the allocated time, students will nominally spend 1.5 hours per
week meeting with the program mentors.

With the exception of the summer session, all of the hours worked by the MSE team will
be on their own time. During the summer 2005 session, IAI will allocate six overhead
hours per week to each student to aid in the completion of Pandora.

Should the customer want to change any deliverable set forth in this SOW, the Pandora
team will follow standard change control procedures described in Section 5.

3 Tasks

The underlying technical goal of Pandora is to produce a generic framework that would
aid in the analysis of problems and could be applied to a wide variety of problems. The
Pandora framework will consist of parsers, models, and correlators.

3.1     Framework

The framework consists of the underlying reusable components necessary to analyze
problems. The framework consists of parsers which read raw data into the system,
models which represent the expected behavior of a system, and correlators that analyze
data. The framework components must be designed to be extensible. Some of the
components when realized into actual system components may have real-time
requirements. Although the generic framework does not have any performance
requirements, design decisions should not preclude real-time performance.

3.1.1    Parsers

As their name implies, parsers are the components of the system responsible for
interpreting and storing all incoming data. To aid in the creation of the framework, a
generic parser will be created that will have the capability to receive incoming data. The
data will then be parsed as appropriate and stored in a specified database. The generic
parser will support both raw and processed data.

3.1.2    Accessors
Accessors are components responsible for reading the parsed data and organizing it into
one of many user relevant arrangements. A generic accessor component will be created
and will have the ability to act as a server or client to access the data.

3.1.3    Models



Pandora SOW                            Page 5 of 9
                                     Statement of Work

A model represents the known or expected behavior of a system. It is essentially
digitized knowledge of a the domain. A model may be manually created by a domain
expert, or it may be the derived result of correlation. To aid in the creation of the
framework, a generic model will be created that can be used as a template for
representing expected behaviors, trends, or anomalies. The format chosen to represent the
models should be flexible enough to permit dynamic changes from both users as well as
subsequent correlation efforts.

3.1.4    Correlators

Correlators compare both parsed and correlated data in order to determine anomalies,
trends, or behaviors. Two generic correlators will be built for this framework. One
correlator will be responsible for correlating parsed data against a related model in an
effort to detect anomalies. Another correlator will be responsible for reading parsed data
and generating a model for the data based on trending patterns in the data.

3.2     Demonstration Capability

The demonstration capability is designed to be both a proof of concept implementation of
the framework as well as a demonstration tool. Pandora will have two demonstration
scenarios. The first scenario will demonstrate the ability of the Pandora Framework to
monitor specified data sources in real-time and alert user when user-designated situations
of interest are detected (user generates the model). The second scenario will demonstrate
the ability of the Pandora Framework to monitor specified data sources in real-time and
alert user when potentially new situations of interest are detected (correlators update the
model).


3.2.1    Data Parsers

Data parsers will be developed that parses the data for the simulated satellite and
supporting data sources. The data will include such narrow band items such as satellite
orientation, orbit, as well as expected characteristics of the satellite Radio Frequency
(RF) feed.


3.2.2    Data Generation
The developer will determine which data fields are relevant for the demonstration
scenarios, and will generate the data sets necessary to demonstrate the framework.


3.2.3    First demonstration scenario
The first demonstration task will demonstrate the capability to correlate an incoming
satellite data feed against a user defined model. The correlator will alert the user
whenever an incoming data value is out of the range defined in the model.




Pandora SOW                            Page 6 of 9
                                      Statement of Work

3.2.4    Second demonstration scenario
The second demonstration scenario is designed to demonstrate a predictive analysis
capability. The Pandora developer will create a correlator capable of creating a model of
expected satellite parameters based on historic satellite data. This generated model must
then be correlated against current satellite data.

3.2.5    Integration into visualization environment

The Pandora team will integrate the framework along with the demonstration capabilities
into a visualization environment. The visualization environment will provide web based
access to the demonstration capabilities. The visualization environment will show the
user the models, and alert the user to anomalies found during correlation. In addition to
providing the capability of running the parsers and correlators, the visualization
environment shall allow the user to see which parsers, correlators, and models are
available, update models, and view correlation results.

3.3     Management tasks

The MSE team will support a weekly team status meeting with their CMU mentors.
Additionally, each member of the MSE team will support an individual meeting for one
half hour each week.

The MSE team will also support a weekly customer status meeting with the customer
representative. The customer meeting may be cancelled for a given week if agreed upon
by the MSE team and the customer.

3.4 Software process definition
The Pandora team will define and follow a formal software development process.
Process documents will be provided to the customer.


4 Deliverables

Table 1 lists the items to be delivered to the customer as well as the delivery dates.
Format of the items will be defined by the development team.




Pandora SOW                             Page 7 of 9
                                     Statement of Work

 Item                                             Delivery Date
 Software Process Documents                       As appropriate
 Use Cases                                        December 9, 2004
 Software      Requirements      Specification    December 14, 2004
 (framework requirements)
 Software      Requirements      Specification    May 7, 2005
 (demonstration requirements)
 Software      Requirements      Specification    May 7, 2005
 (visualization requirements)
 Software Design Document                         May 7, 2005
 System Con-ops                                   May 7, 2005
 Verification and Validation Plan                 May 7, 2005
 Demo Slick Sheet                                 December 9, 2005
 Demonstration Script                             December 9, 2005
 Programmers’ Guide                               December 9, 2005
 Source Code and Executable Software              December 9, 2005
 Test Report                                      December 9, 2005
                               Table 1: Pandora Deliverables

5 Change Control

The objectives of change control are to:

   1.   Assess the impact of scope changes on project schedules, resources, and pricing
   2.   Provide a formal process for approval to proceed with any changes for this SOW
   3.   Establish the impact of any changes
   4.   Provide a project audit record of all material changes to the original SOW

If the customer requests a material change in the scope of this SOW, as determined by the
Pandora team in its sole discretion ("Change"), the Pandora team and the customer will
review the Change through the following change control process. If the Pandora team
determines a change is material, the Pandora team will complete the Change Request
Form (the "Form") and provide the completed Form to the customer. Both the Pandora
team and the Customer will have to provide written approval of the Change detailed in
the Form, including the impact of the Change on the schedule and resources, before the
Pandora team will make the Change. If the customer does not accept the Change as set
forth in the Form (including the impact on the schedule or resources), the Parties will
complete their obligations with respect to this service as set forth in this SOW.

6 Period of Performance

The period of performance for Pandora will be from September 8, 2004 to December 9,
2005. Work periods coincide with Carnegie Mellon semesters. During semester breaks no
work will be performed




Pandora SOW                            Page 8 of 9
                                      Statement of Work

7 Customer Furnished Items



Table 2 lists the items to be delivered by the customer as well as the delivery dates.
  Item                                             Delivery Date
  Demonstration scenario                           November 1, 2004
                                Table2: Customer Deliverables




Pandora SOW                             Page 9 of 9

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:9/11/2012
language:English
pages:9