| 1 | | Design should be started after the Analysis for this revision has passed review (>=3 points). A task with non-reviewed analysis and design gets review at implementation. In that case the mark is for design and analysis, too. Design section for each task should cover implementation method for this task revision (what has to be done exists in Analysis section) - how it should be implemented. For each task in Design section, please include: |
| 2 | | Depending on task type design section should contain |
| 3 | | * Coding tasks - Design of these tasks should describe technology that will be used for reaching task's requirement. These tasks should be designed by a developer. |
| 4 | | * Required libraries |
| 5 | | * Implementation methods, suggested algorithms, etc. |
| 6 | | * UML diagrams (class diagrams) where needed |
| 7 | | * Initial tests (Test Driven Development, Research Tests etc.) |
| 8 | | * Bug Fix - 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. |
| | 1 | [[BackLinksMenu]] |
| | 2 | [[PageOutline]] |
| | 3 | |
| | 4 | '''IMPORTANT NOTE''': This document is being worked on. To see the latest approved version, go to [wiki:PLATFORM_STANDARDS_DESIGN?rev=17]. |
| | 5 | |
| | 6 | = How to make designs = |
| | 7 | This document contains requirements and guidelines for writing good designs. Here you will find information about what a design should look like for the different kinds of tasks. Rules for reviewing will be provided as well. When doing the design you should not forget the major guideline of this project: '''Work towards the goal! ''' |
| | 8 | |
| | 9 | == Task kinds == |
| | 10 | The design should answer the quiestion how the task should be done. It should provide instructions about used technologies, algorithms, etc. Different task kinds have quite different requirements for the design, which are listed here: |
| | 11 | |
| | 12 | === Coding task === |
| | 13 | The design of these tasks should contain the following: |
| | 14 | * a list of all the classes that will be created (with descriptions and class diagrams) |
| | 15 | * note that a class/method that is not supposed to be inherited should be declared final. |
| | 16 | * links to all the classes that will be changed (this does not include the classes that will be refactored due to the changes introduced) and what will be changed in them (e.g. new methods will be added). |
| | 17 | * an explanation of what properties will be used |
| | 18 | * this is because the designs rely heavily on the properties library. The latter also means that generally the classes created should be ProObjects or immutable and that the ProObjects should contain only properties and static final fields. |
| | 19 | * Implementation methods, suggested algorithms, etc. |
| | 20 | * UML diagrams |
| | 21 | * Initial tests |
| | 22 | |
| | 23 | There are subkinds of coding tasks with specific requirements for the design. These are: |
| | 24 | * '''External feature (visible from the user)''' - should |
| | 25 | * '''Researching a technology or a library''' - should |
| | 26 | * '''Internal feature (not directly visible)''' - should |
| | 27 | * '''Structure changes (refactoring)''' - should |
| | 28 | |
| | 29 | === Bug Fix === |
| | 30 | 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. |
| 22 | | * Software requirements - point which of the suitable tools will be installed and configured. |
| 23 | | * Maintenance - Design explains what should be done for meeting the requirements, links to tools that will be used, algorithms, diagrams and whatever is needed for an easy implementation. Depending on specific task, these tasks may be designed by developer or qa. |
| | 48 | * Software requirements - point which of the suitable tools will be installed and configured. |
| | 49 | |
| | 50 | === Maintenance === |
| | 51 | Design explains what should be done for meeting the requirements, links to tools that will be used, algorithms, diagrams and whatever is needed for an easy implementation. Depending on specific task, these tasks may be designed by developer or qa. |
| 30 | | * It would be better if the different task kinds were headings, instead of items in a bullet list. The first paragraph states that a task might be reviewed at implementation, which is not correct. Some other improvements might be made according to the [wiki:PLATFORM_STANDARDS_DESIGN_R1] task. --boyan@2009-01-12 |
| 31 | | * The first paragraph is totaly useless and it is just confuses the reader --pap@2009-01-15 |
| 32 | | * It should be noted that the design of coding tasks should point all afected parts of the code. not only the newly created. --pap@2009-01-15 |
| 33 | | * A good design should point out what classes/methods should be created. If you use the pro-lib you should say what kind of property you would use. --pap@2009-01-15 |
| 34 | | * Also I'd like to note that a reminder of the '''Work towards the goal. ''' rule should be added to every standard. --pap@2009-01-15 |
