里程碑编写规范.doc

THE M MILESTONE DEVELOPMENT PROCESS This document describes a 搈odel Milestone development process and defines the terms which are associated with it The purpose is primarily to encourage a common definition of terms The development processes described here represents the best practices of many groups at Microsoft mostly in Applications The implementation of various aspects of this model varies widely between groups Milestone Zero PurposeSet goals and plans for the project StartsWith completion of the Vision Statement Ends When coding begins Standard termsVision Statement a document written by Marketing to describe the strategic goals for the product Product Specification a design document written by Program Management to describe in detail how the product will work Test Plan a document written by Testing to describe the testing strategy for the product Development Plan and Schedule a document written by Development to describe when features of the product will be coded and by whom User Education Strategy Design Document written by User Education to describe the all documentation learning aids and other types of assistance that will accompany the product that are created within the UE group May also include a high level look at the contents of each piece What Program Management does Completes the Product Specification and submits them for review Review may include formal inspections as defined by Fagan Weinberg or Gilb This task is done when Development can complete a schedule based on the spec and Testing says the document is sufficiently detailed that they can write Test Cases based on the spec The spec may be more complete for features of the first milestone than subsequent ones However some groups have been adversely affected when n x milestone specifications were not complete enough and code had to be re hacked to accomodate issues that were not fully thought out Prioritizes features Develops a project schedule especially if there are significant components of the product which will not come from the team 抯 own development group Written agreement on deliverables from other groups is encouraged and works What Development doesDevelops the Development Schedule and begins code design and architecture Schedule should have buffers for vacation sick time unit or pre release testing bug fixing and unpredictable Comment daj1 Page 2 Some coding such as large archetectural stuff begins before the spec is complete but this doesn t count as MMn Need to say something about this Is it coding based on the spec Comment daj2 Page 2 Project Plan hasn t been mentioned or defined prior to this mention events Even with buffers most development schedules are 30 50 compressed If the reliability of your ship date is important increase the buffers In deciding which features should fall into which milestones consider the following guidelines Mission critical features should be developed early Interdependent features should be together in the same milestone for testing efficiency Features that are difficult to develop should be done early especially if they are critical to the success of the product Printing functionality should never be last Never depend on code from other groups that is scheduled to arrive at or after the last Milestone What Testing doesReviews or conducts formal inspections on the Product Specification If all of the specs cannot be inspected prioritize which ones are the most critical or risky and do them first Drafts a Test Plan and submits it for review by Development and Program Management Initiates a new RAID database Migrates postponed bugs from previous versions Adds bugs reported by Product Support What User Education doesReviews the spec for issues such as usability completeness relationship to other product features user tasks etc Provides feedback to program management on any potential problems Finalizes UE strategy and creates initial schedule to determine scope of work resources handoffs and so on The work definition and schedule are not final until the spec is considered final or done What the Management team does Assesses the postmortem from the previous project and decides how to improve their process in this project Assesses what they would like to learn in this project and sets up metrics collection for that purpose e g bug causal analysis labor tracking techniques for reducing the bugs exposed to testing etc Defines how deliverables between groups ie Testing and Development will be handled Agrees to the project schedule Milestone n PurposesDevelop the product Keep the code stable and the active bug count low StartsWhen coding begins EndsWhen Testing certifies that the code meets the Project Plan 抯 goals for schedule and quality Standard termsTest Specification defines the testing requirements for an area of the product Test Cases defines how to test a feature or set of features Test Scripts a keystroke by keystroke description of a test case most automated testing consists of test scripts Unit Testing tests developed and run by Developers to find bugs before code is released to Testing Testing Release Document TRD written by Development to define which parts of the product are testable and which are not Delivered to Testing as part of a Milestone release Check in the process of inserting newly written or modified code from the developer 抯 machine into the rest of the project on a public server Check in Test a test run by an individual developer prior to check in to determine whether their code will cause defects in other parts of the product Build Verification Test BVT a test run after the product is built to verify that newly incorporated code does not affect the general stability of the product The actual tests run for the BVT may be the same as those run for smoke tests or they may be more extensive Acceptance Test a test to determine whether the product is testable Typically run by Testing before formal testing begins it determines whether there are bugs which block feature testing whether automated test cases can be run whether test data can be loaded or whether there are any other impediments to effect and efficient testing Pre release testing and private builds informal testing done by testers before a formal release is made Pre release testing may be used in place of Acceptance Tests to determine whether a product is ready for formal testing Daily builds the practice of building the product daily and running BVTs The purpose of a daily build is to keep the code base stable Milestone Postmortems a team review of at the end of each milestone The goal is to honestly access progress and look for changes in the process that will avoid any current issues or problems The schedule or feature set may be revised based on the Milestone Postmortem Bug Committee a committee consisting of a representative from Program Management Development Testing User Education and Product Support which decides the final resolution of issues in RAID which are candidates for being resolved as WON 扵 FIX or POSTPONED What Development doesDesigns documents and writes code Tests code through unit testing smoke testing daily builds and BVT 抯 Writes TRD for formal release Resolves reported bugs Tracks development progress against schedule What Testing doesDesigns and documents test specifications and test cases Writes automated scripts Runs acceptance tests on code submitted for formal testing runs test cases on milestone releases Reduces bugs to the minimum reproducible steps reports them in RAID closes them if appropriate after they are resolved Assesses and reports on product quality and feature completeness certifies when code meets project goals May also review user documentation What User Education doesWrites content for all documentation learning aides and any other assistance included with the product Works closely with program management and development to access success of features based on user task analysis and actual drafts of documentation May write code or macros for learning aides or assistance tools Works with testing on a test plan for UE components Code Complete System Testing PurposeTo complete feature development and code optimization to test the product as a system with all features in place StartsWhen the Code Complete milestone code is accepted by Testing EndsWhen the active bug count hits zero for the first time Zero Bug Bounce Standard termsAlpha testing Internal Beta a release of a code complete product within Microsoft for the purpose of allowing more people to use the product and find defects Marketing Beta testing a release of a code complete product to selected customers for the purpose of demonstrating product stability and features Technical Beta testing a release of a code complete product to selected users for the purpose of finding defects Configuration testing the process of testing a product on a wide variety of hardware and software configurations to find defects related to configurations Printer testing the process of testing a product on a wide variety of printers to find defects related to printers and printer drivers Test Passes a complete execution of all test cases for a given product Zero Bug Bounce ZBB the first time development releases a version which has resolves all active defects when it was made This occurs after code complete From Zero Bug Bounce to Release to Manufacturing Development will make releases almost daily which fixes