CPSC319 Project Proposal

CPSC319 Project Proposal

Centralization of NIVMA Forms Data Specification

Team #: D1

Team Name: Macrosoft

Prepared for: Industrial Forestry Service Ltd.

Date: January 22, 2003

1. Description of the Proposed Product

Assumptions

·  PDA data input program will be able to take a configuration file that can change the form used for input.

·  PDA can store many forms and can load them in the field.

Description

The goal of the project is to centralize the NIVMA forms data specification in order to simplify making changes to the forms. To do this we will produce a forms specification file and two utility programs (one for the PC and one for PDA). The form specification file will contain all the data field specifications and will be written in XML. The user will be able to change the data field specifications within the file and use the utility programs to quickly generate updated forms.

The PDA utility program will create the data entry program for field data collection to be used on a PDA, while the PC utility program will generate the PC database application, which will also allow the user to print off paper versions of the form.

To run the PDA data entry program, the user downloads the PDA program and the XML file and installs and runs the program. The program will create a PDA form based on the data specifications taken from the XML file. It will allow the user to enter data from their PDA. Once the user has completed entering data, they must save the data. Before saving the data, the program validates it to ensure that it is in the correct format for upload to the database, this ensures database integrity. The user can then synchronize their PDA’s to the PC, to upload the data file. The PC utility takes the data file and loads the data into the database.

To run the data entry program on the PC, the user must install the program. The program will create a database application based on the XML data specification file. The user can select the form they would like to use to enter data by selecting the XML file they would to load. Before entering any data, the user has the option of printing out paper copies of the form. They can then enter data into the form to be uploaded to the database. The program validates the data before it is uploaded to the database.

Both programs will create forms that have a form name, description, and a list of expressions of valid field values. Error messages will be associated with each expression to communicate with the user the valid field values if they enter an incorrect field value. Forms will also contain fields, which have a field name, type (number or varchar), a paper form cell number, and a description. Certain fields (read-only) will have their value read in from the database and will not be modifiable by the user.

Basic Diagram

Questions & Comments

1.  How are PDA forms currently modified?

2.  We need documentation for communicating with TRENDS database system.

3.  We need details on how to handle data received from a PDA.

4.  We need a sample of various forms and a list of data types expected (e.g. date? time?).

5.  What fields are typically "read-only" and what are examples of their use and functionality?

6.  What possible precautions could we take to ensure data integrity and accuracy?

7.  What can we assume to be reasonable time efficiency and what can we assume to be within the range of reasonable program/data/configuration size?

8.  Can the PDA's use multiple forms at a time (e.g. switch forms in the field)?

Scenarios

I. How to open an XML file on the PC Utility for data entry

1)  Run PC Utility

2)  Select “Open XML file” option in Menu

3)  Find and select XML form to load

4)  Enter data into fields

a)  To upload data set to TRENDS, Select “Upload Data” option in Menu

II. How to open an XML file on the PDA Utility

1)  Run PDA Utility

2)  Synchronize XML file to your PDA

3)  Select “Open XML file” option in Menu

4)  Find and select XML file to load

III. How to print a blank data-entry form

1)  Run PC Utility

2)  Open an XML file on the PC Utility

3)  Select “Print Form” option in Menu

IV. How to enter and save data from the PDA to your PC

1)  Run PDA Utility and open XML file (refer to scenario II)

2)  Enter data into fields

3)  Select “Save Data” option in Menu

4)  Use PDA software to synchronize data into PC

5)  Run PC Utility

6)  Select “Open PDA data” option in Menu

(Edit data if necessary)

7) Select “Upload data” option in Menu

Non-Functional Requirements& Pseudo Requirements

Platform:

Window

Tools and Languages:

·  XML

Store the specified file as a XML file, which can be served as a HTML file by XSL

·  Java

The project will be implemented in Java using the Eclipse IDE. The use of Python is a possible option. Since our group members are more familiar with Java and no one in our group knows Python well, considering the short time we have for this project, we will implement it with Java.

User Interface:

·  The Centralization of NIVMA Forms Data (CNFD) will offer a graphical, window based user interface, controlled by the user through keyboard and mouse.

·  User can create a form and define one or more fields. Form and all related fields will be stored into database.

·  User can select one or more form from a list and download them to Palm Handheld. From Palm Handheld using an IE or Netscape browser a CNFD form can be selected for data entry. Data in Palm Handheld will be save in XML format for each form separately.

·  All XML data will be uploaded to a central computer and can be will be parsed, validated and stored into database.

Performance:

CNFD performance should be fairly fast unless the data, which will be collected from users, is big in length. Transforming data from Palm Handheld to central computer will depends the type of technology in and performance of Palm Handheld.

Glossary

Configuration File: File created for the PDA to create/update forms.

HTML: Hypertext Markup Language

PDA: Personal digital assistant, used here as a generic description for Palm Handheld.

XSL: Extensible Stylesheet Language

XML: Extensible Markup Language, a flexible programming language similar to HTML, that allows users to customize their tags.

Template form: Form accessible through main program that allows user to modify data

fields.

Screen Mock-ups

This is a sample of a form screen. This screen is the PC version. Clicking the Print Form button will print out a blank paper form. Clicking the Update Data button will send the record inputted into the form to the database given that the fields are valid. The PDA version of the form screen will look the same but without the Print Form Button and instead of Update Data the button is Save Data. Clicking on the Save Data button on the PDA form screen will save the form data and have it ready to be synchronized with the PC for input into the database.

Deliverables to Client

Assuming completion of project, we will submit the source code for the form generator, documentation for code, as well as installation and user guides. If we are unable to complete the project, we will make notes of any works in progress and a list of known issues (if any).

2. Software Development Phases and Deliverables

List of Software Development Phases and their Associated Deliverables

During this project, we plan to complete the following software development phases and their associated deliverables.

·  Requirement Elicitation and System Specification – During this software development phase, we specify the system’s requirements the way the user and the client understand. This is done by determining the services and constraints the system should provide, and then creating a system specification.

Deliverables:

§  Section 1 of this proposal.

·  Requirement Analysis - During this software development phase, we describe what the system will do from a user's perspective.

Deliverables:

·  System Context Diagram,

·  Use Cases Model (Actors, Use Case Descriptions, Use Case Diagram),

·  Domain Object Model,

·  Refined GUI screen shots or diagrams.

·  Design - During this software development phase, we describe how the system will be constructed. This is done by structuring the system into components, by identifying the data the system is to manipulate, and by showing the interaction between these various components and the data.

Deliverables:

·  System Architecture (subsystems/components diagram),

·  Interface Descriptions,

·  Class Diagram,

·  Interaction Diagrams.

·  Implementation – A Java implementation of the design.

Deliverables:

·  Source Code,

·  Java Source Code Style Guide,

·  Executable version of the source code,

·  As of now, there are no additional files.

·  Testing - We ensure that the system works as expected by first creating Unit, Integration and System Test Plans, and by gathering Unit, Integration and System Test Results once the tests have been performed.

Deliverables:

·  Unit, Integration and System Test Plans and Results.

·  User Documentation - Any necessary user documentation such as the User Manual, Installation Manual, etc.

3. Team Members and their Roles

NAME: Caitlin Grace N Akai

EMAIL:

PROJECT PHASE LEADER: User Documentation

PROJECT PHASE SUB TEAM MEMBER: Design, Testing

MANAGERIAL ROLE: Contact Manager and Web Master

MANAGERIAL ROLE DESCRIPTION: Caitlin is responsible for managing communication between the client and the team members.

NAME: Palvir Deol

EMAIL:

PROJECT PHASE LEADER: Requirements Analysis

PROJECT PHASE SUB TEAM MEMBER: Design

MANAGERIAL ROLE: Communication Manager

MANAGERIAL ROLE DESCRIPTION: Palvir will be responsible for maintaining and managing the contact information and communication of her team.

NAME: Jessica Jing Li

EMAIL:

PROJECT PHASES SUB TEAM MEMBER: Requirement Analysis, User Documentation, Testing.

MANAGERIAL ROLE: Gantt and Allocation Chart Manager

MANAGERIAL ROLE DESCRIPTION: Jessica is responsible for keeping track and informing the team of the progress of the project and bringing to the team’s attention if a task begins to fall behind. She is also responsible for updating the Gantt chart and for updating the Working Allocation Chart weekly.

NAME: Parminder Mann

EMAIL:

PROJECT PHASES SUB TEAM MEMBER: Requirement Analysis, Design

MANAGERIAL ROLE: Configuration Manager

MANAGERIAL ROLE DESCRIPTION: Parminder is responsible for making sure that all the requirements are met for each software development phase after that phase has been completed.

NAME: David Adrian Swanton

EMAIL:

PROJECT PHASE LEADER: Implementation

MANAGERIAL ROLE: S/W Version Control Manager

MANAGERIAL ROLE DESCRIPTION: David’s managerial role asks him to provide the team with a means to control the various versions of the team’s software and documents.

NAME: Gregory Santos Tiu

EMAIL: or

PROJECT PHASE LEADER: Design

PROJECT PHASE SUB TEAM MEMBER: Implementation

MANAGERIAL ROLE: Research and Training Manager

MANAGERIAL ROLE DESCRIPTION: Greg is responsible for managing the research phase that is related to the team’s project and informing his team members of the results, such that the other members on the team begin to acquire the adequate skills they need for this project.

NAME: Brian Jan Kun Vuong

EMAIL:

PROJECT PHASE LEADER: Testing

PROJECT PHASE SUB TEAM MEMBER: Implementation

MANAGERIAL ROLE: Agenda and Minutes Manager and Risk Manager

MANAGERIAL ROLE DESCRIPTION: Brian is responsible for making sure agendas and minutes are posted in adequate time and is in charge of organizing the teams web site. He is also responsible for choosing a facilitator and a minute taker for each meeting. Brian is also responsible for recognizing and bringing to the teams attention of any potential risks as well as making sure to apply the action/contingency plan.

4. Project Schedule

Work Allocation Chart

This chart shows the number of hours we expect to spend on each of the project phases during the term.

Caitlin
Akai / Palvir Deol / Jing Li / Parminder Mann / Andy Sun / David Swanton / Gregory Tiu / Brian Vuong / Total
Requirement Elicitation / 5 / 5 / 5 / 5 / 5 / 5 / 5 / 5 / 40
Requirement Analysis / 5 / 15 / 15 / 15 / 15 / 5 / 5 / 5 / 80
High Level Design / 25 / 5 / 5 / 5 / 5 / 5 / 25 / 5 / 80
Low Level Design / 5 / 25 / 5 / 25 / 5 / 5 / 5 / 5 / 80
Implementation / 15 / 15 / 15 / 15 / 15 / 70 / 45 / 45 / 235
Testing / 20 / 5 / 20 / 5 / 20 / 5 / 5 / 20 / 100
User Documentation / 5 / 5 / 5 / 5 / 5 / 5 / 5 / 5 / 40
Administration / 25 / 25 / 25 / 25 / 25 / 25 / 25 / 25 / 200
Total: / 105 / 100 / 95 / 100 / 95 / 125 / 120 / 115 / 855

5. Risks and Plans

The following list provides the top three risks that we perceive may hinder our progress on the project. For each of these risks, we propose the following action and contingency plans.

Risk 1: (Structure)

The project may not be highly structured or well-defined and specifically-defined, which would lead to an incorrect, incomplete, and inconsistent system specification. Thus, the end product may be different from the client’s version of the end product.

Plan:

The direct course of action would include each member of the team making a thorough list of the areas of uncertainty (for example, areas that are not well-defined ) pertaining to the sections he/she is in charge of. At the next meeting with the client, all uncertainties on each of the group member’s lists should be completely clarified by the client and there should be no doubt in any of the team member’s minds about the project. The contingency plan, which would be implemented during the design phase, would consist of the team defining the project in as much detail as possible, and making sure the client agrees with the design changes and functionality.