- Site Home
- IB
SL - Topic 5
Abstract Structures
- Topic 6
Resources - Topic 7 Controls
- Option DOOPs
- IAProject
- Paper 3 Research
This is an opportunity to demonstrate not only your programming skills but also your "people skills". It also puts into practise your understanding of OOP principles.
You will need to analyse, design, prototype, test and document your system. You will need to plan how you are going to test as you go along. Do not be tempted to do final testing only.
I am a great believer in giving the moderators what they have asked for in previous years. So read this document for a collation of their comments.
In choosing a project take the following into account:
1. The application you create must meet a real need for a real user.
2. Teachers are not usually the best users - hard to please! Admin staff are better!
3. It must be "do-able" with respect to your ability (even if you have to learn new techniques quickly), in the timespan alloted and available resources. Temper your ambition.
4. It must be sufficiently complex to collect the marks in the mark scheme
Some ideas
Booking System
Children's game or quizzes, monitoring progress
Calculating and displaying any analysis - eg golf handicaps -recording performance
Event handling
Database Inventory or ordering system
Recipe App
Practical issues at the start
1. Organise your folder structure (See moderators comments)
2. Download the zip file Form from the right column and use official IB forms
3. Download and use the checklist
4. Keep checking the markscheme.
5. The first task then is to start completing and then continue to update the official Record of tasks diary document ROT. YOU MUST USE THIS DOCUMENT
Word Count suggestions:
The word count is 2000. If you go over this then the moderator has the right to stop marking the extra. Some parts of the IA have no word count but there are nuances.
What is not included in the word count:
This means that the only parts of the IA that do have a word count are:
Since Criterion A and Criterion E are both worth 6 marks, and Criterion C is worth 12 marks, it makes sense to divide the word count accordingly:
A few words of advice:
No more than 350 - 500 words excluding success criteria bullet points so reference appendicies
It should be clear that your consultaion with the user has led you to your rationale. Say how it will be an effective solution to the problem. Explain why Java/JavaFX. Why desktop app? Please don't say you are using Java because you have been learning it.
What other solutions did you consider but discarded and why?
Show you have considered:
1. The skills required
2. Security and privacy issues
3. Ease of access to get the data
4. Hardware/software requirements
5. Time and cost
6. Any data conversions
You will need to interview the user to begin to put together a features list or requirements. Use these guidelines for planning and conducting and documenting successful interviews.
Whilst interviewing look for evidence to justify the design of the system for your scenario report. You need to be a bit of a sales person to get the user to commit.
Following the interview present the client with a list of features in plain language that you agree the system should do. A feature is what the application needs to do. It can form the basis of your successs criteria as well as be the basis for a Use case summary diagram. See design tips in the resources column.
Success criteria ( 6-8 points) should be on the lines of..."Accurately records....." and be SMART, specific, measurable etc. Success criteria do not count in the word count. Make sure there is evidence that the client agrees with them
"The user interface is intuitive and ..." "An invoice is produced that is accurate and laid out in standard business format....". You want success criteria to be "testable".
Look at the notes below for Criterion B. No more than 1000 words here which excludes diagrams like UML and use case.
Record of Tasks (Must use IB's one)
This is like a diary of program development issues. I would expect you to have 80+ quality entries like "found a bug in the save method. Spent 1 hour fixing it"
Include all the key events in planning, designing, testing and implementing the project
Design overview
This will include flowcharts, UML diagrams, sequence charts, low level, overview pseudo code, data structure or data dictionary table/diagrams.
Include GUI diagrams, but not finished implemented ones, they must look different as your user will give feedback on these and they will develop. There MUST be evidence of user feedback.
Explain in a text box or shape some of what your diagrams etc are showing.
These won't count in the word count then.
Extensibilty of the product
Put this in an appendix to avoid word counting and reference it in the Design overview.
Say how you have made your software extendable and maintainable in the future, perhaps as a result of your class association decisions.
Remember the PowerPoint where I referenced a file on the hard drive which meant it was not extendable. Constants come in handy in this regard as well as enums, don't they? Encapsulation is worth mentioning for the privacy bit and the granddaddy of them all explainationary comments in your code and brilliant documentation.
Talking about comments don't say things like //"Here I iterate over the array list" AS IT IS OBVIOUS IN THE CODE, but more:
//Using a for each iteration over a traditonal one because...
//Using an arraylist rather than the normal array because.."
Truth to tell
Most of the marks are available for correct documentation of your project. Do not neglet this as there is a tendency to focus on coding and run out of time to properly do this.
Resources