This final project report, confirmed with your project demo at the end of the class, is worth 30% of the course grade. It requires you to put all your homeworks together (really not much more here if you have done all of them well), write a summary and a conclusion, and include slides of your project presentations. Printed copies are due in my office at 10am on Mon. Dec. 17; if you can not make it, then you should arrange with me to hand in before that. Each group should hand in one copy.

To get any credit, individuals must write what he or she and others did for the project, as described near the end of this handout. That part is due in Jingyu's office hour on Wed. Dec. 19; if you can not make it, then you should arrange with him to hand in before that.

The requirements are explained in more details below.

1. On the first page, you should clearly write your project title, group name, group members and their email addresses, and an URL for the group project containing all project related information.

2. Also on the first page, you should write a 200-word summary, summarizing the purpose, effort, result, and other highlights.

3. The main part of report should include description of the following items.

1. project description (hw2, 1wk)
2. project plan (hw3, 1wk)
3. requirement analysis (hw4, 1wk)
4. system analysis and design (hw5, 1wk)
5. detailed design (hw6 and hw7, 2wks)
6. coding (hw8, 2wks)
7. testing (hw9, 2wks)
8. delivery (hw10, 1wk)
9. maintenance and evaluation (2 wks)

1. initial project description/plan/design/etc.
2. a sequence of incremental updates to the description/plan/design/etc., each of which is of the form: while doing requirement analysis (or system design, or coding, etc), we found the so and so problem (e.g., something was unspecified; the total amount of work is too large; we found some existing code to use), and we proposed the so and so fix (e.g., we added something in project description; divided the functionality into F1, F2, and F3, and proceeded in order of F1, F3, and F2; we added diagrams for reused code).
3. final project description/plan/design/etc.

• For the coding part, you should also include complete code (if your code is too large, then you may omit the boring parts of it and justify so). The code (as well as other parts such as UML specs) should be printed 2up double-sided (if at all possible).
• For the maintenance and evaluation part, do the reading assignments for this week and next, and report anything you did to your project that you think is relevant. In particular, you may include how others have tried your system, how they evaluated it, and how it helped you to improve your system. You may also include how you evaluated projects by other groups in the course.

4. Finally, write a conclusion for your project: what you learned and achieved, what some possible future works are, and anything else that you feel worth mentioning.

5. Include slides from your project presentation. Use 4up double-sided (if at all possible).

Throughout the report, you should emphasize how your group tried to reuse, used incremental and iterative development, and achieved other goals (e.g., reducing system cost, making system easy to use, increasing system performance, assuring system correctness, etc, as a number of groups did really nicely). You may include any additional description of these items separately if you wish; for various issues that were not explicitly required or emphasized (e.g., comparing nontrivial features of your system with other know systems using matrices, reducing software cost, increasing DB system performance using connection pools, automating testing, providing multiple options for delivery, other ways of making your system easy to use, automatic discovery of syntax errors in my homepages, etc, as we've already seen in the first half of the presentations), you will get good bonus points proportional to the estimated effort.

Each member of the group must sign the final report to get credit, and by signing it, s/he asserts that all stated in the report are true to the best of his/her knowledge. Put your signature next to your name on the first page.

Notes on UML and UML tools

Besides the many interesting issues discussed in the presentations we've seen, as I mentioned above, two people indicated that there are problems with UML and Rose. Complaining about problems is important, but also easy (especially about computer software :(, and in particular about UML and UML tools in their current status); more important would be to find the specific reasons and to look for solutions.

In fact, I have many more complaints about UML and Rose than you ever learned, but I have tried to emphasize the good aspects. Why? Here is what one may really want to think (you may recognize that I am repeating). Suppose there is no UML or UML tools. How are we going to model or specify the system being built and to describe the design and analysis? There are two choice:

Considering that software engineering has a history of over 30 years, while UML has only existed for a few years, one has to admit that UML and UML tools are making much better progress, and we are lucky to be able to learn them in a software engineering course at the right time (this is the first time I myself learned them systematically also).

So, in your presentation and report, when you mention problems with UML and UML tools, try to be specific and come up with constructive ideas at the same time, i.e., not to say just that something is bad, but also say the specific reasons and how things can be improved.

To summarize, try to be critical AND constructive at the same time. If you do suggest interesting solutions or find better alternatives, you will get good grades also.

Notes on team work and individual work

Many groups mentioned that they learned a lot from team work in this course. I'd like to let you know that this includes experiences from extremely good ones and to extremely bad ones. In fact, some of you told me that, despite many courses having team work parts, this is the only course that involves real, serious ones. After some thinking, I decided to add another requirement for the final project report.

Each person individually should write a summary of what he or she did for the group project and what he or she knows what others did for the group project. The amount of detail is up to you, but make sure that it is typed (so that it is readable), is not longer than one page, and is informative. For example, you could write that "I did the entire project", or "I made class diagrams with A, and B revised them; I wrote code for the class Account with B, and C suggested some changes; D and E said they reviewed the code but suggested no changes; I did testing with D while E watched; C and D prepared presentation slides; A and B reviewed the slides and suggested changes; ...".

This must be completely honest and must make any collaboration explicit. In particular, if you write "I did the entire project", it means that "no one else did it with me". If you write "I did so and so with A", it means "you and A both did, and no one else did". If you only watched others in your group doing it, then say so also.

If your group had problems and resolved them yourself (or could not resolve them), and you feel that it was a good learning experience, you may summarize it also.

Something fun to read in the last chapter of the textbook

If you have not read the last chapter, especially the part about how people really make decisions, you may want to read it, even if it is not required. I found that part really interesting and very entertaining.