# Internal Assessment: Criterion C :::success This is part of a series of notes on the Internal Assessment on the Diploma Program of IB. **Last assessment 2026. (old syllabus)** You can check the index with all the others and the rest of teaching material [here](https://hackmd.io/68GDv_RgT-yh9oERMvdnFw#Internal-Assessment) ::: This criterion is 12 marks out of 34 so is the _biggest_ one. It's holistic. This means that even if we have a document that will be criterion C, this criterion will be assessted with the project in general. The idea is that has to be a project that is complex and the student shows off their knowledge about computer science. If you're making a simple calculator you're not going to get far in this part. If you're making a complex transluminal subtanciation then you may go very high. To show it off you have several ways - The first way is the number and the complexity of features that you're dealing with (The success criteria in criterion A). The more the merrier, the more complex the better. - How did you achieve those features. The more template or already cooked, the worse. For demostrating that you have criterion C document. ## Criterion C.pdf In criterion C I suggest to talk about from 1 to 4 candidates of complexity. The most interesting, challenging and complex part of your project. :::info For the delivery of the end of DP1. I want at least those candidates defined. Which are the parts of the code that are the more interesting. ::: In each part of the code (that you can have a subtitle like "data base linking" or "image processing") you need to talk about what is the problem, how did you solved it and why that solution is a good one (maybe with a little discussion from other possible solutions) At the end of criterion C you need to state the bibliography. All the material that you need to reference - All the tutorials that you have followed - All the templates that you have started from - All the frameworks that you have used - All the stackoverflow solutions that you have implemented - All the assets references (if applicable) :::warning Assets are any kind of images/sounds/textures/icons that you use. You need to reference them also. ::: ### Common candidates for Criterion C * Persistence (how the data is saved and retrieved) * Dates (they are usually quite complex, depending on the IA) * APIs. The use of APIs is usually not very complex but can serve in some cases. ### Suggested format for the Criterion C.pdf Choose a specific part of your product. Not all, one feature that is particulary difficult or where you needed to apply a lot of ingenuity. I suggest to have from 1 up to 3. And for each you should have * A title * Description of the problem (functional and technical) * Description of the solution (technical) with code. * Rationale of the solution _(Why your solution is so cool)_. Usually comparing with other discarded solution is a good idea. :::info **Question: What do I mean by a problem?** Is this the client problem? What we mean by this is a problem, an issue that you have found while developing this solution. For example, if we have a calendar for a person, one problem that we could have found is _where_ and _how_ do we store the information of that calendar (this is called persistence). ::: Here I expect that you explain using technical lexicon how the element work and what other possibilities could have been implemented and why you chose the one that you're using. ## Word counting This is one of the criteria that has word count. I reccomend to include the word count at the end of the document. The word count of this criterion should be between around 1000 words approx. (excluding bibliography, quotes, screenshots of code) ## The boundaries From the IB guide ![imagen](https://hackmd.io/_uploads/B10oIamf1x.png) ![imagen](https://hackmd.io/_uploads/Hk638p7M1x.png) :::info The **really** difficult part here is get this **high complexity and ingenuity** ::: Also _remember_ that the criterion C is a bit more holistic, so it's not only evaluated using the criterion C.pdf but the project as a whole. It's not going to be the same using a CLI program of quizes than a generator of 3D scripted animations connected to weather databases. ## Common topics that I'd avoid * **Explaining the choice of the programming language/framework.** This should be included in the rationale in criterion A. If you want to explain the inclusion of a particular library it's fine. * **Explaining the choice of IDE** (the program to program). It's not programming so it's not relevant as is not usually relevant the device that you're using to develop. ### Common topics that I'd add * How have you handled persitency? * Have you used observables? What is an observable? Can you explain what is it _in your code_?