Skip Navigation CECS Home | ANU Home | Search ANU

Master of Computing

COMP87*0 Project Courses

Background and Structure

The Masters of Computing aims to further the training and experience IT graduates for the IT and computing industry. In particular, it offers specializations in the various areas of computing supported by researchers at the College of Engineering and Computer Science. This is supported both by coursework in and a substantial (12 unit), (implementation-based) project in each area.

These courses will comprise a project with an industrial or scientific objective. The project topic must be consistent with the project course's designated area. Assessment will typically be based on the design and implementation of a software system that is related to the project course's area, written documentation, and verbal presentation. These courses are all 12-unit courses which run in either semester.

The projects are normally implementation-oriented, rather than research-oriented, although even for the former it is possible that he project has a significant research component, depending on the nature of the project and the experience and abilities of the student. It is expected that the student has experience in Project Management principles to the degree of the course Managing Software Development and applies these to the project. The followup postgraduate course COMP8110 is recommended to be taken before or concurrently with your project course.

The project, if taken, thus represents a `capstone' course for the MCOMP degree specializing in a particular area. Normally, it will be taken in the last semester of study, when the student has gained the most experience in the project course's area. Those considering going on to the MCOMP Honours degree (especially with the intention of pursuing a research pathway to a PhD), should especially consider taking the project, and also put careful thought to the selection of the designated area (where there is a potential advantage in maintaining the same research area throughout).

Enrollment

Enrolment in each course will require Departmental consent (e.g. from the projects over-coordinator, or the respective course co-ordinator). The guideline for permission to enroll will be having completed at least 6 units from the same research area as the course, and at least 12 other units for the MCOMP. These should have at least a Credit average. For this reason, the project course would be not normally be permitted earlier than the second semester for full-time study.

Enrollment in the course is then further subject to finding an appropriate project topic and supervisor. A project description (such as those on the main page) must exist or be produced for the proposed topic. The potential supervisor will need to confirm to the projects over-coordinator their willingness to supervise and that the topic is appropriate for the desired course. Note that it might not be possible to fulfil all of these conditions before the semester starts; thus, if the university administration imposes a nominal enrollment deadline earlier than this, you simply must enrol in 12 units of other courses initially, and then change your enrollments once given permission to enrol in the project course..

Learning Objectives

The learning objectives will be to:

• apply the student's knowledge and implementation skills in the project course's area of computer science for the project course, and apply this to an advanced and specific project topic in that area.
• deepen their knowledge of the project course's area through undertaking the project.
• learn any specific technical skills required by their topic, and apply them to the project work.
• learn relevant project-related skills, including project management and oral and written communication, and apply these to project work.

Assessment: Implementation-oriented Project

An implementation-oriented project's assessment conditions are described below. Variations may be individually negotiated if the nature of the project topic is significantly different from a typical implementation project. The assessment will be specified in an 'Independent Study Contract' negotiated and signed by the student, their supervisor and the project co-ordinator at the early stages of the semester.

As well as the conditions below, satisfactory participation at the Community of Practice meetings (which at the least requires attendance of at least 7 of the 9 meetings) will be required to pass the course, as it is necessary for degree accreditation purposes.

Evaluated aspect	Deliverable	Weighting
Manager Side	Initial Presentation, Final presentation	10%
Developer Side	Evidence of good project management (including Timetable), Software modelling and description, Structure and presentation of written report, Technical competence	60%
User Side	Software, Documentation/ Users Guide / Help, Feedback from the supervisor / client	30%

Note that the report is generally the primary contributor to the `Developer Side' of the assessment.

Example of things that we look at:

• The report lacks consistency in writing style and has an irregular flow of ideas in places. If this is a result plagiarism or insufficient attribution of other sources, the report may be marked marked down severely or even rejected.
• The report is not very well written and it is possible that this could be partly due to language difficulties. However, an examination of the code shows it to be exceptionally logical and well structured.
• An examination of the code shows it to actually be a "dog's breakfast" in spite of the students having written a wonderful report.
• The report is not very well written and it is possible that this could be partly due to language difficulties. However, an individual interview shows that the student really does have a very deep knowledge of the subject.
• An individual interview shows that the student actually doesn't know very much at all. Suspicion will be that this student did not actually do the work described in the report.

The timetable is the one you will present both during your initial presentation (planning) at the beginning of the semester and in your report (explaining how you did and did not meet your own deadline).

You should keep a Notebook containing your personal notes, reflections, trick that you find during the development of your project. For the purposes of your assessment, it make be asked for.

Assessment: Research-oriented Project

A research-oriented project's assessment conditions are described below. As for implementation-oriented projects, variations may be negotiated, with the assessment specified in an 'Independent Study Contract'. Satisfactory participation at the Community of Practice meetings is mandatory to pass the course, with the same criterion as for the implementation-oriented projects.

The Project Report

It is suggested that your report include a Title page (including your name/number, project title, supervisor/client names, subject name, and date) an Abstract followed by sections which parallel the various phases in the project. For implementation-style projects, the sections might appear as:

1. Introduction (A brief description of the project and its context)

2. Background (A description of any relevant background work and technologies. This should include an overview of the current state-of-the-art in practice and/or research in the project course's area that is relevant to the project)

3. Requirements (Detailed requirements; Note that tables of requirements can be put into an Appendix)

4. Timetable (You could put your proposed timetable here and also list the actual, final timetable which you followed. Save your discussion of this until later.)

5. Modelling (and/or Design)

6. Implementation

7. Testing (and/or Evaluation)

8. Discussion, Conclusions and Future Work

9. Bibliography

For research-style projects, the Requirements section becomes weaker (i.e. replaced by a (generally shorter) scoping of the project), but Background becomes stronger (and generally includes Related Work).

For all projects (especially research-oriented), the following notes on citations and proper attribution should be adhered to.

Suggested Organisation of the Work

1. Requirements Specification and Background Research (3-4 weeks)

   At the very beginning of semester, it will pay you enormously if you work very hard to master the technology that you will need for your project. In particular, if you will be using Java3D and TIWI on the Wedge, you should make sure that you understand as much as you can about these APIs. You may also need to do some work to refine your requirements to a stage that you can comfortably proceed with modelling. Do this in close collaboration with your supervisor.
   At the end of this period, you will have established a Requirement Specification in any form you choose (Use Case, Activity Diagrams ...); as long as both you and your supervisor agree on a common document which become indeed your "Contract" (for research-style projects, this stage instead could comprise of a preliminary investigation followed by a definition of what research will be undertaken, together with a plan, and beginning your review of existing background literature).

2. Modelling / Design (3 weeks)

   Part of your final report will be some detailed modelling. This could be considered to be a logical design for your software. This can take many forms but it should include, at a minimum:

   1. Top-level design, including a description of the classes or modules which will make up your software artefact (together with their most important attributes and associations).
   2. A description of the most important methods or functions, together with their relevant algorithms at a high level of description).
   3. A description of any relevant state machines (if relevant).
   4. A description of some important scenarios which you will be able to use later on to test your software.

   You should undertake your design in close collaboration with your supervisor. For research-style projects, this stage could include undertaking a literature review specific to your project, formulations of the hypotheses to be tested detailed experimental design.

3. Implementation, testing/debugging/second phase and documentation (3 + 3 + 1 weeks)

   You are pretty much on your own for this phase of your project. Five weeks is not very long, so it will help you if you have already experimented by writing some small prototypes of parts of your system in the modelling stage. One good use for your supervisors at this stage is to ask them to comment on the quality of the code that you are constructing (your final grade will include an assessment of the quality of your actual coding).

4. Write up, demonstration and submission (2 weeks - throughout)

   Ideally, the report should be written up gradually throughout the semester in successive drafts, especially if your report writing skills are untested and/or you are not confident with your English. It is a frequent problem with projects that students give a draft report to their supervisors without sufficient time for them to read and return it.

Project Topics

See the main projects page . Note however approval (ultimately from the course co-ordinator) will be needed that the topic sufficiently matches the area of the project course you intend to enrolled in. One criteria for judging this is whether the topic matches thematically to any of the coursework-style courses listed under the same area in MCOMP Schedule 1. Check with your potential supervisor (the project topic proposer) first - hopefully they will have indicated this clearly on the topic's web page if it is. Secondly, discuss this with the overall projects co-ordinator (or respective course co-ordinator).

Supervision

You will meet regularly with your supervisor - about 30 minutes to one hour every week. These meetings are important early in the semester to make sure that you understand the project requirements; that you have access to the material that you need to study to learn the technology required to complete the project; and that you have developed a good project plan. As the semester gets underway, the regular meetings are important to make sure that you are on track and to get some help on technical topics (or some references so that you can solve the problem yourself). Later on in the semester, you should give your supervisor drafts of some of your report so that you can get feedback which will help you improve the final document.

You should arrange regular meetings with your client, as necessary.

Timetable (generic - refinements are announced in the community of practice)

• Week 0 (or before!): choose a supervisor/client/subject and get started!
• Week 1-2: defining project requirements and learning technical tools stage (continues till end of week 3). 1st Practice Meeting in week 2.
• Week 3: finalize negotiation of Study Contracts (with supervisor and projects over-ordinator).
  Initial Presentations - includes overview of project topic and project plan timetable (Practice Meeting 2).
  Detailed Project Requirements document (including project background and timetable), plus initial presentation slides, to be emailed to projects over-coordinator by 4 pm Friday week 3.
• Weeks 4-6: modelling / design stage
  Practice meetings continue.
• Week 7-10: implementation stage
• Mid Semester break: implementation stage continues!
  Mid project result (including prototype, outline of final report) due to supervisor(s).
• Weeks 10-12: testing / evaluation stage
  Practice meetings continue.
• Weeks 12-14: finalization of implementation, writing of documentation and final report write-up stage
• Week 13: Projects due on 4pm Friday (2 hardcopies of final report plus softcopy of report / final presentation slides / project artefacts to the projects over-coordinator)
• Week 14: Final Presentations - includes demonstration where applicable (Practice Meeting 9).

• Copyright | Disclaimer | Privacy | Contact ANU

  Page last updated: 03 January 2012 Please direct all enquiries to: webmaster@cs.anu.edu.au Page authorised by: Head of School, SoCS

  The Australian National University — CRICOS Provider Number 00120C