[Return to Table of Content]

Software Project Plan

• I.. Introduction
• A. Scope and purpose of document
• B. Project objectives
• 1. Objectives
• 2. Major functions
• 3. Performance issues
• 4. Management and technical constraints
• II. Project estimates
• A. Historical data used for estimates
• B. Estimation techniques
• C. Estimates
• III. Project risks
• A. Risk analysis
• 1. Identification
• B. Risk management
• 1. Risk aversion options
• 2. Risk monitoring procedures
• IV. Project resources
• A. People
• B. Hardware and Software

I. Introduction

A. Scope and purpose of document

B. Project objectives

1. Objectives :What is Shimmer?

To help the instructor create a questionnaire-style assignment easily, Shimmer also provides Shimmer Builder GUI. The instructor can create assignments, change assignment properties, edit assignments by adding or removing answers or questions in assignments, view report, configure the using this builder.

After logging on the system by getting permission from authentication server, the student can view, do and submit the assignment via general web browsers and will get the submission result back in e-mail.

Shimmer is not only useful for the instructor but also anybody who want to manipulate web-based assignments easily.

2. Major functions

• Supporting three types of assignment: Signup, Vote and Survey. Signup is an assignment that allows participants to sign up for a limited resources, keep the records of who signed up for what and how many resources have left. Vote is an assignment that allows participants to vote for their favorite choice or choices and provides statistic result. Survey is an assignment that allows participants to answer the provided question in either multiple-choices or text-input fashion and provides statistic result.
• Providing report for each assignment.
• Easily create and manage assignments using Shimmer Builder.
• Login and password verification with Kerberos authentication server of NCSU computer environment (EOS/Unity) system.
• Sending feedback about submission result to user via Internet e-mail.

3. Performance issues

• Browser subsystem: It depends on what is user's favorite web browser. In deed, the effect of the web browser to the system is negligible. However, the network between the browser subsystem and the server subsystem has big impact on the performance. It can even be the bottleneck of the system.
• Builder subsystem: The builder should be able to hold at least one assignment at a time. However, it should be capable of showing GUI components for accepting 20 questions with 10 answers in each question. Moreover, it should easy to use even for a novice.
• Server subsystem: The server should be able to accept at least 10 users at the same time. If the user is in the same local area network, the response time should not exceed 30 seconds, otherwise, it should not take longer than 1 minute.
• Database subsystem: The database file of Shimmer is an assignment-wise fashion. It does not require a high performance database. It might take time to generate a report for each assignment because it is possible to have many users in an assignment. However, it is not a big issue because report generating will not occur often.
• Configurations subsystem: It should provide a convenient way to configure the system.
• Authenticator subsystem: Show give the authentication fast enough so that it will not effect the performance of server subsystem.
• Mailer subsystem: The performance of typical mailer system is fine.

4. Management and technical constraints

• Browser subsystem: Not to be implemented. Use any existed web browser that supports HTML form.
• Builder subsystem: The maximum number of questions and answers that can be shown in one assignment is limited to the memory of the machine that runs the builder. The builder will be implemented by using Java AWT.
• Server subsystem: Server should be able to run anywhere in any platform. To achieve this, the server will be implemented by using Java and Java Servlet. However, in order to use Java Servelt, we need Java Web Server which has not supported in EOS/Unity yet. Therefore, we will use Java Servlet Development Kit so that Java Servlet can be implemented in any server instead.
• Database subsystem: The size of the database depends on the size of the assignment, users in each assignment and number of assignments. Because the database and its query will not be so complicated, we will just use object serialization feature in Java to store the database in files.
• Configurations subsystem: The system should be configured by editing plain-text configuration file.
• Authenticator subsystem: Reuse the existed module about authentication that was implemented in PG package.
• Mailer subsystem: Reuse the existed module about authentication that was implemented in PG package.

[Return to top]

II. Project estimates

A. Historical data used for estimates

B. Estimation techniques

C. Estimates

[Return to top]

III. Project risks

A. Risk analysis

1. Identification

1. Staff cannot contribute enough time to the project.
2. Staff does not have enough experience in the software tool.
3. Product cannot be released within the deadline.
4. Do not have enough documents for the users.
5. Customers keep changing the requirements.
6. Staff cannot provide enough support to the customers.
7. Product has not been tested enough before it is released.
8. Running the product causes unexpected effect to running environment.
9. The performance is down because too many users use the product at the same time.
10. Users hack the system.

B. Risk management

1. Risk aversion options and Risk monitoring procedures

Strategy:

• Manage the timetable.

• Project schedule

Strategy:

• Train the staff.
• Encourage the staff to study more.

• Time that the staff spends on development
• Number of errors.
• Number of defects.

Strategy:

• Keep in touch with the customers and find the appropriate deadline.
• Find more staff.

• Project schedule
• Other related schedule

Strategy:

• Update the documents often.
• Collect the feedback about the documents from the users.
• Provide alternatives of support such as electronic message board.

• Understanding of the users to the product.
• Number of messages in electronic message board.

Strategy:

• Keep in touch with the customers.
• Have the formal requirements gathering meetings with the customers.

• Usability of the product

Strategy:

• Provide on-line help.
• Provide on-line manual.
• Provide training sessions.
• Provide alternatives of support such as electronic message board.

• Amount of e-mail from the users about the problem of using the product.
• Number of messages in electronic message board.

Strategy:

• Make sure to have enough tests.
• Negotiate the deadline not to be too early.

• Amount of test before the product is released
• Number of defects

Strategy:

• Provide enough tests before the product is released.
• Provide backup database.
• Provide logging and recovery strategy.

• Performance and load of the running environment

Strategy:

• Limit number of users in a session.
• Provide the statistic about when is the most popular time of the users to use the product so that some of them maybe able to avoid the traffic.

• Users’ behavior in using the product
• Performance and load of the running environment

Strategy:
Provide secured access.

Monitoring activities -- The following factors can be monitored:
Users’ behavior in using the product
 

[Return to top]

Project resources

People

Hardware and Software

• Kulawat Wongsaroj's home PC : Pentium 200MMX
• EOS/Unity Sun and NT workstations

• remus.csc.ncsu.edu
• timex.csc.ncsu.edu (Thank you Volkan Ozdemi for letting us using his machine)

• JDK(tm) - Java(tm) Development Kit 1.1.5
• JSDK - Java(tm) Servlet Development Kit 2.0
• JGL - The Generic Collection Library for Java(tm) 3.1
• PG - Peer Grader System by students under directions of Dr. Edward Gehringer
• mailer - simple mailer package (part of PG system) by Jason Horne

• vi
• Kawa 3.0