Deliverable 3: Initial Public Release

Software Architecture and Design (Fall 2003)
Last Modified: November 14th 2003

Submission Details

This deliverable consists of two parts. The following items must be submitted electronically on, or before, the given due dates, using the 'submit' command:

Part One, Due on Monday, November 24^th 2003

Project Schedule (pdf file)
Integration tests for new features (runnable test scripts)
Updated Testing document
Updated installation and start-up scripts

Part Two, Due on Monday, December 1^st 2003

Legacy document (pdf file)
Code (all source files, installation and start-up scripts, tests, etc.)
Up to date Testing document
Up to date installation and start-up scripts

Part One

Project Schedule

A working paper outlining the proposed schedule for this deliverable.

Task Information

List of all development tasks needed to get the project from its current state to a complete state. For each task include:

A description of the task or a descriptive task name;
The task's type. For example, 'Documentation', 'Testing', 'Write new code', 'Modify existing code', 'Integrate Modules/Components', etc;
An estimate of the time required to complete the task;
The name of the group member assigned to complete this task.

As implied by the examples of task types, coding, testing, integration, and the various sections of your documents are to be included as tasks in your schedule.

Critical Path Analysis

Use the Critical Path Method to produce a schedule for your project. Include an Integration Task Matrix, a Task Dependency diagram, and the PERT and Gantt charts. Make sure to highlight the critical path on both charts. Use a milestone to incorporate the fact that some tasks need to be completed by one deadline (the Deadline for this part of the deliverable) while other tasks do not need to be completed until some time later (the deadline for part two of this deliverable).

Your schedule must be up to date when you submit it. That is, any tasks that are complete or partially complete by the time you submit the first part of this deliverable should be depicted as such in your Gantt chart.

You may assume that the reader understands the meaning of the Integration Task Matrix, Task Dependency diagram, PERT and Gantt charts. You do not need to thoroughly explain the diagrams but legends are still expected.

Include a section outlining what you can conclude from your diagrams/analysis; explain anything noteworthy. For example, is one group member's work especially critical? Are there any tasks that need special attention? Etc.

Integration Tests

Provide integration tests for your components that exercise the features that will be implemented in part two of this deliverable. At the time you submit part one of this deliverable, most of these tests will fail because you have not completed your implementation of the features. Even so, these tests must be executable and should call the correct methods, send the correct messages, etc. The 'correct' methods/messages/etc. should have been defined in the Inter-Component Interfaces section of your architecture document.

By having you submit these tests before you submit your code we are aiming to give you some experience with Test-Oriented Development. Wherein, you write the tests before you write the code. This method can result in more thorough testing (resulting in few bugs) and sometimes a better design (because you see the usage of your class/function before you write it).

Update your Testing working paper in light of the additional tests.

Installation and Start-up Scripts

To mark your system the TAs will type './install' then './start'. If these scripts do not exist, you will not receive marks for the coding portion of the assignment. The TAs will also need a script to an individual start phone process. Call this script 'phonestart', its usage is described below.

The phonestart script meet the following requirements:

Typing './phonestart ' starts a phone process that connects to a real phone at the given IP address
Typing './phonestart -e [port]' starts an emulator at the given IP and port then starts a phone process, which connects to the emulator. The port is optional

The start script will start the database launch and any other vital processes or servers, then display the Administration Console.

The install processes must be available in the root directory of your submission. This script will do everything that needs to be done for the start and phonestart scripts to work. That is, unzip and untar your submission, set environmental variables, move files around, compile your code, start the database, load necessary data into the database, stop the database, and anything else that needs to be done before calling the start or phonestart scripts.

All scripts that taken more than 3 seconds to complete must provide feedback to the user, including a rough estimate of the amount of time the current series of operations will take. For example, "Starting Phone Server (30 seconds)...", "Install Complete", "Finished Start-up".

Lastly, if the user/TA needs to navigate to another directory once installation is complete then your install script must output a message to that effect. For example, "Please navigate to ~/group99 and type ./start to start the system".

Part Two

Implementation Requirements

For the initial public release of your system you will complete the implementation of the features described in your SRS. Thus, in addition to the requirements specified in the previous deliverables, the initial public release must include the following features:

Billing

Calling Plans -- refer to your SRS
Display a bill -- The administrator must be able to create a bill over any period of time (e.g. the last 3 months)
Automatic bill generation -- Periodically send bills to account holders. Allow the Administrator to change the period from once a month to once a minute (so that TA can see it happen when marking the system)
Add a charge and/or credit account

System Maintenance

Automated Hardware Fault Detection -- Periodically verify that your phone processes are alive, report failures to the Administrator

Implementation Details

Read through your SRS and/or the original project specification to make sure you don't overlook details like: When a subscription is cancelled, a bill must be sent immediately.

All of the billing operations listed above are to be performed through the Administration Console.

For more specifications on these requirements refer to your SRS or the original project documentation. If these requirements contradict your SRS consult your TA or the Professor.

Legacy Document

The purpose of a legacy document is to take note of any changes made to your design or architecture, and to help future developers/maintainers of your system. This document will be especially useful if a new member joins your group or if one of your group members leaves.

Project Status

An updated Gantt chart showing completed tasks (and, implicitly, task completion dates). Explain the most noticeable discrepancies between your estimated schedule and what actually happened. That is, (briefly) discuss any tasks that took significantly longer then expected, and justify any incomplete tasks. In your justifications, do not just say, "We ran out of time", state why you ran out of time.

Changes to Architecture

Describe and justify any changes you made to your architecture. Include diagrams if necessary.

Changes to Requirements

Explain any deviation from the requirements.

Additional Features

Outline any extra features that you chose to add to your system.

Impact Analysis

Select two areas where enhancements are likely to occur. These enhancements might be new features or an upgrade to a subsystem. Include a subsection discussing the impact of each enhancement. Taken together these subsections should not exceed one page.

This section will be especially useful if you ever need to implement the enhancement, so, be specific whenever possible. A prime example of a case where this section would be especially useful would be: "Our message passing code broke and the guy who wrote it left our group".

Recommendations for Future Projects

Give constructive suggestions for how this project might be done differently in future versions of this course, to improve the learning experience.

Installation

Update the scripts described in part one so that they continue to operate as outlined in the section above.

Testing

Update your tests scripts and testing document if necessary.

Note: Needing to modify a test implies that you have altered your design. These design changes should be described in your legacy document.