Logout

Criterion A - Planning

Instructions and Advice

 

Pre-step: Initial Interview
Refer to the Criterion-A-The-Initial-Interview link. FOLLOW THE INSTRUCTIONS ON THAT LINK, but in summary, as a reminder:

1. Problem Statement - A not-too-long statement of the problem you identified client has. This should refer in no way to the solution - it is just the problem.


2. Description of Scenario - This is where you put the problem in context. This too should focus not so much on the solution as it does on the situation itself that presents the problem. So put another way, it puts the problem in a certain context.

Don't go into too many details, since you have to be conscious of your overall extended writing 2000 word limit. On the other hand, if you were doing this for a company, you would have to be detailed enough so that someone else in the company in another part of the world, or decades on, would be able to figure out what problem it was that you were trying to address. So talk about the organization, and the individual; what they do currently, and how they do it.

At this point, the students should make a file called "On-going Questions for Client", where they keep track of things needed to clarify various situations. This can go as an appendix.


3. Rationale for the Proposed Product - Why is a computer program a good approach toward a solution to the problem? Why is a GUI application a good solution? Why is Java a good language to be using? Included here is why is OOP a good approach? And why is Netbeans a good development environment to use?

Do make sure to put as much emphasis on why is a computer programming solution a good solution to this problem as why Java, etc.

Note the following bolded statement in the IB instructions: "with reference to the student’s consultations with the client and/or adviser, justifying how the choice of this particular product is an effective solution." Referencing is The Main Thing.*

Remember to include the word count for this section also, since it is extended writing.

This is one area that the 2020 IB in-service leader was keen on students doing a much better job on; not just being happy with statements like "I chose Java becasue I know it".

---->>> Much more on the rationale. <<<----


4. Referencing <<------!!!!

***Importantly*** all of this, along with the Success Criteria below should all stem from the interviews you had with your user. So one way or the other, reference your conversations with your client. All of the following ways to reference can work, though it seems the first option is the one you are most used to from other school work:

Chicago Style, not MLA

It is the ISB who has chosen MLA for research projects, particularly the EE. But in the sample for this IA, it is the Chicago style, with footnotes, which is used, so we'll stick with that style. I think it is much better anyway. And it's really quite easy to do; just go Insert, Footnote in your Google doc, and use the style seen in the examples below.


A. --> direct quotes from your interview(s). For example: As Mrs. Smith stated in interview #1,"'We need to be able to do this quickly, while our patients are in our office ". 1

or: As Mrs. Smith said in Interview # 1, question # 4, "I would really like to have a graphical way of interating with the data, rather than just using boring old Excel".2

B. --> more general reference to the interview(s). For example: As can be heard in the recording of my second interview with the client, this needs to be done quickly. 3 And my client reiterated this point near the end of our interview. 4


BUT FOOT-NOTE ALL OF THEM See below the a proper way to do so (And see the bottom of this page for the actual footnote # 1.)

___________________

1 Jane Smith, interview by author, Bangkok, November 19, 2019, transcript question # 3, Appendix 1
2 Jane Smith, interview by author, Bangkok, November 19, 2019, transcript question # 7, Appendix 1
3 Jane Smith, interview by author, Bangkok, November 23, 2019, audio recording transcript 3:31, Appendix 2
4 Jane Smith, interview by author, Bangkok, November 23, 2019, audio recording transcript 12:45, Appendix 2

 

5. Prototype of the Product

Basically, the protytyping process is:

Go to Netbeans, make a new application sample form and make a "prototype solution", that is a mock up of how you envision the application working. It will not have any code, just GUI elements. The idea is that you will show this to your client in a second interview where you propose a solution to the problem that arose in your fisrt conversation. Prototyping is a very crucial step to any design scenario, as it is where the producer and client communicate back and forth about how the final product is to look and work. Changes at this stage are a whole lot easier to make compared to after tons of coding has been done.

Be sure to look at some past IAs to get an idea of the way you can use Netbeans to design your GUI interface.

Using the prototype in the second interview:
In a multi-tab application, each tab should be printed out and shown during the second interview. You will go over how you expect the application to function, and get comments and suggestions from your client. Put these ideas on the printed out screen shots with pencil or colored pen. This is the surest way to show that you actually did interect with the client. In fact, seeing two hand-writing styles is great too.

Here's a sample of what your marked up prototype should look like after your prototype interview:



6. Success Criteria for Product - Here you describe the things that need to be accomplished in order for your program to be declared a success when it is finished. This section should be a happy medium between writing too much, and too little, particularly if you use a bulleted list, which is a common approach.

One advantage of using a bulleted list is it that it helps you be focused, and not write too, too much. And another advantage is that it's useful for when the Success Criteria come back as part of the Evaluation of Criterion E - in that case, you can go on down through the list, "check, check, check, check"... But if using a bulleted list, just be careful to not write too little per item in your list; you have to be clear about what will account for success with each point.


But one way or the other, this should be from the user's perspective. So try to stick to things that the user said during your interviews.

So the list that you end up with should be in the "client's voice", in language the user would/could use. So not "the program will use a binary search, blah, blah, blah". Rather, "the user will be able to quickly search for their favorite chocolate from the list the input."

A good approach to this would be to start each criteria for success with "The user will be able to…" or something along those lines.

Criteria for success include things such as the following:

a. What the program will do
For example save records of whatever to a file. Most of your success criteria will be these things that it does. (But don't just list simple things like what will be able to be input; rather focus on the main functionality; the things that the program will ***do***.)

For this, think of all the buttons and all the menu items that your program might likely have; each one of them should perform some specific thing, which will be its own success criteria point.

b. User friendly features
How user friendly your program is, so for example, it has drop-down menus to make its use easier, or it has a help menu, or it comes with user documentation. (It's possible that your user doesn't require a user friendly program, but usually this is a good thing to consider.)

Examples of extra usability features:

Help button - pop-up
Hover thing
Fields demonstrate how to fill them in and clear when clicked.
Example shown.
Example described right under a text field.
Help menu
Combo boxes & other GUI elements themselves
Separate website help
Separate Help window (but how to close and not close the first window.)
etc.

With the following two, at this point, it's more if they come up in the interview, for sure add them. But each is both a bit more focused on the programmer, rather than the client, so don't worry if you don't include them as success criteria yet.
In fact, you may want to come back later on and add one or two more success criteria later on, related to your exception handling that ended up being

c. Error/exception handling
Later on, during your programming "Stage P", there will be lots of specific exception handling I will show you, and you can do. But for now just try to think of all the basic ways your program might be mis-used, causing general errors which you can handle. For example, if a user leaves a textField empty, or types in a letter instead of a number.

d. (Optional) Program efficiency
You may want to have as a goal a certain maximum time the program takes for doing certain things, such as sorting a big database under a certain number of seconds. This may only be important if there will be sophisticated processing.

Another goal (especially if to be run on a small device, like a smart watch) is a certain maximum amount of RAM memory the program takes up, or a certain maximum amount of storage memory the program and the data file takes up.

 


7. Audio File AND Written Transcription of Interviews

For now keep track of the audio file, or your written tanscription; which ever way you recorded your interview. Later on, we'll add these files as appendicies.

And note that you NEED a transcription of the interview from the audio file, in which either all of the interview (if a reasonable length), or the main points only (if a long interview) are transcribed in text. **Note that if you only include an audio file, the IB moderators are not supposed to have to listen to it, so you will not have the top grade for Criterion A possible. It the interviews have to be either written files only, or written transcriptions, in combination with their =audio files.

 

8. Pictures only of:
- the Initial and Prototype Interviews Themselves
OR a picture of the .mp3 etc. file icon

Put ***pictures only*** of 1. the appendix of the initial interiew tanscription, or if it's an audio file, a pictuer of the .mp3 etc. icon.

If it's pictures, make them small enough that they cannot be read, but large enough that you get the idea that they are text douments. This is to (a.) be clear to the moderator that you did interviews, but (b.) not have them counted in the word count. But add the words "Pictures of Interviews; see Appendix for full text (and audio) versions. NOT COUNTED IN WORD COUNT"

 

9. Word count

Actually write "Word count: 123 words" right at the top of this Criterion A section. This includes all narrative parts; so not bulleted lists, unless those bulleted lists themselves are narrative phrases/sentences. And not including the interviews, obviously, which are only pictures here in Criterion A.

 

___________________

1 Jane Smith, interview by author, Bangkok, November 19, 2019, transcript question # 3, Appendix 1
2 Jane Smith, interview by author, Bangkok, November 19, 2019, transcript question # 7, Appendix 1
3 Jane Smith, interview by author, Bangkok, November 23, 2019, audio recording 3:31, Appendix 2
4 Jane Smith, interview by author, Bangkok, November 23, 2019, audio recording 12:45, Appendix 2