# Criterion B

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

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

:::

The Internal is going to be a long journey of creating a solution to a problem using computational thinking.

_mandatory image of the computational thinking process_

## Decomposing

Here we want to decompose our project into different parts to plan it.

If we don't do it, we risk that we're going to be overwhelmed by the task and we get paralyzed, specially if we don't have experience in these type of project (something that is common since you're here to learn).

The Success criteria are going to be helpful here

:::info
The success criteria that we wrote in criterion A are not written in stone, if when we develop the project in criterion B we find that we should revise any Success Criterion we should do it, it will improve the
:::

### How to decompose it?

It depends on the specifics of your project. We're going to use the word **modules** or **components**

### Modularity

_modulor by Le Corbusier_

_Lego Bricks_

Modularity is the concept of dividing the code (the program) into modules so each of the modules can be re-used in other projects and also can be worked on parallel.

This doesn't mean that the code itself is more efficient in doing its job! It means that can be more efficient to divide the task into teams or reuse code. In the case of the internal to subdivide the project in smaller more manageable uits.

This modules should be able to be programed and tested (later in criterion C) independently but the project usually needs them all to properly *work*.

The decomposition can be

* Because several parts are coded in different languages. Usually a web application with a DB has this distintion so the web application should be _at least_ one module and the database should be _at least_ one module.
* Front-end / back end. One of the most common ways of separating a project (specially in web applications but not only on them). Front end refers to the logic of how something is "painted" to the user (is the button green or red?) and the back end is usually the part that is in touch with a DB or other internal logic.
* In case of games, usually there is a module that should be the menu-system (maybe it's done by the engine but maybe not), other should be the GUI integrated when you play, other can be the logic that happens inside the game (maybe a script) and that could be sub-divided.
* In case of any kind of communication with external parties (using an API to get some data) that should be at least one module for doing that and process the data correctly.

Modules, depending on the circunstances can be big or small. If they are too big, you should decompose this big units into smaller modules.

### How many modules do I need?

It _depends_. If you want to have a good grade, the more granulated, the better. If you decompose your Internal in just 2 modules that could be that either the project is too simple (so we should expand it) or the decomposition is too broad (so you should analyze a bit better and have a more detailed decomposition).

### Are my modules the correct ones?

The idea is that we're going to iterate through it. Probably you may have a draft and once you research through code libraries you will have a more detailed idea.

### Are they connected to the Success criteria?

Yes, but they don't have to be linear (that one Success Criteria is one Module). One way of explaining this is using a table like this:


Here you can see thet Module A is needed for SC1, SC2 and SC3. But SC1 to mark it as _done_ we need to develop Module 1 AND module C.

In some cases we may find that the SC are more linear and it's also ok


:::warning
:warning: But if we have too few modules and they overlap too much, then is when we need to create sub-modules

:::

### What do I need to write/draw?

As always, it _depends on your project_. Remember that I use module and component as synonims.

Option 1) Do a table with the different modules/submodules that you have

Option 2) Write a paragraph about these division in components. (Constult with me if you're going to use it)

Option 3) Create a diagram that shows the different modules

#### Example diagaram

Here you have an example of how I'd divide a project into different subprograms. In this case this is just an example and it's incomplete, done in a few minutes, but it's useful as an example.


#### Other types of diagrams

##### Web Aplication

In a web application we may see that there are going to be different parts that require programming, usually the front end, the back end and the databases. The diagram should reflect all these parts. If you don't understand them, now it's the time to read about them!

For example if you're using react, this is a good place to start reading https://react.dev/learn/thinking-in-react

If you're using python with flask you should follow this tutorial and try to understand what's happening underneath to make a diagram https://flask.palletsprojects.com/en/stable/tutorial/

:::warning
:construction: This is a part under ever construction so, when you're done with this please email useful elements so I can use for examples and resources :construction:
:::

##### Email processes

For this type of batch programs, it's easier to understand how the data is going to flow to identify the different parts that need to be developed.

##### Games

If you're using a Object Oriented Programming framework (or similar) like in Godot(https://docs.godotengine.org/en/stable/tutorials/best_practices/what_are_godot_classes.html) you may need to write what are the classes/objects that are going to be the main focus of your project (the ones that you're going to implement or expand).D

## Planning

The planning is a complicated part because you've never done a planning like this.

The idea is that, once you have decomposed your project into smaller parts, you need to plan on WHEN you're going to work in them.

For doing that you have already some constraints that are **my** constraints with the class.

There is going to be a deadline at the end of Term 2, at the end of Term 3 and something that may happen at DP2 Term 1 (Also known as T4). The written feedback will be on Christmas of DP2 and then you will deliver the final project in January of DP2.

But within these constraints you will need to do the planning of the full Internal Assessment.

### The design cicle

So in a project like this we need to follow the following steps

* Analyze the problem (this should be already done in criterion A but sometimes could be improved)
* Research for solutions and how to apply them (this should be partially done, but now we're making sure that is done)
* Plan when to do each of the parts
* Design the specific parts of the solution.
* Develop the solution itself.
* Test if the solution works.
* Evaluate the process.

Rinse and repeat.

This may happen in big scale or at smaller scale but this process is the same. And the IB wants you to plan this.

#### Example of the design cycle in a smaller scale

Imagine that we have booking system (Of the Aula Magna, for instance) and we want to add an email system. This will send emails as remainders to people who have booked. This is not the whole Internal in this case, this would be just one of the **modules**.

* We need to analyze the problem itself: Do we need to write emails or also read them?
* We need to do research. Which libraries of code am I going to use? Which ones work better or can be added to my project?
* We need to plan ahead how much time are we going to spend to do this part
* Take some time to go with the design of the specifics of the solution.
* We actually need to develop this integration, to implement it in our program.
* Then we need to test if works correctly or not.
* Finally we evaluate to what extent does it work. If it's not working then we need to go back any steps (continue development, do some replanning, try to find another implementation, even try to analyze the problem from other perspective)

### Do I have to include also writing the different criteria?

The IB is not explicit but it wants you also to write the part of test, evaluation and planning. So I'd add the writing of the pdfs as part of the process.

Probably I wouldn't include the development journal because it's a constant that you should already keep updated, but if it helps you to have specific dates to keep it updated, you can add it to any diagram.

### How do we do it?

You need a list of tasks that you need to do. You can go by module or by SC, and there also going to be more general tasks (like the final evaluation, recording the video). Once you have a good and detailed lists (With groups and so on) you open a calendar and start setting what is going to happen when.

For this there are 2 approaches (both valid) that I'm going to present you

### Gantt diagrams

Gantt diagrams are planners. In one axis (usually horizontal) are dates (weeks, days, months) and in the other you will find the tasks (usually in the vertical one)


For this project I suggest to use Weeks (so March week 1, week 2, etc)

https://ganttchartmaker.com/

#### Example from previous syllabus

One student from the previous syllabus did this:


For our porpuses is not bad but lacks detail regarding months and dependencies. Also in the new syllabus the reference to the Success Criteria needs to be explicit.

### Agile checkpoints

https://www.atlassian.com/agile/scrum/sprints

Another option is to divide the project in different sprints.

Every x weeks you should have done any of the modules, or any of the success criteria. So you can create a table with the different milestones (or different tables) with the information of **when is going to be finished the milestone** and what requirements and elements are going to be developed there. Also what SC are related to this Milestone.

A fast example could be something like this.


I personally prefer Gantt diagrams, but I give you the option to do it usinge Agile (also known as SCRUM) if if suits you better.

## Grading from the IB guide



## The delivery

This criterion should be added at the end of the Criterion A in the $Your_surname, $your_name - Internal Assessment.pdf

The advancements done for this should be added in the development journal ($Your_surname, $your_name - Development Journal.pdf)