CS102

Project Organisation & Grading

Purpose

The project component of CS102 gives students the opportunity to acquire and practice key engineering skills, including, teamwork, oral and written communication & independent learning. Students are also expected to demonstrate creativity and be self-motivated.

Organisation

The project will be undertaken in groups of four or, maximum, five. It is divided into four stages, three report stages (Requirements, User-Interface & Detailed Design), plus an implementation stage. For each of the report stages groups are asked to prepare a written report which they will subsequently present orally. Other groups will offer feedback on both the written report and the presentation, as will assistants and instructors. Armed with this feedback, groups will revise their report as they see fit. The overall grade for each stage comprises all these elements, but is predominantly based on the final revised report. The implementation stage will be graded on the basis of a demonstration of the software, an examination of the source code, and discussion with group members. Groups are expected to maintain a project wiki, including minutes of group meetings & copies of all reports, presentations & codes. Each group member should keep a record of what they personally have contributed to the project on a separate wiki page.

Grading Criteria

The following detailed criteria are applicable,

• Requirements Stage: creativity, consideration of how to exploit technology. Thinking about what users want (not limitations, technological or personal.) An ability to communicate ideas in a clear and concise manner. No exaggeration or advertising speak! Keep the following in mind; (a) is the project explained clearly enough for someone else to understand, and (b) is there enough information for someone else to design a suitable user-interface. What sort of program is it (a console application, normal Windows style desktop program, a browser-based Applet, a web site, a mobile phone application, single or multi-user, etc?)
• User-Interface Stage: is the program/interface organised such that they it is easy to learn and use. Is it complete & consistent. Was any core functionality specified in the requirements report missed? Is it aesthetic (i.e. does it look nice)? Again, thinking of what the user would like, not how easy it is to program! See these additional points to bear in mind.
• Detailed-Design Stage: reasonably complete specification of system architecture, major objects and interactions, plus class definitions, including their properties and methods. Distribution of work to group members.
• Implementation Stage: demonstration of the program. Code documented and laid out in accordance with accepted styles. The program should be well structured and, if not actually completed, at least be potentially so given a little more time! Flexibility of design/implementation. Amount of work done and participation!

In addition,

• independent learning will be judged in part by use of technologies not explicitly covered in the course, for example, databases, network connections, web technologies--servlets, JSP, etc., serial/parallel IO, RMI, 3D graphics, animation, multi-threading, mobile phone & smart card implementations, etc.
• groups that are seen to be working consistently throughout the course and, in particular, begin acquiring the additional skills they need early, will be judged to have good organisational skills! Resolving any people problems within the group is also important, as is maintaining a complete & up-to-date project website.
• all reports are expected to adhere to general notions of style, structure, spelling, grammar, layout, etc. Reports and presentations should be aesthetic, concise and coherent, demonstrating good communication skills.

Grading Scale

Each of the stages (& parts thereof) will be marked according to the following scale and translated into the corresponding numeric value for grade calculations & entry to Moodle.

• Excellent        10 {practically impossible!}
• Good (+/-)     8  {well thought out, significant effort, creative, demonstrated process improvement.}
• OK (+/-)        6  {means "ok!" Meets minimum standard expected, but without much real effort or extra thought.}
• Weak             4  {clear indication that more work needed!}

Note: As far as possible, the scale should be interpreted in absolute, not relative terms, i.e. they are intended to represent the actual amount and quality of work done, rather than a relative comparison between students or projects. In other words, we should determine the quality of the individual fruit, rather than trying to decide whether apples, oranges or bananas are best!

Additional Points to keep in mind...

(work in progress... needs adding to & organising!  See the individual project stage documents for more information.)

Requirements Evaluation

Each of the following criteria, will the evaluated using the (weak, ok, good, excellent) scale.

Presentation: Is the content in the correct/required form/format?
Understandability: How easy is it to understand/evaluate the content?
Creativity: How novel/appropriate is the proposal?
Completeness: How complete, correct, comprehensive, appropriate is the content?

An overall evaluation (using the same scale) will also be made and will include the degree to which any feedback was incorporated.

[PRESENTATION]
Formal aspects of the communication. Fonts, margins, length, etc.
Reports and presentations should be aesthetic, concise and coherent,
Use of CS102 Reports template (single line spacing please, save the trees!)
Consistency. Style, structure, spelling, grammar, layout, etc.
Proper references/citation (as in template.)

[CREATIVITY]
Creativity, consideration of how to exploit technology.
Think about what users want/need (not personal or technological limitations.)
"Necessity is the mother of invention".
Motivate need--find people with needs (customers)!
Finding alternative customers, and so additional useful features.
Brainstorming. Novel ways of looking at problem, different tradeoffs, etc.
-- note: creativity in detailed design may not make sense, but for implementation we
can use it to indicate use of "extra" technologies, databases, network, jsp, etc.

[UNDERSTANDABILITY]
An ability to communicate ideas in a clear and concise manner.
Begin with a very concise statement of what you are thinking of building, then expand
on it in later sections.
No exaggeration or advertising speak!
Keep the following in mind;
(a) is the project explained fully & clearly enough for someone else to understand, and
(b) is there enough information for someone else to design a suitable user-interface.

[COMPLETENESS]
Background research for similar existing products (include proper references.)
What will distinguish yours? Why should someone chose it?
What sort of program is it (a console application, normal Windows-style desktop
program, a browser-based Applet, a web site, a mobile phone application, a smart-card
app, will it be single or multi-user, how do you envisage distributing it to users,
etc?)
Have all necessary features been included, e.g. save, but no load, or create, but no
delete! Operational procedures, e.g. backups.
Prioritise features... essential, desirable, future extensions.

How to get poor evaluations:
- choose a very simple boring project, eg. a multiple-choice quiz without anything
really different/distinct to it, or one that is so restrictive there is little you can
meaningfully add to it, e.g. chess.
- chosing a project that will not challenge you (help others or save the planet!)
One that has little scope for you to show independent learning skills.
- Ask yourself whether enough people would use your project, such that you could live
on the income?
- not spending enough time and effort to produce a neat, logical and concise
report/presentation. Failure to practice oral presentation beforehand--preparation.
- inconsistencies.
- not showing improvements
- not keeping records!
- use someone else's work without reference, i.e. cheat!

User-Interface Evaluation

Each of the following criteria, will the evaluated using the (weak, ok, good, excellent) scale.

Presentation: Is the content in the correct/required form/format?
Understandability: How easy is it to understand the content?
Creativity: How novel/appropriate is the content?
Completeness: How complete, correct, comprehensive, appropriate is the content?

An overall evaluation (using the same scale) will also be made and will include the degree to which any feedback was incorporated.

[PRESENTATION]
Formal aspects of the communication. Fonts, margins, length, etc.
Reports and presentations should be aesthetic, concise and coherent,
Use of CS102 Reports template (single line spacing please, save the trees!)
Consistency. Style, structure, spelling, grammar, layout, etc.
Proper references/citation (as in template, see also David's Guide to avoiding plagiarism.)
Show actual data/images, not empty screens or random letters!
Font size & colour contrast... can people at the back see/read the presentation?
Don't insult readers/listeners intelligence by explaining the (absolutely) obvious in detail, e.g. the login screen/process!

[CREATIVITY]
Is the program/interface organised such that it is easy to learn and use?
If it does not follow conventional UI forms, what is different and is it a genuine improvement or will it make the user's life more difficult?
Is all the necessary functionality specified in the requirements report easily identifiable?
Is it aesthetic (i.e. does it look nice)? This is very important!
Again, put yourself in the position of the user and think of what they would like, rather than how easy it may or may not be for you to program!

[UNDERSTANDABILITY]
An ability to communicate ideas in a clear and concise manner.
Give a brief introduction to your project; many readers will not have read your previous reports or remember what the project is, so remind them!
Provide an overview of your proposed design in the form of a storyboard or site-map, to provide context for subsequent details.
Show & explain the core functionality first. For example, describe the actual game first, then talk about less important things (login screens, menus, options, etc.), later.

[COMPLETENESS]
Is it complete & consistent. Was any core functionality specified in the requirements report missed?
Consistent style (fonts, colour, sizes, button locations, etc.) throughout the interface.
Consistent layout ( button & menu locations, etc.)
Are borders used to group related components.
Are gaps appropriate?
Do things line up nicely?
Are layout managers used where appropriate?
Are the right UI components used (eg. radio buttons for mutually-exclusive choices.)
Does every screen have a title? Is all relevant information easily visible?
Keep the following in mind:
(a) Can the user easily understand where they are in the program (context)
(b) Can the user quickly navigate to any other desired location/feature.
(c) Where appropriate, do you provide feedback for each action and a means to undo it?
(d) Are the users interactions explained fully & clearly enough for someone else to be able to program them?

How to get poor evaluations
- obviously don't use the report template, don't use correct spelling or grammar, don't organise things logically.
- don't spend time & effort producing consistent images & layouts that might help get your ideas across.
- don't remind listeners what you are trying to do, or give them the big picture up front!
- don't practice your presentation, so don't know who will say what or when. You run out of time!
- spend 95% of the report/presentation talking about minor/irrelevant issues, (logon, option setting, etc.), rather than the game or whatever the real core of the project is.
- not really thinking about what the user needs to be able to do
- just doing the first thing that comes to your mind, without considering any alternatives!
- failing to provide references to images etc., that you use, but didn't create yourselves (plagiarism is not just textual!)

Detailed Design Evaluation

Each of the following criteria, will the evaluated using the (weak, ok, good, excellent) scale.

Presentation: Is the content in the correct/required form/format and presented in an easy to understand form?
Content: Is the design appropriate? Is it complete?

Note: Detailed design is difficult and requires experience. Since this is probably your first large program, please discuss it in detail with the TA. Hopefully, they will guide you towards a reasonable solution and so help you avoid wasting too much time during implementation. The revised report, however, should reflect what you actually did.

[PRESENTATION & UNDERSTANDABILITY]
Uses the CS102 report template properly.
Grammar, spelling, figures numbered with caption & reference in text, etc.
Introduction provides a brief reminder of what the project is and what this report is for (i.e. detailed design)!
High-level view/map without details to give an impression of the design. Use UML as  far as possible.
Details of each class and how they interact. Note: GUI classes should not be included, only the model classes.
Division of labour. Which group members will be primarily responsible for which classes.

[CONTENT]
Does the design follow the MVC design pattern (separating model from UI)?
Are the classes appropriate? Do they have the necessary properties and/or methods?
Is it obvious/clear how they relate to the project/domain?
Are classes & methods named appropriately (Classes=nouns, methods=verbs)?
Are non-trivial algorithms explained?
If data persistence is required, is the mechanism specified (text file, object serialization, database)?
If using a database, are the tables & their columns specified?
Does the report include the distribution of work between group members?

Implementation / Demo Evaluation

An overall evaluation using the (weak, ok, good, excellent) scale, based on:

[CODE REVIEW]
Does it work?
What parts, if any, are not complete?
If not finished, does it have a structure that would allow it to be completed easily, given more time
(or would it need to be thrown away and the program started again from scratch)?
Is it bug-free? How was it tested?
Does the code follow the CS101/102 guidelines (headers, comments, meaningful names, layout, etc.)?

[DEMO]
Is the project/program presented and demonstrated in a professional manner?
(does it have realistic data.)
Is the group ready on time?
Is the demo completed within the allocated time?
Does the demo concentrate on the showing the important functionality first?
Does it represent a reasonable amount of work?
What techniques/technologies are used that have not been explicitly taught in the course?
What has each person in the group contributed?

Misc bits....???

Requirements Stage:

• Begin with a very concise statement of what you are thinking of building, then expand on it in later sections.
• Background research for similar existing products. What will distinguish yours? Why should someone chose it?
• "Necessity is the mother of invention". Motivate need--find customers; people with needs!

UI Stage:

• Introduction. Remind readers what the project is (they may not have read the requirements report or forgotten it!)
• Provide an overview "map" of the software to make it easy for readers and viewers (& even users) to see where everything is.
• Aesthetics are VERY important!  On report, presentation & UI itself!
•  
• Spell check!  report, presentation & UI itself!
• Show (rather than telling or allowing to guess.)
•  
• Consistent style (fonts, colour, sizes, button locations, etc.) throughout the interface
• Consistent layout ( button & menu locations, etc.)
• Navigation. Can users get wherever they need to quickly & easily? Back/Main/etc. buttons/menus.
• Titles/context. Can the user easily figure out where he is?
• Use the right sorts of UI components for the right job! Labels vs. textboxes, radio buttons vs. checkboxes.
• Give feedback on user actions & allow them to be undone (& even redone) if possible.
• Font size & colour contrast... can people at the back see/read the presentation?
• Screen (real estate) pixels are expensive, don't waste them!
• Use borders to group and/or gaps.
• Use layout managers where appropriate!
•  
• Put you presentation on your project webpage (rather than emailing it to yourself!)
• Don't rely on the latest version software being available on presentation machines!
•  
• Show the game/program! Very common mistake is to show all the menus & dialogs and forget to show the program!
• Show game/program first, not last. Readers/viewers should not have to guess what you are talking about or get bored reading about menus/options!
• Show actual data/images, not empty screens or random letters!
• Reduce the number of screens if possible/sensible. Remember, you will have to code them!
• Concentrate on the main/essential features first!
• Don't insult readers/listeners intelligence by explaining the (absolutely) obvious.
•  
• Be able to defend/justify your choices.
• What other options did you consider?

Design Stage:

• Show architecture first
• Show main "logic/model" classes only, not UI classes.
• Specify database tables (if using database!)
• Include any non-trivial algorithms.
• Alternatives considered, choice justified?

• - Is the design detailed enough: Number of classes, interfaces and so on?
  - Is the design good enough to satisfy the requirements?
  - Is MVC or some other appropriate pattern is used in the design?
  - Does class and interface definitions create a good abstraction of the domain?
  - Is there a separation between data model and system model:
    (This point is crucial, seen lots of projects having data classes but don't have any processing units).
  - Is a general UML diagram given? Does it go with UML definition?
  - Do methods, variables have suitable/proper names?
  - Is class interfaces well defined: private/public methods and variables?
  - Does everyone have a fair contribution in terms of sharing the classes
  - Is system shared correctly between members?

Last updated: 07 Apr 2012
Please report any errors or omissions to the course instructor.