Final Evaluation For TimeTracker Project


The following is an evaluation of our experiences in CPSC 451. We do this in the form of three reports. The Product Report discusses how well we executed our assigned task (i.e., producing a working software product). The Project Report describes and evaluates our carrying out of the project. The Assignment Report discusses our experience and response to this as a pedagogical exercise.

Product Report


During the design and development of the TimeTracker time management system both the functional specification and the look and feel of the system changed several times. In this section we present a tabular summary of some of these changes.

Major revisions in the functional specifications:

The original specification called for daily, monthly and weekly views. In a meeting between customer and supplier group representatives held before the Overall Design Document was produced it was agreed that the main view would be a weekly view with information about specific meetings displayed when the meeting was selected. The primary reason for this decision was that screen resolutions would not allow a monthly view with meaningful information. This was executed as specified.

The original specification was not clear as to precisely how availability would be defined. In the aforementioned meeting it was agreed that availability would be in terms of hours worked on a typical day during a typical week. That is, regular hours worked. It was assumed at the time that we would need only deal with a single block of time each day so no provision was made for dealing with split shifts. We also believe that making this provision would make setting availability a great deal more difficult for the user since the user would somehow need to specify how many blocks they would work in a day.

In the original design a reply function was specified. In the aforementioned meeting it was agreed that people would be automatically scheduled into meetings if they were available and informed that they were scheduled in a preformated system message. To decline an invitation the invitee would delete the meeting from their daytimer and a system message would be generated and sent to the conveenor indicating that the invitee would not be attending. This was implemented as specified as were two of the other three system messages: "a meeting you are invited to has been canceled" and "an attempt was made to schedule you to attend a meeting at a specified time and you were unavailable". The message "information about a meeting you are attending has been changed" was not implemented at the time of the demonstration

Other changes to design and functionality of the system:

Functions were added to manage system security

It was specified that no notification of new messages will be given. This was actually implemented.

Employee database was implemented as a separate system that has stand alone utility

 In addition to the above there were also many changes to the system design in the three distinct designs we produced for the customer group. In summary we believe that we met most of the needs and the specifications of the customer group.


Project Report


1. The design process


In general, we felt that the design process was extremely valuable. The primary benefit was that it helped us to formalize the design of the entire system before any coding was done, forcing us to examine the system and its intended operating environment from as many angles as possible: integrity of the database, ease of use, intuitive task flow, and the meeting of as many customer requirements as possible.

2. The test plan


How the Test Plan Worked

On the whole, the test plan was very useful. Having a documented test plan aided in the development of TimeTracker by ensuring that nothing was overlooked during the testing process. By implementing the testing process in a series of stages, it was ensured that all components of the system were operational before combining them into a working system. This had the advantage that the testing team could focus on one level only when performing system testing. For example, if a test failed at the Integration testing stage, the testing team need not backtrack and retest the individual modules unless a module was actually changed. Because of the test plan structure, the testing team could be sure that the modules were in fact working correctly and the search for the problem could then be focused on the combination of separate modules. This saved time and time is money! By specifying a test process before testing began, the test team was relieved of the extra pressure of remembering all areas of the system to be tested and could instead focus on the task at hand.

Following is a detailed checklist of the scheduled testing phases indicating which tests were carried out during development of the Time Tracker Employee Scheduler software system:

Stage 1: Module/Unit Tests (March 11/96 - March 14/96)

This testing stage ensures that each of the listed modules performs its specified function. The modules tested at this stage are for the most part "stand alone" modules (i.e., the building blocks of a larger system). This section of the test plan was very useful. By ensuring that each module was completely tested and in "working order", the programming team was able to concentrate their debugging efforts towards a higher level program when integrating the modules together. As well, by specifying such a test plan in a written document, the programming team found that it was less likely to overlook a potentially critical testing procedure. By allowing some time in between testing stages, we allowed for any unplanned events. This proved a wise decision when some final database revisions postponed some testing during Stage 1.

1. Login Module

Test 1: Test login procedure.

2. Update Database Module

Test 1: This test will make sure that ALL automated meetings and the manual meetings that have been created will be written to database correctly and all messages sent to everyone in the meeting.

3.2 View Meeting Module

Test 1: Will show proper viewing of a meeting. Test 2: Will show proper viewing of a meeting making sure no carried over information is left from a previously view meeting. Test 3: Will show that when an empty space is picked, nothing is in the meeting viewer.

3.3.1 Load Scheduler Form Module

Test 1: Make sure when you load the form for a meeting the function keys appear. Test 2: Try a invalid date/start time and make sure it gives an error and prompts for re-entry.

3.3.2 Select Meeting Module

Test 1: This will be a test when greater than or equal to one convened meeting is in the list box of convened meetings. The task will be successful if the program displays the correct meeting information. Test 2: This task will ensure that the program does not halt when the user clicks in the empty list. Technical Justification: This may not seem like a reasonable test, but when a list box is empty it will have a list index of -1. It is possible for the user to produce a click event on the list without highlighting any meeting. Without error checking to cover this, the system will attempt to gather information about the information in the -1 position of the list, which does not exist, and often will crash. (Although Delphi may foresee this.)

3.3.3 Cancel Meeting Module

Test 1: Will show proper deletion of a message when the user clicks for the system to do so. Test 2: Make sure messages will not be deleted if "Cancel Meeting" was not clicked.

3.3.4 Schedule Meeting Module

Test 1: This test will demonstrate that when all normal input is entered, the system will notify the user that the meeting was scheduled, write messages to all employees invited, and write the meeting to the database. Test 2: This test demonstrates that a meeting in which no employees are scheduled to attend will not be written to the database. Test 3: These tests demonstrate that meetings that are scheduled to occur in the past will not be written to the database.

3.3.5 Manual Scheduling Module

Test 1: Demonstrate that when all normal input is entered, the system will notify the user of those employees that can attend and those that can not. Test 2: These tests demonstrate that if a user attempts to schedule a meeting on a date/time that has past, the system will notify the user of his error.

3.3.6 Automatic Scheduling Module

Test 1: This test will demonstrate that when all normal input is entered, the system will find the best possible time slot. Test 2: This test demonstrates that the system should notify the user that no employees can attend in this time period. Test 3: This test demonstrate that if a user wants to find a time for a meeting on a date/time that has past, the system will notify the user of his error. Test 4: These tests demonstrate that if a user wants to find a time for a meeting from a later date to an earlier date, the system will notify the user of his error.

3.4 Availability Module

Test 1: Test the invalid input of date or time period. Test 2: Test the valid input of date and time period. Test 3: Test the change of availability after the initialization.

3.5 Messages Module

Test 1: Notification of a new meeting requiring your attendance. Test 2: Notification of the system attempting to schedule user into a meeting. Test 3: Notification that a meeting invitee, for a meeting user has scheduled, has declined the invitation. Test 4: Notification of a canceled future meeting. Test 5: Notification of a change in meeting plans/ideas that user is going to attend. Test 6: The user can click on a message and get the in-depth details. Test 7: After the user reads a message, it will no longer be a new message upon re-entry. Test 8: After the message is deleted, it will no longer exist in the system. Test 9: The user is not allowed to delete a message which is tagged as new/unread.

3.6 Alias Module

Test 1: Entering a New Group. Test 2: Creating a new group/alias. Test 3: Creating a new group/alias. Test 4: Deleting a group/alias. Test 5: Edit an existing group/alias.

Stage 2: Integration Testing (March 18/96 - March 22/96)

This stage ensures that the modules that were tested in Stage 1 can be combined without flaws to the system function. Testing at this stage focuses on the higher level functions that are implemented using lower level modules. Again, a documented test plan ensured that nothing was overlooked. It allowed those testing who were testing to concentrate on the testing process rather than on whether or not they had missed anything.

3.0 Main Functions Module

Test 1: Will show proper calling of Scheduling function. Test 2: Will show proper calling of Messages function. Test 3: Will show proper calling of Availability function. Test 4: Will show proper calling of Employees function. Test 5: Will show proper movement of the calendar to previous month. Test 6: Will show proper movement of the calendar to next month. Test 7: Will show proper calling of View Meeting function. Test 8: Will show proper termination of program.

3.0 Event Handler Module

Test 1: Click on all buttons mentioned above to call each module in the system.

3.3.0 Scheduler Event Handler Module

Test 1: Make sure that you can select a meeting. Test 2: Make sure that you can cancel a meeting. Test 3: Make sure that you can schedule a meeting. Test 4: Make sure that you can manually schedule a meeting.

3.7 Calendar Event Handler Module

Test 1: Click on all parts of calendar mentioned above to call manipulate the time period viewable from the system.

Stage 3: Functional Tests

This section describes a list of tests that will be performed on the TimeTracker system during development to ensure conformance to the customers list of requirements. It is intended that adherence to the items in this test plan will result in a package that meets all functions required by the customer. This test section was most useful when used as a checklist to compare and monitor whether or not our customers requirements were being met. While specified as Stage 3, the Functional Test section was more of an iterative process that the programming team used throughout the entire implementation process. This section was again utilized after the Integration testing process as to ensure that customer requirements were in fact met. This was perhaps the most valuable portion of the test plan.

Stage 4: Performance Evaluation

This overall plan is designed to see if an employee can enter the system, make an appointment, and leave, in a reasonable amount of time (30 sec/2 min), for both user scheduled and computer scheduled appointments. This section of our test plan was perhaps the least useful. While worthwhile in the long run, performance testing was not "priority one" at this more prototypical development stage. Axiom enterprises does accept the fact that performance is of great importance for a working system but at this stage of development, reliability and functionality was of utmost concern and the performance testing was more or less put on hold.

Stage 5: Acceptance Tests

The system demonstration will feature the basic functions of Time Tracker System. These features will be evaluated against our customer's initial system requirements. The user manual accompanying the Detailed Design Document will be used to measure the usability of the procedural instructions of the system. We are looking forward to this section of our test plan as we believe that our customers will be satisfied with the product that we have to offer.

3. Group Management


The following is the original description of the responsibilities of the managers for this project. 
Duties of the Managers:

       Product Manager: 
              Oversees the overall project requirements; 
              Delegates to Program Manager & Doc Manager the materials needed for the
              successful completion of the project; 
              Facilitates and coordinates job tasks between the Doc & Prog teams 
              Liaise with customer group; 
              Oversees the overall project documentation. 
  
      Documentation Manager: 
              Structure the Documentation Team; 
              Responsible for setting documentation standards and datelines; 
              Reports to Product Manager. 

       Program Manager: 
              Responsible for setting programming standards and datelines; 
              Reports to Product Manager; 
              Structure the Programming Team;

We developed this management structure after the first document was completed because we thought it would be better to wait until we had a better idea of what we were doing before organizing ourselves to do it. In general this structure has worked very well although we have had to be flexible when one of the managers was ill or otherwise occupied. Looking back, it is clear that our greatest strength was this flexibility and not any particular management structure.

4. Summary of time commitments

We estimate that approximately 70-75% of our efforts were spent on negotiating with our customer and specifying the system in detail. This work resulted in a series of documents and a presentation to our customers. About 20% of our time went into coding, testing and the demonstration of our project. Something less than 5% of our time was involved in group meetings. A detailed breakdown of hours/time spent on each aspect of the project follows: Functional Specifications and Management Plan. Approximately 10% of our time was spent on this document. This was before we were fully organized but this was a relatively small project and all group members took part so it was fairly easy to complete.

Overall Design Document and Detailed Design Document. We spent a lot of time on the Overall Design Document so the Detailed Design Document was relatively simple. We spent about 25% of our time on The Overall Design Document and about 15% of our time on the Detailed Design Document.

User Manual. We put a lot of effort into our user manual to make it the easy to view and use. We spent about 15% of our time to perfect the user manual.

Evaluation. The documentation team put in about 5% effort into this document with the help of some of the programming team (about 5%).

Presentation. There was 3 of us that planned the presentation and we spent about 2 hours rehearsing for it. We also prepared overheads and screen snapshots for this. In total we spent less than 5% of our time on this

Demo. The demo required us all to look and understand the system.About 5% of everyone's efforts were put into this demo!

5. What we would have done differently


In general, we worked well together, the work got done and was of good quality. Here are some things we would do differently in future: More communication between members to inform others, especially the managers, when they are behind in meeting their deadlines. This would help in meeting deadlines without panic and in fairly distributing work.

More customer participation in the interface design phase, this would help reduced the 'guessing' of what they required.

A Design Standards Review Body to constructively critique the system design, with (4-5) team members from both (Documentation/Programming) team, including the Team leaders. This would improve communication about the design and reduce misunderstanding.

Design Assignment Report


1. Suggestions for the next design assignment


These are the observations that our group would like you to take into consideration for future classes in CPSC 451.

Our group believes that using the web, especially HTML has some definite advantages. The first and most obvious is that the web is environmental friendly, we do not need to waste paper as documents on the web are easily accessible. As well, the web can be used like a "hub" where all work can be displayed and accessed by all group members. This allows for better communication within our group. By using the web as a "hub" or meeting place, it reduces the amount of meeting times for the group in general. In all, we found the WWW a definite asset in this course, we would however like to see a few changes. To begin with we suggest that for future CPSC 451 classes allow a lab to teach HTML basics to the class so that all members are able to place documents on the web instead of depending on one or two people to do the job. Secondly, placing graphics on the web is very memory intensive so more disk quota for students in 451 would be helpful.

Our group all agreed that CPSC 451 course is very useful in the real world especially the invaluable team work experience. We all agreed that the experience we have obtained can be advantageous for interviews, as most employers are looking for students who can work in groups and deal with group situations. We also looked at the possibility of having workshops for business presentations and workshops on working in groups. We thought that maybe a brief presentation on how to work in groups would be beneficial to the class as a whole.

We also noted that we should have more customer contact to allow for better communication between us and them. We found that it was often much easier to resolve misunderstandings in a face-to-face meeting than through written documents. The more you can talk to the customer group the quicker you can develop the product that they want.

CPSC 451 is a very good learning process as it made our group decide on action plans on how to complete the assignments and the project as a whole. The specification of the project was broad so it was hard to foresee all possible situations. This should be the case, in the real world you would be given a broad outline of the project and it would be up to you to come up with the problems and scenarios to report back to your client.

2. Lessons Learned


Provide screen snapshots as soon as possible. At first this is a lot of work but it helps clarify the design for the customer and saves work, and misunderstandings, later.

Get to know each other at the start of the project. Acknowledging and utilizing each others strengths and defining members' areas of contributions reduces working / personal conflicts.

Be flexible and contribute to the accomplishment of the task that needs to be done.

Trust each other.

Over-specifying a task to be performed hinders: specifying the goal of the task encourages others to perform above and beyond the tasks' bounds.

Use the 'chain-mail' method for editing/annotating documents to get the editing done more quickly and reduce the need for meetings.

Develop and enforce standards for documents ( in terms of style, format, & tone). One way to do this is to create templates.

Monthly members' reports of their tasks and responsibilities mailed to each member, helps the group to do their(peer) evaluation log/report more easily.

Appreciate individual effort it encourages member participation. Acknowledging individual and team contributions increases project quality and team productivity.Criticisms should be constructive and objective, not personal.

Keep meetings short. Have an agenda and leave detailed planning to subgroups.