CSSE 221 – Introduction to Software Development Honors
Capstone Team Project

1. Overview
2. A Team Assignment, but also a Learning Experience
   1. Two Rules for Teaming / Learning
   2. Team Grading
   3. Subversion Repository
3. Process
   1. Extreme Programming
   2. In-class Time
4. Milestones and Due Dates
   1. Schedule — Specification and Design, then 3 Development Cycles
   2. Milestones for Cycle 0
   3. Milestones for Each Development Cycle
   4. Additional Milestones at the End of the Project

5. Descriptions of Deliverables

1. Elevator statement in your Release Plan
2. Features, grouped into 3 categories (Must-do, Plan-to-do, Will-do-if-time) in your Release Plan
3. User Stories, grouped into 3 cycles (releases), in your Release Plan
4. Screen Layout Sketch
5. CRC cards
6. UML Class Diagram
7. Team Task List for each development cycle
8. Status Report at the end of each development cycle
9. Working Code, committed with comment "Release k" (for k = 1, 2 or 3)
10. Each person's Individual Task List for each development cycle
11. Each person's Evaluation of Team Performance for each cycle

6. Grading Rubric

For this project you will design and implement a computer game of your own choosing, subject to the constraints that it must:

• Have a good graphical user interface (GUI)
• Be a networked game (i.e., two players at two computers play the game concurrently, with information relevant to the game being exchanged in real time over the network)
• Make reasonable use of a Thread that your program explicitly generates (for an animation, for example)
• Specify three categories of features:
  • Must-do — Features required for a successful project
  • Plan-to-do — Additional features that you expect will be appropriate for the project to earn a high grade
  • Will-do-if-time — Bonus features that you will include if the project turns out to have been too easy or if you just want a challenge!

Regarding networking: a two-player game is fine, and the game can require the players to cooperate or compete (your choice). You may strive for a more-than-two player game if you wish, but that is not required. Be cautious about games that require large amounts of information to be exchanged in real time.

Regarding the three categories of feaures: It is very difficult for you to “scope” the project appropriately for a 4-week team project. By listing your features in three categories, you allow yourself to recover from a badly scoped project (either one that turns out to be too easy or one that turns out to be too hard). See the Grading Rubric below for how this affects the grading.

Two Rules for Teaming / Learning

Team Grading

See Team Grade and Individual Grade for how the team is graded and how individual grades may be more or less than the team's grade. Note here that:

Those who don't obey the two rules for an appropriate learning experience (in Team Participation, to the left) will receive a reduced grade.

• This means BOTH the person who (for example) did not participate in a major activity
• AND the person(s) who did not actively help that person participate.

Also:

• Those who don't “carry their weight” or otherwise shirk their individual responsibilities will receive a reduced grade.
• A person who goes “above and beyond the call of duty” may receive an increased grade.
  • In particular, if you aspire to a higher level of achievement than your teammates do on this project, your team should talk with me EARLY IN THE PROJECT to see how we can structure the project for this.
• If you have a team member who is not participating appropriately, help the team member change his behavior and BRING ME INTO THE LOOP EARLY.
  • If necessary, the team can experience a “divorce” in which the non-participant leaves the team.

Subversion Repository

    http://svn.cs.rose-hulman.edu/repos/
    csse221-201010-TeamX

Check out the Capstone project from this repository.

All work should be placed in this project folder and committed back to your repository.

• Exception: If you do other short projects (a) to learn how something in Swing (or whatever) works, or (b) as a spike solution to better understand the complexity of a problem, feel free to include those projects in your TeamX repository (alongside the CapstoneProject folder, not beneath it).

After you check out your CapstoneProject, examine its Planning folder and note that templates for all of your non-code documents are already in your CapstoneProject, beneath Planning.

Recall the advice on using version control in teams.

Extreme Programming

You will use many of the Rules and Practices of Extreme Programming. In particular, you will use, in one form or another, all the indicated rules/practices on the image to the right (which is taken from the preceding link).

For pair programming, each team member should do at least one pair programming session per cycle.

Additionally, you should use documented stubs throughout (i.e., document each method while the method has a stub, THEN write the method's code).

In-class time

You will usually have about 1/3 of each of our sessions to work on your team project.

• We'll do other, unrelated-to-the-project, individual work in the rest of each session.

• Organize (have we accomplished our tasks due today? what will we do next? who will do what?),
• Discuss (what classes belong in our design? what should be the user stories for our next cycle?), and
• Integrate code and other deliverables.

Team meetings and communication

Schedule regular out-of-class meetings, at least once a week. Recall the advice on conducting Effective Meetings.

You will have a Stand-Up Meeting at each class session.

Reach agreement on how you will communicate with each other between meetings:

• Exchange email addresses and phone numbers.
• Agree how often you will check your email, during the week and over the weekend.
• Decide if you want to use other modes of communication, e.g. Instant Messenger (IM).

• Each person's Individual Reflection on the project (survey on Angel)
• A Poster Presentation of the project (in the Union Lobby, 4:30 p.m. to 6:30 p.m., day TBD)

Release Plan

The Release Plan specifies, for each scheduled release of the software, which User Stories will be implemented in that release.

Your Release Plan document should contain your:

• Elevator Statement
• Features, organized into 3 categories (Must-do, Plan-to-do, Will-do-if-time)
• User Stories, organized into 3 cycles (releases)

At the beginning of each cycle, you review your Release Plan and possibly revise which user stories are to be implemented in that cycle.

• That is part of how you retain agility.

Find the template for your first Release Plan document in Planning/Cycle1.

• After the first cycle, you will copy your Release Plan from the previous cycle into a new Release Plan document for the forthcoming cycle.
• That makes it easy for readers to see the history of revisions to your Release Plan and learn from that history.

Elevator Statement

Your Release Plan document should contain an Elevator Statement — a description of your project that could be delivered to an interested party in about 30 seconds (e.g. while you are riding in the elevator with them).

• Your elevator statement helps give context to your User Stories that also appear in your Release Plan document.
• Your elevator statement with your Screen Layout Sketch provides a high-level, visual specification of your project.

Place your Elevator Statement in the Planning/Cycle1/ReleasePlan-ForCycle1.docx file that we provided, at the indicated place in that file.

Grading Rubric: Your Elevator Statement must be of the appropriate length (else no credit) and use correct grammar and spelling (else score reduced by up to 50%). Additionally:

• 50% — Elevator statement makes sense with no context other than that it is a game developed for a 4-week project in Introduction to Software Development Honors.
• 50% — Elevator statement interests the reader in the project.

Features

Your Release Plan document should contain a list of the Features of your project.

• Features are, well, features. Think of them as abbreviated versions of your most important User Stories.

You should have about 30 plus or minus 10 features, organized into 3 groups — Must-do, Plan-to-do, Will-do-if-time.

• If you have more, group some together; if fewer, break some into subparts.
• Grouping the features into these categories helps control your project's scope; the "Will-do-if-time" features can be included or not as need be.
• In your first version of your Release Plan, you may include the "Will-do-if-time" features or not, as you see fit. You will revisit this decision after the first development cycle.
• I will review and approve your features, possibly requiring that some features move from one category to another to adjust the scope of your project.

Place your Features in the Planning/Cycle1/ReleasePlan-ForCycle1.docx file that we provided, at the indicated place in that file.

Grading Rubric: Your Features must be of the appropriate number (else no credit) and use correct grammar and spelling (else score reduced by up to 50%). Additionally:

• 50% — The features make sense with no context other than your Elevator Statement and Screen Layout Sketch.
• 50% — The features describe the project adequately.

User Stories

Your Release Plan document should contain your User Stories. From the Rules of Extreme Programming (XP) at www.extremeprogramming.org/rules/userstories.html:

User Stories are written by the customers as things that the system needs to do for them … They are in the format of about three sentences [for us, 1 to 3 sentences] of text written by the customer in the customer’s terminology without techno-syntax … Each story will get a 1, 2 or 3 week [for us, 1, 2 or 3 hours] estimate in “ideal development time” [includes testing, but no meetings, email or other interruptions].

• You should have 40 plus or minus 20 User Stories. (Real XP projects might begin with 80 plus or minus 20.)
• Each User Story should have a 1, 2 or 3 hour estimate in ideal development time. (Real projects would have 1, 2 or 2 week time estimates.)
  • If a User Story needs more time, break it down into sub-stories.
  • If it requires less than 30 minutes, lump it with another User Story.
• Use your Features as a starting point for generating your User Stories.

Note that User Stories are descriptions of what the user would be able to DO with the software. For example:

User launches program and sees a blank drawing area and some buttons representing actions that could be taken.

This story doesn’t say anything about the buttons actually working, so that is not part of this user story. A User Story for a button working might be something like:

User clicks the Rectangle button and can then draw a rectangle in the drawing area by clicking and dragging the mouse.

If the user can't tell by RUNNING the program whether the User Story was satisfied, then it is NOT a User Story.

Short development cycles are a key feature of Extreme Programming. This is especially useful for projects where the development team—that’s you—is unfamiliar with the problem to be solved.

User stories are powerful in two important ways.

• First, they make it very clear how to test whether the story has been completed. As such, they generate what is called Acceptance Tests.
• Second, they keep the development team focused on the importance of meeting the needs of the user.

For this assignment you’ll play both the customer role and that of the development team.

• As a customer, the number of features completed will help determine your grade (and how much fun you have with the project).
• As a development team, you’ll have to do the work to implement the user stories.

Place your User Stories in the Planning/Cycle1/ReleasePlan-ForCycle1.docx file that we provided, at the indicated place in that file.

Grading Rubric: Your User Stories must be of the appropriate number (else no credit) and use correct grammar and spelling (else score reduced by up to 50%). Additionally:

• 40% — The User Stories make sense with no context other than your Elevator Statement and Screen Layout Sketch.
• 40% — The User Stories describe the project adequately.
• 20% — The User Stories' time estimates are not unreasonable.

Screen Layout Sketch

One way to specify a project is to list its Features or User Stories, as described above. Another way is to provide a Screen Layout Sketch that depicts the user interface for your project.

Reach consensus in class on a draft of the Screen Layout Sketch that you will use. Then, one or more team members may finish the sketch outside of class.

• The sketch need not be detailed, but should be annotated sufficiently to convey how the user operates your program.
• Two or three pages that show the main screen and major subscreens are probably enough, if you have annotations to indicate submenu's, dialogs and other screens.

Place your Screen Layout Sketch in the Planning/Cycle0 folder, replacing the ScreenLayoutSketch.pdf file that is already there as a stub.

• If you did your sketches on paper (that's fine!), scan them. (There is a nice scanner in the CSSE lab, Moench F-217.)
• You probably have PDF Creator on your computer; if not, there are plenty of free PDF writers available.

Grading Rubric:

• 50% — The Screen Layout Sketch makes sense with no context other than your Elevator Statement.
• 50% — The Screen Layout Sketch describes the user interface of your project adequately.

CRC Cards

Your project must incorporate a good object-oriented (OO) design, as described in your textbook (Chapter 8, sections 1 and 2, and Chapter 12). To come up with this design you will:

• Use CRC Cards to migrate from your User Stories to the classes that will implement those User Stories.
• From your CRC Cards, develop a UML Class Diagram that shows the classes and their relationships.
• At the start of each development cycle, flesh out the details on your UML Class Diagram of the classes that are relevant to that cycle.
• Refactor whenever appropriate, updating your UML Class Diagram as you do so.
• Apply the principles of High Cohesion and Low Coupling as practical.

CRC Cards are part of Extreme Programming and described at www.extremeprogramming.org/rules/crccards.html. Briefly:

• CRC stands for Class, Responsibilities and Collaboration.
• Use index cards for the CRC Cards. Each index card has:
  • a class name (which should be a noun) on the top,
  • a list of responsibilities (which should be verbs), written on the left-hand-side, and
  • a list of the collaborators needed to carry out the responsibilities, written on the right-hand-side.
• Develop the CRC Cards by repeatedly:
  1. Pick a responsibility of the program. (Use your User Stories to generate these responsibilities.)
  2. Pick a class to carry out that responsibility.
  3. Add that responsibility to the class’s card.
  4. Can that class carry out the responsibility by itself?
     • Yes — Return to step 1.
     • No —
       • Decide which classes should help.
       • List them as collaborators on the card you are working on.
       • Add additional responsibilities to the collaborators’ cards.

  You are done only once you have dealt with all responsibilities on all cards and your User Stories won't generate any more responsibilities. Projects of your size would typically have about 25 plus or minus 10 classes, each with 1 to 5 responsibilities.

Place your CRC Cards in the Planning/Cycle0 folder, replacing the CRCCards.pdf file that is already there as a stub.

• You can scan your cards (there is a nice scanner in the CSSE lab, Moench F-217) or type them into a document, your choice.
• You probably have PDF Creator on your computer; if not, there are plenty of free PDF writers available.

Grading Rubric: Your CRC Cards must be of the appropriate number (else no credit) and make sense given the context of your Screen Layout Sketch, Features and User Stories (else score reduced by up to 50%). Additionally:

• 20% — You have enough classes, that is, most of the User Stories can be implemented by your CRC Cards.
• 20% — You have enough detail in your classes, that is, most of the responsibilities listed can be implemented with help that the listed Collaborators are capable of giving.
• 10% — Your class names are nouns and your responsibilities use verbs.
• 20% — Your design has classes that have high cohesion.
• 10% — Your design has classes that have low coupling.
• 20% — Overall, your design is good object-oriented design.

UML Class Diagram

After you have completed your CRC Cards, use them to generate a UML Class Diagram, as described at www.agilemodeling.com/artifacts/classDiagram.htm (and at many other places as well).

Here is a sanity check for your UML class diagram. Does it:

1. Have a class (possibly called Main) with the required main method?
2. Have classes for all visual elements, e.g. the frame, all panels, all buttons?
   • You might implement some of the buttons as anonymous classes, but it would be wise to include them as full-fledged classes on your UML class diagram, perhaps with a Note indicating that the button is implemented as an anonymous class.
3. Have IS-A arrows to JBlah for classes that extend Swing components?
4. Have IS-A arrows to ActionListener and other Listener interfaces where necessary?
5. Indicate what creates   what?
6. Have every object created by something?
7. For each development cycle, have the necessary details (attributes and properties) for that development cycle?
8. For each development cycle, for each property relevant to that development cycle, have ALL the associations necessary to implement that property?

You must draw your UML Class Diagram using UMLet.

• Install the most current version. I recommend the stand-alone rather than the Eclipse plug-in, since the latter imposes limitations in both functionality and screen real estate.

Find and use an empty template for your first UML Class Diagram in Planning/Cycle1.

• After the first cycle, you will copy your UML Class Diagram from the previous cycle into a new UML Class Diagram for the forthcoming cycle.
• That makes it easy for readers to see the history of revisions to your UML CLass Diagram and learn from that history.

Grading Rubric: Your UML Class diagram must be readable (but need not be optimal in terms of minimizing line-crossings and so forth); it must use correct correct notation; and it must be up-to-date with your code (else no credit). Additionally, for all of the User Stories in the upcoming cycle:

• 10% — You have enough classes, that is, all those User Stories can be implemented by the classes in your UML Class Diagram.
• 10% — You have enough detail in the attributes of your classes to implement those User Stories.
• 20% — You have enough detail in the operations of your classes to implement those User Stories.
• 20% — All of the operations relevant to those User Stories can be implemented with help that the associated objects are capable of giving.
• 5% — Your class names are nouns and your operations use verbs.
• 5% — Your design has classes that have high cohesion.
• 5% — Your design has classes that have low coupling.
• 5% — Where practical, you provide interfaces to allow others to interface their code with yours.
• 10% — Overall, your design is good object-oriented design.
• 10% — Overall, your UML Class Diagram is complete enough to turn to coding.

Team Task List

At the beginning of each development cycle, AFTER you have finalized the User Stories to be implemented in that cycle, make a Team Task List for implementing those user stories.

This list should contain all the tasks that you think you have to do to implement the user stories for the cycle. Each task should include:

• A one-sentence description of the task, with any other notes you think will be helpful to the team.
• How long you think it will take you to complete that task, to the nearest half-hour.
  • If more than 3 hours, break it down into subtasks. If less than 15 minutes or so, combine it with another task.
• Who will do the task. (This can be more than one person, e.g. if pair programming.)
  • If more than one person, it would be wise to indicate when and where they will meet to do the task.
• When the task should be completed by.
• The status of the task, e.g. not-started, in-progress, completed, cancelled, modified to ...
• After the task is completed (or cancelled), indicate how long it actually took to complete the task, to the nearest half-hour.
  • So for every task, keep track of how long you work on that task.

Be sure to include:

• Specification tasks, like updating your Release Plan at the beginning of each cycle.
• Design tasks, like updating your UML Class Diagram prior to coding.
• Implementation tasks, like implementing one of your User Stories.
• Integration tasks — how will you integrate code written by separate teams or subteams? When, by whom?
• Testing tasks — how will you perform integration/system/acceptance tests of the code? When, by whom?
• Exploration tasks like implementing a Spike Solution to a problem whose complexity you are having difficulty judging.

You will have a separate Team Task Plan document for each cycle; find and use the template for your Cycle 1 Team Task Plan in Planning/Cycle1, and similarly for Cycles 2 and 3.

It is normal for the task list to change during the cycle — just commit the updated file to your repository whenever it changes.

Grading Rubric: Your Team Task List must have enough tasks to implement all of the User Stories in the current cycle (else at most half credit) and it must appear that your team used your Team Task List throughout the cycle (else at most half credit). Additionally:

• 25% — There is enough detail in the descriptions of the Tasks for them to be carried out, given the context of your User Stories and UML Class Diagram.
• 25% — Your team appears to have taken seriously the requirements of estimating how long each Task would take.
• 25% — Your team appears to have taken seriously the requirements of measuring how long each Task actually took.
• 25% — Your team appears to have taken seriously the requirements of documenting who will do the task, when it will be completed, and its status.

Individual Task List

One of the hardest skills to develop in software engineering is how to estimate how long it will take to implement a given feature. According to the Personal Software Process (PSP), one of the best ways to being developing this skill is to:

1. For each feature you implement or task that you do, estimate how long you think it will take you to do that task.
2. Measure how long it in fact took you to do that task.
3. Note the difference between (a) and (b).

To this end, throughout the three development cycles, maintain an Individual Task List, as follows:

• As you take on tasks during a development cycle, list them in your own Individual Task List document for that cycle, including estimated and actual times to complete the task.

  • You can copy-and-paste from the Team Task List (which lists the tasks for the entire team) to your Individual Task List.
  • Your Individual Task List is your individual responsibility to maintain.
  • List ALL the time you spend on the project during the cycle, both in-class and outside class.
  • It is OK to have items that aren’t on your Team Task List. Log ALL your work on the project.

• As with the Team Task List, time estimates should be to the nearest half-hour.
  • If more than 3 hours, break it down into subtasks. If less than 15 minutes or so, combine it with another task.
• Students who aspire to an A should spend about 3 hours a week in class and 4 to 8 hours a week out of class on this project. So if your hours for a week total to much less than 9 hours:
  • Make sure that you are reporting ALL your work on the project.
  • Consider spending more time on the project out of class.

You will have a separate Individual Task List document for each cycle, and each student has their own Individual Task List; find the template for your Cycle 1 Individual Task List with your username in Planning/Cycle1, and similarly for Cycles 2 and 3.

Grading Rubric: Your Individual Task List must appear to list all of your work during the cycle (else at most half credit) and it must appear that you updated your Individual Task List throughout the cycle (else at most half credit). Additionally:

• 50% — You appear to have taken seriously the requirements of estimating how long each Task would take.
• 50% — You appear to have taken seriously the requirements of measuring how long each Task actually took.

Working Code

At the end of Cycle 1, commit your Working Code with a comment Release 1; and similarly for Cycles 2 and 3. Your released code should:

• compile and run,
• be documented appropriately, with the html Javadoc generated,
• contain NO compiler warnings,
• include only genuine TODO's (i.e., none that are accidentally left behind),
• be written using documented stubs (i.e., document each method while the method has a stub, THEN write the method's code), and
• use good style, as described by java.sun.com/docs/codeconv and enforced in part by control-shift-F in Eclipse.

  • Good style includes (but is not limited to) self-documenting class, method, field and variable names; introducing local variables as needed but not more than needed; introducing fields as needed but not more than needed; avoiding global variables except possibly for static constants; and reasonably-sized methods (generally not more than about 15 lines).

You should strive to pass all your acceptance tests for this cycle (as generated from your User Stories), but it is OK if your code does not do so.

If there are aspects of your classes that can be tested apart from the GUI, then it would be great if you provide JUnit tests for those features.

Grading Rubric:

• Subtract 20% of your possible score on this deliverable for every violation of the qualities listed above.

Status Report

At the END of each development cycle, complete the Status Report for that cycle. It should indicate:

• The User Stories that you expected to accomplish in this cycle (copy-and-pasted from your Release Plan).
• An indication of which User Stories you did NOT complete as planned.
  • It would be wise to include any relevant explanations, e.g. “Moved this User Story to the next cycle because we need to learn more about slider bars.”
• An indication of any noteworthy additional accomplishments (beyond the planned User Stories) in this cycle.

You will have a separate Status Report document for each cycle; find and use the template for your Cycle 1 Status Report in Planning/Cycle1, and similarly for Cycles 2 and 3.

Grading Rubric:

• 100% — You successfully list all the User Stories that were planned but not implemented in the cycle.

Evaluation of Team Performance

For each cycle (including Cycle 0), I will post a survey on ANGEL called Evaluation of Team Performance. The surveys for the first three cycles will be brief; the survey for the final cycle will be longer. The surveys will help:

• Diagnose any team dysfunction while there is still time to do something about it.
• Adjust individual scores appropriately from the team score (see the Grading Rubric below).
• Identify where you are doing well as a teammate and where you can improve.

Each person does the Evaluation of Team Performance at the end of each cycle; it is NOT a team activity.

Individual Reflection

Poster Presentation

Recall the advice on doing a Poster Presentation.

Grading Rubric:

• 20% — Your poster communicates the quantity of your work.
• 20% — Your poster communicates the quality of your work.
• 30% — You successfully answer technical questions about your project.
• 30% — You successfully answer questions about your teaming experience.

You will list the Features of your project in your Release Plan. Furthermore, you will organize them into three categories:

• Must-do
• Plan-to-do
• Will-do-if-time

I will review and approve them (possibly requiring that some features move from one category to another). Furthermore, if the project turns out to be more difficult than we had anticipated, you should alert me to that fact in your Status Report documents and I may then move features from Must-do to Plan-to-do and/or from Plan-to-do to Will-do-if-time.

• I won't move features in the other direction after my initial approval.

Your Team Score is:

Your Individual Score (that is, your final grade on the project) is your Team Score, but REDUCED if you are NOT:

• participating fully in all major aspects of the project
• understanding (at an appropriate level) everything your team turns in
• carrying your weight on the team
• following the required process, including (but not limited to) pair programming at least once per cycle and using documented stubs in all your coding.
• helping your teammates do the above (in part by answering the Evaluation of Team Performance survey candidly)
• maintaining your Individual Task List appropriately

If you aspire to a higher level of achievement than your teammates do on this project, your team should talk with me early in the project to see how we can structure the project for this.