Version	Primary Author(s)	Description of Version	Date Completed
Draft 1	Richard Allen	First rough draft.	6/3/2004
Draft 2	Richard Allen	Changed BJ’s name, changed project due date, fixed misspelling.	6/7/2004
Version 1	Richard Allen	Changed presentation due date	6/8/2004

1. Introduction

This document is a formal plan for an academic team project to develop an electronic system for tracking the circulation of books in a library. The following sections give a basic background of the project including an overview, deliverables, milestones, and a glossary of terms and acronyms.

1.1 Overview

The primary intent of this project is to reduce the workload involved in managing the circulation of books at a university. Another intent of this project is to provide a convenient method to search for books that the library has in circulation and generate reports on the status of books. Following is the high-level functionality that the Library Circulation System (LCS) will provide.

Maintain a database of all books in the library’s circulation.
Provide a graphical user interface (GUI) to the database which allows users to perform the following functions:

Enter new books into the system (into circulation)
Check books out/in
Change the status of books (e.g., missing, lost, reserved, etc.)
Generate reports on the books in the system (e.g., all lost books, all overdue books, etc.)
Search for books in the system

Provide a GUI for creating, modifying, and deleting users of the system.
Restrict access to the functionality of the system based on user roles (i.e., only administrators can create users, only librarian users can enter new books into the system, every user can perform book searches, etc.).

The team members have agreed that LCS will be developed as a web-based application. A web-based solution will provide many benefits including the following:

The application only needs be installed and maintained on one computer.
The application can be accessed from any computer that has Internet access and a compatible web browser, which means that students can search for books from home.
Future releases of the application can provide web-based interfaces (e.g., Web Services) for other library systems, so that other libraries can search the inventory or even reserve a book.

The team has estimated that they will be able to complete the entire required documentation and software by 8:00 PM on July 22. The total expected effort is 300 total person-hours.

1.2 Deliverables

The table below lists the deliverables that will be provided as part of LCS. Both product and project deliverables are included. Product deliverables are those items that are created to produce the system. Project deliverables are those items that are created to support the project.

Deliverable	Description	Dates
Software Project Management Plan (SPMP)	A complete formal project plan, including technical and managerial processes that will be implemented in the development and delivery of the system	6/8/2004
Software Requirements Specification (SRS)	A formal document detailing the functional and non-functional requirements of the system	6/17/2004
Software Design Specification (SDS)	A formal document detailing the component designs as well as the relationships among components	6/29/2004
Test Scenarios	Formal documentation detailing scenarios that must be followed in order to ensure that the product software is satisfactorily tested.	7/6/2004
Product Software	The executable code for the LCS	7/22/2004
User Guide	A formal document describing, for each user type, how to use the entire system	7/22/2004
Product Reference Manual	A formal document describing how to install, setup, and run the application	7/22/2004
Final Presentation	A demonstration of the product software and a presentation of the project experience	7/22/2004

Table 1.2.1 Deliverables

The milestones of the project are the completion of each of these deliverables. All team members must sign off on every deliverable before it is presented to the client. A single copy of all document deliverables will be provided to the client in printed format on the due dates by 10:00 PM. The executable code for LCS will be delivered on Compact Disc to the client on the due date by 8:00 PM. The Final Presentation will be complete on the due date by 8:00 PM.

1.3 Evolution of the SPMP

All members of the project team have agreed upon this SPMP. Any team member may make changes to the SPMP, but the entire project team must approve all changes. This document may be periodically updated during the lifecycle of the project to reflect changes in the project schedule. All changes will be documented in order to keep the SPMP current. Richard Allen will be responsible for coordinating and finalizing all changes to the SPMP.

1.4 Reference Materials

IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions

1.5 Definitions and Acronyms

This section provides a quick reference for the acronyms used throughout this document. All of these acronyms are explained in the text as they are introduced; therefore, the definitions will not be repeated in this section.

LCS Library Circulation System

SDS Software Design Specification

SPMP Software Project Management Plan

SRS Software Requirements Specification

J2SE Java 2 Platform, Standard Edition

JSP JavaServer Pages

JSTL JavaServer Pages Standard Tag Library

2. Project Organization

The following sections explain the organizational structure for the project, the specific roles and responsibilities for each team member, and the process model that will be used.

2.1 Process Model

The main process model for this project will be a variation of the waterfall model, which includes overlapping phases, feedback loops, and prototypes. Subsequent phases will begin before the previous phase is complete. Feedback from the subsequent phase will be applied to the previous phase before it is complete. The diagram below shows the major phases as well as the deliverables for this model. The deliverables shown with a dashed outline are internal deliverables, meaning they won’t be delivered to the client. These deliverables include a static Interface Prototype and a Functional Prototype. In this diagram, the User Guide and Product Reference Manual deliverables are considered part of the Product Software deliverable.

Figure 2.1.1 Waterfall Model

2.2 Organizational Structure

The project team consists of six team members, Mohammed Ali, Richard Allen, BuYunG J. Tarianto, Susrutha Narla, Wayne Salhany, and Thara Soman. The chart below illustrates the basic structure of the team, however, all team members are equally accountable for the completion of each deliverable and the overall project.

Figure 2.2.1 Organization Chart

2.3 Organizational Boundaries and Interfaces

The project team will perform all of the work on the project. Questions regarding requirements and deliverables that cannot be answered from within the team will be directed to the client, Dr. Hassan Pournaghshband. Richard Allen and Wayne Salhany will act as liaisons to the client.

2.4 Roles and Responsibilities

The following table lists the roles necessary to complete the project, and what team members will fulfill those roles. Each role has an assigned lead person, who is responsible for coordinating effort to ensure that the associated responsibilities are met. Although each team member is assigned a lead role, all team members will serve as support staff for every other role as the need arises.

Role	Responsibility	Lead Person
Project Manager	Plans, organizes, and coordinates the team project. Schedules and prepares team meetings. Resolves conflicts. Works as a liaison between team members. Monitors and reports the weekly status of the team. Ensures that project deliverables are met.	Richard Allen
Requirements Analyst	Identifies, prioritizes, and documents requirements that satisfy the customer’s needs. Clearly communicates the requirements to the Application Developers. Defines acceptance criteria for the completion of the solution.	Thara Soman
Application Designer	Designs a solution to the problem that satisfies the requirements. Determines the data needs for the solution. Determines what hardware and tools are necessary. Assists the Technical Writers in documenting the design.	Susrutha Narla
Application Developer	Develops the software solution. Determines the data needs for the solution. Determines what hardware and tools are necessary. Fixes bugs found by the Quality Assurance Testers. Assists the Technical Writers in creating online help, and writing the user manual.	Mohammed Ali
Quality Assurance Engineer	Tests the software solution to identify bugs and ensure that the requirements have been met. Communicates problems found with the solution to the Application Developers. Retests bug fixes. Determines whether the software solution is ready for delivery.	BuYunG J. Tarianto
Technical Writer	Coordinates the project documents and their review by all team members. Collects, proofreads, and integrates document parts. Generates the final version of all the documents.	Wayne Salhany

Table 2.4.1 Team Roles

3. Managerial Process

The following sections describe how management will monitor the project status. In addition the risks are detailed and contingency plans are explained.

3.1 Management Objectives and Priorities

The foremost objectives of the project are the following:

1. All deliverables are completed and submitted to the client by 7/22/2004.

2. All intermediate milestones (everything due before 7/22/2004) do not slip beyond two days of the schedule.

3. The final product software meets 90% of all high priority requirements agreed to by the team.

4. Zero known high severity defects remain in the final product software at the time of release.

5. The client is left feeling satisfied with the deliverables that the project team produced. Measures of the client’s satisfaction will be the grades that the team receives on project deliverables, as well as the final grades that the team receives.

6. The final product software is of good quality and maintainable. To meet this objective, the following objectives will be met:

· No Java packages in the project software will have a cyclical dependency.

· No Java classes in the project software will have a cyclomatic complexity above 10.

· All methods and classes in the project software code will be documented. In addition, the design and the requirements will be documented.

See section 3.4 Monitoring and Controlling Mechanisms and section 4. Technical Process for additional information on how these objectives will be achieved.

Table 3.1.1 below illustrates that the project can be viewed as having several dimensions. Some of these are fixed while others remain flexible. Analyzing these dimensions illustrate which of the dimensions could be adjusted if necessary.

Project Dimension	Fixed	Flexible
Resources	X
Hours Worked		X
Schedule	X
Scope		X

Table 3.1.1 Project Dimensions

The number of resources for the project is fixed at six people, and the overall schedule of the project is fixed because it is a class project, therefore, the project must be completed by the end of the semester. The scope and the hours worked are the dimensions that can be adjusted if necessary. To ensure that the team meets the deadlines for the deliverables, team members are willing to increase the hours they work. Since the detailed scope of the project is left up to the team, the team can also reduce the scope as necessary to meet the project milestones. All team members will work together and support each other as necessary to ensure the success of the project.

3.2 Assumptions, Dependencies, and Constraints

The project will be developed under the following organizational assumptions:

The development team consists of six members who will contribute approximately even amounts of time to completing the project.
Each team member will be willing and able to contribute a minimum of six hours a week, directly to the project.
Either the team members or Southern Polytechnic State University will provide the tools (hardware, software, office space, etc) necessary to complete the project.
The development team has enough experience as a whole to complete the project.
The development team will cooperate to complete the project.

The project will be developed under the following project assumptions (detailed more fully in the SRS):

The users of the system will be librarians, students, and system administrators.
The data for the system will be provided by and entered into the system by university personnel.
The system will properly run on the Microsoft Windows operating system (Windows 2000 or greater).
The system will meet the high-level requirements stated in section 1.1 Overview.

The main constraint of the project is the timeline, which is governed by the class schedule. In addition each team member has other responsibilities including other classes, a full time job and/or children, which requires his or her commitment.

3.3 Risk Management

The main risk to project success is that each phase of the project will take more time than anticipated. This risk is believed to be high since the project team has never worked together before or produced a product that meets the same or similar requirements and therefore, has no historical data on which to base the estimates of effort. The estimates of effort are based in large part on educated guesses. If a phase is found to take significantly longer than expected, then the team will determine if the scope should be reduced or if more resources can be assigned to the particular task(s) in order to meet the deadline for the final product.

The other major risk to the project is the possibility of losing team members due to dropping the class. Losing even one team member causes a 17% loss in manpower. In addition the team could then be lacking necessary skills to complete the project. In order to mitigate this risk, every team member has been assigned multiple roles. If a team member drops, their workload will be distributed to the remaining team members. Should a critical skill be lacking, the potential exists to adjust the scope of the project. This risk is believed to be low based on the team’s apparent commitment to the project.

An additional risk to the project is that the team has agreed to develop a web-based application and only two members of the team have previous web-development experience. The success of the project is dependent on the team’s ability to communicate web-development knowledge effectively, and learn and apply a little understood technology in a single semester. This risk is considered moderate since one team member knows the technology very well, and the other team members are accustomed to having to learn and apply a new technology in a short timeframe. This risk is to be mitigated by meeting twice a week and communicating status to the team leader once a week at a time separate from the meetings. Team members also have shared phone numbers, shared emails, and joined a Yahoo group, which opens multiple lines of communication. Team members are expected to express troubles that they may be having, and the team lead will use the status reports to try and identify any team member who may be having trouble.

3.4 Monitoring and Controlling Mechanisms

Team meetings will be held twice a week on Tuesday and Thursday to determine progress work cooperatively on the deliverables. In addition, weekly status reports from each team member will be reported to Richard on Saturday of each week. The status reports will include percent completed, estimated completion date, and effort expended figures for the topic that the team member is working on.

Major problems will be reported as soon as discovered to the entire team. Additional meetings will be held, if necessary, to handle special issues (such as milestone slippage). Team leads are responsible for communicating progress to Richard.

In addition email and phone communications will be applied as necessary. All team members have joined a Yahoo group. All products of the project will be uploaded to the Yahoo group. The Yahoo group will act as a configuration control tool for the project. Email will be the preferred method of non-critical communication among team members.

Actual start and finish dates will be recorded as progress occurs on the project. These dates will be compared to the original baseline to confirm that project deliverables and milestones will be completed in accordance with the project plan. Richard will do the monitoring on a weekly basis. The entire team will be involved with decisions regarding the reassignment of resources or changes in priority.

BuYunG J. Tarianto will be responsible for collecting and analyzing the software defects, package cyclical dependencies, cyclomatic complexity, and reviewing the code for comments. BuYunG will report these metrics to Richard and will also be responsible for initiating a resolution to any problems he finds.

Thara Soman will be responsible for determining if the product software truly meets the requirements. Thara will report her findings to Richard and will also be responsible for initiating any fixes to software that does not meet its stated requirements. This includes ensuring that the product software does not include requirements that are outside the scope of what the team has agreed to.

Additional information on the techniques to be used for monitoring and controlling the project can be found in section 4.3 Project Support Functions.

3.5 Staffing Plan

The six team members have joined together to work on the project because of their similar interests and varying knowledge and skills. Overall the team should have the necessary skills to complete the project. No other members will be recruited and hired for this project.

Each of the six team members is expected to work approximately 6 hours per week on the project until completion. Team members may work more during the time that their particular responsibility is being completed. It is estimated that the project will take approximately 300 total person-hours to be completed. These hours are detailed in section 5.3 Resource Requirements.

4. Technical Process

The following sections describe the technical standards to be used in the project including methodology, management of documents, and coding guidelines.

4.1 Methods, Tools and Techniques

LCS will be developed using a variation of the waterfall model, which includes overlapping phases, feedback loops, and prototypes. For example, before the requirements analysis phase is completed the program design phase will begin. Before the program design phase is completed, the program coding phase will begin and an early prototype will be developed. Feedback from later phases will be incorporated into earlier phases before those phases are complete. Lessons learned from the early prototype will be incorporated into the final product. This process is well suited for this project because of the solid deadlines and the lack of a real customer (i.e., the requirements, once defined, won’t change much).

LCS will be developed on Personal Computers (PC) compatible with the x86 architecture running either Microsoft Windows XP or Microsoft Windows 2000, supplied by the individual developer or the SPSU computer labs. The developers will use the Eclipse Integrated Development Environment (IDE) for coding, integration, compiling, and debugging. Apache Ant will be used for building and deployment during unit, integration, and system testing. CVSNT (http://www.cvsnt.org) will be used as the Configuration Management tool (CM) for versioning the source code, executable binary libraries, and other artifacts necessary to build and run the application.

LCS will be a web-based application supporting the following browsers.

Internet Explorer 6 or later
Netscape 7 or later
Mozilla 1.0.1 or later

LCS will be developed using the following Java technologies.

Java 2 Platform, Standard Edition, version 1.4 (J2SE)
Java Servlet, version 2.4
JavaServer Pages, version 2.0 (JSP)
JavaServer Pages Standard Tag Library, version 1.1 (JSTL)

Java Servlet 2.4, JSP 2.0, and JSTL 1.1 are specifications. The implementations of these specifications that will be used are the following.

Apache Tomcat, version 5 (Java Servlet 2.4 and JSP 2.0)
Jakarta Standard Taglib, version 1.1 (JSTL 1.1)

In addition, the following Java libraries will be used.

Jakarta Struts, version 1.1
Log4j, version 1.2.8

Jakarta Struts is a framework for building Java web applications that encourages architectures based on the Model 2 approach, which is a variation of the Model-View-Controller architecture. Log4j is a library that provides logging services for Java based applications.

The database for LCS will run on MySQL (http://www.mysql.com). MySQL is the world’s most popular open-source database. MySQL is freely available, easy to use, and cross-platform. If needed, the creators of MySQL also provide professional technical support at a cost.

Microsoft Excel will be used to keep a list of active and fixed software defects, as well as the percentage of requirements that have been completed, and metrics collected on cyclomatic complexity and package cyclical dependency. JavaNCSS will be used in conjunction with Ant to calculate the cyclomatic complexity at every build. In additional, JDepend (http://www.clarkware.com/software/JDepend.html) will be used in conjunction with Ant to determine any package cyclical dependencies.

4.2 Software Documentation

All documentation for LCS will be created using Microsoft Office 2000 or XP, Microsoft Visio, Microsoft Project, and Rational Rose. The final document deliverables will be in Microsoft Word 2000 format.

The following IEEE standard document formats will be used for the final document deliverables (except for the final report) with minor changes.

IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions

Finally, all presentation slides will be created using Microsoft PowerPoint.

4.3 Project Support Functions and Process

All members of the team have joined a Yahoo group that was created specifically for this project. The Yahoo group is to be used only for this project. No file uploaded to the Yahoo group will be deleted or overwritten unless agreed upon by the entire group. File names should include the date when the file was created to prevent conflicts with another version of the same file.

All document deliverables must be uploaded to the Yahoo group 48 hours before their deadline so that all team members can review the document and make corrections and suggestions. All corrections and suggestions must be emailed to every member of the group 24 hours before the deadline so that the member coordinating the document can make corrections in time for the deadline. All team members must signoff the final document 12 hours before the deadline.

Wayne Salhany will maintain a Concurrent Versioning System (CVS) repository on his personal computer or a computer at SPSU, using CVSNT as mentioned above. When the coding phase starts, every Thursday by 10:00 PM the developers will deliver software updates that compile with no errors to Wayne via floppy, CD, or upload to the Yahoo group. Along with the software updates, the developers will notify Wayne of what requirements the updates fulfill. Wayne will commit those changes to the CVS repository by Saturday morning 8:00 AM. Wayne will perform all builds created for system testing and product release directly from the CVS computer. Builds will be executed by an Ant build script that will directly pull all source code, libraries, etc. from the CVS repository. Each build will run JavaNCSS and JDepend. The resulting metrics and a list of requirements fulfilled by the build will be put into a release file. Each build and release file will be zipped up and uploaded to the Yahoo group for other team members to review. Each distribution build will contain source code as well as all executable code, libraries, etc. necessary to deploy and run the application. Richard will deploy builds for system test on his laptop or home computer and make these builds available for other team members to test either via the Internet or by allowing other team members to use his laptop for testing. In addition, Wayne will deploy builds on the CVS computer and make that computer available for members to test.

BuYunG will maintain a list of defects found during testing in an Excel spreadsheet. Every Thursday by 10:00 PM testers and developers will notify BuYunG of new defects, fixes to defects that need to be tested and confirmed fixes to defects via Email or upload to the Yahoo group. Every defect reported to BuYunG must contain a brief description of the defect, the name of the person who found the defect, a description of how to reproduce the defect, and a priority for the defect. BuYunG will integrate the changes in his Excel spreadsheet, assign numbers to the new defects, and upload the latest version of the spreadsheet to the Yahoo group by Saturday morning 8:00 AM.

All defects will use the following priority scheme.

High Severity: A defect that will stop the total software system and all work related to the system is stopped.
Medium Severity: A defect that will cause the loss of a function of the system, thereby not allowing the user to complete his or her work as planned.
Low Severity: A defect that causes some inconvenience and possibly requires the user to perform a little work around to complete his or her task.
Minor Severity: A defect that only causes some possible misunderstanding of terminology or minor adjustments in the usage interpretation.

BuYunG will also maintain a collection of the metrics produced by JavaNCSS and JDepend, organized by the date they were produced, in an Excel spreadsheet. BuYunG will upload the latest version of this spreadsheet to the Yahoo group each week by Saturday morning 8:00 AM.

Each requirement for the system will be numbered. When developers report that they have fulfilled a requirement, they will refer the requirement by number. Thara Soman will maintain a collection of the requirements that have been proven, by testing, to have been fulfilled by the product software. Thara will update this list of requirements each week while the system is being tested.

The metrics collected will be reported to Richard on a weekly basis so that she can determine if the team will meet its scheduled milestones and make any adjustments as necessary. The final product will not be released for demonstration to the class until agreed upon by the entire team.

5. Work Packages, Schedule, and Budget

The following sections explain what tasks are to be done and by whom. This plan may become more detailed as the project progresses and the risks are better understood.

5.1 Dependencies

The dependencies for the project are outlined below.

Task	Dependencies
Software Project Management Plan (SPMP)	None
Software Requirements Specification (SRS)	SPMP
Software Design Specification (SDS)	SPMP, SRS
Test scenarios	SPMP, SRS, SDS
Coding	SPMP, SRS, SDS
Verification and Validation (testing)	SPMP, SRS, SDS, Coding
User guide	SPMP, SRS, SDS
Product reference manual	SPMP, SRS, SDS, Coding
Final demonstration and presentation	Everything above
Project Planning	None

Table 5.1.1 Task Dependencies

5.2 Resource Requirements

The project team will do all of the work on the project. No additional resources will be required. The following table details the expected person-hours for each major task.

The estimates are educated guesses based on experience in developing applications for class projects, the scope of the project, and the technology to be used on the project. As the project progresses, the actual time needed to complete tasks will be input into the project plan. Based on history, some adjustments to future estimates may occur.

Task	Effort in Person-Hours
Software Project Management Plan (SPMP)	10
Software Requirements Specification (SRS)	48
Software Design Specification (SDS)	60
Coding	94
Verification and Validation (testing)	30
User guide and product reference manual	18
Final presentation	18
Project Planning	22
Total Effort	300

Table 5.2.1 Task Effort

5.3 Budget and Resource Allocation

The following table shows the expected resource allocations for each major task. Of course should a particular task fall behind schedule, any other available resources may be reassigned. Likewise, if a predecessor activity is taking more time than expected, a future task may start with less supplemental resources. All team members will be involved in these types of decisions.

Task	Main Resource	Supplemental Resources
Software Project Management Plan (SPMP)	Richard Allen	Susrutha Narla
Software Requirements Specification (SRS)	Thara Soman	Mohammed Ali Richard Allen Susrutha Narla Wayne Salhany
Software Design Specification (SDS)	Susrutha Narla	Mohammed Ali Richard Allen BuYunG J. Tarianto Wayne Salhany Thara Soman
Coding	Mohammed Ali	Richard Allen Susrutha Narla Wayne Salhany Thara Soman
Verification and Validation (testing)	BuYunG J. Tarianto	Mohammed Ali Thara Soman
User guide and product reference manual	Wayne Salhany	BuYunG J. Tarianto
Final Presentation	Wayne Salhany	Richard Allen BuYunG J. Tarianto
Project Planning	Richard Allen	Susrutha Narla

Table 5.3.1 Task Resource Allocation

5.4 Schedule

The following Gantt chart details the major tasks along with their expected start and finish dates. The duration on the chart is shown in days. The duration doesn’t necessarily reflect the amount of effort that will expended for that task. The effort was shown previously.

These dates make up the baseline against which future progress will be measured. Actual start and finish dates will be recorded as progress occurs on the project. These dates will be compared to the original baseline to confirm that project deliverables and milestones will be completed in accordance with the project plan. This plan will be closely monitored by Richard to insure that the project is completed on time. The entire team will be involved with any decisions to reassign resources.

Figure 5.4.1 Task Schedule