Get help now

Review of related literature of reservation and billing system

  • Pages 7
  • Words 1606
  • Views 411
  • dovnload

    Download

    Cite

  • Pages 7
  • Words 1606
  • Views 411
  • Academic anxiety?

    Get original paper in 3 hours and nail the task

    Get your paper price

    124 experts online

    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

    This essay was written by a fellow student. You may use it as a guide or sample for writing your own paper, but remember to cite it correctly. Don’t submit it as your own as it will be considered plagiarism.

    Need a custom essay sample written specially to meet your requirements?

    Choose skilled expert on your subject and get original paper with free plagiarism report

    Order custom paper Without paying upfront

    Review of related literature of reservation and billing system. (2016, Aug 19). Retrieved from https://graduateway.com/review-of-related-literature-of-reservation-and-billing-system/

    Hi, my name is Amy 👋

    In case you can't find a relevant example, our professional writers are ready to help you write a unique paper. Just talk to our smart assistant Amy and she'll connect you with the best match.

    Get help with your paper
    We use cookies to give you the best experience possible. By continuing we’ll assume you’re on board with our cookie policy