Project Evaluation





  • How well the project satisfies the original functional specifications


  • How useful the design process was and differences we propose for the design assignment.


  • Test plan evaluation.


  • Management structure evaluation.


  • Comparisons of actual times taken for each part.


  • How we would have done it differently if it were a "real" project and What way we could make the project less work.


  • Lessons learned




    • We as a team, communicated well and avoided any personality conflicts which could have had a negative effect on the progress of the project.

    The group was divided into two major sub-groups: design team,and documentation team. We had much better organization in the sub-groups due to their smaller size. Each of the subgroups were assigned specific tasks which were more easily accomplished. Everyone stayed involoved throughout the project and each person played a key role which helped in completing it.

    One of drawbacks of how the project was done was that the customers presented amendments in document form, which did not seem to be an effective way to have the changes done. It would have been a good idea to have the two groups meet more frequently.

    A major deficiency in our group was that it lacked a strong leader to ensure the organization of the team. We should have formally appointed a person to organize all meetings and to ensure that the members completed their assigned tasks.

    In terms of coding the project, the group failed to set specific deadlines. Our choice of MS Access as our platform was not a good idea because our lack of experience with the language.

    Satisfying the original functional specifications



    The project closely resembled the specifications of the customer requirements. However, some of the aspects of the program were not in functional order.

    The project is user friendly as the customer group had requested. Since we used a Fourth Generation Language, the graphical design promoted ease of use and user friendly applications.

    As requested by the customers, security issues were met as well. This was done in terms of distributing the project into three main access level groups.

    Due to poor estimation of time required to learn the Access, we were unable to fully implement all the features that we have laid out. We may have been wiser to cut back on some of the requested features in order to put together a more solid implementation with a smaller set of features.

    Two of the extra features, the phone charge system and update tax system that were added in, were not functional at the demo due to time constraints.

    The major requirements are listed below, with a description on how we satisfied them:

    Login:

    The login screen matched the security measures as required by the customers. The administration has access to all sections of the system, while kitchen and front desk staff are restricted to their respective sections.

    Kitchen:

    The room service menu was present, but due to time constraints was not fully functional. Room Service menu items could not be added or deleted for the customer order. These functions were promised, but due to poor scheduling techniques by our coding team, they were not finished. However in the future version of this system, these functions will be implemented. The dynamic billing system of the room service orders will also be implemented as promised in future a version.


    Front Desk:

    Reservations: The reservation system was fully operational. This consisted of selecting a room to be reserved under all different criteria. After reserving a room, the front desk personnel could then enter the customers information for checking-in purposes.

    Group reservations did not work though, we had set aside a field for this purpose, but due to time constraints and poor orgranization, this could not be implemented.

    Messages: This part of the front desk system worked properly. The front desk personnel could select a room number and leave a message for the customer whose name the room is registered under.

    Viewing the message also worked with compliance to the customers requirements. A message could be seen after selecting the room number of the customer.

    Administration:

    Kithen:

    Adding Menu Items: This part of the system gave access to the administrator to add any new items to the room service menu, along with the price of the item.

    Deleting Menu Items: This part of the system gave access to the administrator to delete any item currently on the room service menu.

    Editting Menu Items: This part of the system gave access to the administrator to edit any item currently on the room service menu, along with the price of the item.

    Edit Tax: This function allows the administrator to edit the different taxes available on the system. This function was an extra feature suggested by the supplier group.

    The preceeding sections of the administrator functions were not implemented due to time constraints.

    Front Desk:

    Adding Rooms: This part of the system gave access to the administrator to add a new room to the hotel, along with the price, and category of the room.

    Deleting Menu Items: This part of the system gave access to the administrator to delete any room currently in the hotel.

    Editting Menu Items: This part of the system gave access to the administrator to edit any room that is currently in the hotel. The category, and price of the room can be altered.

    Edit Tax: This function allows the administrator to edit the different taxes available on the system. This function was an extra feature suggested by the supplier group.

    The preceeding sections of the administrator functions were not implemented due to time constraints.

    Administrator:

    Adding an Employee: This part of the system gave access to the administrator to add a new employee to the hotel in any department.

    This administrator function was fully operational.

    Deleting an Employee: This part of the system gave access to the administrator to delete any employee currently working for the hotel in any department.

    Editting an Employee: This part of the system gave access to the administrator to edit any employee currently working for the hotel. The department, name of employee, or password could also be changed by the administrator.

    These functions could not be implemented for the prototyped system.

    How useful the design process was and differences we propose for the design assignment



    More demonstrations between customer and supplier groups were needed.

    Due to other major obligations, meeting times were hard to plan. Since all group members were students enrolled in other courses and having different schedules, it was hard to organize mutual meeting times.

    The design process was useful in laying out the orginal requirements. It gave us a basis to recognize the functional specifications laid out by the customers.

    Our team ended up spending too much time on writing up the design of the system because of the strict requirements on the amount of pages that had to be done for each document.

    For the next design assignment I would suggest some changes to promote more of the spirit of the SEI guidelines. I would take old projects and store them on the web, along with the evaluations of the projects. These can serve as a Database for new projects in future years, and could be invaluable for future groups. In addition, I would suggest that some metric evaluation of our projects should be mandatory, and this should also be stored in databases for future use

    The Design process was in general good, however I feel that some of the tenants taught in this course could not be followed do to the limitations of this project. For one, as was mentioned by the Visiting Speaker from MOTOROLA University, small projects do not need thousands of pages of documentation, I feel that these projects are over documented, and more time spent on actual programming would greatly benefit the end results.



    Test plan evaluation



    Due to the lack of time, we sacrificed testing of the system.



    Management structure evaluation



    Since we had little experience in working in a group of this size, we found it difficult to follow the original structure. The structure of the team that was specified in the management plan was closely followed in terms of dividing the groups into smaller divisions. The main problem that we faced was that we lacked a strong leader.


    Comparisons of actual times taken for each part



    Each deadline for the documents were followed quite effectively. Everyone contributed their ideas through e-mail and group meetings which was then editted by the documentation team. The group spent too much time on the completion of the docuemntation requirements, thus leaving less time for the acutual implementation of the system.


    How we would have done it differently if it were a "real" project and What way could we have made the project less work



    If this were a real project we would have a different strategy to approach the problem. A few major points are:

    Group Organization

  • A different group structure would be set up. One of our groups problems was with the groups structure. In a 'real' project the question of who is in charge is taken away from the individual members. Having a predetermined leader would be necessary. This would have eliminated some of our groups questions. No doubt would have been left as to who was to organize the work that was to be done.

  • The documentation team would concentrate fully on the documentation and prepare a final design plan for the design team to implement. The design team should be present in the initial design stages to ensure that everything proposed is technically feasible.

  • Group break downs would have be handled more effectivly. People moving from one sub-group to another would have been avoided.



    Workmanship

  • Deadlines would need to be set. If each sub-group had to bring its work to present to the rest of the group at a partictular point a high quality of workmanship would be set. Encourage team work. Make the group feel that it is a group effort. Our testing failures are a result of our workmanship. Being unable to complete the protoype the testing plan did not succeed. In a 'real' environment it seem necessary to set aside a group of individuals to test that the product is up to the personal standards that the company has set.


    Customer Relations

  • More respect for the customers concerns about the project. Meeting the needs of the customer would be a higher concern. Meeting the customer group more often would ensure that the customers needs were met.

    Some dessenting opinions are as follows:

  • The group was divided into four people for documentation, and eight for the actual coding of the system. However, due to a weak leader and poor organization of the coding team the system was not fully functional.

  • Due to lack of organization in the coding team, the implementation of the system was greatly delayed.




    Lessons learned



  • We felt that the whole group learned that putting a project together is more work that they anticipated.


  • We learned the hard way that the medium that is going to be used by the group should be known to the extent that the programming team should be able to complete a project with it.

  • If an unfamiliar language is used, some members of the group should focus entirely on learning it so they are prepared when it is time to code.

  • We learned that interaction between the customer group is vital to the survival of the project.

  • Learning to have multiple people coding at the same time takes a certain amount of thinking, and planning. One cannot just rely on the super programmers myth as I once believed. Substantial planning at the beginning could have had serious benefits to group work later.

  • We thought that using the web as a means of communicating within our group and was very effective. Another point is that when working in groups you need to assign responsibility for the success of tasks to specific people. If no one accepts responsibility for the outcome then things don't get done.