| |
| META TOPICPARENT |
name="CSC122SylF2021" |
Software Development Report Requirements
Overview |
| |
| Problem summary |
✔ |
✔ |
| Implementation requirements |
✔ |
✔ |
| System design |
✔ |
✔ |
|
|
<
< |
| Testing plan |
✔ |
|
| Testing report |
|
✔ |
|
>
> |
| Execution instructions |
|
✔ |
| Acceptance Testing plan |
✔ |
|
| Acceptance Testing report |
|
✔ |
|
| |
| Estimation of time required |
✔ |
|
| Analysis of time used |
|
✔ |
| Identification of outside resources used |
✔ |
✔ |
|
| |
| Ethical report |
|
✔ |
| Future improvements |
|
✔ |
| Lessons learned |
✔ |
✔ |
|
|
<
< |
|
>
> |
| Improvement of work over last time |
✔ |
✔ |
|
| |
- If a given category is not appropriate in a given instance, still list the category and include "not applicable".
- Proper grammar and quality layout are required.
|
| |
-
- For object-oriented code:
- A UML diagram containing all classes. Each class should include all field variables and methods properly documented
- For any non-trivial methods, pseudo code should be included in the system design.
|
|
<
< |
- Testing plan: A testing plan can include the following components
|
>
> |
- Execution instructions. This includes the steps (starting with compiling) to run the program. Include what is needed to highlight any special features included. Assume the program will be run on a lab machine unless otherwise stated
- Acceptance Testing plan: An acceptance testing plan are the tests that are used by the "user" to confirm if the software is acceptable A testing plan can include the following components
|
| |
-
- Sufficient test cases
- tests of individual components of the software
- simple cases
|
| |
-
-
- Input used (specific values not a description). If the values are long enough, a reference to the file is sufficient if the file is included when submitting the work
- Expected output (specific values not a description).
- This is often formatted as a table.
|
|
<
< |
- Testing report: This includes everything in the testing plan along with the achieved results and an indicator if the test was passed for each test case. If the software it is not at a stage where it can be tested, that should be explained here (in addition to the testing plan that would be used if the software could have been tested). This is typically the previous table with two additional columns
|
>
> |
- Acceptance Testing report: This includes everything in the testing plan along with the achieved results and an indicator if the test was passed for each test case. If the software it is not at a stage where it can be tested, that should be explained here (in addition to the testing plan that would be used if the software could have been tested). This is typically the previous table with two additional columns
|
| |
- Estimation of time required: This is a good faith estimate as to how long it will take to write the software. This can often be a single sentence.
- Analysis of time used: This is a statement of how long it took to write the software. Dividing that amount into the times spent designing, coding different components, testing, etc. is a good thing to do esp. as the software get more complex. This should also include a comparison to the estimation is one was previously made. This is normally a very short paragraph.
|
|
<
< |
- Identification of outside resources used: This is required. If no outside resources were used, the it should state that no outside resources were used. Use of the textbook or lecture notes need not be documented. The same with using provided code. However, in the code itself, any outside code (including provided code) needs to have a comment indicating where it came from. This needs to include details as to what help was received. An example would be John Smith helps me understand how to declared a 2D array to be used for my tic-tac-toe board. Jan Doe help me with the logic to determine who won.
|
>
> |
- Identification of outside resources used: This is required. If no outside resources were used, the it should state that no outside resources were used. Use of the textbook or lecture notes need not be documented. The same with using provided code. However, in the code itself, any outside code (including provided code) needs to have a comment indicating where it came from. This needs to include details as to what help was received. An example would be John Smith helps me understand how to declared a 2D array to be used for my tic-tac-toe board. Jan Doe help me with the logic to determine who won.
|
| |
- Potential security risks: This is a short bulleted list of potential security issues if there are any. Otherwise, indicate that none have been identified.
- Security report: This is a bulleted list of all known possible security issues associated with the software and how they were address, if they were addressed. Any unaddressed issues should be identified with a short statement as to the risk involved.
|
|
<
< |
- Potential ethical implications: This is a short bulleted list of potential ethical issues if there are any. This includes ways the software could be used for good and/or bad. Otherwise, indicate that none have been identified.
- Ethical report: This is a bulleted list of all possible ethical issues (both good and bad) associated with the software.
|
>
> |
- Potential ethical implications: This is a short bulleted list of potential ethical issues if there are any. This includes ways the software could be used for good and/or bad. Otherwise, indicate that none have been identified.
- Ethical report: This is a bulleted list of all possible ethical issues (both good and bad) associated with the software.
|
| |
- Future improvements: This is a bulleted list of things could be improved in the software. This is not optional. There is always room for improvement. This can include what you would have liked to accomplish if you had the time. For the tic-tac-toe example it could include add graphics.
- Lessons learned. This is a bulleted list of at least two things you learned while writing the code.
|
|
<
< |
- Improvement of work over last time: This is a list of how you are improving based on feedback from your last assignment. It could be as easy as I put a banner comment in all files. Or I have started to declare and initialize my variables in two statements. Your goal is to show that you have learned something from the last assignment (especially the feedback) and are applying in the next one. This can be skipped only for first assignment of a given course.
|
| | \ No newline at end of file |
|
>
> |
- Improvement of work over last time: This is a list of how you are improving based on feedback from your last assignment. It could be as easy as I put a banner comment in all files. Or I have started to declare and initialize my variables in two statements. Your goal is to show that you have read the feedback and improved based on it. This can be skipped only for first assignment of a given course. If you have not made any improvements (either because none were necessary or you did not do it, indicate that here)
|
Copyright © 2008-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.