Changes between Version 31 and Version 32 of PLATFORM_STANDARDS_ANALYSIS


Ignore:
Timestamp:
01/22/09 17:47:01 (16 years ago)
Author:
boyan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PLATFORM_STANDARDS_ANALYSIS

    v31 v32  
    55 
    66= How to write analyses = 
    7 This page contains requirements and guidelines for writing good analyses. Here you will find information about what the structure of an analysis should be and how to approach the different kinds of tasks. Rules for reviewing will be provided as well. 
     7This document contains requirements and guidelines for writing good analyses. Here you will find information about what the structure of an analysis should be and how to approach the different kinds of tasks. Rules for reviewing will be provided as well. 
    88 
    99== General information == 
    1010 
    11 The analysis should be kept in a section of the task's wiki page called Analysis. When creating the task's page, use the TaskPageTemplate - it provides a backbone structure for the analysis, which consists of the following: 
     11The analysis of a task is written in a section of its wiki page called Analysis. When creating the task's page, use the TaskPageTemplate - it provides a backbone structure for the analysis, which consists of the following sections: 
    1212 * Overview - a brief description of the task (not more than a couple of sentences). In the first revision of the task, it should provide a brief overview of the whole task as well as what should be done in this revision. Otherwise, it should state what the current revision of the task is about.  
    1313 * Task requirements - probably the most important section. It should include a list of requirements that the task must fulfill. These are used for reviewing the design and implementation phase so they should be chosen very carefully. It is recommended to write them as a bullet list. Make sure the requirements are fulfillable for the effort of the current revison of the task. When not sure, mark the less important requirements as oprional. 
    … …  
    2323 * Discuss unclear aspects of the task with other team members. 
    2424 * Fill all the sections of the analysis that are mentioned above. 
    25  * Fill the task name in the ticket query at the top of the page. 
     25 * Fill the task name in the ticket query at the top of the newly created page. 
    2626 
    2727== Task kinds == 
    … …  
    4545==== A sample approach ==== 
    4646When analysing coding tasks, the following resources might be useful: 
    47  * The [source:/manage/sched/sophie2_wbs.py] file - find the task name and take a look at the description, the dependencies, the total effort, the effort for the current revision and when are the next revisions scheduled for. 
     47 * The [source:/manage/sched/sophie2_wbs.py] file - find the task name and take a look at the description, the dependencies, the total effort, the effort for the current revision and when the next revisions are scheduled for. 
    4848 * The [wiki:TASK_INDEX] page - take a look at the efforts and the schedule in a more convenient way than in the WBS file. 
    49  * The googledocs - scim through the specifications - although not complete and somewhat inaccurate, they can provide you with some guidelines. 
     49 * The googledocs - scim through the specifications - although not complete and somewhat inaccurate, they can provide some guidelines. 
    5050 * The source code - take a look at the existing functionality, try to think about what new to add and how to improve the existing code. 
    5151 * The team - ask someone that has done a previous revision or has more expirience in that area of the code. 
    … …  
    102102  * A draft of a specification diagram for external features. 
    103103 
    104 Reviewers should either follow the standards in this document or comment them in the '''Comments''' section of this page. Scores are in the range 1-5. Here are rules for scoring an analysis. 
    105  * Score 1 (fail): The analysis is not structured according to the standards (or to a little extent) OR the task requirements are incorrect and irrelevant to this task. 
    106  * Score 2 (fail): The analysis is structured according to the standards in the most part but has some things that are unclear or may mislead the designer/implementor. 
     104Reviewers should either follow the standards in this document or comment them in the ''Comments'' section of this page. Scores are in the range 1-5. Here are the rules for scoring an analysis: 
     105 * Score 1 (fail): The analysis is not structured according to the standards (or is to very little extent) OR the task requirements are incorrect and irrelevant to this task. 
     106 * Score 2 (fail): The analysis is structured according to the standards in the most part but has some things that are missing, unclear or may mislead the designer/implementer. 
    107107 * Score 3 (pass): The analysis is structured according to the standards but is too short and there's a lot more to be added. 
    108108 * Score 4 (pass): The analysis is structured according to the standards and provides enough information for the designer and implementer (useful links, good implementation idea, clear task requirements that are fulfillabe for the effort stated, etc.). 
    109109 * Score 5 (pass): The analysis is structured according to the standards and there's nothing more to be added - it's perfect in such a way that a person who is not quite familiar with the project can do well with the design and implementation. 
    110110 
    111 All reviews should be motivated. A detailed comment about why an analysis fails is required. For score 3 a list of things that could be better should be provided. Comments are encouraged for higher scores as well. Non-integer scores are STRONGLY disencouraged. If you give an analysis a score of 3.5, then you probably have not reviewed it thoroughly enough and cannot clearly state whether the analysis is good or not. Once an analysis has been reviewed, it cannot be altered. If you think an analysis is wrong, you should request a super review. Currently all super reviews should be discussed with Milo. Make sure you are able to provide clear arguments of why the analysis is not good before you request a super review. 
     111All reviews should be motivated. A detailed comment about why an analysis fails is required. For a score of 3 a list of things that could be better should be provided. Comments are encouraged for higher scores as well. Non-integer scores are STRONGLY disencouraged. If you give an analysis a score of 3.5, then you probably have not reviewed it thoroughly enough and cannot clearly state whether the analysis is good or not. Once an analysis has been reviewed, it cannot be altered. If you think an analysis is wrong, you should request a super review. Currently all super reviews should be discussed with Milo. Make sure you are able to provide clear arguments of why the analysis is not good before you request a super review. 
    112112 
    113113= Comments = 
    114   ^Your comment here --dev.id@YYYY-MM-DD^ 
     114  ^Your comment here --developer-id@YYYY-MM-DD^