Having gone through each screen step by step we were able to see the functionality and features of each screen. We especially appreciated the fact that Macrohard has taken the time to give us optional ways of doing things. eg. having shortcut keys to access the functions of the system. We are pleased that Macrohard implemented the context-sensitive Help too. The presentation also clarified many of our queries which we had in our review of the User Manual. For this, we like to congratulate Macrohard for their flexibility in accommodating our requirements.
The only critique that we have with the presentation is that the way in which you talk about and describe the different screens. It tends to be a bit confusing at times. In your attempt to fully cover all the screens and functionality of each buttons in such a short time limit, it seems complicated. To go through the screens in a more logical manner would be a point to improve on for the future presentations.
We realize that this is a first draft of the system, and we appreciate being consulted and being allowed to view the system at this time. We hope that our consultation concerning the design decisions at this point will help in the further development of the final product.
Thank you.
The Main menu was clear and easy to understand. It was well defined into the basic functions and nicely presented. The order window was well done as well, with the data clearly laid out and the most useful information centered in the screen. The buttons were consistent in the header and footer and there was no ambiguity in functional intent. The searches and filter features on the Product list window was very nice. BFI liked the Route list, especially the Regenerate route list command which was very simple and straightforward. The route list report was quite nicely laid out which was of major importance.
The section appeared to be completed according to specification. Considering the complexity of the interface, BFI was very impressed with the amount of functionality our suppliers managed to implement in such a short time.
There were a few very minor deviations from the specification on these screens (eg, the printing of certain fields in the report), however these are attributed to a lack of time. The features were trivial to implement and were not included because the group wisely chose to distribute its time to create a well-rounded overview of the product.
BFI is confident that the customer and order information areas satisfy all functional demands.
It is a neat idea of not implementing the Print button function (due to the restriction of the demo) but instead, it generates a layout how the list should be printed. Nevertheless, it would be also nice to be ready-to-go-and-run if the it is actually implemented with the proper print function.
The Add to Order button (Only valid when entered from the order window) is a good feature which allows the user to add a product from that screen. Via the order windows first, the user should be able to tell which order he/she is dealing with.
Finally, as mentioned in our previous documents, the button label
There was some functionality that the supplier group had missed or
done differently from our original specification. We originally
asked for the system to be able to print a list of customers of a
specified number for which the salesperson could take along in
doing his/her route. This specified number n, would be the top n
customers that would likely purchase our products. In this way, if
our salesperson didn't have time to visit all the customers in one
trip, then he/she could choose to visit only those customers that
were most likely to buy. However, the supplier group presented us
with a slightly different method. In their final implementation,
there was a column called "Active" which corresponded to each
customer. If the salesperson wanted to include a customer in the
route, he/she would mark off that customer to be active. This was
a suitable alternative but it required that the salesperson choose
the customer that is to be excluded or included and in doing so,
might not actually choose the most prospective customers to visit.
Another thing that the supplier group overlooked was to include the
"notes" section in the route list. The "notes" section are
optional descriptions that the salesperson writes about a customer.
We had ask that this be included in the route list printout, but
this was not seen during the system demonstration.
Overall, the supplier group had done a good job in providing the
functionality that our group had asked for in the routing aspect of
the system. The system they produced allowed us to print the
optimal list, to choose the desired customers to be included in the
route list, and to display the products that the salesperson must
take for the trip. The supplier group were quit willing to make
amendments as requested and often provided us with good
alternatives or compromises.
The demonstration of the new software package surprised us a great
deal. Not only did our supplier group deliver a complete system, following
all requirements and added corrections, but also displayed added features
that were a bonus to what we needed. This shows that our supplier group not
only worked to get the minimal system up and running, but made an active
effort to deliver a system that is user friendly. The demo showed attention
to detail, such as being able to select and unselect which customer should
be printed on the route list, being able to use a mouse or a fast key,
advising the user of all changes done to the records, an online help system,
being able to enter different windows from more than one area, and many more.
Conclusively, we can say that we are satisfied with the outcome of this
project. We experienced that it is possible to work without dispute, that
any conflict can be settled in a diplomatic and compromising way, and that
people do try to satisfy your requests a best as they can, sometimes even
better than expected. Overall it was a positive experience to work with
supplier group 1, and a positive outcome of the project.
Overall the design process encouraged communication amongst the
supplier and customer groups, indirectly. On only one occasion did
we actually meet with our supplier group to discuss progress on the
system and to address any questions from both sides. The remaining
communication was done via the documents placed on the Web and was
successful only when both sides had read the documentation
completely. We were able to let our supplier group know what we
liked and disliked with the system by responding to the documents.
Throughout the design process and now after viewing the demo there
are still many improvements that we had initially overlooked.
Revision of the documents gave us many ideas but we came to realize
that only time yields perfection. The importance and cost
associated with system maintenance became more apparent as the
system approached its final stage of development. In all the
design process helped us as customers realize what exactly we
wanted in the system and it helped clarify many problems.
Throughout the design process we were witness to unforeseen problems
many of which could have been avoided. We have a few suggestions
that may help improve the process.
Time was a major factor in producing the required documents and
there just did not seem to be enough of it. In the future we
suggest that you allow longer time periods to complete documents.
Of particular concern was the informal specification. We hardly
had enough time to get to know our group members before the
document was due. In this case more time should have been given to
establish group structure and a means of communication before the
actual document was written.
The most important suggestion involves communication or the lack of
it. Simply put our supplier and customer groups did not communicate
as effectively as they could have. Throughout the design process there were
misunderstandings because one group did not understand what the
other had said. In most of these cases the inconsistencies were
noticed only within the documents and even then some were
overlooked. To solve this communication problem we suggest that
more emphasis be placed on group communication. That is dedicate
more class time in which the groups should meet and stress the
importance of internal and external communication, e.g. e-mail. We
understand that it was the groups who were supposed to communicate
with each other but without proper guidance this was a difficult
task to achieve.
The role of the customer in the project was rather small. We feel
that by involving the customer more in the design process the end
product would more likely meet their requirements. For example
require that the two groups meet every few weeks to discuss
progress and potential or existing problems then have the customers
produce a communication log discussing those sessions.
Lastly we noticed that as the project proceeded the amount of
interest in it dwindled. Many students within the group became
less interested in performing their duties. The problem we feel
lies within the size and complexity of the project. We understand
that it was worth fifty percent of our mark so that it rightly
should not be overly easy. The problem seemed to stem from
redundant information and massive reading. As an example the
design document was over one hundred pages. This required an
extreme amount of reading and at the best of times was difficult to
ensure that all group members had read it. We suggest that, to
enhance overall learning and to stress the importance of software
engineering, the course be extended to a full year.
The Route List
For the most part, the supplier group had done a good job in
meeting our requirements for providing an optimal route for our
salesperson. They had managed to produce a list that our
salesperson can use to guide him/her to all the required
destination in a efficient manner. Satisfaction in regard to the Project and the final System
BFI has virtually no complaints or criticism to give
about how our supplier group conducted the development of the requested
system. Right from the beginning communication was courteous and straight
forward, which made our work, explaining what we wanted in the new software
package, that much easier. Most of the communication was held through the
required documentation, while minor misunderstandings were dealt with via
email or small group meetings. Virtually all problems, that arose, dealt with
the routing part of the system. However, this feature was initially explained
by us in a somewhat ambiguous way, causing the supplier group to make some
erroneous assumptions. Once we explained our requirements in more detail, and
compromised with the supplier group to a more simpler version of what we
originally wanted the supplier group then went ahead to produce a design that
only needed very small corrections in some areas. We are pleased to say that
all recommendations we had asked for were implemented in the final version
of the software.The Design Process
In all there were three major documents involved in the design
process. They were the informal specification, the functional
specification, and the overall design document. The informal
specification was an attempt to define and understand the problem.
We did this somewhat apprehensively as we were not given much time
to establish a group structure and means of communication. Hence
the informal specification was incomplete. The functional
specification gave us the opportunity to include any desired
features omitted in the informal specification. All the changes
between the two documents were met as requested. The response to
the overall design document again gave us the opportunity to ensure
that the system was being designed to our specifications. As
before the supplier group was open to suggestions on improvements
and features of the system.