Final
Report Department of Computer
Science Page maintainer: Terrence
Asgar-Deen |
| Editors: | Al-Amin Vira Terrence Asgar-Deen |
|---|---|
| Contributors: | Carsten Jaeger Thomas Hui Kevin Pattison Matt Johnson |
All opinions in red are the comments of Terrence Asgar-Deen, dHACs Software President.
This document evaluates the course work for Computer Science 451. In a simulation of real world software development, each member of the class was placed in two groups of twelve or thirteen people. This document discuss the success of the supplier group dHACs Software.
The main idea behind this project was the design and implementation of Sales Routing System (SRS) for Peachy Business Forms, a form supplier company in Calgary. dHACs Software has recently demonstrated the first-cut prototype.
The initial specifications from Peachy Business Forms included:
In addition, the system should provide flexibility to allow Peachy Business Forms' sales staff to adjust their routes according to their personal preferences. These features were established and verified through various discussions with Peachy Business Forms' representatives.
One of the primary concerns for the system is security. dHACs Software's SRS was designed around the issues of privacy and confidentiality, and ensures maximum security. Access to the system is protected with encrypted passwords and functionality in SRS is divided into two security levels:
Firstly, the salesperson is granted limited security privilege to the system, allowing the salesperson to interact with the system in their standard daily routine. The salesperson's major responsibilities include:
On the contrary, the administrator, having the highest security level in the system can perform any task in the system. The major responsibilities of the administrator includes:
Two different security levels ensures data integrity in the SRS software built for Peachy Business Forms.
dHACs software has also provided easy methods of accessing data in the database and generating reports on the fly. The SRS meets this requirement by providing the user with a single consistent interface throughout the entire system. Software engineering experts agree that having a single uniform tool bar throughout the system is beneficial for user's with minimal experience with this system and computing in general. The second requirement outlined called for generation of reports on the fly, the Sales Routing System generates all of these reports.
Reports provided by the SRS neatly encompasses most of the required system features. Reports that are provided by the system include:
Another feature of this system was to provides for Peachy Business Forms was the ability for a salesperson to change his/her route list based on his/her personal preference. dHACs Software ensure this capability to its fullest extent. The user of the system can change his/her route list, resulting in immediate update of the system for all future sessions.
The central goal of the system was to satisfy the responsibilities of route administration for salespeople who service multiple customers in a day. The SRS allows Peachy Business Forms to maintain records of which salespeople are responsible for which clients, the products that each salesperson is to deliver to the clients for each day and to suggest a visiting order in which the customers are to be serviced. Additionally, the system will have the capability to generate invoices, guarantee security levels and provide up-to-date information about the status of certain orders. While its primary function is not to replace the existing paper-based system in place at Peachy Business Forms, this will certainly accomplish all that was possible before, with the additional benefit of efficiency and accuracy. In short, the system strives to relieve the burden of administrative tasks, freeing time for more productive use.
In conclusion, the specifications were fulfilled in designing the project. The final product will include all the requirements and additional features that are necessary for completion. While the first prototype included some bugs, the production release of SRS will have ironed these out.
In order to make the project progress more efficiently, some changes are suggested. Reducing labors cost and minimizing the overall workload on individuals are some of the things that must be evaluated when trying to accomplish a task like this project.
The first thing that is recommended is that there needs to be greater emphasis put on concentrating on the project and putting more focus on the relationship between the supplier and customer. Since customers and suppliers work closely providing vital information to each other, it's a good idea to frequently share and discuss ideas in great details about common goals that are to be achieved in the project. The most obvious advantage of this technique is human resources are minimized. For example, if both sides are biased on certain ideas and suggestions, this will cost a certain amount of time to solve and find out the most reasonable and acceptable solutions. In the other words, if both sides are more open to opinions and suggestions via good social interaction in frequent discussions, an efficient progression of software development will be achieved. The other advantage being that the achievement of the final product would be accomplished by both sides, instead of it being the product of the supplier group only. This effort will improve the communication between the customer and the supplier, ultimately resulting in a higher quality product, for both the customer and the supplier.
The second suggested improvement for optimizing the design process is closer internal communication. In a sense, it means that when the project team is broken down into sub-groups, they should work more closer and discuss the issues in a great details between inter-group members. For the group to achieve this suggestion, we should encourage each other to speak up more and share his or her ideas and opinions concerning the project.
Also, a rigid development and checkpoint meeting timeline is appropriate. The main reason being scheduled meeting favors involvement among every single member in the group, which should be counted for in the final project. For example, if one of the group members can't finish his or her part on time, he or she can ask for help during the scheduled meeting rather than wait till the last second to ask for help.
In conclusion, management on human resources would be more effective and complete if every idea and opinion of the group members are accounted for. There are several advantages and disadvantages involved when working as a whole rather that working individually. For a group to succeed in achieving a realistic goal, every group member must contribute to reach the final goal.
The design process was very useful for the design of the system. The design method we used was somewhere in between a object-oriented design and a structured design method. This seemed to work well but may not have been the best choice for the platform we were developing on, which happened to be Access. The reason for this is that when developing database systems in Access it is hard to follow the design specifications, which is easily accomplished when using languages such as C or C++.
If we were to restart this project, we would definitely try to design the system using a completely object-oriented design methodology. This would make the design specifications a lot more useful when implementing the system. Another major change we would make is not to develop the system in Access. Although Access makes it simple to implement simple things, to do anything really complex is really quite difficult and requires the programmer to know a lot about Access functionality. Even though our programmers were extremely proficient in Access, some of the systems feature were not fully implemented within the expected time constraints.
We do not have any changes that should be made for the design assignment, except maybe there should be more emphasis put on the object-orientated design and OOD should be recommended as the way to go about the design. OOD is much better for designing a system with a graphical user interface, and will be more useful when designing in Access (if that continues to be the language of choice). I think that this will be more common in the future as CPSC 333 has switched from the structured design to the OOD methodology.
The testing plan that we used worked quite well. Our testing team was assigned certain parts of the system to test and then they relayed their findings via E-mail to the Quality Assurance Leader. The way each part of the system was tested was by picking common tasks that were to be done on the system, and then performing these tasks and noting any problems that may have occurred. By doing this we found most of the problems with the system.
We also used walk-throughs to test the system. These walk-throughs were a set number of task that are performed in a particular order to see if there are any problems when jumping around in the system. This was important because some parts of the system may work when tested on their own, but when tested with a lot of other tasks, the system may fail.
Overall, I think that our testing plan worked quite well and there is nothing that we would really need to change, however, more testing could have been done.
This part of the project did not take as long as it probably should have, i.e. a face to face meeting with the customer group (Peachy Business Forms). We had one brief meeting with the customer group that gave a rough idea of what they wanted. Because they (and we) were still going through some of the group dynamic things (getting to know each other), we were not sure who the decision makers were in the group, i.e. there was not clear structure to their team at this point. In a "real life" situation, there would probably have been an Office Manager, a Sales Manager, and perhaps President who we would be contracting with. On our side (dHACs), we might have had a project manager and sales/marketing person who would be working with the customer.
I think had we been given more time to structure our group into functional roles, we would have come up with this idea early on. Given the way the marking was to be done for the project, people felt (at first) that we should do things by committee, i.e. the more you said, the better mark you will get. This soon proved to an inappropriate structure, given other workloads and commitments group members had.
There should have been more meetings with the customer group. Exchanging emails was not always the best way to understand things. Again, time constraints were the overriding factor preventing a more productive dialog from taking place.
This took a great deal of time to produce. We were able to divide ourselves into groups that would be responsible for the various portions of this report. We probably spent more time than we should have on the "idealized" version of the product. Drawing entity relationship diagrams, data flow diagrams, etc. was nice, but it wound up that our final prototype was still tied very tightly to the capabilities of the software package we used to develop the product.
Dissenting Opinion
The design process was extremely important. Although it was unused for the most part, it did provide excellent insight into the requirements and how the system should work. Without it, the requirements analysis would have been incomplete. In addition, the SEI maturity model suggestions that documentation is one of the side effects of good process, regardless of its value at the time of writing, future work may require/depend on it. In retrospect, insufficient effort was placed on this task.
Our Webmaster and others spent a long time trying to determine if arrows were pointing the right way and if terminology being used was correct. In the overall scheme of things, it didn't really matter that much. During the product demo, the customer only cared if the product did what it was supposed to, if there was online help and if there was a way to change passwords.
If this were a "real project", we would not have spent so much time on producing pretty charts and graphs. We would have set up the basic structures on paper, defined the data elements, and probably have gone into prototyping mode much earlier in the process. This would have enabled us to verify some of our concepts and ideas earlier on and would have given us time to add appropriate help and searching features that the customer asked for.
Dissenting Opinion
Many of the important aspects of this course have clearly been lost in the above paragraphs. The above opinion is not the opinion of the entire group. While it is instantly gratifying to produce results quickly, it is the experience of others that taking the time to carefully plan the structure of a programming project has many rewards. Differing styles of planning may include producing "pretty charts and graphs"; moreover, this remains an excellent technique for understanding the overall system functionality at such an early stage in development.
In addition, the use of a "real project" is based one group member's experiences. However, it is not the opinion of other members of the group that this point of view is necessarily valid in its usage in this document. If it was always correct, then the software crisis that exists (in whatever form one chooses to see it) would not be a major issue in the field of software engineering. This fact is illustrated in the above statement that prototyping should begin immediately, well before the system is even partially understood.
I think the detailed design was well done by the group, but some team members were better versed at reviewing it than others. By the time the overall design was done, there were more deadlines to be met and the feedback provided was difficult to incorporate. Assigning responsibility for particular modules was done, but there seemed to be different strategies being followed. When some of them conflicted, we found it difficult to resolve. This later had a bit of an impact on the development team as they found the specifications were difficult to implement in the tool we had chosen (i.e. MS Access).
Structuring the group in the way suggested in the course outline (i.e. "Each person should review another person's section...pick the one with which your module has the strongest interactions") was not really practical. We had divided into a design team and a user interface team that made this somewhat impractical.
In a "real life" situation, we think we would have structured ourselves according to the customer needs and also to take advantage of each group members strengths. In the groups we formed, we were looking more to make sure everyone did their fair share instead of trying to get people to do what they were good at.
Dissenting Opinion
In "real life", the team would have been chosen based primarily on skills and competency in the specific subject area, i.e. software engineering. In addition, it is the belief that subdivision of the group would already exist regardless of the customer, based only on the skills of the individual group members involved. While initially the tasks were split on a "fair share" basis in this project, this was completely untrue as the end of the course approached. In fact, most of the work/tasks were assigned to the most competent and dependable individuals for completion.
Because this presentation counted for 10% of the marks, we felt we had to make a good impression. We tried to show the features of the system and find innovative ways of giving the customer the information they needed. For example, our group gave the customer a printed copy of the presentation so that they could take notes. I think we spent an appropriate amount of time on this.
Dissenting Opinion
It is not the opinion of the entire group that the quality and effort placed in the presentation was proportional to the numerical grading value associated with it. Rather, the presentation provided an opportunity to demonstrate our ability to be computer scientist in an industry simulation. In fact, our presentation was a reflection of our pride in be computer scientists, not to earn marks in the course.
The customer group did not ask too many difficult questions during this session and we were able to satisfactorily answer them. In "real life", this session would have lasted much longer than 10 minutes and we would have gone through a more formal contract negotiation phase.
A lot of time and effort was spent on putting together the detailed design document. Our Webmaster and others were working overtime to get things in place by the deadline. Because of this and the fact that it was to be 80-100 pages, we focused somewhat more on quantity than quality. In "real life", we think the customer would have cared more about what was in the document as opposed to how much was in it. We developed testing plans that we would follow, but because access to the prototype was limited, we found it somewhat inconvenient to complete all testing aspects we had planned.
Dissenting Opinion
In fact, there was a lot of quality in this document. The major problem was that it was reasonably terse and general. In fact, much of the specifications were not even documented. The detailed design document was quality content, but minimal and without sufficient quantification.
Our development team built a prototype which was demonstrated to the group for feedback. Moving the prototype from one machine to another gave us a few headaches, but all in all, it looked pretty good. We used concepts of modeless environments and chose to implement this in MS Access.
In "real life", we would have probably developed this in some other tool that we could run on a network in our company so that the development team could get at it easily. We would have also had more than two people responsible for portions of the code and given ourselves bit more time to work on it. Our development team did a very good job under the circumstances and spent a great deal of time on making it look good.
We built the appropriate user manual with screen shots, etc. In "real life", the user manual would not have been built this early into the project. We were still going through final parts of the prototype by the time the user manual was done. This made it necessary to go back and change some screen shots, explanations, glossary terms, indexes, etc.
Dissenting Opinion
In fact, the user manual should have been built BEFORE the prototype. Such a skeletal manual is not necessarily meant for the user and would not have included extreme specifics or screen snapshots, but would have helped to focus and describe the interactions of the user in more detail. In many cases, producing a first cut minimalist manual before beginning to code has many advantages. The only evident "disadvantage" is that it requires more work.
Our presentation team did a really good job. They rehearsed the presentation and worked as a well coordinated team. They dressed appropriately for the part and focused their attention to the customer. A transcript of the demo was submitted. Our customer group was somewhat displeased in that the prototype did not implement some of the features we had thought we would have done by this time to the extent they had hoped.
In "real life" we would have probably been presenting to a smaller audience and have shown them a few more iterations of the prototype prior to this point. Through a more formal set of discussions (say weekly meetings), our prototype and the suggestions for improvement to processes would have been a bit closer to what the customer was expecting.
During the semester, the group has changed somewhat from the original groups designated. The groups themselves were evident throughout the semester but there were many transitions from one group to another as the course continued.
At the start, the groups were very organized and the work was quickly and efficiently completed. These groups worked well together, as they did throughout the course, but various factors started to arise that caused problems with the overall group layout.
Some groups did their work which was later found to be completed incorrectly. As a result, people from other groups had to fill the gaps and finish the work for the other groups. This is what started the role transitions during the course. This progressed as the course continued and started to cause stress within the majority of the members. This led to a lot of wasted time and disorganization which slowed down the output of the group members.
Opinion
In fact, the group hierarchy should have been developed and enforced earlier. In fact, the majority of the group did not like the idea of a group hierarchy at the beginning of the course. Slowly, as it became clear that project was not progressing evident leaders emerged, including Terrence Asgar-Deen and Brian Low. In addition, since the groups talents were not explored, Jeremy Tang's programming skills and Patrick Chan's attention to detail (as a document editor and general troubleshooter) went unnoticed for a long time. Moreover, since the group was not balanced in skills certain areas were underdeveloped. A prime example is an interface design leader who has taken CPSC 481. In fact, only one member had completed CPSC 481, the overall group leader.
But as the course continued, and as the presentations started the groups were getting more organized again and with the completion of the course the various members were within groups that were again efficient. But at many awkward points, more competent and industrious members were forced to transfer from one group to another to get the work done.