Project Plan

Team Portion

Revised 10/31/2001

Team Members:

Dan Belina

Ben Colburn

Kieron Hinds

Paul Miles

Brief Overview of Project:

To create a standard Java-based Calendar Application that runs in the Mac OS X environment. The following features will be included:

  • Ability to schedule any number of events on one or more days. Events will include a title, description (optional), location (optional), and time (optional).
  • Events can automatically recur. The user can modify an individual occurrence of the event without affecting all other occurrences (maybe).
  • Hyperlinks will appear automatically for any email address or web address in the event’s description. This will open the user’s default web application with this information.
  • Standard view will show a month, with event times and titles listed in order.
  • Clicking on an event will show additional details for that event.
  • Users can open the application just like any other application.
  • (Optional)User can set alarms or reminders for an event. A daemon running in the background will alert the user when the application is not running.

Use Scenarios:

Software requirements: Users will be required to have Java 2 Runtime installed. The hardware requirements are the same as what is required by the Java 2 Runtime. MacOS X already has the Java 2 Runtime installed by default.

Installation: The user will be provided with a file that the user can execute by clicking on it. The installation option will install the application in a certain location, and add itself to an application menu where the user can use the program like any other. Also, the daemon will automatically start up at run time.

Opening the Application: The user will need to open the Applications folder, and then open the folder containing the program, the name of which has not been determined. The user will click on the icon to launch the calendar. The application will automatically open or create a calendar file that is stored in the user’s home directory.

Starting the Reminder Service(Optional): The daemon that acts as a reminder service will launch automatically upon machine startup by default. The user can start it manually in a similar way to opening the application.

Closing the Application: The user will close the application the same way any other Mac OS X application is closed. When it is closed, the calendar file that is open will be saved to disk automatically.

Ending the Reminder Service(Optional): The daemon that acts as a reminder service can be turned off by clicking on the taskbar icon and selecting to shut down the service from a pop up menu.

Saving a Calendar: The calendar will be automatically saved to disk after each event is added.

Scheduling an Event: After opening a calendar, the user can click the New Appointment Button to add an event. A dialog box will appear prompting users the enter the day, start time, end time, title, location, and description of the event. The day will automatically default to the current day highlighted in the Calender view. If the user wishes to make the even recur, the user will need to click on the “Recurrence” button of this dialog box. Another dialog box appears, allowing the user to select which weekdays the event recurs on, and how often. Finally, the user can select which day to end the final recurrence. An additional option will be to select a day for the event, but not a time. This is for events that don’t necessarily occur at a certain time of the day. When the user has entered all information and exits the dialog box, the event is saved and will appear on the calendar.

Viewing event details: After opening the application, the user will need to click on the appointment as it appears on the calendar. The appointment details will be shown on a “docking Detail Pane” at the bottom of the window. All of the information entered for the appointment will be displayed there. Changing the event details provides an alternate way for the user to view the details.

Changing event details: After opening the application, the user will need to double-click on the event as it appears on the calendar. The same dialog box that appeared when the event was entered will appear with the event details entered in. The user can change anything in this dialog box. If the user wants to make the event recur or change recurrence details already entered, the user can click the recurrence button and make changes in that dialog box.

Deleting an event: The user can click on the event, and then select an option for deleting the event.

Note: in all cases there may be additional ways of performing tasks that aren’t listed here. They will be determined during the design phase.

Development Environment:

The application will be written on Java 1.3.1 (Java 2) using the SDK. The SDK is available on Crux, and can be downloaded for free and installed on any machine supporting the Java 2 platform with a windowing environment. An IDE that might be used is Sun’s Forte for Java, Community Edition, downloadable for free. The IDE is not required, and all files can be edited using a simple text editor. Source control will not be used.

Data will be stored in the XML file format. Java’s API for XML Processing 1.1 (JAXP) will be used. Included with the API are Crimson and Xalan, which support parsing and XSLT respectively. The XML file format was chosen because it is easy to deal with, supported with software by Sun, is an open standard, and is “self-describing” in a file format.

Evaluation Criteria:

  • The user will provide feedback after each tollgate to ensure that the application meets the standards of a user friendly application and works correctly.
  • The final specifications of the project will be compared to the initial features list.
  • The records kept by team members will be compared to initial assignments.

Initial Size Estimate:

The size of the program code is expected to be less than 1MB. This does not include third party code. There will be around 50 class files for the user interface because of the object oriented nature of the Swing (Windowing) environment. There will be around 20 additional class files for application code relating to the calendar’s algorithm. There will be around 20 additional class files for application code relating to the calendar’s daemon.

Proposed Project Schedule:

10/8 – 10/26 Design phase

  • 10/8 – 10/15 Design GUI Layout on Paper
  • 10/8 – 10/20 Define Objects and Function Prototypes
  • 10/20 – 10/26 Refine Function Prototypes (look for “holes”)

10/26 – 11/28 Coding & Testing phases

  • 10/26 – 10/29Create stubs for all objects, create dummy windows
  • 10/29 – 11/7Create code for each major portion (daemon, saving to disk,

windows) and link to other code for Checkpoint 1 features

  • 11/7 – 11/11Testing, refining, and progress meeting
  • 11/11 – 11/17Create code for other features
  • 11/26 – 11/27No more features to be added, testing, and refinement only
  • 11/28 Final code due

10/8 – 12/3 Documentation phase

  • 10/8 – 10/15Add details to use cases, convert them to instruction manual
  • 10/20 – 10/26Refine documentation with changes made during design changes
  • 10/26 – 11/28Code documentation added on the fly (use Java Doc)
  • 11/28 – 12/3Check to ensure documentation matches actual procedure
  • 11/28 – 12/3Presentation preparation

In addition, all members are required to document what they worked on and when.

Concrete Checkpoints:

  • 11/7 Checkpoint 1 - Skeleton application with minimal functionality:
  • Basic GUI: - Presentable to user for feedback.
  • Backend Code ready for testing with stubs.
  • XML/Database module/interface ready for testing with stubs.
  • Merge of 3 components above - Ready for testing GUI compatibility with backend code, calendar events accessible from database.
  • Daemon runs as a standalone.
  • 11/18 Checkpoint 2 - Major features developed:
  • Completed GUI: Should be close to final as possible; GUI should meet major user

requirements.

  • Able to add and modify events: Backend code handles GUI events robustly.
  • Daemon responds to recurring events saved in database. Basic reminder functionality
  • 11/28 Checkpoint 3 - Necessary advanced Calendar and Daemon functions developed:
  • Different GUI views, user options specified by userid, installation packaged developed and ready for deployment.
  • Daemon issues reminder specific to user logged in; can be set to start automatically or manually. Also incorporated into installation package.
  • 12/3 Checkpoint 4 - Documentation Completed
  • Documentation reviewed by user for completeness and ease of use.
  • Installation documentation verified by actual installation by user.
  • All documentation made accessible Online?

Top Ten Risks:

  • Code written in Java is supposed to be platform independent, but it may not be perfect. Solution: investigate known issues regarding Java 2 on the Mac OS X platform; read white papers on Mac OS X Java 2 support.
  • Can a daemon made in Java run in the background on any platform, and is this doable without hindering the machine’s performance? Solution: If it isn’t, then just that portion can be written in an alternate language that the OS supports, such as C.
  • Existing open source applications may exist performing all of these tasks. Solution: look into existing applications; write the software anyway or incorporate its features and build on top of that.
  • Being able to complete enough of the application in time to make it usable. Solution: features are divided into checkpoints, ensuring that minimal but required functionality is available before anything else.
  • User may need extra software besides the main application as a method of storing data. Solution: explore memory requirements of loading Java objects for each event; compare to other calendars; check the XML standard; check external database engines.
  • Coordination efforts may be too complicated because there are four people in the group. There needs to be an efficient way to divide the workload up without one or two people doing a majority of the tasks. Solution: check general schedules to try and make sure people are available to work when they need to; achieve consensus in advance of what each person can do and when.

Team Structure

All team members will design code for what they are implementing during the design phase, but will need to present it to team members for review.

Kieron Hinds and Ben Colburn will work on implementing the GUI. Components.

Dan will work on implementing the calendar algorithms that provide the calendar functionality; He will work with the GUI sub-team to implement the main application container that owns all other application objects.

He will work with Paul to synchronize access of stored data through the data handler object which is also owned by the Main application container.

Paul Miles will work on the data access for the calendar, develop the installation package

and keep documentation.