We felt that given our specifications, the library system was a very challenging project due to it's inherent complexity and size. Nonetheless, VoidWorks Inc. managed to meet and exceed all of our requirements and expectations. It was even more impressive after learning that the implementation was handled by one sole developer.

We were very impressed with the BMS system and how smoothly it appeared to work. Some of the things that exceeded our requirements included a full featured help system and a complete tutorial section. This will benefit the users of our system immensely. The user interface was very functional and while the

dialogs were uncluttered they were comprehensive enough to allow for efficient usage. Having functionality in convenient places made it obvious that much thought went into the design of the

interface. For example, a 'New customer' button was placed on the dialog to borrow books. This way, if a new customer was taking out books, they could be added directly to the system from this screen. VoidWorks demonstrated a very good understanding of our users' needs.

Having icons on the buttons made the screens visually more attractive and intuitive. All the screens had a consistent look and feel which made the task of the learning how to use the application much easier. In our original specifications, we asked for the system to be easy to use and this expectation was fully met.

Although we did not have strict performance requirements, the BMS system appeared to be very efficient. During the presentation, screens came up quickly and query results were generated almost instantaneously. Upon receiving the implementation we found it worked just as well on our own machines.

Report generation capabilities were part of our original specification. Though VoidWorks claimed to have implemented this, it was not covered in the final presentation.

Presentation

The scenarios presented in the final product demonstration were fluid and very easy to follow. It was an effective way to show how easily the application could be used and how quickly it could be learned.

The choice of use cases shown during the presentation were well thought out. We liked the idea of seeing frequently used functions, like borrowing and returning books, combined with less common functions, like adding books to the library. This illustrated that regardless of the types of actions a librarian might perform, all tasks were equally intuitive and easy to execute.

Distributing the software to our entire customer group demonstrated their confidence in the application's robustness. This also showed that VoidWorks was proud of their product and rightfully so.

Not enough time was dedicated to the customer group making it difficult to formulate a consistent set of specifications. During the first few days of 451, we were expected to come up with an informal set of specifications for a software system which didn't yet exist in our minds.

 This made it difficult for suppliers who were working from "unfinished thoughts". Since the supplier has a huge responsibility to design and devlop a complete system from these initial specifications, more time should be spent as a customer. It is unfair to give a supplier such low quality work that may not have been taken seriously.  

A possible improvement to 451 may be to not even mention anything about supplier groups for the first two weeks. This allows the customer groups to produce more polished and reasonable specifications, and to be more committed to the project. Our meetings consisted of brainstorming sessions which made it easy for everyone to share ideas. We found this was an effective way to involve all members of the group. After brainstorming, it came time to select someone to collect the results and publish them for the next deadline. Though there was a substantial amount of work for one person, it was difficult to split among two or three. With the few assignments, there was little opportunity for everyone to share the workload equally.

Miscommunication was one of the difficulties experienced between our customer group and the supplier group. This could have been alleviated with more interaction and more scheduled meetings. In the future, more time should be set aside for question and answer periods to aid in the design process.

Security was one issue we miscommunicated throughout the entire design phase. We mentioned in our informal spec that two different classes of users would be required to use the system. Our library had librarians and supervisors, each with different levels of access. When the system was implemented, only two password were provided, one for supervisors and one for librarians. For security purposes, we would have preferred each employee having their own password. It is unfortunate that we realized this shortcoming so late in the project's phase.

The Role of the Customer Group in this Course

 We feel that the customer experience wasn't realistic because as computer science majors we had too much insight into programming and software design. The project specification is given more from the standpoint of a computer scientist than of a real world customer. It might be good to team up with the management faculty for a software engineering and management course. Computer

Science students could do the programming and act as the suppliers whereas the management students would play the role of the customer.

 With the work load assigned in this class, it would be better suited as a full year course. Time constraints placed on students limits the quality of the learning experience.