IB Computer Science IA Projects             Getting Started            Dave Mulkey, Germany 2014

Simply Getting Started (or getting started simply)

1. Start with a simple idea - a possible simple idea.
   For example - a Tic-Tac-Toe game.
   Is it too simple?  That depends on how you solve the problem.  
     
2. Improve the user's life.  
   Why would a person want to play Tic-Tac-Toe?  To win a trophy?  No, probably not.  Probably to pass the time, play a few games out of boredom.  If that's true, then it needs to be :
   - quick
   - simple
   - play at the right level of difficulty
    
3. How can it be made EVEN BETTER?  Changeable?  Flexible?
   In Tic-Tac-Toe, maybe you want it to play a really "good" strategy.  Maybe you want different levels of difficulty - beginner, intermediate, advanced.  Maybe you can play on a bigger board.  How about three dimensional?
   Good software lets the user change settings.  For example, play with smiley faces and frowny faces instead of X and O.  Can you make "skins"?  If you have instructions, can the user choose a different language?
    
4. But don't make the user do everything - something needs to be AUTOMATED.
   How about letting the computer play against itself, so the user can just watch?
   Can it remember games that were played?  Keep score over several days?
   Can it give advice - teach me how to play better?
   What automation makes all this worthwhile?
    
5. More, more, more.
   How about organizing a tournament, with several players, making sure everyone plays against everyone (round-robin) or double-elimination?  How about playing online against an opponent in another country?  On a 3D board?  Connect it to an educational quiz?
    
6. Computer systems have Input, Output, Processing, and Storage.
   Make sure you spend time and effort in all these areas.
    
7. No - don't make it bigger and bigger - KEEP IT SIMPLE
   Once you have brainstormed all the clever ideas, throw some away and only keep "enough" - whatever that is.  

Here is a VISUAL prototype.   Here is a FUNCTIONAL prototype

Starting Over (?)

You have NINE MONTHS to complete this project.  So you could:
   -   wait 8 months and then start?  Bad idea!
   -  start one project, throw it away, then start another?  Maybe once, but only in the early stages.

Let's throw away the Tic-Tac-Toe game, and start over with a different idea.

1. Simple Idea - adding numbers (wow - that MUST be too simple!)
    
2. Improve the user's life
   This will depend on the user.  Who wants to add numbers anyway?
   Someone checking their bank account.
   The school's accountant, checking money for books, salaries, etc.
   A student calculating a grade-point-average.
    
3. How can it be made EVEN BETTER?  Changeable?  Flexible?
   Computers make fewer mistakes (?), making corrections is easy (or should be),
   can save a copy of every calculation, can reformat it and print it out or copy into a word-processor.
   Make sure they can do "extra" things like copy/paste, saving, corrections, pretty printing, etc
   They should be able to specify the format they want for the display - e.g. how many decimal
   places, do they want scientific notation, so they want numbers printed in a row or column,
   use a comma instead of a decimal point, etc
    
4. Automation
   Can the computer be "smart" about this work?  Like can it "guess" what numbers I want to type, so I don't need to do it?  Here are a few ideas:
   - Rather than typing 5,5,5,6,6,7,7,7,7 , type 5x3 + 6x2 + 7x4
   - Accountants like to leave out the decimal point, typing  650, 1400 instead of 6.50 , 14.00
   - It could report the highest and lowest values, as a common error is typing a double digit (thus producing an unusally large number) or leaving out a digit (making a very small number)
    
5. Make it better
   - save all numbers and results into data file(s)
   - don't permit round-off (truncation) errors, like  5.9 + 0.1 = 5.99999999999999
   - write reports with rows and columns for "sets" of numbers
   - print nice reports on paper with headers and footers and nice fonts
    
6. More, more, more
   If you get addition to work, how about adding multiplication and division and subtraction
   How about permitting the user to type and print fractions
   How about other strange types of numbers like times and dates?
    
7. Computer systems have Input, Output, Processing, and Storage.
   Make sure you spend time and effort in all these areas.
   
   
8. No - don't make it bigger and bigger - KEEP IT SIMPLE
   Once you have brainstormed all the clever ideas, throw some away and only keep "enough".

Here is a VISUAL prototype    Here is a FUNCTIONAL prototype

Enough is Enough

So what is enough?  Consider the following:

• You probably want a good grade, so enough is something that completely satisfies the IB Assessment Criteria
   
• The intended-end-user probably has specific needs or wishes that you should try to satisfy.
   
• Enough cannot exceed the amount of time, energy and skills that you have.  You have 9 months, but that is not 9 x 30 days x 24 hours!  The IBO says 30 hours is expected.  Unfortunately 50 hours is more likely.  You need to think ahead and make a reasonable estimate of how long the work will take.  Work productively and quickly.

Setting Goals

You are required to write GOALS (criteria for success) as part of the Analysis Stage in the IB Assessment Criteria - Stage A.  These must be:

• sensibly connected to your analysis
• agreed to by the intended-user
• testable when the product is finished

You must write clear, specific goals.  These should be performance features.  They are NOT programming goals.  For example:

• using arrays is not a goal - it's a way to achieve a goal
• store names in a file - it's closer, but it's still about programming
• store a list of names and allow the user to change them - that is a proper goal
  It doesn't matter HOW your program does it, although reliable and flexible methods are better

Your goals must specify the features that the user needs in order to solve their problem. 

Who is the User?  Why?

After choosing a topic/problem, the next big question is: "Who is the intended end-user?"  You really NEED an intended user.  You might be an expert programmer.  You might be experienced in the problem domain (for example, using a student planner).  But that doesn't mean that you actually know exactly what another person wants or needs.

You need to choose a user, and then talk to them to clearly specify the goals of the program.  They will have both reasonable and unreasonable wishes.  You need to AGREE with them on reasonable goals for the project.

Once you have an intended end-user, you can start discussing user-stories and specifying goals.