Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Guidelines to Review Work products

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Guidelines to review Work Products v1.0
Document Template Reference No: 1-3
Copyright © RASS Tools Limited, UK
Website: ww...
Guidelines to Review Work Products v1.0
Document Template Reference No: 1-3
Copyright © RASS Tools Limited, UK
Website: ww...
Guidelines to Review Work Products v1.0
Document Template Reference No: 1-3
Copyright © RASS Tools Limited, UK
Website: ww...
Anuncio
Anuncio
Anuncio
Próximo SlideShare
Chapter 3 Static Techniques
Chapter 3 Static Techniques
Cargando en…3
×

Eche un vistazo a continuación

1 de 19 Anuncio
Anuncio

Más Contenido Relacionado

Anuncio
Anuncio

Guidelines to Review Work products

  1. 1. Guidelines to review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Guidelines to review Work Products v1.0 Author: AshokKumar LalSingh 8 Dec 2009 Copyright Notice The document “Guidelines to review work products” has been authored by Ashok Kumar LalSingh, Director - RASS Tools Limited, UK. RASS Tools Limited reserves all rights to modify this document and permit its uses. Use of this document for the purpose other than personal reference is not permitted without the explicit authorization from RASS Tools Limited. RASS Tools Limited will not be responsible for financial or any other losses arising due to the unauthorised use of this document.
  2. 2. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 2 of 19 Index 1 Introduction ........................................................................................................................................ 3 2 Definitions of Roles used during Review ............................................................................................ 5 3 Which Review method to use?........................................................................................................... 6 4 What are various aspects of reviews?................................................................................................ 7 5 What types of activities are performed during reviews?................................................................. 12 6 What skills are needed to perform reviews?.................................................................................... 13 7 How to record and report outcome of reviews?.............................................................................. 14 8 Sample Review Checklists................................................................................................................. 15 9 Glossaries.......................................................................................................................................... 18 10 Document Control............................................................................................................................. 19
  3. 3. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 3 of 19 1 Introduction This document describes the guidelines to review work products or artifacts such as documents, designs, software code, and reports etc. Reviewing of work products happens after the creation or change and before the approval of the work product. Reviewing the work products is a required quality assurance activity. Review impacts cost, performance and risk factors. It is critical for success as well as improvements in all spheres of business and technical activities. Review methods: Different types of work product may require different types of review methods. Reviews may use formal or informal methods. Informal Review method: Sending a document’s review request through an email is widely used as an informal review method. Formal reviews should be preferred over informal reviews. Research studies indicate that formal reviews greatly outperform informal reviews in cost-effectiveness. Informal reviews may often be time-wasting through lack of focus. Therefore while conducting informal reviews; reviewers must be communicated with the review focus for their part in the form of review checklist or a statement. Formal Review methods: The following methods of formal reviews are generally used. • Peer To Peer Review • Walkthrough Review • Inspection Review Peer to Peer Review: ‘Peer to Peer Review’ takes place within peers who are familiar with the work product and related aspects. The peers are individual persons or members of a team. The peers may have expertise (skills and experience) in different areas related to different aspects the work product. After the author or the producer has declared the work product to be complete, one or more peers do the review. The reviewers may consult other persons if they are in doubt or require additional information. At the end of the review, the reviewer completes the Review Records Form (Doc Ref No: 1-7) and sends the same to the producer. Walkthrough Review: Walkthrough Reviews are conducted through a presentation where at least Author or Producer, Recorder and Reviewers are present. Author or producer may also be the recorder. Author or producer makes the presentation. In case of software code, presentation need not be done literally reading line by line, but it should be more of a paraphrasing the code being reviewed. In case of documents, author or producer may explain concepts along with reading the document. Reviewers can interrupt as soon as they have found a defect or needs additional information. Then the point for interruption is discussed. Recorder notes the defect if all agrees to it. Inspection Review: Inspection Review is similar to the ‘Walkthrough Review’ except the addition of a Moderator to the review team. Moderator checks the preparedness for everyone. Recorder notes the defect when signaled by the moderator i.e. an agreement among review team is not required. Rest review process is the same as ‘Walkthrough Review’. Often ‘Root Cause Analysis of defects’ is also done after the review is completed. Further details on review methods is available in the following section 3
  4. 4. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 4 of 19 Review Aspects: All work products are not reviewed identically. Reviews may focus different quality assurance aspects for different work products. These quality assurance aspects are combined into three main groups as given bellow. • Functional Aspects • Technical Aspects • Management Aspects • Quality Standard Aspects Functional Aspects: Here review focuses on the required functionality provided by the work product. Review checks the adequacy of functionalities and missing functionalities. Reviewers may also suggest improvements or alternative implementation ways for inadequacies of functionalities. Technical Aspects: Here review focuses on work product engineering that may involve reviewing of design, construction, testing and implementation aspects. Reviewers may also suggest improvements or alternative implementation ways for inadequacies of functionalities. Management Aspects: Management aspects of review is concerned mainly on management side of the work product such as planning, resourcing and controlling costs, productivity, profitability and customer service. Management aspects are reviewed before a work product is sent to the customer. Often management aspects are part of the work product approval process. Reviews for management aspects can be conducted in a formal meeting or just by one person. Quality Standard Aspects: These review aspects focus on enforcing compliance with quality management systems such as applying standards, following guidelines, identifying, analyzing and rectifying defects. For further details on Review Aspects, please refer information in section 4. Review Checklists: Formal review methods require that all aspects of review are focused. Review checklists plays very important role to help reviewers to focus attention, ask relevant questions and collect information about items included in the checklists. Section 5 describes various review checklists for some of the work products. Inadequate Reviews: Inadequate Reviews – • may cause unexpected problems • be very costly to rectify problems • be the reason for failures Take it seriously: Reviews must be taken with seriousness. It is unavoidable and required activity. This guide will help you to prepare for successfully doing reviews.
  5. 5. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 5 of 19 2 Definitions of Roles used during Review The following Table 1 describes the roles required to perform formal reviews. Role Role Definition Author or Producer Author or Producer is an individual or a team of individuals who have created the work product. The following are some of the responsibilities of an Author or a Producer ensures readiness of work product for review, assists moderator in planning for review, prepares for briefing in overview meeting, fixes all defects identified, resolves all issues raised during Review, provides process metrics to moderator. Moderator Moderator is the person who organizes/controls the review meetings, selects reviewers and assign roles, ensures work product readiness, schedules the review meeting, ensures adherence to review objectives, determines work product partitioning requirements, schedules overview meeting, ensures receipt of required information by participants, ensure individual preparation before logging meeting, triggers defect logging for the recorder, ensures consensus on defects/issues logged, determine disposition of work product, collects process metrics and distribute results ((Size, effort and defect data, along with defect analysis) and determines need for updating any checklists. Reviewer Reviewer is responsible for scrutinizing the document or the work product under review, verifying its completeness and correctness make suggestions and observations during the meeting ensuring active participation. Reader Reader is a person who reads the document or the work product in the Review meetings. Recorder Recorder documents the issues discussed during the meeting in the form of an action list. In case of Peer Review meetings the Recorder also documents the defects observed during the review meeting. The Recorder will Record defect after consensus is reached or on signal from Moderator, read back recorded defect for verification, ensure information logged is clear, complete and correct. Table 1
  6. 6. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 6 of 19 3 Which Review method to use? The following Table 2 shows some of the review activities performed under each type of reviews. Objectives of Review Peer To Peer Review Walkthroug h Review Inspection Review Manageme nt Review Check omissions, adequacy and defects √ √ √ √ Provide alternatives and improvements √ Check conformance to standards/ specifications Examine issues of following guidelines √ √ Check if the work product is suitable for release √ Collect data for process improvement √ Table 2 The Table 3 shows the work products and which review may be used on the work products. Work Product Name Peer To Peer Review Walkthrou gh Review Inspection Review Managem ent Review Business Processes, Forms, Templates, Guidelines, Standards and similar documents √ √ √ √ Program or Project estimates, plans and schedules √ √ √ √ Requirements or Statement of Work √ √ Functional Specifications and Acceptance Test Plans √ √ √ Test Cases √ Software Code √ Design Documents √ √ Table 3
  7. 7. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 7 of 19 4 What are various aspects of reviews? The following Table 4 gives describes the details of review aspects. Please note. This is not a complete list. You can use this list to create the review checklist for a work product. Section 5 describes review checklists for few work products. You can improve over these checklists by using information on review aspects. Review aspect What to focus during the Review? Compliance with contractual requirements The main focus of this review aspect is the Statement of Work (SOW) and the Contract. • Contractual requirements are part of the SOW. • Standards and specifications included by reference in the contract. Completeness A document or product may be in process and not yet completed at the time of the review. Because of this, the reviewer must judge whether the degree of completeness at a particular time is adequate. At every stage of document development, all required sections and section headers should be present. Completeness of paragraph content depends upon when the required information is, or should be, known. Criteria that may apply, depending on the document, include identified and appropriate – • intent and purpose of the document • document audience • timeframes • contact information • reviews and approvals The sources of information to assist in making this determination include associated documentation on planning and execution. Functionality Aspects Appropriate content for intended audience A document is targeted at an audience, and its review must focus on how well it is able to meet the needs of the targeted audience. If there are guidelines, reviewers must use the guidelines. However, the reviewers may be required to make judgment as to whether the material provided is suitable for the intended audience. For example, an application user may not need design details which are critical for development and support personnel.
  8. 8. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 8 of 19 Review aspect What to focus during the Review? Technical adequacy Understanding of Technical adequacy at times may be complex and require technical knowledge and skills. In general reviewers may cover the following: • Are there violation of known facts or principles • Consistent with approaches known to be successful • Well researched or based on proven prototypes • Well thought out, not thrown together • Make sense both technically and practically Technical Feasibility Feasibility is the degree to which plans, requirements, or design can be implemented given the state of the art, schedule and resource constraints, available tools, techniques, and other factors. An additional consideration is that items that are feasible in isolation may not be feasible when taken together. Each item must therefore be evaluated in the context of accompanying items. Technical Aspects Traceability Traceability means that the document being reviewed is in agreement with any predecessor documents. Traceability has three criteria: • The document fully implements the applicable stipulations of a predecessor document • All material in a subsequent or lower-level document has its basis in the predecessor document, that is, no untraceable material has been introduced • The two documents do not contradict one another. plus • A referenced section contains the information or otherwise fully implements the applicable stipulations indicated in the reference, • All material in a lower-level or detailed section of the document has its basis in the predecessor sections, that is, no untraceable material has been introduced • The sections of the document do not contradict one another.
  9. 9. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 9 of 19 Review aspect What to focus during the Review? Testability of requirements A requirement is considered to be testable if an objective, feasible test can be designed to determine whether the requirement is met by the solution. An example of an untestable requirement is “The module shall be composed of small units that execute as quickly as possible.” A testable requirement would state “The module shall be composed of units each smaller than 500 lines of executable code, and each executing in under 10 microseconds.” Adequate test coverage of requirements This factor applies to test planning documents. Questions to be asked include: • Is every requirement addressed by at least one test? • Have test cases been selected for an “average” situation as well as for “boundary” • Situations such as minimum and maximum values? • Have “stress” cases been selected, such as out- of-bounds values? • Have meaningful combinations of inputs been selected? • Are test cases efficient in that they do not test the same feature over and over? Support of enterprise architectures This factor evaluates the document’s agreement with such defined strategies and models. Questions to be asked is ‘Does it agree with defined enterprise views and support/align with the data and application architecture?’. Adherence to documentation standards This factor identifies appropriate and applicable documentation standards and required or recommended document formats and assesses adherence to these. In most cases required format for document is the template for a document type. Other sources are project or contractor-proposed formats and special contract-specified formats. Evaluation should be relatively straightforward based upon the applicable guidance. Quality Assurance Aspects Consistency The document being evaluated does not contradict itself or with references in either content or style. Criteria for consistency include: • All statements must be compatible, • A given term must have the same meaning throughout, • A given item or concept must be referred to by the same name or description throughout, and • The level of detail and presentation style must
  10. 10. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 10 of 19 Review aspect What to focus during the Review? be the same throughout. Readability, comprehensibility and general understandability The ease with which the document can be comprehended. Criteria include: • Use of generally accepted rules of grammar, capitalization, punctuation, symbols, and notation • Non-standard terms, phrases, acronyms, and abbreviations are defined • The level of complexity is appropriate to the intended audience • The material being presented can be interpreted in unique way Use of appropriate requirement, design, or coding techniques A contract may describe exceptions or augmentations to the techniques that have been approved. The statement of work (SOW) may also expand upon, clarify, or change the technique to be used. These sources should be the basis for determining the techniques to be used and for evaluating compliance. Appropriate level of detail Level of detail is a subjective factor whose evaluation must be based on the intended use and audience of the document. A document can err in either direction: a document that is supposed to provide an overview might be too detailed and a document that is supposed to provide details might be too high-level. Review of the applicable documentation plan, document descriptor, and other documents of the same type may aid in determining whether the level of detail is appropriate. Allocation of sizing, timing, or resources • The total of the allocated amounts is within the overall allocation. • Do the allocations seem realistic and feasible? • Do the allocations take into account the demands on each unit component, or do they seem to be mere mechanical allocations, such as dividing available resources by number of units? • Are the allocations based on prototyping and other analysis, or just on guesswork? Adequacy of proposed tools, facilities, procedures, or resources This review factor applies to planning documents. Evaluation requires judgment as to whether the proposed items will be adequate to fulfill their intended purpose. A useful evaluation technique is comparison with past projects, when possible. Management Aspects Alignment with the Documents will be evaluated for adherence to, and
  11. 11. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 11 of 19 Review aspect What to focus during the Review? management objectives support of management objectives. Table 4
  12. 12. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 12 of 19 5 What types of activities are performed during reviews? The activities performed during reviews depend upon the work product and the review method used. The following is the partial list of generic activities that may be performed during reviews. • Read the original and referenced documents and records • Explain concepts with relevant examples with facts and figures • Check for information required for checklist items and complete the checklist • Discuss issues from various angles and aspects • Logging observations about omissions, inconsistencies, deviations and defects • Cross checking with references, standards and guidelines • Validate financial and other vital figures • Refer issues to experts or authorities external to the review team and get their views • Do root cause and other analysis such as reconciliation • Suggesting alternate ways and improvements • Prepare and submit review reports and update review records
  13. 13. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 13 of 19 6 What skills are needed to perform reviews? Looking at the information in section 4, it is obvious that review focus has large scope. To perform reviews one must have adequate skills required by various review aspects. As a single person is most likely not to have all of the skills, more than one reviewer or a review team is required where a member of review team can focus of a particular set of review aspects. The following are the broad classification of skills from reviews perspective. • Functional • Technical • Quality Assurance • Managements Functional Expertise: Functional expertise refers to the skills and experience in particular functional areas. People with these skills are often called business analysts or simply analysts, accountants, consultants, subject matter experts etc. People in executive roles and functional heads may also qualify for functional expertise. Technical Expertise: Technical expertise refers to the skills and experience in science and engineering related functional areas such as analysis, design, construction, testing, implementation, maintenance and support. People with these skills are often called engineers, technician, system analysts, architects, designers, technical consultants, subject matter experts etc. People in executive roles and technical heads may also qualify for technical expertise. Quality Assurance Expertise: Quality assurance expertise refers to the skills and experience in one or more quality systems and process improvement methodologies such as ISO, SCI-CMM, Six Sigma, Business Process Re-engineering etc. People with these skills are often called quality analyst, auditors, inspectors, quality consultants etc. People in executive roles quality assurance and quality assurance heads may also qualify for technical expertise. Management Expertise: Management expertise refers to the skills and experience in managing functional and technical areas. People with these skills are often called executives, managers, administrators, heads, management experts etc. Along with type of expertise, the level of expertise is important consideration for being a reviewer. Right type and level of expertise will ensure successful reviews.
  14. 14. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 14 of 19 7 How to record and report outcome of reviews? Outcome of review is recorded in various ways depending upon the work product under review. All reviews must complete the Review Records form (Doc Ref No: 1-7) and if required, document root cause analysis, alternatives and improvements.
  15. 15. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 15 of 19 8 Sample Review Checklists The following are few sample checklists for specific work products. The checklists given here are yet not comprehensive and will be updated in due course. We have yet not created a template for the review checklist. We intend to create a one page checklist common to all work product and one page checklist specific to the work product. Work Products Checks to do during the Review Business Processes, Guidelines, Standards, Templates, Forms and documents based on the templates • Has the document been created using a template? • Has the Guidelines for Documents Authoring been followed? • Has the spell checker been run? • Is the document complete with all sections? • Has something been omitted such as procedure or a concept? • Do you have any concern about the validity of concepts and procedures? • Is the document detailed and easy to understand? • Are the referenced documents’ references correct? • Are there any contradictions at the Entry and Exit stage of the process? • Are there any violations of Policies and Business Rules? • Will it improve the existing process? • Have the related other documents also updated in case of a change? • Is training required to implement the new process or the changes? • Are there any implementation problems? • All types of Project Plans, Estimates and Schedules • Is the project scope clear and well defined? • Is the start and end date clear? • Is the list of Control and Configuration items been prepared? • Is the list of the current team members maintained? • Are the resources suggested in the Resource Plan/Training plan suggested along with Proposal available and are they adequate? (If required) • Are Roles and responsibilities of all the team members have been defined? • Is the frequency of Project Status Review defined? • Is the method of communication with the client clear? • Are details of Onsite Contact person have been given? • Is H/W and S/W development environment defined? • Is Familiarization procedure mentioned? • Is delivery procedure mentioned? • Is deemed acceptance criteria defined? • Is workflow explained? • Is Change Request procedure defined? • Is project having any deviations? • If Yes, List of deviations (Deviation document) has been maintained? • Are milestones, delivery schedule and deliverables maintained? • Is the Project team members training Plan prepared? (if required) • Is the procedure for status reporting clear? • Does it cover timesheet analysis, Link failures, Server problems, etc. • Is Acceptance Criteria clear? • Is Risk Management Plan prepared? • Is project end procedure mentioned? Is Inter group co-ordination activities defined? Software Requirements • Are the requirements complete, consistent, accurate and testable? • Are external and internal interfaces properly identified and defined? • Are the requirements traceable to system level agreed and approved?
  16. 16. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 16 of 19 • Are security & performance requirements defined? • Are system constraints and assumptions documented? • Are validation/acceptance criteria complete? • Is acceptance criteria clearly defined? Functional Specifications (FS) • Is the template for FS used? • Is FS detailed enough? • Is FS unambiguous & traceable to requirements? • Are all requirements covered in FS? • Are flow charts/diagrams correct & self-explanatory? • Are cross-references to flow charts/diagrams, sections correct? • Are there any Critical/High Risk deliverables such as screens /queries/ reports that will be used by highest authority (e.g. CEO) at the customer end? System Design • Are Design Specification & System Test Plan detailed? • Is Design Specification traceable to Functional Specification? • Is design modular? • Are requirements reflected in the architecture? • Are modules∗ functionally independent? • Are interfaces defined for modules and external system? • Is data structure consistent with requirements? • Has maintainability been considered? • Does the algorithm accomplish the desired function? • Is the algorithm logically correct? • Is the interface consistent with the logical design? • Have error handling methods been specified? • Are local data structures been properly defined? • Is design detail amenable to implementation language? • Is required performance achievable within the constraints imposed by the suggested system environment? • Are all boundary conditions, error conditions identified & addressed in Design Specification? • Is Database/Files integrity maintained? • Is volume of processing for all tables/files identified? • Have performance issues/implications been examined and assessed? If yes, please note aspects reviewed. Test Cases General • Traceability to requirements • Boundary conditions : (Loops, Range/discrete values) • Condition branches • Initialization/Default values • Computation (overflow, underflow, precision, rounding) User Interface • Look and feel/Screen Layout • Reports (Layout, sort order, Page/control totals) • Error/Exception handling • Messages (Grammar, Spelling, Informative) Database/File • Triggers
  17. 17. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 17 of 19 • Transactions (locking, recovery, restart) • Update/Retrieval • Access control Table 5
  18. 18. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 18 of 19 9 Glossaries The glossary entries in this section are specific to this document. …… Abbreviation Description DCR Document Change Request Info Information MS Microsoft Proc Process SOW Statement of Work CEO Chief Executive Officer H/W Hardware S/W Software FS Functional Specifications GDL Guidelines FRM Form
  19. 19. Guidelines to Review Work Products v1.0 Document Template Reference No: 1-3 Copyright © RASS Tools Limited, UK Website: www.rasstools.com, Doc Ref No: 1-6 Page 19 of 19 10 Document Control Access Control and Distribution This is a controlled document. It is available in MS Word versions which can be printed. Its access is controlled as per the document management process. Approved by Name Designation Date Signature Ashok Kumar LalSingh Director, RASS Tools Ltd. Released by Name Designation Date Signature Ashok Kumar LalSingh Director, RASS Tools Ltd. Reviewed by Name Designation Review Requirement Changes Summary Log Issue No Date Changed by Changes summary 1 08/12/2009 Ashok Kumar LalSingh First release

×