Project Description
| Winter Quarter 1996 January 23, 1996
Document Author:
Project Sponsor:
| Yakko Wakko and Dot Profile Team:
Manager: Harry Marlin |
Tentative 1996 Winter Quarter Project Schedule
Yakko Wakko and Dot Profile (YWD Profile) project team is a subgroup of the Java as Desktop project. Our project is focused on building a Java calendar browser applet. The College of Computing currently uses two calendar programs: Now Up-to-Date and the X utility "plan". The Now Up-to-Date application runs on MacIntosh platform while the "plan" utility runs on Unix workstations. People with accounts in the College of Computing have the option to create a publicly readable calendar file. Our Java calendar applet must be able to read and display the information in the calendar file, allow updates to the calendar from Java, and be able to browse other people's calendar and schedule appointments.
There are several precursor systems that attempts to do the same tasks. This project team will study these other works to gain insight on the inner-working and pros and cons of the system. By studying the existing systems we will be able to create a new system that is an improvement from the existing ones. The precursor systems to be studied are: Netscape Calendar, DISCS, and previous Java Prototypes.
The Netscape Calendar was created by a College of Computing undergraduate. The application uses Hypertext Markup Language along with Perl to produce a browse-able calendar on Netscape. DISCS is a continuing project as part of the Real-World Lab (CS 4310/1/2) that implements a calendar system for the Office of Information Technology (OIT). Several College of Computing graduates have done initial Java prototypes for an edit-able calendar.
Many of the previous systems that we are going to study are written in HTML. The limited functions in HTML places many constraints on what the system can provide. Building a calendar program with Java applets provides us with more functionality and options. With the more powerful Java applet, the new calendar will be a vast improvement from previous systems.
We have discovered that a College of Computing graduate student named Anind Dey is also doing a similiar project with us. With Dr. Abowd's approval, Anind has joined our group and will work as the third programmer for this project. Anind is joining our group at the beginning of our development (when we are learning Java). Being able to train and work with us from the very beginning, Mr. Dey will be a great asset to our project team.
| Important Client Deadlines | ||
|---|---|---|
| Part to Turn in | Deadline | General Description |
| Project Plan | January 12th, 1996 | o Team introduction o Project schedule o Explanation of activities o Brief project description |
| Requirements Document | January 29th, 1996 | o List of functional activities o Storyboard |
| Design Document | February 9th, 1996 | o Describe how the system is implemented |
| Initial Prototype | February 23th, 1996 | o Cool looking Java calendar |
| Final Project Notebook | March 3rd, 1996 | o Software ready to ship and sell |
| Tentative 1996 Winter Quarter Project Schedule | ||||||||
|---|---|---|---|---|---|---|---|---|
| Activities | Jan 15 | Jan 22 | Jan 29 | Feb 5 | Feb 12 | Feb 19 | Feb 26 | Mar 4 |
| Learning Java | xxxxx | |||||||
| Requirement Gathering | xxxxx | |||||||
| Create Goals | xxxxx | |||||||
| Requirements Document | xxxxx | |||||||
| Brainstorm | xxxxx | |||||||
| Design Document | xxxxx | |||||||
| Design Review | xxxxx | |||||||
| Final Design | xxxxx | |||||||
| Module Implementations | xxxxx | |||||||
| Component Testing | xxxxx | |||||||
| Component Debugging | xxxxx | |||||||
| Component Re-Testing | xxxxx | |||||||
| Component Revision | xxxxx | |||||||
| System Integration | xxxxx | |||||||
| System Testing | xxxxx | |||||||
| System Debugging | xxxxx | |||||||
| System Re-Testing | xxxxx | |||||||
| System Revision | xxxxx |
We will be developing a prototype using Java applets. The applets will be executable within both Java browsers and Netscape 2.0bx browsers. All members of the team will be engaged in this activity. The programmer and architect will spend most of their time learning the applet language and gathering tutorial materials to build up their experience. The programmers will then hold a training session for the remaining project team members.
Architect (10 hrs), Programmers (45 hrs), Manager (2.5 hrs), Writer (2.5 hrs)
January 22, 1996. The training session will be on the team meeting date, which is January 30th, 13:00 at CoC202.
Requirements Gathering (10 hours)
We will be conducting interviews with the stakeholder (in this case, Dr. Abowd) to gather requirements for the system.
Architect (5 hrs), Manager (2.5 hrs), Writer (2.5 hrs)
January 24, 1996.
The manager will create goals for the system. The list of goals will dictate the essentials for the system and, if time allows, options and extra functionality that may make the system more useable and/or powerful. The obstacles and constraints will be considered.
Manager (4.5 hrs), Writer (0.5 hrs)
January 26, 1996.
Requirements Document (40 hours)
The requirements document will specifies what the system will do and functionalities that the system will have. The document will also give scenarios and storyboards on the behavior of the system. This is what the system will be build on.
Architect (20 hrs), Programmers (5 hours), Manager (5 hrs), Writer (10 hrs)
Projected Deadline: January 27, 1996.
Client Due Date: January 29, 1996.
The manager and architect will brainstorm on possible functions for the calendar.
Manager (3 hrs), Architect (3.5 hrs), Writer (0.5 hrs)
January 29, 1996.
The design document will give specific description on the functionality of various modules. How the modules link to other modules will be display in graphical form. The programmers will base their implementation on the design document to ensure coherence among the different modules that will be written by different programmers.
Architect (40 hrs), Programmer (30 hrs), Manager (6 hrs), Writer (20 hrs)
Projected deadline: February 6, 1996.
Client Due Date: February 9, 1996.
The whole team will review the design that decide if there should be any changes. This is the last chance to do any significant design changes.
Architect (5 hrs), Programmers (10 hrs), Manager (3 hrs), Writer (2 hrs)
February 9, 1996.
This is after the design document is turned in to the client and changes will be made to the design document according to the client`s suggestion.
Architect (5 hrs), Writer (5 hrs)
February 12, 1996.
Module Implementations (90 hours)
With the design document finalize, the programmers will implement the modules specified in the design document. The architect will coordinate the assignment and the manager will oversee the project. The writer will keep note of the problems that the programmers encountered in order to document it.
Architect (10 hrs), Programmer (60 hrs), Manager (10 hrs), Writer (10 hrs)
Projected Deadline: February 19, 1996.
Client Due Date: February 23, 1996.
The programmers will test the components with various data sets to uncover problems with modules.
Programmer (10 hrs)
February 19, 1996.
The programmers will fix problems that might exist in the program. At this stage, the modules should be almost complete except with the exception of problems with selected test sets.
Programmer (20 hrs)
February 21, 1996.
Component Re-Testing (10 hours)
After the "bugs" are detected and fixed, there should be another test phrase to make sure no addition bugs appears. Fixing one problem of a program might result in another problem, this phrase is used to eliminate additional problems.
Programmers (10 hrs)
February 24, 1996.
This is the last stage of the component test phrase. The architect will work with the programmer to make sure the components are implemented according to the design document and that different components are compatible when put with each other.
Architect (2 hrs), Programmers (10 hrs)
February 26, 1996.
The architect will assist the programmers in integrating the various components together. The writer will be present to document any difficulties the team might encounter. The modules will be put together and will work as a whole.
Architect (5 hrs), Programmers (10 hrs), Writer (5 hrs)
February 29, 1996.
After the modules are integrated, sample test data must be runned to make sure the modules behave as they were when it was independent. Addition problems regarding integration might be detected.
Programmer (10 hrs)
March 1, 1996.
The system testing phrase will most likely uncover additional bugs that were not detected earlier. This is the last chance for the programmers to detect bugs that exists in the system and bugs that might arise from the integration of various modules.
Architect (5 hrs), Programmer (15 hrs), Manager (5 hrs), Writer (5 hrs)
March 4, 1996.
The programmers will fix many bugs in the debugging phrase. This phrase is used to re-test the system to make sure that no additional bugs appears because of the previous phrase.
Programmers (20 hrs)
March 6, 1996.
Problems detected in the re-test phrase will be corrected in the revision phrase. This phrase corrects any last minute problems that might appear.
Architect (5 hrs), Programmers (15 hrs), Manager (5 hrs), Writer (5 hrs)
March 11, 1996.
| 
| 
| 
| 
| 
| 
|
| Top | Plan | Req Doc | Design Doc | Prototype | History | Revision |