| 20 | | |
| 21 | | |
| 22 | | |
| 23 | | * Initial tests (Test Driven Development, Research Tests etc. |
| 24 | | )}} |
| 25 | | |
| 26 | | * Bug Fix - |
| 27 | | |
| 28 | | {{{ |
| 29 | | Design of bug fixes is similar to Coding tasks' design, but should also answer the questions why does this bug appear, which part of the code is guilty for the wrong functionality (what was wrong with the code, why it was not suitable). Design also contains auto-tests that prove bug wouldn't be presented after implementation. These tasks should be designed by a developer. |
| 30 | | * In which module did the bug appear |
| 31 | | * In which part of the code did the bug appear |
| 32 | | * Required libraries |
| 33 | | * Implementation methods, suggested algorithms, etc. |
| 34 | | * UML diagrams (class diagrams) where needed |
| 35 | | * Initial tests |
| | 20 | * Bug Fix |
| | 21 | Analysis of bug fixes should explain what the problem is, in which module, when it appears. |
| | 22 | * Overview - explains the mis functionality in a sentence. Describe what happens and when. |
| | 23 | * Requirements - Here should be listed requirements of the result - what is desired functionality, what should this element have, etc. |
| | 24 | * Task result - In this section should be listed what is the result of the task. For these tasks it will be code but depending on task may also contain diagrams, graphics, etc |
| | 25 | * Implementation idea - Brief overview of implementation methods, suggested algorithms, etc. |
| | 26 | * Related - Here should be listed related tasks that might be useful for solving this task. You may also point to previous and next revisions of the same task, useful external links, etc. |
| | 27 | * How to demo |
