[Prev][Next][Index]

cse308 - addition to project report

I added the following to Handout R for final project report.  Note
that it contains important information for you to get credits for this
part.  I will explain more and may add more tomorrow in class also.
If you have any questions, ask then also.

Annie
--
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:

  in English (or another natural language) or 
  in some notation someone invented.

  The former is often ambiguous, verbose, boring to read, and thus not
  good for understanding and communicating the precise meanings
  required by computer software. It is also hard to manipulate
  mechanically and thus not good for automating software construction.

  The latter could overcome all the problems of the former, except
  that it was not standardized, so few people understand or use it.
  This is why UML is the best effort so far; it is a unified notation.

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.

  For example, Richard mentioned that it took him 30 (did I remember
  the number right?) hours to print specifications from Rose. It was
  because of the paper quota, right? Not a fault of Rose. In fact,
  printing in Rose is easy: a few clicks to choose what to print and
  there it goes.

  How should things be improved? Rose should tell you that the
  printing request has been sent to the operating system (cm, while
  writing this, I suspect that Rose said it in the log... I will leave
  for Richard to check). Then, the operating system and system
  administrator should tell you the reason if printing fails.

  For another example, Michael simply said that he does not like
  UML.  Try to be specific. Why? How to improve it? Or do you see a
  better alternative so that we should throw away UML?

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.