This document outlines the requirements for the mini project assignment, which is worth 50% of the student's grade. It discusses developing a program to solve a problem and writing a report to explain the work. A plan is due December 1st and should describe the problem, solution, and timeline. The program is due January 13th and must be well-structured and commented. The report is due then too and should motivate the program, provide examples, discuss challenges and related work, and conclude the project.

1. A I P ro g ra m m ing
Week Nine
The Mini Project
Richard Price
rmp@ cs.bham.ac.uk
www.cs.bham.ac.uk/internal/courses/ai-prog-a/

2. R ec a p
• Errors:
– Syntax errors.
– Compile-time.
– Runtime.
– Bugs/Semantic errors.
• Debugging:
– Mishaps help you track down errors.
– Print out your variables.
– Use the trace tool.
2

3. T he M ini-P ro jec t
• Basic idea:
– Design, plan and develop a solid piece of work.
– Write a report explaining your work.
• To create a relatively large program
– Larger than weekly assessed work.
– Opportunity to express yourself and do something creative.
• Worth 50% of your AI Programming A mark.
– Your weekly assessments have now ended for this term.
– They are also worth 50% in total.
– Will be fully marked before the end of term.
• Essentially we want you to condense what you’ve learnt into a single piece of
work.
3

4. T im e S c a le
• Deadlines:
– Plan: Monday 1 st December 5pm.
– Project: Tuesday 1 3th January 5pm.
4

5. T he s m a ll print…
• Plan:
– Myself and/ the demonstrators will be talking to you during lab sessions.
or
– Office hour Monday’s 2pm.
• Deadline 1 3th January 2009:
– Immediate 5% penalty for lateness.
– Every three days afterwards is another 5% .
– No submissions accepted after 27th January.
– Extensions should be requested through the Welfare team.
– For medical reasons or similar.
5

6. P la n - 10%
• A description of the problem.
– Does not have to be a complete description.
• Summary of your program.
– What parts of the problem will it solve.
• W hat will it do?
– Examples of it’s behaviour.
– What knowledge of the real- word does it need to know.
• Program’s ontology.
– How will this knowledge be stored.
• Database, lists, variables?
• Suitable Format?
– A general breakdown of the program.
• How do the blocks inter-relate?
• A timetable.
• Around two A4 pages in length.
6

7. T he P ro g ra m - 45%
• Needs to be readable.
• Use comments.
– Explain what it does.
– Is it clever?
– What should it do if it doesn’t work.
• Sensible variable and procedure names.
• Break down your code.
– A lot!
• If you use someone else’s code highlight this.
• Term ends on December 1 2th.
– Get the help of the demonstrators until then.
7

8. T he R epo rt - 45%
• Why is this a useful program?
Motivation:
• Examples of the program working.
Illustration:
• What where the problems encountered?
E xplanation:
How did you solve them?
• How do use your program?
Instructions:
• Report on other peoples work which may be similar.
R elated work:
• Possibilities for future work?
Limitations :
• Summarise what has been done.
C onclusions:
What could have been done differently?
• List your sources.
B ibliography:
• I would like to thank…
Acknowledgements:
• Your program.
Appendix A:
• Additional trace output, examples.
Appendix B :
• 2000 words not counting Bibliography, acknowledgements and appendices.
8

9. T he R epo rt - 45%
• The emphasis is on the explanation.
• Describe separately:
– What you did.
– How you did it.
– Why you did it that way.
• Create a story.
• Refer to figures, illustrations etc.
• Acknowledge other peoples work.
– Explanation of related work is important.
• Use a spell checker and get it proof read.
9