W06 SENG 411 Project
From Craig
| Table of contents |
Project Information
A major component of SENG 411 is the project. The project is broken down into 4 major milestones:
- Requirements gathering
- Project Planning
- Iteration 1
- Iteration 2
For each milestone a series of goals are defined and groups will be required to submit completed work in support of those goals. In support of the goals, students will not be told specifically what documents to produce; how the group shows that it has fulfilled the goals is up to the students themselves. It is highly recommended that students review SENG 311 course material and research agile methods to see how the goals can be met.
Each group will have 6 members (+/- depending on enrollment). Students will choose the members of their own groups.
Group members will decide on the project and will act as their own customer. During phase 1, the group will go through the process of gathering requirements, defining business objectives, defining methodology, identifying acceptance tests, and selecting a general architecture. To make this project more realistic in terms of complexity, students will define a project which has a total scope which would require approx. 2 years development time. It will not be necessary to complete the project for this course.
In phase 2, the group will develop the project plan. Included within that plan will be project estimations and scheduling. It is important that the groups define the first 2 iterations of the project as those iterations will make up phases 3 and 4 of the project. Functionality prioritization and risk assessments will also be completed as part of this phase.
In phase 3, the group will iterate through the project's functionality. The result should be that the most important functionality is implemented by the completion of this phase. Supporting documentation should remain in sync with the implementation effort. Often in this phase, important framework or structural components are implemented. The group must also ensure that the implementation is properly tested and that any completed functionality satisfies acceptance tests. After the completion of phase 3, 2 major functional changes will be introduced into the project by the Intructor/TAs.
In phase 4, the group will iterate through the project's functionality again. The result that more of the defined scope is implemented. Also, the functional changes defined after the completion of phase 3 must be addressed within this phase. As always, supporting documentation must be in sync with the project.
Choosing a project
Choosing a good project requires some thought. Choosing a poor project may make it difficult for the team to achieve the goals as set out in the milestones. Here are some general guidelines:
- Choose a project whose scope would take 6 people between 1 - 2 years to fully design and implement. You are not expected to complete the project in this course.
- Because you are going to use an iterative development process, we will only have time to perform the first two iterations. Be sure that you can complete a reasonable development effort within our limited timeframe. (ie. make sure that basic functionality and architecture is sufficiently small that you can complete it in 3.5 months). Triage will be important here.
- If a team member has domain knowledge in a particular field, you might consider utilizing that knowledge for the project.
Individual assessment
Group projects always cause concern for students. The largest concern is that one will be assigned to a group where a groupmate is not contributing to the project. This causes a great deal of stress in that the other groupmates must "pick up the slack". Two things have been done to help avoid that problem. Firstly, students will choose their own teams; be sure you choose wisely. If, for some reason, students are having difficulty choosing teams, teams may be assigned in some circumstances. Secondly, evaluation of the project will be partially based on individual contributions made to the project. Students must submit time sheets which record their activities are part of each project milestone. (Note: I have worked as a scientific auditor for Canada Revenue Agency. Do not try to fake these documents. It is obvious when an attempt has been made to do so). It is also recommended that students put their name on the handed-in components to which they contributed. For example, if you wrote section 3, and 4 and part of section 7 for milestone 1, make sure it is clearly noted that you worked on those components.
If there are problems in the team dynamic, it is your responsibility to come to me and make me aware of these problems sooner rather than later. Most problems can be solved provided I have enough time to deal with them. Let's say that one of your groupmates was not contributing to the project. Don't wait until December 8, 2005 before telling. At that point, it's too late and I can do nothing other than assign that student the same marks which are being assigned to the other group members.
Students are expected to contribute to their groups. If a student is found to not be contributing to his/her group, the following process will take place:
- Students lodge complaint, in writing, to the instructor. This complaint will identify the student which the complaintants allege is not contributing and will also include all supporting evidence.
- Instructor will evaluate time-sheets and handed in components (if applicable)
- Instructor will interview the identified student.
- If the instructor deems the concerns to be warranted, the identified student will be given a letter which contains the following:
- A statement of the concerns
- The evidence which supports those concerns
- A description of what behavioural changes must be made so that the student does not fail the project component of the course.
- Note: A copy of this letter will be sent to the Undergraduate Affairs Head within the Department of Computer Science.
If after this time, the student does not comply with the specifications of the letter, the student will receive an F for the project component of the course.
General Structure
The project is structured in the following way:
- Students will form into groups of 6 people
- Students will choose their own groups
- Each group will decide on their project.
- Each group will act as its own customer
- Each group will define the project's scope. This scope will be larger than can be completed within the semester
- The project will have 4 milestones due on the following dates:
- Milestone 1: February 1, 2006
- Milestone 2: March 1, 2006
- Milestone 3: March 22, 2006
- Milestone 4: April 13, 2006
- Each group will decide on its development process. Groups must choose an agile method
- Using an interative approach, each group will implement functionality defined within the project's scope.
- Each group will be evaluated on what they complete as well as the quality of the work produced.
- Between Milestone 3 and Milestone 4, 2 functional changes will be introduced into the project. These changes will be decided upon by the instructor and TAs. Groups will be evaluated based on how reslient they are to those changes.
Milestones
Project Milestone 1 - Due February 1, 2006
Project Milestone 2 - Due March 1, 2006 @ 16:00
Project Milestone 3 - Due March 22, 2006 @ 16:00
Project Milestone 4 - Due April 13, 2006 @ 16:00
