What is Stage B?

Stage A was the Analysis section of the project.  It was supposed to concentrate on the existing problem, and end with a list of goals (Criteria for Success).  That means you already know what you should achieve. 

The next stage is the Design.  This stage should present a clear overview of HOW to achieve the solution.  Stage B Design is separated into three parts:

• Data-structures - variables, arrays, files, objects
• Algorithms - methods
• Modules - objects, data-structures and methods, with clear connections between them

The steps below can be done in any order.  You are likely to work on all of them IN PARALLEL -
adding a bit to each, then add a bit to another part.

Step B0 - Functional Prototype

A functional prototype is used to test the feasibility of technical aspects of the design.  For example, you may need to save data into a file.  That means that specific data must be saved, in a specific format.  Once you start trying to write a method for this algorithm, you will probablby find things that you didn't think of before.  For example, it might be useful to save the current date.  This becomes especially obvious when you start writing the Load method and you need to know what the name of the game/file is.

A functional prototype is NOT supposed to be "complete" - especially the interfaces are not important.  But it's nice if there are some interfaces.  It's the automation that we want to test.

Here are some notes about writing a functional prototype.

So the second step in the design process is to pick out some of the tricky algorithms and write a simple version that convinces you that the program will be possible.  The functional prototype is to help the DEVELOPER (programmer) and is not really intended for the CLIENT, although you may find it helpful to show it to the CLIENT.

Step B1 - Design Overview

Start by making a design overview.  This includes tasks, interfaces, objects, algorithms and data.  This can be changed later - in fact, you should constantly change and update this document as you work on your program.  It will help you focus your thinking, as well as keeping track of all the parts of your rather lengthy program.

Here is an example overview for a sports-team-management program.  It is supposed to do the obvious things, keeping track of players and statistics.

You can fill this out in any order you wish, although the intention is to do it from left to right.  The User Stories and Prototype from Stage A should lead to TASKS that the user wants to perform.  For each task, think of an appropriate interface.  That interface will need some automation to be provided by algorithms.  The interfaces and algorithms will indicate data that must be stored.

Spend a couple hours to write a design overview with at least as much detail as the Sports Management overview.  Yours will certainly have at least 3 tasks and 3 interfaces, and something like 3 algorithms for automation of each interface.

Here is a blank form for you to use:
   DesignOverviewBlank.doc  DesignOverviewLabelled.doc     

Step B2 - Modules = Objects and Data Structures

The Design Overview helps you to organize the various pieces of the program.  That doesn't necessarily specify how to write it.

The OOP (Object Oriented Programming) approach is generally more productive than just writing a lot of methods in one big program.  It's not a requirement for SL students - it is pretty much a requirement for HL.  Using Objects (and classes) helps to organize the program, as well as resulting in programming commands that are easy to write and easy to read (makes the examiners happy).

Stage B3 of the documentation requires a design-overview diagram.  This is considerably easier to organize if you use OOP techniques. 

Now read these notes about OOP techniques for data storage.

Step B3 - Algorithms = Methods

This is the clever part of the solution.  This implements AUTOMATION.  This is NOT about what the user does, but rather what the PROGRAM does after the user has started it.  This is where you show off your INGENUITY.  For example, if you are creating a database for library books, it could just be an alphabetical list of titles.  But users may want to find a book by typing the name of the author, and this could be done either by SORTING books by authors' names, or by SEARCHING for an author's name, or both.  And when it is searching, if it detects PARTIAL matches (e.g. finding a name which was misspelled) that is cleverer and more useful than simply searching for exact matches.

You can PLAN your methods by writing Pseudocode, leaving out tricky technical details and focusing on the main concepts.  You could draw flowcharts, but that is very time-consuming and actually doesn't do any more than Pseudocode.  Writing Pseudocode is FASTER and EASIER than writing and debugging Java - you should try it. 

Step B4 - Testing Plan = Test Cases

Unless you are better than most professional programmers (highly unlikely) you will actually spend more time TESTING and DEBUGGING your program than you actually spend writing Java code.  In any case, you must FULLY TEST your program. 

A Testing PLAN will save you time and effort in the long run.  You should write down SPECIFIC CASES that you will will test.  Each TEST CASE contains:

- a situation (which button was pushed, what happened before)
- test data (actual numbers and Strings)
- the EXPECTED correct result (might be data, but could also be an event)

If you have a clear and complete plan, you are less likely to forget or ignore some problems (bugs) in your program.

Step B-Final - Presenting Stage B - Development

Read the check-list and assessment criteria for Stage B, and look at some examples. You will realize that there are MANY POSSIBLE WAYS to structure your presentation of Stage B.  The following is recommended, but not "required":

- INTERFACE (pictures)
    Start with a picture from your visual prototype (or screen captured from you functional prototype)
    Include some brief introductory text

- OVERVIEW
   Draw a FLOWCHART or a HIERARCHICAL TOP-DOWN DECOMPOSITION CHART showing the overall structure/functioning of the program.
   This chart does not need to contain tiny details.  For example, [Search for name] is fine - it's not necessary to show a loop.

- MODULES
   Draw a box for each OBJECT and each DATA-STRUCTURE 
perhaps presented as a UML diagram
and possibly a box showing GLOBAL VARIABLES
   Don't bother listing all the temporary counting variables of all your loops. 
   In these boxes, include REALISTIC SAMPLE DATA - not blank boxes

-ALGORITHMS
    Write PSEUDOCODE for all of the SIGNIFICANT ALGORITHMS (methods).
    These are the methods that were DIFFICULT and/or IMPORTANT.
    Small details can be left out, but loops and decisions should be shown.
    For example : "input number from age box" is sufficient
                       no need to write Integer.parseInt or other small details

- TESTING PLAN
   Make a TABLE containing all your TEST CASES (see examples in sample projects)
   Make sure that your TEST CASES include at least one entry for EACH GOAL stated in Stage A

For clarity, every entry should contain some brief explanatory text. 

** Recommended word-count =???

=== EXAMPLE =====================================================
This example is the closest to the model described above.
It probably contains a bit too much text and explanation.
Example 3 - 4 Color Map Theorem
=================================================================

Another Example : http://xmltwo.ibo.org/publications/DP/Group4/d_4_comsc_tsm_1201_2/IA8en/Documentation/Crit_B_Design.pdf

This example scored 4/6 marks.  The moderator's comments:

"The record of tasks includes all 5 stages (plan, design, develop, test and implement) in sufficient detail.
The design overview is detailed, but should have been explained for better understanding.
A test plan is partially complete because it does not clearly address the criteria for success.
For full marks, the design overview should include UML diagrams with interdependencies explained
and some algorithm design. The test plan should address all success criteria."

-----------------------------------------------------------------------------------------------

IB Documentation for Stage B 

== RECOMMENDATIONS Checklist ==

=== Assessment Criteria = REQUIREMENTS ===

Criterion B: Solution overview (6 marks)

•        The student must provide a record of tasks and a design overview that includes an outline test plan.

•       The Record of tasks form must be used.

•        The record of tasks and design overview must refer to the product proposed in criterion A.