Criterion B
Section 1
Defining the Problem: Answer the following questions related to the problem in your design folder. (100-200 words) INDIVIDUAL
- What am I trying to solve? (define the problem and describe the program you will create)
- Who could potentially be the target audience?
- What tools will I use? (a computer is not a tool!)
Important note: You really need to dig into the problem beyond what has been provided to you in the project documents.
Section 2 – PARTNER
Specifications, Design Overview, and Test Plan (No word count applies)
Section 2a: Design Specifications
You will be creating a solution to your client’s or the target audience’s problem. The first part of this process for you will be to come up with a list of design specifications (requirements the solution should include). The design specs are meant for you to decompose the project into smaller sub problems. You will then create a test for each subproblem to determine whether you’ve completed that task.
The specification should include specific and testable criteria that will help you know if you’ve completed the project successfully. Follow the following formatting:
Design Specification Table Example:
| Design Specification | Test Plan |
| (GOOD SPEC) Data will be read from the file one line at a time in the readFile() function of the Histograms file. | (GOOD TEST) Input: a testing file called haiku.txt Expected Output: I will print each word read and compare to the original text. |
| (BAD SPEC) Make a variable | (BAD TEST) I will look at the file and check that a variable is there. |
| (BAD SPEC) The program will be aesthetically pleasing. | (BAD TEST) I will make sure that the program looks good. |
| (GOOD SPEC) After reading from a file the program will count how many times a score appears within a range. | (BAD TEST, not testable) I will print and make sure that the count is ok. (GOOD TEST, this is testable) Input: a testing file called haiku.txt and a number of bins of int’s from the user Expected output: Bins 1, 2 and 9 should have 1 count, while all other bins should have X count. |
| (GOOD SPEC) The program will calculate the average size of a tumor. | Input: For a sample data of 3 integers 10, 9 and 8 Expected output: The output average will be 9. |
| (GOOD SPEC) The program will allow the user to search for the mean rating for any user in the dataset. | Input: User 1 Expected: User 1 mean rating is x.xx |
Section 2b: Design Overview
In a table, explain each part of your project. For example, if your project has three different files, you’ll want to explain what each one does. You’ll also want to explain the contents of test files and text files that you will use.
Example:
| File Name | Explanation | Function Name and Function description |
| Histogram.py | It contains a function to read from a file and create a histogram that can be printed on the console. | createHistogram() : description readFile() : description createBins() : description |
| Main.py | Runs the program by creating a new instance of Histogram, asking the user for input, and calling createHistogram(). | NA |
| HistogramTest.py | Runs tests to check the output of the Histogram function, makes sure the file is being read correctly and <insert function names> work well. | createHistogramTest() : description |
| Haiku.txt | It contains a simple set of text to be able to test the program. The contents don’t make much sense, but it helps to understand whether different functions work correctly. | NA |
Section 2c: Design Plan
Iterations 1:
For each design spec, you will want to have pseudocode (example) or a flowchart ( thorough example, quick example, better example, best example). If you would like to use a different format than the examples, you’re more than welcome. A flowchart shows the progression of steps that you will take to solve each subproblem/design specification. Pseudocode can be used instead of a flowchart, to explain algorithms in plain English. Each line doesn’t need to correspond to one line of code, you can make generalized statements like “read from a file with readlines()”.
You may also combine different functions into combined flowcharts; just make sure to make it clear what your plan is and what design specs you’re tackling.
Annotate the entire design in enough detail for your peers to follow and understand.
Iteration 2:
You must have at least two iterations of your design. Include both iterations in your submission. The iterations can be labeled as “Iteration 1” and “Iteration 2”. Your second iteration can be your final solution’s logic. Make sure to get feedback from your peers before starting iteration 2 of your design.
Section 3
Design Evaluation (200-300 words) – INDIVIDUAL
At the end of your design document, include an evaluation of your Design Plan. Make sure to include feedback from at least two groups that helped you change your first iteration of the Design Plan.
You should also include at least three limitations/restrictions about the original design that were improved in future iterations.
Make sure to include at least three limitations that you found in the first Iteration. Limitations can be related to logic mistakes, output mistakes, or format mistakes (your flowchart didn’t make sense).
Suggested Timeline Of Work
- Read the project’s instructions.
- Create your design overview. Explain each file and its functions.
- You don’t need to explain the test files if your project has a test file.
- Create success criteria. Think “what will my product be able to do once I’m done”. Some projects will use function explanations are success criteria, others will be more general such as “the snake will grow when the head touches the food”.
- Create pseudocode or a flowchart for each success criteria.
- You may combine different success criteria into one pseudocode snippet, but be clear about which success criteria are being represented.
- Get feedback on your pseudocode or flowcharts.
- You can get feedback from group members or other peers.
- Create a second iteration of your pseudocode or flowcharts.
- We understand that sometimes your initial design won’t change much. That’s ok, just make sure to make it clear to show what did change.
- Write your design evaluation.
- Turn in your project.