AC11001 Project Guidelines

These notes contain a set of guidelines for your project, describe what will be assessed and describe the marking scheme.

During AC11001, in addition to other course work, you will be working in teams on the development of a fully functioning software application.  

The aim of the project is to introduce you to team working; to enable you to demonstrate your understanding of the software development process, and to give you assessed practice in object oriented software development through the design and development of a fully functional (and working!) application. Although you work in teams for the initial stages, the project which you submit is an individual piece of work. 

Overview

At the start of the module, you will be given a project brief and asked to work in teams to produce a requirements document and an initial design for your project. The aim here is to get you thinking about the design process, not necessarily to come up with a realistic design. This work is assessed and returned to you.

Around half way through the module, you will be asked to spend time on refining the design, again as a team, on the basis of your increased experience and on the feedback you have received from module tutors. This document is also assessed and should be regarded as the final version of your design. From then on, you work individually on the implementation of the design as a Java program and on the documentation of your application. You will probably find that you want to modify the design a bit, but essentially you should be working to the design your team produced. You can continue to use your team colleagues for support and discussion.

At the end of the module, you have a week to devote entirely to your project, and module staff will be on hand during normal lecture and practical times to help make sure your project is as good as it can be. When you finish, you hand in a report, which must include the following sections:

• a set of requirements
• a design, including documentation of your classes
• a source code listing
• a report (one per student)
• a (working) program

Your requirements should not change much from the ones you have produced earlier. You may not meet all the requirements but that is fine as long as you document that in your report and say why.

Your design should show how your program has been designed form an object oriented perspective, and also show how you went about designing the user experience of your propgram. You may also include some pseudocode to highlight parts of your program that you feel particularly pleased with.

The source code listing should be documented. Use comments (not too many, not too few), and sensible names for classes, methods, fields and variables to make your program as self documenting as possible.

The format of the report and poster are given below.

We are not expecting a large sophisticated program. The aim of the exercise is for you to practice the art of programming from requirements to design to implementation. A program that is well designed, well documented and works but does not meet all of the requirements will gain more marks than a poorly designed, poorly commented program that tries to meet all of the requirements but does not work.

Points to remember

• Depending on your requirements, work on one at a time. Get one working, then move on to the next one. Build your program up, one requirement at a time.

• Using the methods taught in class, you should be able to identify the classes, methods and other components fairly easily, but if at some stage you think you may have got it wrong (i.e. chosen unsuitable classes etc.) ask a member of the module team for help.

• Decide on your data structures as early as you can. Don't make them too complicated. They do not need to be for any of the projects. But if you get your data structures correct you will find developing the algorithms a lot easier.

• Comment as you go along. It will save you a lot of time at the end. Make sure that you comment so that automatic documentation can be generated.

• Design-write-compile-test classes and their methods before going on to the next one. Build your program up a bit at a time.

• Plan your project. Stick to the plan as far as you can but modify it if need be. Remember to leave time for writing the report and preparing your poster.

• Remember also that there is a whole world of Java packages and libraries for you to use if you are feeling a bit adventurous!

Report

You report should be no longer than 10 pages and should comprise the following sections.
Page sizes are guidelines. Try to stick to them. Quality not quantity is what counts.

Executive Summary - one page.

Describes what your program does. Describes successes of the project. Describes failures. Provides an overall conclusion as to the success and usefulness of the project.

Introduction - 1/2 page

Introduces the report to the reader

Requirements - one/two pages

Describes requirements for the project

Design - one/two pages

Describes design of project. Refers to the OO design documentation in Appendix A

Source Code - one/two pages

Describes any features of the source code you want to point out. Refer to the source code in Appendix B.

Evaluation - one page

Describes how the program was evaluated. How did you prove it worked and how did you check for bugs. Try testing your program with other users apart from your self. Are there any bugs you know of? Describe them. Any of the requirements missed? Any new ones added in?

Summary and Conclusion - one page

Summarises the report and provides a conclusion as to the success and usefulness of the project

Critical Self Evaluation - one page

Provide a self evaluation of how well you have done. What have you learned? How would you do things differently if you could do it again. How could you provide a better product? Award yourself a mark out of 100 and justify it.

Appendix A

Object oriented design documentation

Appendix B

Source code listing.

Appendix C

Disc with working version of program and any associated data files and set of instructions for running the program in a file called readme.txt.

The aim of the report is to describe the various stages of your project and provide a summary on how successful it was. The executive summary should describe your program to a busy reader who is NOT familiar with computing terms. The requirements section should describe what your program was going to do. The design and listing sections should describe to another software developer how your program does things. The evaluation section should tell the reader how you evaluated that your program was acceptable.

Presentations

Work as a group to produce a poster about the project. You will present your poster on Thursday of teh final week in the lab. Presentations will take the form of a "sales convention" where all the teams have a stall with their poster, which explains and advertises their project as if it were a commercial product. You may also prepare any additional materials you wish (such as leaflets to hand out and so on). All students are required to attend the sales convention and should try to get round and see other students' posters (and ask questions). There MAY be a prize for the best presentation!

Module feedback

You will be asked in this last lab session to complete an online module evaluation form.

This feedback is very important to us and helps us to decide on improvements and changes to next year's module. Your final reports will not be accepted without a completed questionnaire.

Marking scheme

Copyright © 1997, 2003 Peter Gregor. All rights reserved.
Revised: 15th September 2003