Criterion B: Solution Overview
Criterion B is the blueprint for your entire project. It involves creating a detailed design overview, maintaining a thorough Record of Tasks (RoT), and developing a comprehensive Test Plan. This criterion shows your ability to translate planning into a structured, functional design while keeping a clear record of your progress.
Key Components of Criterion B
1. Design Overview
What It Is: The Design Overview is a comprehensive visual and structured representation of your solution’s architecture, demonstrating your algorithmic thinking and the range of techniques you plan to use.
How to Create It:
-
Structure Chart: Include a structure chart that breaks down your solution into its key components and shows how these components interact.
-
Detailed Layout Design Sketches: Provide clear drawings or sketches showing what each version/stage of your user interface (UI) will look like. Include multiple iterations if applicable to show progression.
-
System Flowchart / Data Flow Diagrams (DFD) / UML / Entity-Relationship Diagram (ERD): Develop a high-level abstract flowchart of your program that shows the overall process flow. This should include UML diagrams, DFDs, or ERDs to illustrate the data flow and relationships between different components.
- Algorithmic Thinking Evidence: Provide multiple diagrams or pseudocode snippets as evidence of your algorithmic thinking. Include:
- System Flowchart: Show the abstract view of the entire program.
- Flowcharts for Key Algorithms: Include detailed flowcharts illustrating the complex algorithms used in your project.
- Pseudocode: Provide pseudocode for complex algorithms, annotated to explain each step of the process.
- Data Structures Diagrams: Illustrate the data structures you plan to use (e.g., arrays, linked lists, databases). Ensure these diagrams show how data will be organized, accessed, and manipulated.
- Annotations: Include multiple annotations for the complex techniques, highlighting your algorithmic thinking for each part. Explain how these designs will address the proposed product identified in Criterion A.
Important Considerations:
- Reference to Criterion A and RoT: Your designs must directly refer to the proposed product outlined in Criterion A and be consistent with the Record of Tasks (RoT).
- Detail and Functionality: The designs should be detailed enough to indicate how the product will function. Avoid generic or superficial designs-show the range of appropriate techniques and original thinking that will be used in the development.
Example: If your project involves an inventory management system:
- Structure Chart: Break down the system into modules like user authentication, inventory management, reporting, etc.
- UI Sketches: Show sketches for the login screen, inventory dashboard, and report generation page.
- System Flowchart: Illustrate the overall process from user input to database interaction and report generation.
- Flowcharts for Algorithms: Detail the algorithm for sorting inventory items or handling stock updates.
- Pseudocode: Provide pseudocode for the algorithm managing stock levels.
2. Record of Tasks (RoT)
What It Is: The Record of Tasks (RoT) is a detailed log of all significant steps taken during the project, demonstrating the progression of the solution over time.
- Use the IB-Provided Form: Use the official IB Record of Tasks form, ensuring it is consistently updated throughout the project.
- Include Around 50 Tasks: A thorough RoT should include around 50 tasks, covering all stages of the Systems Development Life Cycle (SDLC):
- Planning and Research Stages: Document initial research, client consultations, and decision-making processes.
- Designing Stages: Include the creation of the design overview, structure charts, UI sketches, and algorithm development.
- Development Stages: Log coding progress, including file I/O, algorithms, data structures, and GUI implementation.
- Testing or Prototyping Stages: Record testing activities, prototype iterations, and bug fixing.
- Implementation Stages: Document final product preparation, user training, and feedback sessions.
- Final Feedback and Reflection: Include the final feedback session with the client and your reflection on the project.
- Interaction with Client: Include evidence of at least 4 interactions or check-in sessions with the client throughout the SDLC. Document how client feedback informed the development of the solution.
- Time Estimates: Include a “Time Estimated” column, filled in with the estimated number of days or weeks for each task.
Example RoT Entry: (General Structure)
This table provides a general structure for documenting the Record of Tasks (RoT) in your Internal Assessment. Your work should be unique and tailored to the specific development process of your product. Use this as a reference, but ensure your tasks reflect the distinct requirements and activities of your individual project.
| Task Number | Planned Action | Planned Outcome | Time Estimated | Target Completion Date | Criterion |
|---|---|---|---|---|---|
| Planning | |||||
| 1 | Identify the problem and client/advisor | Clearly understand the problem and the client/advisor’s needs for the solution | __ days/weeks | __//__ | A |
| 2 | Teacher approval of topic and client/advisor | Obtain teacher approval to proceed with the chosen topic and client/advisor | __ days/weeks | __//__ | A |
| 3 | Justify rationale for chosen product | Provide a rationale for the chosen solution to address the identified problem | __ days/weeks | __//__ | A |
| 4 | Define success criteria | Establish measurable success criteria to evaluate the solution’s effectiveness | __ days/weeks | __//__ | A |
| Design Overview | |||||
| 5 | Create preliminary designs | Develop initial designs, including UI wireframes and data flow diagrams | __ days/weeks | __//__ | B |
| 6 | Develop detailed design | Create detailed designs that include system flowcharts, data structure diagrams, and pseudocode | __ days/weeks | __//__ | B |
| 7 | Submit solution overview for feasibility | Submit the design overview to the teacher to check the feasibility of the solution | __ days/weeks | __//__ | B |
| 8 | Refine designs based on feedback | Adjust the designs for clarity and ingenuity based on teacher and client/advisor feedback | __ days/weeks | __//__ | B |
| Development | |||||
| 9 | Develop the product | Begin coding the product according to the detailed designs, implementing core functionalities | __ days/weeks | __//__ | C |
| 10 | Test the product (unit testing) | Perform unit tests on individual components to ensure they meet the design specifications | __ days/weeks | __//__ | C, D |
| 11 | Integrate and test complex features | Integrate more complex features and conduct testing to ensure they function as intended | __ days/weeks | __//__ | C, D |
| 12 | Cite sources | Ensure all sources and external code libraries are properly cited in the product | __ days/weeks | __//__ | C |
| Functionality | |||||
| 13 | Conduct functionality testing | Test the product against the success criteria to verify full functionality | __ days/weeks | __//__ | D |
| 14 | Gather client/advisor feedback | Present the functional product to the client/advisor for feedback on usability and functionality | __ days/weeks | __//__ | A, D |
| Evaluation | |||||
| 15 | Evaluate product against success criteria | Conduct a thorough evaluation of the product to determine if it meets all success criteria | __ days/weeks | __//__ | E |
| 16 | Recommend further development | Based on evaluation and feedback, provide recommendations for further development of the product | __ days/weeks | __//__ | E |
3. Test Plan
What It Is: The Test Plan is a detailed guide for testing your solution to ensure it meets the success criteria defined in Criterion A.
How to Create It:
- Address All Success Criteria: Ensure the test plan covers every success criterion from Criterion A. Each test should demonstrate what input will be used, the expected outcome, and what constitutes a successful test.
- Multiple Columns: Include the following columns in your test plan:
- Test Number: Unique identifier for each test.
- Description (with related Success Criterion number): Briefly describe the test and include the success criterion it addresses.
- Input Data: Specify the input conditions for the test.
- Expected Outcome: Clearly state what the expected outcome of the test is.
- Actual Outcome: Record the result after executing the test.
- Figure/Reference: If applicable, reference any supporting evidence, such as screenshots or logs.
Example Test Plan Format:
| Test Number | Success Criterion (Related Number) | Description of Test | Input Data | Expected Outcome | Actual Outcome | Figure/Reference |
|---|---|---|---|---|---|---|
| 1 | 1. Add Inventory Item | Test adding a new item to inventory. | Name: “Laptop”, Quantity: 10 | Item appears in the inventory list. | Passed | Fig. 1.1 |
| 2 | 2. Generate Report | Test generating inventory report. | Click “Generate Report” button | Report PDF downloads and displays all items. | Passed | Fig. 2.1 |
4. Client Consultation Evidence
What It Is: Evidence of meaningful client interactions should be documented and included in the appendix.
How to Document It:
- Record in the RoT: Mention every interaction with the client in the Record of Tasks. Include details about how these interactions influenced the development process.
- Appendix: Include reports or notes from each consultation session in the appendix of your IA documentation.
Example: Include an appendix entry summarizing the client feedback session on the initial UI design and how it led to design adjustments.
Avoiding Common Pitfalls
- Superficial Designs: Avoid submitting incomplete or generic designs. The designs should show detailed algorithmic thinking and the techniques to be used.
- Lack of Client Interaction: Make sure to document all client interactions and incorporate their feedback into your design and development process.
- Insufficient Test Plan: Ensure that every success criterion has a corresponding test in the test plan.
Presentation and Formatting
- File Naming: Save the document as “Crit_B.pdf”.
- Clarity: Use clear, labeled diagrams and well-organized tables to present your design, RoT, and Test Plan.
- Annotations and Explanations: Include annotations in your designs and flowcharts to explain your algorithmic thinking and how the product will function.
IA Templates
Need help getting started? Download the Record of Tasks Template and Test Plan Template to structure your documentation. See all available templates on the Templates page.
Links to Other Criteria
For more detailed information on the other criteria, please navigate to the corresponding pages:
- Criterion A: Planning
- Criterion C: Development
- Criterion D: Functionality and Extensibility
- Criterion E: Evaluation
By adhering to these guidelines for Criterion B, you will create a detailed and comprehensive solution overview that lays the groundwork for the development of a functional, well-documented product. Your Record of Tasks and Test Plan will provide a roadmap for your project, ensuring a structured and systematic approach to development.