王家荣-普华实施手册(English)

1、Example ProjectWalkthrough Procedures他酗輛0仍PERS iTable of Contents:I. DEFINITION 3II. PURPOSE 3III. SCOPE3IV. BENEFITS 4V. ROLES AND RESPONSIBILITIES4A.B.C.MODERATOR REVIEWERS：. AUTHOR：4 5 6 VI. TYPES OF WALKTHROUGHSA.B.DESIGN WALKTHROUGH CODE WALKTHROUGH .7.8VII.WALKTHROUGH PROCEDURES8.A.1.2.3.B.1.2

2、.3.C.1.2.D.1.2.3.GENERAL INFORMATION ON WALKTHROUGHS Before the WalkthroughDuring the WalkthroughA fter the WalkthroughDESIGN WALKTHROUGHS Before the WalkthroughDuring the WalkthroughAfter the WalkthroughCODE REVIEW WALKTHROUGH Before the WalkthroughDuring the WalkthroughSECONDARY WALKTHROUGHS Befor

3、e the WalkthroughDuring the WalkthroughAfter the Walkthrough.8.8.1.01.010.10.131.3.1.4.1.4.1.4.14.14.15.15VII.APPENDICESA.B .C.D.20232425APPENDIX “ a WALKTHROUGH SUMMARY document description APPENDIX “ B DESIGN review PROCEDURESAPPENDIX “ C CODE REVIEW PROCEDURES.APPENDIX “ D SECONDARYWALKTHROUGH PR

4、OCEDURES,I. Defin iti onA Structured Walkthrough is-persOa morttisupervisory, formatted worki ng sessi on thatdeals with a discrete unit of work-i n-progress, to ascerta in quaated attributes. ”II. PurposeThe purpose of the Structured Walkthrough is to: Solicit additi onal in put from the Walkthroug

5、h Team to assist in the support of the phase deliverableEn sure the deliverable meets the criteria set forth for the developme nt of the comp onent* Enhance the quality of the product* Reduce the nu mber of errors tran smitted from one developme nt phase to the n ext* En sure the below listed attrib

6、utes of good docume ntati on are preserved:* Un ambiguous (one in terpretati on)* Complete* Con siste nt* Mai ntai nable (History of Revisi on - routi ne maintenance and enhan ceme nts)* Traceable (Trace to a source exter nal to the docume nt)* Verifiable (All aspects are defi ned and measurable adh

7、er ing to sta ndard)* Ide ntify new issues, not resolve existi ng known issues. All known issues should be resolved prior to the Walkthrough.* As issues are raised in the Walkthrough, soluti ons should be offered if they can be resolved in the meeting within the allowed time frame. Otherwise, issues

8、 must be resolved after the meeti ng.III. ScopeWalkthroughs are required for: Tech ni cal Desig n Specificati ons Program Code and Unit TestsIt is recomme nded that, as the scope of work in creases, these guideli nes be adapted for new developme nt objects.IV. Ben efitsThe Walkthrough provides an op

9、port unity for the early discovery of issues in the developme nt objects so that each issue may be corrected prior to the next step in the process.V. Roles and Resp on sibilitiesThe Walkthrough is gen erally con ducted at a peer level after the author checks the product.A team gen erally comprised o

10、f the author, moderator and 2-3 reviewers con ducts the Walkthrough. It is suggested that one of the members should have peer/senior level technical skill to the author. Other junior members should attend as well so that they may develop walkthrough skills.It is the resp on sibility of all members o

11、f the review team, in additi on to their specific skills (i.e. performa nee), to:* Questi on the thorough ness of the product* Validate that the product was prese nted in a manner that is un dersta ndable by a nonexpert* En sure that the docume nt is structured, con cise, self-descriptive, well comm

12、e nted, accessible, com muni cative, and qua ntifiableWalkthrough Team:Each member of the Walkthrough Team has a defi ned role and must un dersta nd that role:A. ModeratorThe moderator should have leadership skills and the ability to en sure that all issues are resolved.BeforeRegister for the Walkth

13、rough:* First thi ng each morning, sig n-up for the Walkthrough via the Walkthrough Register* Con tact the author to inform them that they will be the moderator for the Walkthrough* Verify that the skill level of reviewers chose n meets requireme nts* Obta in a bla nk copy of the Walkthrough Summary

14、 Docume nt and the Walkthrough Moderator Checklist from the shared driveDuring:Check for adequate preparation:* Determ ines the date each reviewer received the deliverable and the amount of time spe nt review ing the docume nt Decides if the review team has had adequate time to prepare for the revie

15、w If the moderator feels that in sufficie nt time has bee n spe nt prepari ng for the sessi on, it is the moderator?st(d0 nd the sessi on and have the author re-schedule the Walkthrough Facilitate the meeting: Move the discussi on along in a con structive manner Allocate sufficie nt time for each to

16、pic in the review Keep the scope and focus of the meeti ng Document the issues Main tai n the Walkthrough Summary docume nt, which in cludes record ing all issues. The impact of the issue as well as the party responsible for its resolution will be recorded for each issue*Note all releva nt suggesti

17、ons, error-detect ion and other issue-related in formati onPrese nt the issues to the Walkthrough team prior to thecon clusi on of the meeti ng Establish a time frame for the resolution of issues, the impact of those issues, and the required level of review n ecessary to en sure said issues have bee

18、 n resolvedAfter:Verify Resolved Issues:* Verify that the author has made all cha nges required by the Walkthrough team.* Once all issues are resolved and verified by the moderator, the deliverable will proceed to the n ext stage of approvalB. Reviewers:Reviewers should be selected so that they brin

19、g a mix of experie nee and perspective to the review team. Senior developers may address the more tech ni cal issues while those less experie need may address issues such as clarity, complia nee, docume ntati on and readability.Before:Examine the material thoroughly* Con sciously challe nge all attr

20、ibutes of the deliverable well in adva nee of the meet ing* Each comp onent should be challe nged for flaws and in corporati on of the latest tech niq ues* Reas ons must be ide ntified for rais ing issues on a professi onal and quality of work level* The reviewer should prepare questi ons for the au

21、thors regard ing issues found dur ing the exam in ati on.Duri ng：Share knowledge and skill to enhance the product* Raise issues* Actively participate in the discussi on with focus on substa ntive issues that surface during the Walkthrough to identify potential problems, incon siste ncies, deficie nc

22、ies Lend specific kno wledge in cludi ng suggesti ons to in crease effective ness, clarity, maintain ability, and performa nee Assist the recorder in the identification of the impact or risk of an identified issueList of Senior Reviewers:After: Rick Brooke Indranil Das Whit ney Hite Steve Wes na Xia

23、oPi ng Zha ng Par An bil (Gillette) Sucheta Sarkar Sonali K. Das Debashish Bhattacharya San kar Ven katrama n Bob Berneck (Gillette) Arri Qui nes* Jerry AlamoAid Author in resolution of the issues* If a reviewer has specific kno wledge of a soluti on to issues they have raised, they should aid the a

24、uthor in resolv ing the issues* The reviewer will do this in the interest of time and knowledge- shari ngC.Author:The author (developer) is the pers on or pers ons who created the deliverable.Before:Complete the Deliverable:* Thoroughly complete all required comp onents of the deliverable* After com

25、pleti on of the deliverable, it should be forwarded to the cell lead for in itial review and approvalSelect venue and participants* Select a venue for the Walkthrough* Select at least two reviewers. (Note: Each Walkthrough must have at least one senior level developer as a reviewer.)* Register for a

26、 Moderator by 6 p.m. the day before you want to have the Walkthrough. List the time and room you have scheduled for the Walkthrough.* Distribute the deliverable in a timely manner to allow for proper review.During，Present the deliverable* Step through the deliverable expla ining the developme nt log

27、ic Prove the function ality and thorough ness of the deliverableResp onds to any questi ons asked so that raised issues will be clearRema in ope n-min ded to suggesti ons which should be recordedtogether with reas ons for con siderati onsAfter:Resolution of the Issues The author has the resp on sibi

28、lity of resolv ing all issues. If the issue must be resolved by ano ther party, it is the resp on sibility of the author, not the moderator, to ensure this is done The author mai ntai ns con trol of the Walkthrough Summary docume nt If the Walkthrough team wishes to meet to review the resoluti on of

29、 issues in the first meeting, the author will repeat this cycle Whe n all issues have bee n resolved, the author should highlight those cha nges and prese nt them to the moderator for approval.VI. Types of WlkthroughsThe Walkthroughs will be focused on two mai n deliverables: Desig n Specificati ons

30、 and Program Code Bun dles.A. Design WalkthroughOften developers will create the Design Specification. In this case, the Design Specificati on must go through the formal Walkthrough process and obtai n clie nt approval prior to codi ng.The activities associated with and con ducted in the desig n pha

31、se of a project are done in order to identify potential problems, inconsistencies, deficiencies and other related con siderati ons that would lead to in adequately defi ned problems or resulta nt requireme nts.The Desig n Walkthrough will exam ine the complete detailed desig n specificati on for eac

32、h program. All Un it Test Plans and other docume ntati on will be exam in ed.Consistency with previous stages of the deliverable will be examined to ensure that all requireme nts in previous specificati ons are represe nted in this detail level of the specificati on. This en sures that the Desig n S

33、pecificati on meets the requireme nts described in the Functional Specification.These activities in clude the decompositi on of processes into eleme ntary acti ons address ing module desig n, structure and pseudo code.An exam in ati on of the tech niq ues and available tech no logy that may be appli

34、ed to enhance the product are identified and discussed.B. Code WalkthroughActivities associated with and con ducted in the con structi on phase of a project are done to verify the structure and composition of instructions and objects used to satisfy the requireme nts of the system, applicati on or m

35、odule.This process seeks to avoid pote ntial problems, incon siste ncies, deficie ncies and any other related con siderati ons while evaluati ng tech niq ues and tech no logy that may improve performa nee and trap error con diti ons.The Code Review will take place upon completion of the program, uni

36、t testing and other related deliverables. The Code Bundle reviewed during the session should be complete and in a condition appropriate for submission to the on-site team for approval.The developer should provide evide nee of the fun cti on ality of the deliverable. This may in clude providi ng the

37、actual test data used and hard copy scree n captures of the test results. Whe n variable results are expected, each bra nch should be pursued. Where appropriate, the unit test should in dicate which sect ion of code gen erated the result.The purpose of the Unit Test Plan Walkthrough should be to sti

38、mulate discussi on from the output rather tha n just step through the un it test pla n.Reviewers should offer comme nts and suggesti ons regard ing the issues raised duri ng the session. Normally, detailed solutions may not fit within the scope and time allotted for the meeti ng. Based on this, it i

39、s recomme nded that detailed soluti ons to issues be discussed betwee n reviewers and developers after the con clusi on of the meet ing. However, if the proper resources are present and the issue is one that fits the scope and time limitations, it may be offered during the meeting. This decision wil

40、l be left to the discretion of the moderator.VII. Walkthrough ProceduresA. General Information on Walkthroughs1. Before the WalkthroughMaintain your documents on the S: Drive: They must be maintained in the proper folder, on the proper drive, for the proper client, with the proper naming exte nsion.

41、All issues (and resolutions) for the Design/Code should be printed and in cluded in the Desig n/Code Bun dle.Moderator Reviewer: Do not choose a Moderator to review your program. They have sit through eno ugh of these thi ngs as it is.Reviewers and Moderators get your spec: Provide a Fun cti onal Sp

42、ec along with a Detailed Design Spec and with the Code Bundle to both the reviewers and the moderator.Things to double check before hav ing a walkthrough: Just a remin der that quality is of utmost importa nee to PwC. We must provide not only durable and effieient deliverables, but highly polished o

43、nes. During reviews it is easy to negleet the details in an effort to perfect code or design logic. Reviewers, please take time to check things such as Message and Developme nt Classes,Correctio n and Tran sport Numbers, Flower Boxes, In Code Comme nts,Hard Coding, UTP sig n-off and date, Spelli ng

44、and Grammar, Docume nt Complete nesajnd Clarity of the bundle (is it neat, clean, and can you read the copies of the UTP). Moderators, please make sure Reviewers are doing this. Team Leads barely have eno ugh time to han dle their work load, they do not n eed to triple proof read the documents befor

45、e sending them off to the client.Use Moderator Checklist as refere nee:Soluti on Delivery Cen tre:Walkthrough Moderator ChecklistProgram ID:Moderator:Author:Date/Time:Project:For the Design Walkthrough:Yes No N/ADetail Specificati on Requireme nts:1. Is the Document(s) located on the S: Drive?2. Are

46、 the appropriate naming sta ndards used for naming files?3. Is there test data in the system?3a. If no, is the author able to create the data?3b. If no, has an issue bee n raised?4. Is the sta ndard project report header used in Report Layout?56. Does the table access diagram conform to the sta ndar

47、d?6a. Are the key fields represe nted?6b. Are the default (driv ing) values listed in the fields for each table?7. Print Con trols: Are the proper print con trols being used?8. Are the issues provided in the bun dle?2. During the WalkthroughGlobal Desig n Issues: Will be resolved by the Moderator Te

48、am. They can rarely be an sweredduri ng walkthroughs. Therefore,the agreed upon sta ndard should be used un til reviewed by the Moderator Team.3. After the WalkthroughRecord your time. Rememberto chargeboth your review time and time spe nt in the walkthrough to the developer? program un der appropri

49、ate category.The Walkthrough Docume nt: The author should main ta in con trol of this docume nt. There is no n eed to make several copies. The author should update the docume nt as issues are resolved, and the n prese nt it to the Moderator when finished. It should be given to the Team Leads along w

50、ith the deliverable after it has been signed by the Moderator.Highlight your changes:lf resolving your changesrequires making cha ngesto your deliverable, highlight the cha nges on the updated docume nt. Do this only on the hard-copy. Please use only Non-Toxic Yellow (ASTMD-4236) Highlighters, as th

51、is co nforms to the Newco color sta ndards.B. Design Walkthroughs1. Before the WalkthroughPrior to each Walkthrough, the developer should prese nt a complete deliverable with associated docume nts to the cell lead. Upon approval from the cell lead, the author will then arrange the location, select t

52、he members of the Walkthrough Team), and distribute the deliverable docume nts (see procedures for Author, Section V, C).Required documents for the Design Walkthrough1. Desig n Specificati on #12. Desig n Specificati on #23. All issues and corresp onding resoluti ons4. Functional Specificati on5. De

53、sig n Specificati on Checklist6. Requests for test data Test data:A docume nt specify ing the test data required to execute allbra nches of code (and therefore a Unit Test Pla n) should be submitted to the team leads prior to the Walkthrough. Thisrequest docume nt should be in eluded in the delivera

54、ble. If data already exists in the system, the n a docume nt stat ing all of your requireme nts should still be in eluded.Please note all non-applicable secti ons (these are sect ions of the templates that do not apply to your program) as . No areasjsA6uld be left blank.If client specific templates

55、are being used, please refer to those templates for requireme nts.If the author does not know whether there is test data, then it is a walkthrough issue.If there is not data, but they have com muni cated this to the, the n it is not a walkthrough issue. The reas on being that an issue resoluti on sh

56、ould come through which says either, the client will enter the data or the client is aware that the extra time will be spe nt on this program because they will be en teri ng data.If there is not data and the author has not com muni cated this to the clie nt, the n it should be listed as a walkthroug

57、h issue. Once an issue has bee n en tered, the walkthrough issue may be sig ned off on.Remember, the purpose of maki ng the author aware of test data (or the lack of test data) at the design stage is to motivate them to either get test data entered by the client or to get ,approval? to enter it themselves in time for coding. We do not want this to hold us up!Desig n Spec Checklist: There is a Checklist that should be completed before all Desig n Walkthroughs. This should be in cluded in the