This memorandum presents an evaluation of the design process from the point of view of Supplier Group #11. The topics for the discussion include:
2) An assessment of the usefulness of the design process.
3) Suggestions for improving the design process.
4) A discussion of the various components of the test plan.
6) Proposed changes to project had it been an actual commercial development.
Back to Supplier Group # 11 Main Page --->
A significant deviation from the original Informal Specifications set out by our customer group involves the omission of "real time" functionality. The manner in which Customer Group 11 interpreted the original requirements suggested that the focus of the development effort rest firmly on a simulation (or even actual manufacturing) of embedded microcontroller hardware. Thus a customer at the automated gas station would be able to drive into the station, enter his credit card into a card reading device and begin pumping gas: All data would be updated in real time. Shutting down a particular pump would cause a pump to refuse transactions. Moreover, multiple pumps would operate simultaneously.
Producing such a system would require a fairly sophisticated network (an absolute minimum of two computers connected peer-to-peer via a network card) and would require a programming effort dedicated to handling synchronization conflicts and managing an efficient communications protocol (possibly customized for the application at hand) rather than actual data management. Also, a platform for real time processing, a degree of experience and familiarity with networked programming within the group, and a large amount of time would be needed to generate a reasonable simulation of such a system.
After consulting with the TA (Sean Orourke), it was decided (with Sean's approval) that the emphasis for development would instead be placed on a simulation of the data-handling "back end" of the system with a focus on the actual interface and overall organization of the system. The real time networking functionality, deemed outside the scope of the assignment, was "subcontracted" to a microcontroller manufacturer. However, the specifcations for this portion of the system *were* incorporated into the Overall and Detailed design documents.
Ultimately, the portion of the system that *was* in fact implemented conformed closely to the original informal specifications. The system was broken down into 3 major access levels:
Administrative Access Station Control Access Fuel Delivery
The administrator may add and delete users (with the exception of his own account), modify passwords and view various usage logs. The administrator also has access to the Station Control portion of the system.
Station Control handles all of the reporting capabilities, alterations to various variables (such as fuel price or reporting period), and viewing and configuring information pertaining to the current status of the system such as pump and tank status.
The fuel delivery component is very simple:
It allows fuel delivery personnel to enter information about their deliveries (fuel type, amount, value, etc.) into the system. A fuel delivery agent may not have access to any of the other portions of the system (Administration or Station Control).
What began as a very formal and fully drawn out set of procedures to software design, turned into something not quite what most expected. Though on paper, the Design Process followed by this term's Software Engineering class, seemed (and is) quite intuitive and the proper way to go about software design, in practice, in an novice environment such as ours (short time frame, little group to group interaction, and little to no direct guidance or mentors), it doesn't seem so logical. Most of the time of the group and it's individuals, was spent on writing documentation. Since there was little time to allow for a fluid flow between the major sections of the design process, it became a rather choppy and somewhat disjoint set of events.
The first problem to address, regards the lack of time and environment. It is understood that a change in the time frame to accomplish a complete course of Software Engineering is an unlikely solution, but there were some areas and periods of time when better more, efficient usage of time could have been spent. One example would be lab time periods. It would have been nice to have spent this time further understanding and analyzing the stages of the design process, in more detail, in relation to our specific projects with the TAs (it is also understood the lack of bodies to fill these positions, and adequately). Our TAs were not nearly as well informed or knowledgeable as we would have presumed. It was very difficult to get information on the "what and how" that was required for the document that was currently being worked on and nearly impossible to get information on how that document was to be marked.
The other concern that our group had was the amount of group to group interaction that existed between the Supplier Group and the Customer Groups. It seemed as though, the whole Supplier portion of the project could have seemingly been completed without the Customer Group at all. This may be somewhat of an exaggeration, but the amount of feedback and communication between the two groups was severely one sided. The Customer group could not possibly fulfill it's Supplier's needs with a simple and uninformative set of responses to the massive amounts of information they receive. Several pages of comments, which only a fraction could be deemed informative, could not possibly cover all of the problems that a 100+ page document can have. A solution to this problem may be to also develop the roles of different individuals of a Software Engineering Team. For example, the roles of communication sub-teams, programming sub-teams, documentation sub-teams, and so-on. The individuals of these sub-teams need not stay stagnantly in the same position, thus allowing them to understand all components of a design team.
Fortunately for our Supplier Group, Group #11, with strong leadership, great internal communication, and hard work, the design process worked itself out. We were able to keep good relations with our Customer, as well amongst ourselves, and in the end deliver a product we all could be pleased with. Without such leadership and individuals with field experience, such success could not be forseen.
In the following section, we will suggest possible changes to the design process to improve its effectiveness. We think these changes, if taken into consideration, will help the suppliers produce a better product and customers follow along with the development of the product. In some cases, time might be saved due to removing redundant steps, combining parts, and specifying more details by different parties. Also, some points will be brought up on the structure of the design process we used as to how it order of events may be improved. The design process is what we will be mainly discussing but some suggestions will target the course structure that was used to maintain the marking. More specifically, logs and placement of all information on the web will be included in the following section because of its close involvement in the groups process development. We will make suggestions to many of the factors that contributed, or at least, played some part of the design process.
Time constraints of the course didn't really cause many problems for our group. There was enough time finish the project with reasonable effectiveness but the deadlines for certain parts were just too clustered or spread out. Without removing any of the parts of the project development process, we suggest that some of the assignments be given a little more time to complete. The detailed design document was a rather large assignment and since our final program was to follow everything specified in this document, it is very important that we can thoroughly complete and evaluate this document. With a short time frame to finish the DDD, we had a presentation to prepare for. This doesn't allow enough time to present some reasonable prototype for the customers that describes what they want because the DDD was just handed in but its evaluation was not complete. The DDD also cannot really be seen by everyone given the size of the document. Even the people doing the short presentation could not go over it to cover all the points the customers wanted to hear. Also, due to time timing of the DDD, it was intermingled with other course midterms and many other other assignments. This reduced the quality and understanding of the DDD. So shifting the all the assignments up to and including the DDD earlier, or just the DDD later would be beneficial. That way some time at the beginning or end of the semester can be used to improve project development. Given the size of the detailed design document, moving it could cause other problems with the timeline of events. The customer groups will not have that much time to respond to it. So maybe even streamline the DDD into smaller parts will help people cope with the entire document. Having the DDD broken down into smaller sections with different due dates might help both the customer and supplier group understand it better.
As can be seen, the timing of assignment deadlines can be considered to improving the process, but also briefly mentioned is the problems that might arrise to these timing changes. So we should look at the parts of the process in detail. Since the size of the DDD is a concern of ours, we suggest maybe shortening how large it has to be and actually specifying what needs to be in it in more detail. No one can really go through that large a document quickly and understand it. With a large group, we were able to complete the task but the group became fragmented, and they did not know exactly what other people did. Making this change should allow everyone to go over the DDD and understand what is going on and what everyone has done.
Another item of concern was what each process step, or assignment, needed. It was quite clear that many people were confused as to what to put into each part. This could be the result of the initial specifications of what the customers had to expand. With that, the customers would add more confusion to the issue by defining requirements which we were unsure whether we could implement it. By providing more specific information as to what each assignment had to have, or providing more time to figure out the requirements, or better yet, have an assignment to just respond and repeat what the requirements were, this would eliminate some confusion in the documents for the system being developed. On the other side, placing more detail in the initial specifications for the customers and how far they were to carry out the requirements would assist the supplier groups and also result with less confusion. Having more meetings between the supplier and customer groups would have a great impact in clarifying details (even greater impact if TA's also knew EXACTLY what was going on).
The order of events of the design process could be changed to allow better involvement for both the customer and even members in the supplier group. The customer group could only comment on the overall design document and not the detailed design document. It's understandable that the DDD is considered the binding "contract" to the customers, but since they don't comment on the DDD, why not have it due much later and have an initial user manual and some prototype of the program to show the customers. Then a second user manual could actually follow the final program more precisely through the prototype. That way the final program would incorporate the customers input as to what they would like to see and the DDD would be more complete. Another way would be to have some customer response to the DDD but given its size, this can be a lot of work for them to go over.
Finally, given a project of this size, we had the man-power (or should I say: staff-power) to complete the assignments and project with considerable effectiveness and quality. It must be pointed out that the group was well divided to complete the tasks, and is such a case, parts of the group did not know what other parts were doing. This also made logs much harder to produce. Assignments were usually quite large and nobody would try to actually understand everything. Webmasters had a lot of work to do with editing and formating. Reducing the formatting work needed for the web would help, maybe reducing the size of the documents to put up. That way Webmasters can better concentrate on editing and understanding what was in the document, and maybe able to relate this information to the rest of the group.
Overall, the process has merits and flows fairly smoothly towards creating very well designed projects. It provides excellent step-by-step understanding of what goes into designing a project through the breakdown of the design documents. Many of the problems could be alleviated with better group dynamics and excellent group organization, but this can't always be the case in an intensive environment caused by the fact that many individuals have other course demands. So taking some of the above mentioned suggestions might help in making the software engineering process more enjoyable, efficient, and more productive in both the outcome and our what we take from it.
The majority of the testing was actually performed by the programming team. The station system was thoroughly tested but any testing of the pump functions was not performed. This was because of the contracting out of the pump to be put on micro coded chips by another comapny. They are responsable for the testing of the pump interface.
The station system was vastly unit tested and then was put through thorough integration testing. This allowed the programming team to locate the fallowing errors in the initial prototype.
- Any bugs in the individual parts - Any bugs in the interaction of the individual parts
We were very fortunate that the main programmer for the station system was very active in the design of the testing methods. Because of his vast knowlage of the system and its parts this allowed for a very complete testing of the system and its individual parts.
One problem was that the test plan did not look for any differances between the customer groups specifications and the actual finished project. Although we did later go back and fix any deviations between the design specifications and the project threre was really no set plan for co-ordinating the two.
After looking at the final version of the assignment it is obvious that the testing plans were very useful in helping us reach our final goal for a fully automated gas station system. In the end we were very happy with how the system turned out.
The management plan includes project team management and the development of the sytem.
The development team is divided into smaller teams. Each of these is responsible for a logical section of the system during the design and analysis phase. Each sub-team stays with the assigned section through out the whole design & analysis phase. Thus, this arrangement allows the development team to have a thorough understanding of the component of the system being developed. Although the subsystems are independent from each other, the development teams have to consult each other to make sure that the subsystems will integrate to a fine-working system. At the end of the design & analysis phase, the teams are re-organized to programming team, help team and documentation team. The task of these teams focus on implementing a physical system and writing up the User Manual.
There are some minor changes to the development plan so that the system being developed satisfies the (additional/modified) requirements from our customer group.
The software developed follows closely to the original requirement from our customer group. However, there are some features that have been added/modified or unimplemented. The unimplemented features are those that is hardware dependent such as credit checking and realtime networking functionality.
From the original specification, the subsystem are completely independent (ie, each access level will have a main menu specifically design for the user with that access level). However, the final products allows the administrator (ie, the user with "administration access level") to have access to the Station Control subsystem. This makes the administrator to have more control on the system as a whole. Thus, the administrator would also be able to perform the operation specifically designed for user with status of Station Control access.
The final product also takes the advantage of the graphical base system such as giving a graph for the statistics of credit/debit cards that are accepted/rejected. The graph gives the user a better view of the statistics.
An additional feature to this system is the generation of the standard reports based on a number of search criteria. With this feature, the user could generate reports of necessary information and filter out the information not needed in such reports.
Finally, this system is developed with the focus on user friendly interface, and the correct functionality. This system is graphics based and supports on-line help for each menu. This satisfies the requirement for the user-friendly feature of the system.
First off, the project was really three projects combined into one. We had developed around the pump interface and interactions, the head office accounting procedures, and the remote data up-link between a head office and a gas station.
In a real world project development effort, three subgroups would have been formed and would have been used throughout the system development lifecycle. Each group would concentrate on their own particular part and would have contacts between the groups. Each group would then separtately develope the pumps, head office interaction, and remote communications referring to each other on the relevent parts that will interconnect all the subsystems.
Secondly, the demands of the customer would have been met more closely and thouraly due to the fact that what they wanted would have been possible in the real world. I would have used their original user specifications for the comercial development of the entire system, however their specifications for the head office application that would control the system would have to be revamped entirely. These specifications need to be done in very clear detail and more interaction with the customer would have taken place to nail out the design specs!
Thirdly, using the internet as a GroupWare medium is far to inferior, and far less adequate a tool for development teams to use. It does not invite communication between the customer, beteen the suppliers group members and within the development team itself ! There are numerous other solutions that would have been far more beneficial. Also, because of the way the groups worked, only one person was responsible for publishing the documentation to the www as well as proofing... Setting the teams up in these three groups, and then having each group be responsible for there own documnetation is far more efficient and less work overall !
We found quickly that in order to accomplish what we needed, we had to split up into subgroups. It is true that for several steps of the design process, we found that brainstorming sessions with the entire group were a much needed source of ideas, as this allowed us to bounce ideas off each other and get the diversity of input necessary. This was especially the case in the initial planning phases of the design, when the focus was on general program structure, database implementation, and other very broad topics. Once these were out of the way, it was necessary to split up and work in smaller units where communication was simpler, and schedules were easier to synchronize. This allowed us to work out detailed tasks among subgroup members, all of whom knew most if not all of the aspects of the particular job they were working on.
This also provided a sort of built-in modularity to our work. In many cases this was a benefit, but it tended to make our group members "specialists" in one area of our system or another, be it data abstractions, user interface, or implementation. This in some sense steered us as to the tasks assigned to different group members. For example, the help documentation was a natural task for the people who had done the user interface, but some of them wanted to work on implementation, which meant reassigning the members of the subgroups. Overall, this did not cause very many problems as we were lucky enough to work very well together as a group.
One element which restricted the implementation of the system was that the user manual was not written at the same time that the programming was being done. This caused some incongruities since the authors of the manuals had to write their conception of a largely non-existant system, and then the programmers were forced to try to adapt their implementation to the already written manual. These steps should have taken place simultaneously, or if not, then the manual should have been written to describe a system that was already in place.
It would have been very useful to have users of our product come in and "test drive" a prototype and give us their oppinions about the system, and in particular about the ways in which they would most likely be interacting with it. This was obviously impossible due to the time limitations, but it caused us to have to make assumptions about what the users would find most useful, what they needed easy access to, and so on. It would have been much easier to design this system if we had had experience in administrating the operation and accounting of a chain of gas stations ourselves!
While the design process used was a useful tool to organize all of the members of the group to complete the task of producing our project, it certainly did not accurately reflect a very a realistic process for developing software in the "real world." First, in "real life", the team would be totally committed to the project on a full-time basis which was not the case in the context of a full University schedule. Second of all, there would be a great deal more real incentive to develop an impressive product. Finally much less time would have been spent on the kind of "busy-work" associated with this project. Instead this time would have been invested to insure that the entire group had a real and complete understanding of the system at hand. In this course, there was neither time nor incentive for this to really take place. On the positive side, the group learned about the importance of cooperation and organization, development of a very meticulously clear design paradigm and the importance of consistent and well fleshed-out ways of breaking tasks up while retaining coherence in the overall design. In our opinion this was truly the most challenging aspect of this course. It would have been helpful if the actual course material had focused more on developing a concrete set of heuristics and examples vis-à-vis "good software design" and object-oriented methods than on vague lists of things that were "a good thing to do."
Introduction - Vladimir
Levin
Section 1 - Vladimir
Levin
Section 2- John
Mozayani
Section 3- Les
Lohl
Section 4- Sean
Reid
Section 5- Francis
Nyugen
Section 6- Carey
Bingham
Section 7- Dominik
Royko
Conclusion - Vladimir
Levin
Last Updated 04/19/1997
By : Carey Bingham
e-mail : bingham@cpsc.ucalgary.ca