IB Computer Science (CS) HL Internal Assessment Example

What further consultation evidence could show that the client’s needs were refined over time, rather than captured mainly in one interview? Adding even one follow-up clarification would make the planning stronger.

The student’s use of SHA-256 for the master password and AES for stored passwords shows thoughtful security planning. These choices are directly connected to the purpose of the application, which strengthens the rationale substantially.

The rationale is well linked to the client’s actual pain points: the student clearly explains why a password manager is preferable to a spreadsheet for security and efficiency. This keeps the justification focused on need, not just on technology choice.

The consultation evidence is strong because the student includes direct interview detail about the current Google Sheets workflow and the security concern that passwords are not properly protected. That authentic client voice helps justify the project direction.

The student grounds the project in a clear client context by naming Mr. X’s role and responsibilities. This makes the problem realistic and shows the solution is being designed for a specific workplace need rather than a generic password manager.

The success criteria are broad and testable, covering authentication, CRUD actions, ordering, search, and encryption/decryption. This gives a strong basis for later evaluation because each criterion can be checked against observable behaviour.

The criteria reflect the client’s actual needs, especially the requirement that passwords remain hidden until intentionally revealed. That direct alignment between consultation and success criteria is a major strength.

The prototype section is useful because the student explains that the GUI mock-ups served as a visual guide during development. This makes the design overview purposeful rather than purely descriptive.

The sequence of GUI prototypes covers the major user journey from password creation to login and then into the main application. That breadth helps the reader understand the intended workflow before development begins.

The flowchart for password creation shows a clear decision path, including the check for matching entries before proceeding. This is a good example of translating a user requirement into a structured design process.

Consider adding short notes beside each flowchart to explain the purpose of the key decisions and outputs. That would make the design overview easier to follow and would more clearly show how each panel supports the final application.

The data dictionary is informative, but some field descriptions are very brief and do not fully explain how each field is used in the solution. More detail on constraints, relationships, and why each data type was chosen would make the database design clearer.

The submission says the tests will ensure the application functions as intended, but there is still no explicit task record or development log showing how the product was built over time. A dated log of steps, decisions, and changes would better demonstrate the development process.

The ERD would be stronger if the student briefly interpreted the relationship between the tables in prose. Explaining why the structure supports the password manager’s workflow would help connect the diagram to the design rationale.

The test plan is well structured because each test includes data, expected result, and a pass/fail outcome. That makes the tests repeatable and easy to check against the success criteria.

The ordering test is a strong design choice because it checks that accounts are displayed alphabetically using several example names. This demonstrates that the student is testing behaviour with meaningful data rather than a single trivial case.

The UPDATE explanation is well tied to the product’s purpose: changing account name, description, and password for a selected record. The student demonstrates that database updates are not isolated code, but part of the user workflow.

Consider adding brief source references directly beside code explanations, especially where the student adapts cryptographic or SQL techniques. Point-of-use attribution would make the documentation clearer and strengthen academic integrity.

The student explains the INSERT logic clearly, linking the code to the storage of a hashed password in the database. This is effective documentation because it shows both what the code does and why it matters for security.

The DELETE section shows effective use of a prepared SQL operation with a clear explanation of how the selected account is removed. That concise link between code and outcome supports the development strand well.

The explanation of the encryption key handling is too brief for such an important security feature. The student should clarify where the key comes from, how it is protected, and how it is reused so the reader can judge whether the approach is secure.

The SELECT explanation shows good understanding of how the login check depends on retrieving the stored hash before comparison. This is a strong example of documenting the purpose of a database query in context.

The student could strengthen this section by briefly justifying why AES was suitable here and noting any limitations of the implementation. That would show more mature evaluation of the cryptographic technique, not just description.

The AES explanation describes the basic steps well, but it does not specify the cipher mode or initialization vector strategy. For a password manager, that missing detail matters because security depends on more than simply using AES.

The hashing section is well explained and clearly connects SHA-256 to the security goal of protecting the login password. The student shows a solid understanding of why hashing is appropriate for a non-retrievable master password.

The bibliography identifies relevant sources, but the formatting is not fully uniform across entries. Consistent citation style would make the documentation look more polished and would make it easier to trace which source informed each technique.

The functionality evidence is still based on screenshots and written test outcomes rather than a video demonstration of the running product. That means the submission cannot fully show live behaviour under user interaction, which limits the strength of the functionality claim.

The test evidence does show the product performing a wide range of tasks, including authentication, creating accounts, searching, editing, deleting, and decryption. That breadth gives credible support that the application is functioning across its main workflow.

If a video is not available, the student should include a short sequence of screenshots with brief captions showing one complete user journey from login to deletion or decryption. That would make the functionality evidence easier to follow.

The inclusion of a view-password test is valuable because it checks a core feature of the system rather than a superficial interaction. This is a good match for the client’s need to hide credentials until intentionally revealed.

What evidence would most convincingly prove that decryption and retrieval are working for a fresh user session, rather than only in the tested scenario shown here?

The final test demonstrates secure retrieval and comparison of stored data, which is important because it checks the link between encryption, storage, and user access. This shows that the student is thinking about end-to-end functionality.

The flow from success message to opening the home page and closing the setup window shows good attention to user experience. This kind of state transition matters because it makes the application feel coherent rather than fragmented.

The error-handling description appropriately shows that unauthorized access is blocked. That is an important behavioural feature for a password manager because it directly supports the application’s purpose.

The evaluation would be stronger if each criterion included a brief reference to a specific test result or screen capture. That would move the discussion from general confirmation to direct evidence-based evaluation.

The evaluation table is thorough because it checks every stated success criterion rather than only a few examples. This gives the reader a complete overview of how well the product met the original specification.

The judgments are generally well supported by the product features already discussed, especially where the student links the evaluation to login security, account management, and encryption. That coherence makes the evaluation credible.

The recommendations section is still too limited in scope. One improvement is relevant, but the student should provide a broader set of realistic next steps so the evaluation shows deeper reflection on how the product could evolve.

The student could expand the recommendations by prioritising a few improvements such as auto-lock, stronger key management, backup/export, or search refinements. Explaining why each would help the client would make the section more substantial.

The client’s request for a copy-to-clipboard function is specific and actionable, which makes the feedback meaningful for future development. It shows the student has gathered practical advice rather than vague praise.

The client testing transcript provides useful positive feedback in the client’s own words, especially the comment that the application is a big improvement over Google Sheets. This is valuable because it captures genuine client response rather than only the student’s interpretation.