I. With regard to the Unreal Estate Catalogue System, we required a level of functionality which would assist our Realtors in conducting their daily business in an efficient and effective manner. Thus we demanded a system which would enable our staff to have ready access to information while retaining security and a high degree of reliability and data integrity.
The specific features that were expected included:
1) Ease of use
2) Graphical interface with information displayed in an intuitive, visual manner.
3) Robust two-tiered approach to data-handling.
4) A high level of performance and data synchronization in a networked environment.
5) Access Levels and Security.
6) Flexible and powerful reporting capabilities.
II. In terms of the design process itself, we will discuss the roles of meetings, document design, liaisons discussions and their influence on the quality of the final product that was obtained.
We at Unreal Estate Inc., also known as Customer group #10, are satisfied at the software engineering process used during the project. However, there are a few recommendations we would like to make to improve the process with respect to the customer group standpoint. Before we do that, we will be going over Supplier group #10's presentation of the system and how well our requirements were met.
Overall the Unreal Estate Cataloging System designed by Supplier Group #10 met all of the requirements we set out at the beginning and even exceeded them somewhat. The extra features that were implemented impressed us greatly and we have total confidence that this system is the quality system that our company was looking for.
We are pleased with many of the features and how well they followed our requirements. The browse functionality of the system will let users to view information about properties quite easily. The information provided had enough buyer information to allow them to assess whether or not they would be interested in renting or financing properties. Another feature that was nice about the system was that the screens were consistent. For example, the administrator screen, the agent screen, and the browse screen were all basically identical. Even with this, we are pleased the system functionality was managed to maintain the administrator and agent as distinct users. We appreciate the effort taken to do this as it makes learning to use the system much easier.
All of the functions requested were added, but we will now highlight some parts of the system which stood out from the presentation:
The administrator presentation:
The agent presentation:
General overview:
The system as viewed was more then what we could have asked for. The level of detail attended to within the application was astounding. They seem to have complete control over the design and interface elements of the system. The interface was also extremely consistent throughout the application. It is obvious that a lot of time, careful thought, and ingenuity went into designing this application. The system followed very closely to our requirements and even took our concerns into consideration. The Supplier group has developed a system that will enhance Unreal Estate's growth in the industry and provide services to customers in their search for property in the city.
As for the development process, we managed to follow them and learn valuable lessons of the problems that can occur. At the beginning, our group was newly formed and because of that, it was unclear was sort of system we wanted. The description of what we had to do provided very little requirements at best. As a result we had to come up with many of our own. This could have been a problem had we been unreasonable customers, since we also had the same supplier perspective the Supplier group had. With the help of the meetings between the two groups, we were able to work out attainable requirements for the system. The entire, final half of the project was based on the Detailed Design Document, so we felt that the Customers should be able to comment on it. As it was described, the DDD embodies the "contract" between the two groups for the system that is to be developed. Almost no company would think of signing a contract without making sure that they, at least, had the opportunity to make changes to suit their interests. However, we didn't have the opportunity to do that; after the ODD, the Customer doesn't comment on or even need to peruse anything except the User Manual.
Perhaps the ODD and the DDD could be compressed into one document that the Customer can comment on. This would keep more of the members of the Customer group in touch with the Suppliers' current position. This would also reduce any confusion about specific details which might be forgotten over the course of the project design.
The one scheduled meeting between Customer and Supplier groups in the first week of labs was clearly insufficient. The Customer needs to know what is going on, and the Supplier has to be aware of the Customers' needs from some place other than a web page. Additionally, the first meeting was very early, making it good for first introductions and clearing up any superficial misunderstandings. However, as many of the problems that could be discussed at these meetings do not appear until later in the development cycle, more meetings in the middle and latter stages would be beneficial to both groups.
As it was, the Customers ended up in a vacuum, only seeing the system through the Suppliers' web page. It would be extremely helpful if we could get together later in the term to discuss some of the problems of the system, misunderstandings in the requirements, or incorrect information. More contact between Customer and Supplier can only improve the chances of the Supplier producing a system to meet our requirements.
The Waterfall method used for the project is not one which always produces software of the highest quality and usability. A prototyping model would probably have been more useful. It would certainly be a model which would involve the Customer far more than our limited involvement compared to the method we used. Producing a simple implementation of the system before the User Manual would allow us to give a better evaluation, since a manual is of little use when there is no system to use it with. In addition, there might be areas of which may suit our interests such as layouts and whether it is practical to do something a certain way. A prototyping model would help in that respect. Given the time constraints of the course, it might not be feasible to implement this kind of model but something a lower scale might be. In any case, we feel that having more scheduled meetings in between the two groups would be beneficial to the any process that is used. Still, we can say that the process can produce an excellent product as the Supplier group has shown us.
We are very pleased with the system produced for us by the R.I.P group (Supplier group #10). The system they have designed is extremely well organized and highly flexible. It incorporates many levels of "help" which will make it very easy to integrate this system into our daily business routine. All of our expectations for an intuitive and interactive interface have been met or exceeded. The open architecture incorporated into this system also makes it easy to import our current data into this product. It has been a pleasure working with the people at R.I.P toward the completion of this project and we are looking forward to the final implementation of this system at our head Unreal Estate office.
