# Internal Assessment (IA) in Computer Science: Criterion B

:::success
This is part of a series of notes on the Internal Assessment on the Diploma Program of IB.

You can check the index with all the others and the rest of teaching material [here](https://hackmd.io/68GDv_RgT-yh9oERMvdnFw#Internal-Assessment)

:::

###### tags: `IB` `CS` `IA`

This is being written in the 2nd trimester of DP1

## What you're suposed to have already

### Criterion A

You should have already an scenario (the problem that you're going to solve) and described who is the client or the advisor.

You should already have the interview with the client/advisor.

You should have written some Success criteria of your solution (what features will it have)

### The solution itself

By now you should now which technology are you going to use and start to be familiar with it. Do the tutorials. Create sample projects.

:::info
I asked this in "technology test.pdf"
:::

## The next step DESIGN

Now that we have a _rough_ idea of what we need. Now we need to be serious about it and make it splicit. Using the analogy of a house, in criterion A they asked us that they wanted a school with 20 rooms. Now in criterion B we're going to draw the blueprints of those rooms.

In criterion B they ask for 3 things

* Record of tasks
* Design
* Test plan

They don't count for the limit of words so write as needed.

### Record of tasks

IB want you to write all your progress in developing your solution so you will have to track it using a record of tasks. So everything that you do related to the IA should be written here. The more detail the better.

You can use this link to downlowad the template https://gss.sd42.libguides.com/c.php?g=710341&p=5060984


:::danger
Remember that IB tells that we have to use the template. **USE IT**
:::

I will go over a bit over the details of each part:

you will have to **number the tasks** in order. **Write the tasks** (first what you have done) what you planned to do (make an interview, implement a specific feature), **what is the outcome** (record it, have a feature done), **the time estimate** means the time (of actual work) that you think you need to get it and the **target completion date** (or the date that you have done it). The **criterion** means the criterion that you're improving. Can be A, B, C, D, E or N/A. If it's developing or finding resources regarding how, for example, the programming language/frameworks that you have chosen works, that will be on Crierion C (development)

In this case you have started already your internal so you can write the things that you actually have done regarding it and the corresponding dates.

The idea is that here you will put as much detail as possible and an external person should be able to follow the progress of the development.

:::warning
:warning:

Remember to update your record of tasks. Not updating it will be reflected in the grade of criterion B in each of the steps

:::

If you modify the the scenario in your internal, you will need to start over a new record of tasks. But if the scenario is the same but change anything else, you can keep the previous version of the Record of Tasks.

### Test plan

Once you have approved your Success criteria from criterion A you can start to make your test plan. The test plan should be detailed to be used by someone else to check if your solution meets the success criteria. I suggest a table like this

| Success Criterion | Test | Expected outcome |
| -------- | -------- | -------- |
| 1) Database | Create a new record | The record is created |
| 1) Database | Update an existing record | The record is updated |
| 2) Website styling | Open the website | The style of the website corresponds to the context |

The more detailed the better. Many success criteria should have more than one test related. Some others can have just one test. Is something that you could do yourself or someone else should be able to do.

Let's do another version more detailed

| Success Criterion | Test | Expected outcome |
| -------- | -------- | -------- |
| 1) Database | Create a new record with default values | The record is created |
| 1) Database | Create a new record with custom values | The record is created |
| 1) Database | Create a new record with invalid values | The record is not created and an error is output |
| 1) Database | Update an existing record | The record is updated |
| 1) Database | Update an existing record invalid values | The record is not updated and an error is output |
| 2) Website styling | Open the website | The style of the website corresponds to the context |

Since some students didn't read it the first time I'm going to write it again in a fancy box:

:::warning
:warning: There should be more tests than success criteria :warning:

:::

### Design

In criterion A you have to write a rationale of why the tool that you're using is good for what you're planning to do. Now you will need to describe it. Preferably using diagrams.

You can draw diagrams using https://www.drawio.com/ but any program is allowed and even draw by hand (they have to be clear enough to be understood)

Depending on the IA there are several things to do but in general:

* If your IA has several pieces (A front end and a back end, a database and an interface, some hardware and some software) I want to know which pieces there are and how are they connected.

This is a diagram that I used in one project

In this case even if you don't know what are the specifics we can see that there are various pieces and how are connected in some specifics.

In this case this other diagram:

is a litte too much in the high level and need to be accompanied with the other one. You can see more info [here](http://fabacademy.org/2020/labs/barcelona/students/david-prieto/projects/final-project-development/#getting-serious)

## Types of diagrams

This may or may not apply to your IA, so I'm going to put some requisites.

They ask you explicitly that these diagrams need to show your **algorithmic thinking** so use at least some of those.

### Visual references

If any of your success criteria is related to how things look and/or you have an interest or expertise in visual design, some diagrams can be about the visual part of your IA. If it needs to look like something specific you can have a mood board.

#### Mood board

A mood board is a collection of (usually graphical) references to create something new and get inspiration (like if it was an IA but actually human and traceable). Very common in visual design industries like animation and videogames.

To set an example here you have a small animation from [Stefano Perelli](https://thewinterguest.artstation.com/projects/xEgdr):

{%youtube rGtEHTAkOb4%}

And here you have the moodboard that was done **before** doing the animation to find the specific style of the animation


If you see the video you will recognize the colours, the style and certain gimnics that were used in the animation.

In your case you can do the mood board (if it applies) to find which colors, which aesthetic are you going to use later.

#### When to use this diagram

When you have a SC that specifies a certain aesthetic (webpage based in among us or videogame).

### Architeture diagrams

In this type of diagrams you need to specify **where** are the data being computed. Is it working all in local? Do we have several servers working together? In this case we don't care about the data flow but where are the different elements that we're conneting to.

In this diagram we explain the main elements of our product and their relationship. Are we having a DB (Database) in SQL (or MongoDB)? We need to know.

Also I'm asking that in this diagram you should specify where are the programs. The diagram should answer to the question

**Where is this program being run?**

#### When to use this diagram

The only exception for not using this diagrams are applications that are standalone that everything they do they do in local without interacting with anybody.

This diagram shows algorithmic thinking, so if you can fit one of this in your IA, include it.

### Functional diagrams

This is very common in all the IA. Here you explain what are the process or processes that happen in your IA, what are the main algorithms that you have. Remember that the reader should be able to **read** these diagrams and understand what's happening.

#### Data validation diagram

In the case that your Internal has some validation of data (is this email correct and in my database and related to something?) you can use this type of diagram. Only applies if you're going to process something not trivial.

#### Answer decision diagram

Appropiate for bots//TO-DO

### Database diagrams (DB Scheme)

(this shema is clear to read but has some weaknesses)

If your IA has a DB (very common) you should have diagrams about its schema. That is how the data is ordered. If you can, add some text boxes that include some CLEAR INFORMATION about the purpose of the tables and their relationships.

If you're using a NoSQL DB I want to know the underlying structure of the DB that you're using. So you will need to show it. [Here you have more infomation](https://www.integrate.io/blog/the-sql-vs-nosql-difference/)

If you're accessing to several DB (like one that it's yours and other that is an extenal API) we can have seveal of them if they are relevant to your product (like the object model of openStreetMap) and how they map together.

### Data flow diagrams

In this diagram we want to know how the different parts of the IA (DB, different programs, including external APIs) interface with each other and **what type of data are they sending**.

### Screen designs

Navigation maps are useful in the case of applications that have a front end (something that can be seen by the user). Here you draw (hand draw, mock-up or else)

Here you show all the possible screens (or pages). They don't need to work, they need to show how are going to be the elements displayed. Login pages, dashboards, etc.

### Web maps (or navigation maps)

Navigation maps are useful in the case of applications that have a front end (something that can be seen by the user). Here you draw (hand draw, mock-up or else)

Here you show all the possible screens (or pages)

### Connetion diagrams

(For products that have hardware parts)
//TO-DO

### Planning diagram

In this diagram you split your product in different elements (programatic or not) and which tools are you using for each of it. This maybe implied in other diagrams (For example in data flow) but it might be useful when you're working with different parts that work together or parts that don't involve programming (such as creating user documentation or cases)

#### When to use this type of diagram.

This diagram is useful in general but in some cases is embedded in other diagrams. It's

### Chronogram

A chronogram (or Gantt diagram) is a diagram that you can use to program yourself during a certain amount of time.


The basics is that you're going to divide the IA into different tasks (also useful for the Record of Tasks) and you program yourself.

On the rows you may have:
-Different criteria documentation.
-Different steps in your IA. These steps are relevant when your IA has different parts that need to work together or different steps.

You can add in general the different milestones and steps that you think you're going to have. Also is specially useful to program yourself during the summer between DP1 and DP2.


#### When to use this diagram

When you have an Internal with different pieces (physical or different programs) that you need to develop at different times.

Also if you want to have a good grisp of time control over the IA.

In general this is an optional diagram.

### Bill of Materials (BOM)

A bill of materials is just a table with the materials that are needed to do a certain process. It's a table where you specify which elements do you need to buy/get in order to do something.

_Example of a BOM of a window_

My suggestion is to include as columns "part, description, cost"

#### When to use this diagram

In CS IA this is **only** for IA with physical objects (Arduino, microcontrollers, robotics, paper). If you're not making something like this you don't need to do it, but if you're planning something physical this diagram is quite useful (even if it doesn't show algorithmic thinking)

## Are these designs final?

No. And if you iterate through the design you should include the new diagrams and keep the old ones (you can differenciate them stating which version was before the other).

If you don't change the product you can have different stages of diagrams.

## What I'm asking (May 25, I need to update this for May 26)

I'm asking a zip file with

Criterion A.pdf
Criterion B.pdf
Record of tasks.pdf //different pdf using the template. 
Solution state.pdf //not for the final IA

In technology demostration you should write and screenshot your progress in the code. The tutorials that you have used, the progress that you have made actually doing the solution. This part is key so you have a good summer where you don't have to worry about the IA.

:::info
**Readability**

Remember that diagrams should be READABLE

If you put a diagram that I need to zoom it to read it, I will **ignore** it.

Example of unreadable diagram that seems more a vision test than an actual diagram:

:::

## The boundaries

From the IB guide


### Other reference

https://ib.compscihub.net/wp-content/uploads/2015/04/B.pdf