| Version 30 (modified by deyan, 16 years ago) (diff) |
|---|
- The purpose of the analysis is to give as much as possible of the needed information for designing and implementing the task.
- The analysis of the first revision of each task should contain a brief overview of the whole task.
- Think well about the task! You should figure out very well what the aim (result) of the task should be and how to be reached.
- List the main features that have to be present in the final result of the task. These are used later to verify the design and implementation.
- Stick to the current revision of the task, but keep an eye to the whole task progress, and stay alert for possible smells.
- It is strongly recommended to discuss unclear aspects of the task with other team members.
- It is advisable to include some rough implementations ideas.
- Analyses must be kept in the task's page in chapter called Analysis.
- Every analysis must be made by one developer and one QA, and reviewed by other developer/QA.
- You can use PageTemplates/TaskPageTemplate#Analysis wiki page template for your analysis.
- Example for analysis that meets the requirements is GLOBAL_SPEC_STRUCTURE_R0
Depending on task type the analysis section content varies.
- Coding tasks - Analysis of these tasks should describe the aim of this revision.
- Overview - contains explanation of the task. This explanation should present what will be done from the user point of view, what will be the visible result from the task.
- Requirements - Here should be listed requirements of the result - what is desired functionality, what should this element have, etc.
- 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
- Implementation idea - Brief overview of implementation methods, suggested algorithms, etc.
- 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.
- How to demo - Explains how the result of this task may be presented to the team or external person.
- Bug Fix - Analysis of bug fixes should explain what the problem is, in which module, when it appears.
- Overview - explains the mis functionality in a sentence. Describe what happens and in what circumstances.
- Requirements - Here should be listed requirements of the result - what is the expected functionality. Please give detailed requirements, the bug can be a result of misunderstanding the original task requirements.
- Task result - In this section should be listed what is the result of the task. For these tasks it will be maintained code but depending on task may also contain diagrams, graphics, etc
- Implementation idea - Brief overview of implementation methods, suggested algorithms, etc. You may point the mistaken part of the code here.
- Related - Here should be listed related tasks that might be useful for solving this task. You should list tasks that depend on this bug (mis functionality, lack of feature, etc). You should also point related use cases.
- How to demo - Depending on task requirements, explain the problem in Implementation or Design, present the solution in Implementation section. Link useful test cases.
- Document - Analysis of documents tasks should point the aim of this document.
- Overview - Overview of specific revision should point what will be done in this revision.
- Requirements - Requirements to the documents that will be the result
- What sections should they contain
- Are these internal or external documents.
- Optional - who has to read these documents and in what period.
- Is it an important document.
- Task result - Should point revision target documents - wiki pages, diagrams, etc.
- Implementation idea - You may research related examples and share them in this section.
- Related - Here should be listed related tasks that might be useful. You should link previous revisions of this task. You may list useful external links too.
- How to demo - Link the document and give idea about highlighting parts of the implementation.
- Setup
- Overview - explains the role of this appliance in the project, what will it be used for.
- Requirements
- What services will be available, what depends on them.
- Task result
- In most common case the result is a set up appliance
- and/or setup, backup scripts.
- Implementation idea - Brief overview of implementation methods, suggested hardware requirements, etc.
- Related - Here should be listed related tasks that might be useful for solving this task. You should list tasks that depend on this appliance.
- How to demo - List how this setup can be presented.
- Maintenance
- Overview - explains what should be revised in a sentence
- Requirements
- Are there impediments related to this maintenance in the backlog
- What are the steps that are recreated each maintenance
- Log requirements
- Task result
- In most common case the result is a maintained appliance/tool.
- and/or setup, backup scripts.
- Implementation idea - Couple of sentences about implementation.
- Related - Here should be listed related tasks that might be useful for solving this task. You should also list previous revisions and setup of this tool/appliance. External links may be useful too.
- How to demo - Give instructions about presenting the results depending on task requirements.
Examples of good analyses:
Review and super review are scores 1-5. >=3 points means analysis passed the review and can be designed. Review should judge does this analysis answer the question "what has to be done this revision", does the analysis meet the analysis requirements. Passed analysis are not edited, only a Super Review may force analysis refactoring.
Comments
- boyan:
- the overview for coding tasks does not always represent the thing from the user point of view as stated - there is often implementation information that the user does not know.
- I don't agree that SCHEDULE_MAINTENANCE_R1 can be used as a good example of analysis - the overview section lists the task requirements instead of a more general explanation.
- The example listed in the beginning (GLOBAL_SPEC_STRUCTURE_R0) should be listed along the other examples.
- Different task kinds can be marked as headings instead of listed in a bullet list - this will improve readability.
- deyan
- Currently the implementation idea is pointed as an advise, not as a requirement.
- For some tasks it may be useful to have a draft of a specification diagram. This should be decided as a recommended or optional rule.
- A recommendation for adding the descriptions from the manage/sched/sophie2_wbs.py to the overview as "code" might be useful.
EDIT: adding the deacriptions to the overview formatted as code, for example. You can see APP_PLUGIN_MANAGER_LIST_R0 for an example.
- sriggins
- Deyan: Could you elaborate on "A recommendation for adding the descriptions from the manage/sched/sophie2_wbs.py to the overview as "code" might be useful." please?
