FINAL PROJECT EVALUATION
The PlaNet Meeting Management System
Supplier Group #8

Transcript of Presentation

Overview of Requirements

1. Ability to add, modify and delete personal appointments and group meetings.
2. Meeting should specify: start time, end time, location, list of attendees and comments.
3. Security and Maintenance: administration system to add, delete and modify employees/employee information (including passwords). We incorporated this functionality for meeting locations as well.
4. Automatically generated notices to inform employees of any changes to their schedules.

Fulfillment of Requirements:

1. All of the above requirements were met through the use of the easily learned and understood calendar metaphor along with fully functional on-line context- sensitive help.
2. Enhancements were requested to find common available times and schedule periodic meetings. Unfortunately, due to time constraints, these were not implemented. However, they have been planned for in the design specifications. We feel that these would be valuable improvements to the final product and intend to implement them for any subsequent release of PlaNet.

Eric:

1. Login (Administrator)
2. Add Trish as a new user
3. Add a new meeting with Trish and Bob (notice misspelling of Bob)
4. Correct misspelling of Bob.
5. Exit

Trish:

1. Login
2. Notice message about new meeting
3. Change my password
4. When was meeting? - go back and look at notices
5. View the details of the meeting
6. Recall that I have a conflict with the meeting
7. Use on-line help to cancel attendance at meeting.
8. Add new meeting (orthodontist appointment) using on-line help.
9. Exit

Eric:

1. Login
2. Notice from Trish about canceled attendance.
3. Attempt to delete a room already scheduled for a meeting - can't be done.
4. Add a new meeting room
5. Modify meeting to be held at a new time in the new room.
6. Go back and successfully delete the meeting room
7. Add a meeting in June
8. Exit

Trish:

1. Attempt to login using old password - unsuccessful
2. Login using new password
3. Notice about new meeting updated by Eric
4. View meeting and confirm that there is no conflict

How well our project satisfies our original functional specifications

We believe our final project exceeds our original functional specifications. Much of the functionality we'd placed in the "If time permits" section was actually implemented. After a meeting with our customer, we realized the importance of notifications to the system and altered our design plan to accomodate this feature.

We would like to have had "Find Common Time" and "Periodic Meeting" working in time for our final presentation, but due to time constraints this was not possible. Since these were optimizations they did not compromise the sucess of our overall application, we are leaving them as additions to the final version.

How useful we found the design process and differences we proposed

The design process was helpful in setting the ground work for our project. Though we would have liked to have seen more of a push toward object oriented design since the DFDs were of little use to our windows application. Surprisingly, it was the screen shots that gave us the most accurate feel for what our system would become.

Regardless of all the design documents we prepared, it was hard to get a realistic idea of what was involved until the project was programmed. We also feel that it would have been useful to allow time for Joint Application Design.

We propose that, in the future, the customer be given a bigger role in the process. As a group, we agreed that one of two important changes could be made; join CPSC 333 and CPSC 451 into a full year course or make 451 a full year course where half the class are in supplier groups and the others in customer groups that would switch roles in January. We feel that the customer should take their role more seriously since the sucess of the supplier group relies on their commitment. Customers should have more time to decide and agree on a set of requirements. After a particularly frustrating experience with our own customer group, this has become an poignant concern of ours.

How our test plan worked

It is our regret that the test plans were never used. The coding was very involved and took more time that we'd anticipated. Completing the application and providing the functionality requested by the customer took precedence over the testing phase. Testing occured throughout development, but we didn't hold a meeting specifically for testing the system as we would have liked.

How Our Finished Product Compared with the Functional Specification

We found it paid off to solidify the important design decisions early on so we didn't have to make major design changes later. This meant that our code was easier to write and the project was easier to partition among the programmers. We did spend a lot of time on design in the first half of the course.

One of the most useful parts of the functional specification was the user interface section. While we were coding, we relied extensively on the screen shots from Visual C++. It is hard to say how closely we followed the functional specification because on some parts we did more on others we did less.

1. New programming environment -

only one programmer had (minor) experience with Delphi. We all to learn a new system and that caused us to stray and worry about little implementation details rather than stay focused on what the product had to do.

2. Changing Requirements -

As we came closer to getting a product, we started understanding what was really difficult and what wasn't. This caused us to not implement some of the difficult things that were written in our specs. Also, the customer changed the requirments on us quite late in the design stages.

These changing requirements caused us to shift focus on what was important. Some of the new requirements received higher prioirities than some of the old ones in the original spec.

We felt that we implemented most of the promised functionality with meetings. We came up with a very usable interface and users could easily add/view/modify meetings. Some minor things were not implemented, but a lot of these special cases were not formally written down in the functional spec anyway. For example, the user couldn't alter the day that a meeting was to take place. We thought we could do this but when we saw the hidden difficulties, it was too late to get it working for the final presentation.

The program could not schedule meetings as well as we had hoped because the user could not ask the program to find a common time for all people. This would have been a big time-saving feature for potential users in the system and it was one of the main points in our funcitonal specification. Also, periodic meetings were not implemented in the system.

This was one of our most tested sections and was done to exceed the requirements written in the functional spec. Since this section was one of the first to be completed, we had time to think about it more and add testing for special cases: like adding a duplicate employee or removing a location that had meetings scheduled for it already. This part of the system exceeded our own expecations.

This component of our system surprised everyone on our team and everyone else that saw it. Our system had full blown context- sensitive help. The user could get help about all system functions and could even search for specific topics. We were very vague in our functional specification about the help system, but ended up implementing a very comprehensive system anyhow. This exceeded our own expectations and the customers' as well.

This component was added as a requirement very late in the design phase and caused us to redesign significant portions of the system. Despite that, we still managed to implement it according to our functional specification. Notices were sent to employees when

1. A meeting was added to their schedule
2. A meeting was deleted from their schedule
3. A meeting in their schedule changed
4. Someone cancelled attendance from a meeting they selected.

We did not send any special notice information when a conflict in a users schedule occurred. We had this in our functional spec but didn't have time to code it. This made the system very usable because users would be updated about schedule changes. In our opinion, any successful scheduling system needed this feature as a prerequisite.

This system was almost a full blown email system, with the exception that users could not mail arbitrary text. Each had a mail box though and messages were sent to users in response to system events (like someone cancelling a meeting). Users could read their mail or delete it.

We did not envision such an elaborate system in our original specification.

Overall Ease of Use

We designed our system to be easy to use. This meant that a lot of the constructions we chose were difficult to implement. To our surprise, we did end up implementing them though. Some of the visual innovations we had were:

Calendar Control

• User could change days by clicking on the calendar
• User could see on which days he was busy.
• User could change the day of a meeting by bringing up a calendar object. (Good example of reuse as well)

Daily Schedule

• This was an orderly list of all the time slots in a users day.
• Timetable conflicts were visible in a user's day.

Other Employees Schedules

• Employees were grayed out when they were busy. This changed according to the meeting day and time proposed. This made the application very easy to use since you knew when you could safely schedule a meeting.

Our Management Plan

The following points will be discussed regarding how our group's various plans for completion of the project relate to the actual performance of those planned actions:

A - Personnel Management

At the very start of the project, our group proceeded to divide itself into subgroups which would concentrate on specific areas of the project. These subgroups included: project coordination, overall program design, technical writing, user interface design and programming, database design and programming, presentation, and Web site management.

Various members of our group were assigned to one or more of these subgroups. Assignments depended primarily on the skills of the team members, but also relied on a degree of volunteerism from the members for the various subgroups.

In general, the actual task performance of the team's members matched the way that the subgroups had been initially set up. There was a certain degree of overlap, and role-changes as well. For example, if more work was needed on technical writing, some team members from other subgroups would help out. Also, initially it was Dave Gomboc that did a lot of our Web page maintenance and editing, but as the project advanced, Eric became much more involved with the Web site. Another modification that was made was to the allocation of programming work. It was felt that 5 programmers would be suitable for implementation of the project code, since any more would become unwieldy. The presentation team became much smaller as well.

A note should be made regarding project coordination. Many more meetings were held at the early stage of the project than at the later stages. In addition, most of the meetings toward the end of the project took less time. The reason is that allocation of tasks for the various team members required much more attention at the earlier stages. This was because the deadlines for the various tasks were far more frequent, and so more care was needed to coordinate the group's actions. After the code stage commenced, and deadlines became less frequent, the amount effort spent in personnel management decreased substantially.

B - Time Management

It was very unclear through the many stages of the project exactly how much time would be needed to complete the various project tasks. The varying degrees of complexity of the issues in the project design documents often led to uncertainty over how much time that would be needed for completion of those documents. Personal schedules, meetings with the customer group, and other time conflicts often made coordination of our efforts difficult. In addition to this, during the implementation phase there was some uncertainty as to how much time it would take to code the product. Learning the programming environment, understanding database programming issues, solving performance bottlenecks, and debugging the code all made it very difficult to assess the project's time requirements.

Initially, our group had planned to coordinate our time management through the use of progress reports. This became impractical on a strict basis, however, probably because of the work overhead it would incur. Reporting was done generally on an ad-hoc basis: progress reviews were often done within group meetings, as well as using e-mail.

C - Project Structuring

As part of our group's project management plans, we had initially proposed dividing up our system into 5 structural components: the database 'back-end', the employee management subsystem, the navigation system, the timetable and diary subsystem, and program documentation. This was a highly effective division of our project since it allowed our team's subgroups to concentrate on areas of specialty. Each of these projects were done in parallel by the various subgroups. For instance, the user-interface subgroup could be working on methods for presentation of the data in the employee management subsystem, while the same time the database subgroup would be working on ways of designing database for the same subsystem. This division of labor was used both in the design stages and the implementation stages. In this way, a highly effective, efficient division of labor was carried through the entire project.

Things we would have done differently in the real world

Software engineering techniques were neglected in an attempt to meet deadlines. Code reusability, code extendability, documentation and code maintenance were all comprised under the imposed time constraints. Preparation for our final presentation suffered since the code was still being debugged up to the last half hour prior to the presentation. Were this a 'real' project we would have comprised less and focused on the software engineering aspects more.

Changes we'd make if we were to do it again

There are several areas we'd choose to approach differently, given the opportunity to do this project again. One of our greatest regrets is that we didn't request more meetings with our customer. In the meetings we did conduct, we wish we would have known the importance of taking more detailed minutes. While the initial requirements were subject to many changes by the customer, there were also some conflicting interpretations among members of our supplier group. A well documented set of notes from these meetings would have saved us the task of redesigning our system and would have spared us much frustration. In retrospect, we also feel that had we negotiated more with Imagine8, we could have obtained a well defined and better understood set of requirements earlier in the project.

Too much time was spent in the first few weeks getting things organized when setting agendas would have been more useful.

It would have been to our advantage to test our graphical user interface with the customer. Had we sought feedback from the customer on a more regular basis, it would have simplified many of our tasks. Applying JAD would have helped in this area.

Implementation took a lot longer than was speculated by the instructor, who did not recommend coding until March. Had we known sooner, coding would have begun much earlier in the semester. We experienced many platform decision changes before selecting Delphi. Our initial choice was Visual C++, but after talking to others, we decided against it since it has a reputation for being too low level. As our programming team had almost no prior experience with Delphi, time was required to learn the new language.

Coding standards such as variables names and code documentation would have been very helpful. Were this product to be maintained, these would have been made critical considerations. Not enough time was spent consolidating internal methods and this resulted in some redundant code.

The lack of a common code base, or document base, made it very awkward to have multiple authors working on the same code/documents. When various people were working on the same program, we had to take great precautions when merging code. With respect to document submissions, the web master's job of integrating multiple contributions could have been simplified with a document-sharing system.

Our group was divided into technical writers and programmers, which we felt was the most logical and natural division. After completion of the user manual, it was evident we'd made the mistake of working too independently. We now realize that we should have worked more closely together to maintain consistency between our documents and the actual application.

We never considered the issue of portability. Had we found or should we find a market for our product we would have to address issues like database compatibility, cross-platform compilation and migration of the GUI.

As a software engineering course, the general consensus was that the project forced us to place too much emphasis on programming. No marks were awarded for clean object oriented designs so the code became quite unmanageable.

Lessons we've learned

In general, we agree that important and applicable lessons were learned during this project. We gained valuable experience working with large groups and learning to designate responsibilities.

As a group, we've learned to be patient with people whose ideas are a little different from your own, because they may turn out to be better ideas.

We've learned that getting the database structure and the front-end GUI right early in the project is essential. Though it is also important not to solidify it too much in case modifications are required later.

We've seen the value in choosing a development platform that is easy to learn and sufficiently powerful to achieve our goals. There's no sense spending valuable time learning a complex language or working with tools kits that don't provide the components you need.

Focus on the debugging problems that hinder critical functionality. Save debugging of superficial things until the major problems are worked out. Aim for reusability of code. Allow for enough time to rework code so that redundancy is eliminated.

Remember - the product is for the client! Consider user-related issues like help, visibility of interface items, the product appearance under different screen resolutions, hot keys, and other HCI aspects.

System performance can be hard to evaluate before implementation is well advanced. There has to be enough time provided to evaluate performance so that optimization can be done to correct bottlenecks.

A group-ware system, and source code administration system (e.g. SourceSafe) would be highly valuable.

Things we are proud of

We are proud of our group accomplishments this semester. We were fortunate to have benefited from and been influenced by the experiences of other group members. Designation of tasks, competent and dedicated workers and great group dynamics are some of the factors that can be attributed to the success of Ingrated Software Solutions Inc.

The division of labour concept worked well for our group. Assigning different members to different tasks allowed us the opportunity to work with a variety of people and personality types. Internal deadlines were good in that they allowed us time for revision and improvements and a way in which to accomplish our many goals.

We take great pride in the confidence and professionalism demonstrated in both of our presentations. It was rewarding after all the hard work and time invested in such a project!

With respect to our application, we are especially proud of the extensive amount of context-sensitive on-line help. Our code was very robust and bugs were never debilitating. Our live database allowed us to demonstrate real-time additions, deletions and modifications during the presentation.

Our greatest disappointment is that after developing such a fantastic product, it will likely never be used or seen again. We'll never feel we had a fair opportunity to show-off all of PlaNet's features and functionality. It's still a great feeling to know we successfully developed and delivered an application of this scale.