Overall Project Evaluation
Book Lenders of Canada would like to take this opportunity to express
our thanks to Nexus Corporation for a job well done. This software
development company has shown itself to be extremely organized and
professional from the beginning, and their demo was of no exception.
It was obvious that all members of their team, who were always present
and knowledgable, had put a lot of time, energy and thought into the
design and implementation of the system.
The development team did an excellent job of presenting the library
system they developed for our company. The demo was well planned,
informative and interesting. Firstly, our company was impressed with
how quickly they had the system loaded and running. The practical
scenarios provided a tour of the entire scope and sequence of the
system. All of our members feel that a tutorial based on the demo would
provide an excellent overview of the system for a novice user.
We feel that Nexus Corporation succeeded in producing a high quality,
dependable, and convenient system for Book Lenders of Canada. It was a
pleasure to work with this company and we look forward to doing
business in the future.
The demonstration given by NEXUS corporation conveyed a strict
compliance with are detailed design document and verbal requests.
Moreover, all the features implemented were done so in a manner which
we had tried to explain in our document. Not unexpectedly though,
there were a few discrepancies between our wishes and the final
product. Mostly, they were in form of additions. Firstly, is the
setup procedure. A full installation disk to setup the program was
provided which is a nice 'commercial' touch. This was never considered
by our group, but we all agreed, was a good idea. Secondly, the speed
of the system compared to an application such as Access was most
impressive. On the negative side, for the lending books function, we
stated that an information screen should be displayed about a borrower
when his or her library number was entered into the system. This was
not implemented. This does not greatly interfere with the lending
operation, but it would have made the system more informative as one is
doing transactions. Another point, probably trivial, but an important
operation was the login screen at the start of the program where a
password is entered. It had been implemented, but it didn't work. We
felt confident that it would be simple to correct, but this is a
critical feature in any database program.
The following is a list of functions/details that we have requested and
their implementation status (ie. are they implemented).
-
Add a new book: very well done, especially the confirmation to leave a
field empty
-
Remove a book: love the search
-
Update a book: done
-
Search for a book: excellent!
-
Report on status of all books: once again, excellent search function
-
Adding a borrower: done
-
Searching borrower: love that search!
-
Removing borrower: great job on filling in the empty fields
-
Updating borrower: done
-
Report on all borrowers: fantastic search function!
-
Lending Books: great job, thanks for considering a scanned in call
number along with a typed one
-
Returning Books: excellent use of arrows!
-
Renewing Books: done
-
Recalling Books: nice message when someone tries to renew a book on
recall
-
Searching for Books: very impressive search!
-
Single password: done
-
Book on loan limit: done
-
Fees: done
-
History of fines: like the idea of saving to a file for archiving
The Design Process
Our experience as a customer group has left us with both good and bad
thoughts about the design process.
The design process overall was a good learning experience. However, we
feel that we would have gained more if the process more closely
modeled real world software design. For example, the customer would
demand to see the product as it is being developed. Group members
should be able to be disciplined more effectively either through
evaluations or being able to terminate group-membership.
We feel that there was misinformation and misinterpretation between
customer and supplier groups. This is because much of our
communication was through documents. We discuss this further in the
section of improvement for next year process.
Many of the inconsistencies between the delivered product and what we
expected could have been ironed out had we seen an early prototype.
This would also facilitate usability testing with customers.
The design process worked well in some other area. For example, the
requirements we specified in the functional specification were clearly
communicated. Writing down the requirements forced them to be
communicated effectively. The process of reviewing the design helped
clarify the specifications even more and allow the product to evolve.
If we were to do things differently, what would we do?
Throughout the year we have found the role of customer groups
invaluable to creating a new perspective on product development. This
is a much different view from the standard computer science course
where your sole responsibility is for developing a product from a given
specification. We feel we are now in a much better position to
understand and meet customers concerns in future projects, having been
now been on that side of the "development fence". However we feel that
the process in general might be aided by the following suggestions:
More Interaction between the customer and supplier groups is necessary,
times must be set up where the groups can meet, especially between the
initial design document, and the detailed design document. This is a
time period when many of the small details of the project need to be
flushed out, and more interaction could definitely speed this up, and
smooth over any rough edges.
More time dedicated to labs would also be a benefit, as well as
relocating the time period, people seem reluctant to work in the early
evening, as many people are tired after a long day of school.
We believe it would be fundamentally invaluable to keep all of the
documentation for old projects in a Data Warehouse, where future groups
could access them, this would follow the teaching of current SEI
philosophy as well as being an invaluable benefit to students, who can
see what has been done in the past, and how it has worked out. This
would require new projects every year, or cycling them with the Data
Warehouse, but the end result of being able to practice some of the
techniques mentioned in class would have benefits that more than
outweigh any negatives. On this topic it would have been nice to cover
the SEI material earlier in the course, so we could possibly make use
of these techniques in the development stages of the project.
Requiring the actual implementation of some metrics on the project
would be quite beneficial from the perception of the group, as well as
more formal testing requirements which need to be completed, would
definitely benefit software quality.