Masters IT (eScience)
(Software Development - 12 units)
Semester 2 2007
Important : A normal prerequisite is 40 units of courses from
the MInfTech program as well as COMP6704.
Context
COMP6703 is a 12 unit project course which runs
in semester 1 and semester 2 of each year.
Normally it is expected that students will have completed at least 42 units
from groups A, B, C and D of the MInfTech program before
taking a project. This means that the project course would normally be
taken during the last semester that a student is enrolled in the
Masters program.
This course will comprise a project (possibly a small-team project)
with an industrial
or scientific objective. Assessment
will be based on the design and implementation of a software system,
written documentation,
and verbal presentation.
Background and Structure
The minimum entry requirements for the Masters
are to have some second year computing (2 courses at minimum). After one full
year of Masters study, a student would be expected to be at least as skilled
as a good 3rd year BIT student (a "good" student, because Masters
students are meant to have had a Distinction average score in their last year
of a degree). So the Masters eScience project can be thought of as being equivalent
in standard to either a Honours CS project or a 4th year software engineering
project. (but, because its weighting is only 12 units, it will not be
able to be as ambitious as either of them). It should take roughly 300-350
hours
Format
The project
will deal with the construction of a piece of software - usually
from the broad
area of interest of eScience. The development
effort will involve some significant challenges and will probably necessitate
the learning of some new technologies.
Students will need to demonstrate a systematic,
and thorough approach to project planning and execution.
Some software development
projects will more suited
to small groups (of, say, 2 people) but, within these groups
each person
must undertake all roles of the software process for a portion of
the software.
Assessment will be on the basis of the report, the program, the code, a presentation
and, possibly, an individual interview with each student.
Marking
scheme
The project's scope and assessment conditions 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. Unless otherwise specified in the Contract, the following
scheme will be used.
| Evaluated aspect |
Deliverable |
Weighting |
| Manager Side |
Timetable, Initial Presentation, Notebook
Final presentation,
Meeting participation
|
10.00% |
| Developer Side |
Evidence of good project management
Software description and modelling
Presentation of written thesis
Technical competence
General feeling
Code |
50.00% |
| User Side |
Software
Documentation/Users Guide/Help
Feedback from the client |
40.00% |
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).
Your Notebook should contain your personal notes, reflections, trick that you
find during the development of your project
The 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
-
Introduction (A brief description of the project
and its context)
-
Requirements (Detailed requirements; Note that
tables of requirements can be put into an Appendix)
-
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.)
-
Modelling
-
Implementation and testing
-
Discussion, Conclusions and Future Work
-
Bibliography
Together with your final report, you are required
to submit an informal notebook that
you maintain throughout your project. This will not be marked but is
a requirement of the project simply because we want to encourage you
to keep a notebook.
Suggested Organisation of the work
-
| 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 (this will
help you in your Computer Graphics subject as well). 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".
-
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
- A description of the classes which will participate in your application
(together with their most important attributes and associations).
- A description of the most important methods together with their
relevant algorithms.
- A description of any relevant state machines.
- A description of some important scenarios which you will be able
to use later on to test your software.
You should undertake your modelling in close
collaboration with your supervisor. It would be good to adopt some of the
ideas of Executable UML for this phase, but this is not compulsory.
-
| 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. One good use for your supervisors at this stage is
to ask them to comment on the coding quality of some classes that you are
constructing (your final grade will include an assessment of the quality
of your actual coding).
-
| Write
up, demonstration and submission |
2 weeks |
You are very much on your own
for the last part of your project. 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. If you are unconfident of your English
expression then you should start writing parts of your report early on
in the semester and hand them to your supervisor for comment.
Project topics
Topics will be drawn from interdisciplinary areas which might be called "eScience".
Some of these topics will be close to "research" in nature, others
will be very applied. Some will have a visualisation component.
The idea is that the student will contribute to building real, living software
that others will use in the future.
If you are enrolled in this course, you should contact the
projexct coordinator,
to discuss your topic and to be allocated a supervisor.
A preliminary topic will possibly have been assigned
to you before the commencement of semester, but it is possible to modify its
specifications, or to choose a different topic completely, providing you negotiate
this early enough. Look at the project topics listed
on the eScience pages to get some ideas.
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.
Timetable
- Week 2 - 27/7/2007 - Supervisor, Project Topic, Breif Description finalized. (Details emailed to co-ordinator)
- Week 7 - 31/8/2007 - Mid-project result (prototype, report draft, first implementation ...) due and exposed to your supervisor during that week also the draft report must be emailed to both
your supervisor and to the co-ordicator.
- Final presentation Monday 29/10/2007 (Presentations will be 15 mins plus 3 mins change over.)
- Final report due Friday 4:00pm 2/11/2007 departmental office or under Eric McCreath's door n227.
