From oard@glue.umd.edu Tue Nov 18 21:27:25 2003 Date: Wed, 5 Nov 2003 11:31:06 -0500 (EST) From: Doug Oard To: j3browning@comcast.net Cc: LBSC 690 , Daqing He Subject: Re: Project Paper Hi Janet - good question - I mentioned some of this in class once in response to a question, but it is good to have it in writing too. As the course description says, 15% of the course grade will be based on the project report, so this is indeed an important question! The sole role of the project report is to convey information that cannot be conveyed as effectively during the project demonstration. The key here is the content, not the style of the report. So there are essentially no style guidelines except that I would like to be able to understand it (so it is helpful if it is well written), and I would like it to be reasonably concise (in my mind, about 5 pages, single spaced). So what content should be there. So things spring immediately to mind: 1) Why you did this 2) How you went about it. This has two aspects: (1) how did you learn what was really needed (did you just make it up, or do you have a real customer? If you have a real customer, how did you use their understanding of the true problem to guide your work?), and (2) how did you organize your efforts - Mythical man-month kinds of issues. 3) What you learned about the nature of your problem 4) What you learned about the capabilities and limitations of the technologies that you chose to work with 5) What you know about how well your system meets the needs for which it was created? Did you test it? How? What insights did you gain? 6) What plans are there for a continued life for what you have created? Will some customer adopt it? Of course, different groups will devote more or less space to each of these, and some groups will add other things. For example, some groups might talk about changes that they made to their vision of who their customer really was along the way as they learned more. Others might talk about suggestions for supportng project groups in future semesters that would extend their capabilities. Others might want to write about group dynamics (perhaps as a form of "group therapy":). So there is no cookbook recipe for a good project report. The key is to learn a lot, and to describe what you have learned. We used to require three formatted reports along the way (specification, test plan, and user manual). This is an experiment this year to give you more scope for exploration and working with the technologies you choose -- you all have responsed by choosing to pursue complex projects with strong ties to real needs. This is great, and exactly what we hoped for. So don't sweat the report too much at this stage - go do great things, and in the end you will have a lot to write about! Doug On Wed, 5 Nov 2003 j3browning@comcast.net wrote: > Dr. Oard, > > I see that each team will be required to submit a paper on our project. > Are there any specific guidelines you want us to follow, any specific > requirements that need to be included? > > It would be helpful to be aware of any requirements as we work through > our projects. > > Thanks, > > Janet Browning