One of the most important differences between working on a homework assignment and working in industry on a product is teamwork. Once you graduate, you will never again be able to work entirely by yourself on any company-sponsored project. The group project for CS3733 is designed to mimic, to some degree, the experience you might have on working on a multi-team project.
Each team will develop a component that fits into a greater application. Once all components are developed and tested, it should be possible to mix-and-match components to form individual instances of the application. In this way we will satisfy our reuse objective.
We now present the basic process that each group will follow (see syllabus for dates).
The class will be divided into groups of three students. If you have a preference of the students with whom you wish to work, please forward that information on to the TA responsible for groups. Students who do not respond by Sunday March 16th at 5:00 PM will be randomly assigned to remaining groups.
Note that it is fine to send requests such as "Student X and Y would like to work together" which I will use to try to fit within a single group.
The Requirements Analysis Document (RAD) describes the project which is to be completed by the entire class. Each group will select a specific component on which to work. Note that each component will be implemented (at least) twice, so we will have a good chance to completing the whole assignment.
Group RAD document is in preparation [3-10]. Its latest version can always be found in the sourceforge documents area.
The analysis for each group project will be formally assigned on Monday March 31st. Your first task is to set up regular meeting times with your teammates. You shall also be responsible for preparing a schedule showing the hours your group intends to meet and the individual hours each team member expects to work.
Expected format here.
Once all interfaces are fixed for each component, they are relatively stable. Check out the latest on-line documentation for the interfaces that you will need. If you have any questions, your group must see the TAs or the professor.
Expected format here.
Once the interfaces are properly defined, it will be possible to implement shells for each component in the system and make them available for assembly. Note that it is expected that there will be no functionality in these components. Rather the purpose is to ensure that every group has become at least familiar with the CompUnit component model to which their components must ultimately conform.
Deliverable: Upload your component using the online web-based system.
Once the classes have been analyzed, your task is to put together a skeleton version of your component. It will literally do nothing but be instantiated and support the provided/required connections to other components.
The alpha version will likely do nothing but output to the screen "Not Implemented" when it gets a request to perform a method which it declares to provide as part of a provided interface. However, you can follow
The implemented alpha version is due by Monday April 14th via an online submission (now available).
There are no points assigned to this version. The goal is to get a head start on the technology and the interfaces.
As described in class, the focus is on getting a working component. I will describe a way to show testing within the CompUnit technology but I don't want to distract the teams from producing working and completed components.
As your component implementation increases in functionality the goal is to pre-test issues that are likely to occur when the system is integrated from all components. By the time the beta version is released, all interfaces used by components will be stabilized.
The final component produced here should represent more than half of the required functionality of your component.
The implemented beta version is due by Tuesday April 22nd via an online submission (now available).
Many well-designed projects fail when the implementation occurs. The primary responsibilities of this phase are to ensure that the principles decided during the design phase are maintained and that the code is robust enough to gracefully handle error situations. The goal of every implementation should be to produce well-documented code that a programmer will not be embarrassed if an external review occurred.
The Group Implementation (GI) deliverable is due at the start of class on Monday April 28th. Once completed, all groups will have one final day to assemble a fully working KombatSolitaire system from individual components developed by other students in the class.
The challenge of the group project will be evident in this phase as we try to mix-n-match components from each of the groups to form fully-functioning examples of Kombat Solitaire.
Once a software component is implemented and tested, each group is responsible for
packaging that component for external use. This includes appropriate documentation
of all interfaces and example scenarios on how the component is to be used. As a
starter, each group will produce javadoc documentation so that other teams
will be able to use their component.
A challenge is a task that one does not know at the outset whether success is assured. An earlier version of KombatSolitaire was used during early offerings of this course, and the code has been much improved. I have provided a lot of infrastructure code to help this project along, but ultimately the success of the project will be determined by your hard work.
| heineman@cs.wpi.edu |
| 04/21/08 12:53:40 AM |