Project Overview
The Hotel Reservation System is intended to provide a small to mid-size hotel with computerized reservation capabilities. Initial inception limits the functionality to employees creating and displaying reservations, however, the project is projected to provide billing, check-in/check-out, and guest-centric reports. It will be developed in small increments, and deployed immediately upon completion of each development cycle. As such, functionality will gradually grow.
Reference Documents
Concept of Operations
Document Templates
Applicable Standards
Coding Standard
C++ code will closely resemble the GNU standard, while borrowing the documentation and comment standards defined by Javadoc.
Deviations from and additions to GNU / Javadoc:
Private member variable names begin with a ‘_’ character Tabs will be replaced with two spaces, and line length limited to 79 characters. Local and member variables will be completely lowercase with underscores (‘_’) separating words. Public and Protected Functions begin in lowercase, with additional words being capitalized. Private Functions begin with capital letters.
Brackets beginning on a newline have the same indentation as the first character of the previous line.
Document Standard
Each document follows the corresponding template found here. Documents developed with Microsoft Office must be stored in Office 2003 compatible formats (i.e. no .docx, .pptx, etc…) or Portable Document Format (PDF). All modifications are to be recorded in the Modification history that heads every project document; they should describe any action taken and the portion of the document it pertains to. The use of first-person is forbidden; documents are intended to be professional quality, with multiple authors. A 10 point font is currently used, but may change if readability is affected. Such a change will be retro-active, applying to all completed documents as well.
Artifact Size Metric Standard
Progress is measured in terms of database complexity; which is a combination of the number of fields and the number of forms.
Project Team Organization
There is no de-facto project manager for this project, each member is expected to report his or her progress to the entire group, and to follow the progress of every other member. Keeping everything in the open will help to ensure that project management does not become a choke-point. That said, we expect each member to have his or her own strengths and weaknesses, so individual tasks may have a manager assigned to them.
After the first iteration completes, we will have a better picture of who is best suited for each type of task. Presently, the team breakdown is as follows:
Christopher will be responsible for managing both our project website, and our application website (graphical front-end), as well as serving as technical director for database development.
Anqi will head Test Planning and Quality Assurance
Jin Long will be in charge of Requirements Specification and Use Case generation
Andon will function as Editor and Technical Director for C++ and php components, such as billing.
All other tasks are taken off of the TODO pile as discussed in Risk Management section of this document.
Because of course schedule conflicts and transportation, face-to-face meetings will be used sparingly. It is expected that most communication will occur through E-Mail or in brief meetings between classes. E-Mail is well suited to this project because UML diagrams can follow directly from written word; the team will not have enough previous experience to develop UML diagrams on a whiteboard during face-to-face meetings.
Deliverables
Artifact
Tentative Due Dates
Meeting Minutes
11/04/2009
12/02/2009
Individual Logs
11/04/2009One entry per-teammate per-week
12/02/2009
Group Project Management Reports
11/04/2009One entry per-week
12/02/2009
ConOps
11/04/2009
Project Plan
11/04/2009(Updated Every Cycle)
SRS
11/04/2009
High-Level Design
11/04/2009(Updated Every Cycle)
Detailed Design
11/04/2009(Updated Every Cycle)
Test Plan
10/07/2009(Updated Every Cycle)
User’s Manual
12/02/2009
Final Test Results
12/02/2009
Source, Executable, Build Instructions
11/04/2009
12/02/2009
Project Legacy
12/02/2009
Software Life Cycle Process
The iterative model is ideal for this project, because it rapidly cycles through Requirements, Analysis and Design, Implementation and Testing. Keeping each of these cycles reasonably small ensures that common language is picked-up early on and that it is constantly reinforced. It also ensures that the entire team has time to critique one another’s work, making future cycles more efficient.
Critically, the iterative model guarantees that even if production slows, after each small cycle completes, there is a deployable product. If the waterfall model were followed, there would be a high probability that no working system would be produced before the non-negotiable project deadline; particularly since the team does not have enough experience with this sort of project to get Requirements and Design right in a single attempt.
Diagram Courtesy of Wikimedia
Initial planning consists of determining the operating environment, and a set of required and optional features. At the start of each cycle, a set of related features will be taken off of the TODO list and approximately one to two days will be spent planning and creating new requirements around the features. The rest of the cycle is dedicated to design, implementation and testing. Finally, evaluation takes place to determine the appropriate set of features for the next cycle. Because most optional features were identified during initial planning, “feature creep” is kept to a minimum.
Tools and Computing Environment
The project has two main components:
1. Back-end
Consists of Microsoft SQL Server running on some variant of
Microsoft Windows
2. Front-end
Designed using Microsoft Access, and accessible on any
device that has network connectivity and a web browser.
Additional components, if needed, will be written in C++ and compiled with gcc. Php may be used
to provide a web interface with components written in C++.
Allowable libraries include:
Compression:zlib
Database:MySQL
XML Parser:Xerces-C++
Billing:PayPal API (Sandbox)
Configuration Management
Source code will be stored on an off-site svn server, and each batch of check-ins will require a short summary in a CHANGES file. Andon will oversee the administration of and proper protocol for using the version control server.
Documents have a primary author, who assumes the responsibility of ensuring accuracy and conformance. All team members are allowed to modify a document, and are expected to submit the modified document to its primary author to commit changes. Additionally, changes should be forwarded to all team members for comment.
Quality Assurance
Testing will be performed after every development cycle, and results will be recorded for future reference. In addition to new test cases, previous test cases should be reused to prevent regression issues, especially errant test cases. Document uploads will be forwarded to Andon for editing, to ensure style and format consistency, and technical accuracy. New deliverable documents will be forwarded to the entire team before they are uploaded to the project website; members are expected to look over the document ensuring sections related to their own assigned tasks are accurate. Code reviews will be performed when one or more team members have idle time. This is not associated with any particular stage of the development cycle. Risk Management
The single greatest risk facing this project is difficulty communicating. The team consists of two members with English as their native tongue, and two who speak Chinese. This can make assigning and monitoring task progress a logistical problem. Consequently, two considerations have been made to help bridge the aforementioned language divide.
First, tasks are pooled together based on their level of written word and abstraction. That is to say, documents and procedures that follow strict procedural order or whose purpose is to visually represent a concept are considered appropriate for any member of the team. The remaining tasks are best left to the English speaking members. To prevent idle human resources, English members should attempt to complete all of the verbose tasks before taking on the abstract pile.
Second, the waterfall model will not be used. Because communication is less than ideal, if large tasks followed in lock-step fashion, the development pipeline would experience frequent clogs; requiring members to drop what they are doing to help unclog it. The iterative model is not without these clogs, however, they are much smaller and simpler to address – and if they occur again, a general solution and the language to describe it already exists.
Table of Work Packages, Time Estimates, and Assignments
Task Name
Duration
Responsibility
Concept of Operations
7 days
Christopher
Project Management Plan
7 days
Andon
Software Requirements Specification
7 days
JinLong
Test Plan
7 days
Anqi
Data Flow Diagram (High Level Design)
7 days
Andon
Entity Relation Diagram (High Level Design)
7 days
JinLong
Detailed Design
14 days
Anqi, JinLong
Database Creation
21 days
Christopher
Website Frontend
7 days
Christopher
Testing
5 days
Anqi, Christopher
Test Results
5 days
Christopher
User’s Manual
7 days
Andon
Build Instructions
7 days
JinLong
Project Legacy
7 days
Anqi
PERT Chart
Technical Progress Metrics
Meeting Minutes
Individual Log Entries
Number of UML class objects
Number of UML diagrams
Database Fields
Database Forms
Database Reports
Combined man hours (as reported in weekly progress reports)
Number of C++ classes
Number of non-accessor / mutator methods
Accessor and mutator methods are a consequence of black-box design, and represent the number of variables, rather than actual functionality. Number of source/header pairs
Plan for tracking, control, and reporting of progress
Each week, every team member is expected to provide a brief progress report, to all other members via E-Mail. This progress report should include any difficulties encountered (such as defects or unanticipated requirement changes), major decisions made, documents edited, and a rough estimate time spent on and time required to complete each task.
Either Andon or Christopher will take this information on no longer than a bi-weekly basis and develop a more detailed report that includes the important points from the individual reports, along with progress metrics, QA results, and any changes to risk.
Template created by G. Walton ([email protected]) on Aug 30, 1999 and last updated Aug 15, 2000
This page last modified by Christopher Steiner ([email protected]) on November 3, 2009
