Project 5 - Process Description

The process you design must be derived from Extreme Programming (XP), but it does not need to include all aspects of XP. A set of possible process elements can be found here. You should be reasonably ambitious in your choice. That is, if you don't choose enough activities, then not only won't you learn as much as you might, but points will be taken off. On the other hand, if you choose too many activities, you may not be able to accomplish all of them or they may not have sufficient quality.

In addition to its usual content, your Process Plan document should include the following items.

Description of which of the XP rules you will be following, and in what way, if any, you are adapting the rule for the purposes of the project. For each rule give the following:

Rule name
How you are adapting it (paragraph)
How will you know it is accomplished
Responsible person

Planning: a description of the iterations is that you will produce, including a schedule. Each iteration must be end-to-end (accept input from the user and produce output for the user).

You must include activities responsible for producing at least the following deliverables:

A numbered set of user stories constructed by your team based on the Customer Needs document, questions posted to the newsgroup, asked in class, or via email
An iteration history giving for each iteration, an iteration number, the iteration's actual completion date, and its features annotated with the numbers of the corresponding user stories
A refactoring report containing the list of refactorings you performed indicating for each refactoring, the date, the iteration, the class(es) involved, the corresponding unit tests (from the test plan document), the reason, the refactoring type from the list of refactorings given at the refactoring web site, and the lines of code involved
A UML Class model diagram and accompanying description of your design. The class model diagram and the refactoring report should be coordinated; that is, classes mentioned in the refactoring report should appear in the class model. Of course, other classes necessary to describe the system should also appear
A pair-programming log including times, participants, and accomplishments (code units worked on). Note that you should do enough pair programming so that the following two conditions hold: 1) each team member is engaged in at least two, hour-long coding efforts with different partners and 2) the productivity and quality of pair programming and individual programming efforts can be compared in your Process Assessment
An "acceptance" test report including the iteration # during which the test was employed, the relevant user story # (if applicable), the relevant refactoring (if applicable), the test input, expected output and actual output. The test report should also include the following two items: 1) an affirmation that each of the user stories is evidenced by at least one test; and 2) some measurement of code coverage. For the latter, you are free to find any tool and apply it to your code. You should say where you got the tool from, exactly what it measures, and, using it, how well your tests covered your code.
Documentation as described in the Customer Needs statement
Code (including unit tests using JUnit) for all iterations

Your code should be turned in incrementally. Each time you do an iteration create a link on your project Swiki page whose name includes the iteration number. Place your code (including the corresponding unit tests) for that iteration in a Zip file uploaded to the link. All released code should be executable and should be invocable according to the rules described in the Customer Needs statement.

After you have completed your product development, you will be asked to do a Process Assessment, similar to Projects 1-4. So remember to keep track of your time spent, defects, number of acceptance test cases, and lines of code. Also, in the Process Assessment document you should describe how well you conformed to each of the rules you selected.