last edited 6 July 2003

Comments on the Project Proposals

General

The front of your mark sheet was marked by your supervisor.  It concentrates mostly on the content of your research. The back of your mark sheet was marked by someone else (in all cases but one, by me!)  It reflects how complete and well-structured your proposal was, and whether you met all the criteria asked for at the bottom of your assesment document, under "the moderator will be asking:".  

In fact, all 6 of the questions were supposed to have been answered in the Introduction, or at least easily traced from there (e.g. The sentence "my complete schedule is in Section 4.2" makes it easy to find the schedule.)  Very few students did this correctly, so I went to the effort of trying to dig answers out of the rest of your sections as well.  Next year's students won't be that lucky!  But they also will get a revised Assesment Document based on the confusions your year has had.

If you got a bad mark: I don't know if this will cheer you up, but it's much better to find out now that you need more work on your structure or that you didn't understand what your supervisor wanted you to do than to find out after you submit your project.  This is only one course mark, your dissertation will have way more impact on your overall result.

Whatever mark you got: The point of this exercise was to prove that you have learned to do and to write up academic research. This is not quite the same as the point of the project, which will also be marked by how good your project is, which is partly dependent on how challenging it is. So don't necessarily take this mark as either a promise or a threat of things to come. Issues like project difficulty will have more impact on your dissertation mark. Hopefully both the classes & the comments on your proposal will help elevate the mark on your final dissertation.

Congratulations on finishing the term and good luck on your projects!

Common problems

Structure

Despite my lectures, notes on Dissertation Writing, and last minute proposal advice, this was one of the most frequently neglected topics.  To reiterate again:

 Make sure you have written one, coherent document. ( The introductory `essay' is a chapter/section that serves as an introduction!) Make sure each subsection has its own introduction and conclusion.  A dissertation has introduction & conclusion chapters; a chapter has introductory and concluding paragraphs; a paragraph has introductory and concluding sentences.

Fill In (Mark 2)

One of the main reasons you need to know what your thesis is is to determine what you should spend time writing about.  A good scientific document is concise as well as informative. You should only be writing about things that are directly relevant to your thesis and advance your argument.

You shouldn't spend a great deal of time writing on "general truths" of software engineering. It's OK to reference & briefly outline a technique you've chosen, particularly if this helps provide / explain the structure of your document or approach, but don't just reiterate information tangential to your document. It's much better to have a short dissertation / document than one with irrelevant or overly pedantic information.

The point of the proposal is to get started doing research. Ideally this will be a lot of literature research: papers and reports on similar projects, on tools you might use, on the industry or problem you are trying to address or assist. There can also be tool research, where you begin doing comparisons and prototypes. You should also get as far as you can on proposing a structure for your software: the basic architecture and representations (again, prototyping might help here.)  Writing all of these things will help you order and advance your project, and who knows, might get you some useful  feedback from your supervisor & / or course instructor.

There is really no reason to try to fill in pages with information you learned in your software engineering course or with protracted quotes.



Reference style

You must use one of the two allowable reference styles (see the library handout). I think it would be best if everyone used Harvard/Chicago style e.g. (Bryson 2003), not [4]. This is both easiest to read (since you don't have to flip to the back to see what's being referenced - often the author & year is enough to recognize a paper) and easiest to write, since the tags don't change when you add more references (not that this is a problem if you are using latex!)

The only reason numeric references exist is to save space in journals. In really tight journals like nature (where you only get 2 pages) you have superscript or subscript numerals. Dissertations are not like this.

Regardless of how you reference your articles, a dissertation bibliography should be in alphabetic order, not order of appearance.

The Infamous Mark 6:  Introductory maps to the rest of document

This isn't the entire introduction, it's just the bit of the introduction that tells you what's in the rest of the document. This was in the requirements, but many people didn't do it. Marking: if absent, F. If vaguely described what's in the rest of the document, LP. If you briefly said what was in what chapter in one paragraph G. Distinctions went to concise sections well integrated into the argument structure that fully and clearly explained the dissertation's structure and where things could be found.

Bibliography

Every entry must have:
URLs are a *Last Resort*.  If a document came out in any other format, you should report that instead! A dissertation is an archival document; people may refer to it years or even decades from now. A URL may be changed tomorrow. So make sure to give enough information so a reader in the future can read the same document you have.

When to reference

You should reference *everything* you assert, that is, anything you don't prove by reason or that isn't a report on your own experience / work. Look at any scientific paper, you'll see every assertion has references after it. In scientific papers, a paper is referenced *every time* information is used from it, not just once. Examples:

The Literature Review

A lit review doesn't have to be just a liturgy of other people's projects. In the best case it is a good explanation of a field or concept where each assertion or explanation is properly referenced. Normally, everyone important in a field would get referenced in such a lit review, since the way you become important is by making points in your paper that reviews subsequently need & want to mention. Of course if there are particular articles or books that will have a great deal of influence on your dissertation it may well be worth reviewing them individually in their own section.

Testing

Anyone doing iterative development should have testing start with or even BEFORE implementation (read eXtreme programming...) It's also a very good idea to save early versions of your program so that you can test your late version against the early ones. It's much easier to show that feature X makes program B better than program A than to show that feature X is "good", because "good" tends to be a) ill-defined and b) difficult to achieve in 3 months.

page author: Joanna Bryson