| | 1 | == Workflow == |
| | 2 | |
| | 3 | === Diagram === |
| | 4 | |
| | 5 | Each taken task in the current sprint should pass trough the following phases described in this diagram: |
| | 6 | [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png] |
| | 7 | |
| | 8 | === Explanation Of States === |
| | 9 | |
| | 10 | * '''new''' |
| | 11 | * task is waiting to be taken, and someone to determine what should be done |
| | 12 | * '''analysis started''' |
| | 13 | * to learn how to write good analysis, see [wiki:PLATFORM_STANDARDS_ANALYSIS Platform Standards Analysis] |
| | 14 | * there should be at least one example of how to do one or more things that should be done |
| | 15 | * it should take not more than 0.25 of the task effort |
| | 16 | * '''analysis finished''' |
| | 17 | * it is already determined what should be done |
| | 18 | * the task is waiting for review. (Wait for the review of the analysis before starting the design otherwise your work can be for nothing!) |
| | 19 | * '''review''' |
| | 20 | * the reviewer looks through the analysis to see if it is correct(observing the [wiki:PLATFORM_STANDARDS_ANALYSIS] document and trying to improve it) |
| | 21 | * the analysis should apply to [wiki:PageTemplates/TaskPageTemplate#Analysis its template] |
| | 22 | * '''analysis ok''' |
| | 23 | * the reviewer decides that the analysis of the task is correct |
| | 24 | * '''design started''' |
| | 25 | * the implementer is designing the task or in other words tries to decide how it should be done |
| | 26 | * it is not compulsory but recommended that the design should be made by the implementer |
| | 27 | * it is recommended that the design should not be made by the analyzer of the task |
| | 28 | * designing is not only getting an idea of how to do something but understanding the concept, step by step |
| | 29 | * for many tasks the design phase should take most of the time |
| | 30 | * '''design finished''' |
| | 31 | * it is determined how the task should be done |
| | 32 | * it is designed and is waiting for review. |
| | 33 | * '''review''' |
| | 34 | * the reviewer looks through the design to see if it is correct.observing the [wiki:PLATFORM_STANDARDS_DESIGN] document and trying to improve it) |
| | 35 | * The reviewer can imagine himself as an implementer and see if he can implement the task following the design without problems |
| | 36 | * '''design ok''' |
| | 37 | * the reviewer decides that the design of the task is correct |
| | 38 | * '''implementation started''' |
| | 39 | * the implementer makes an attempt to complete the task |
| | 40 | * he/she should follow the design strictly |
| | 41 | * he/she should write an Implementation section of the task as the result of the implementation |
| | 42 | * '''implementation finished''': the implementer decides that the implementation of the task is ready |
| | 43 | * '''review''': the reviewer look through the implementation to see if it is correct |
| | 44 | * '''implementation ok''' |
| | 45 | * the reviewer decides that the implementation of the task is correct |
| | 46 | * the implementation section must be filled |
| | 47 | * '''testing started''': there should be appropriate tests written for the task |
| | 48 | * Standards for testing can be found in the following documents: |
| | 49 | * [wiki:PLATFORM_STANDARDS_AUTO_TESTS] |
| | 50 | * [wiki:PLATFORM_STANDARDS_MANUAL_TESTS] |
| | 51 | * '''testing finished''': testing state is done, waiting for review |
| | 52 | * '''review''' |
| | 53 | * the reviewer looks for missing or wrong tests |
| | 54 | * if there are any, the reviewer may decide they can be added later |
| | 55 | * if they are too important or wrong they should be fixed - the review fails |
| | 56 | * '''testing ok''' |
| | 57 | * the last task state |
| | 58 | |
| | 59 | * notes |
| | 60 | * failing a state (for example moving from implementing to analyzing because implementation failed) requires that the state of the product is reversed to the initial state |
| | 61 | * the transitions of each state are defined in [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png Workflow diagram] |
| | 62 | * for every task we have tickets which are available for reading and filtering in the View Tickets section in Trac. For every state of a particular task, you have to go to its ticket and update its status depending on the state you are working on. There are custom ticket fields which we should filled with information about the task phase owner, reviewer and score. There is also importance field(See [wiki:SCHEDULE_WBS_DEPENDENCIES_R1#Design] for its usage). See [wiki:SCS_ISSUE_TRACKER_SETUP_R1] for more information about our issue tracking. |
| | 63 | * Reviews should have reasoning for the given mark. These better be connected to concrete requirements in the standards, |
