Purpo | Set goals and plans for the project |
Starts | With completion of the Vision Statement |
Ends | When coding begins |
Standard terms | Vision 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. | |
Ur Education Strategy/Design Document written by Ur 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 bad on the spec, and Testing says the document is sufficiently detailed that they can write Test Cas bad on the spec. The spec may be more complete for features of the first milestone than subquent ones. However, some groups have been adverly 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. | 1988年五行|
What Development does | Develops the Development Schedule and begins code design and architecture. Schedule should have buffers for vacation, sick time, unit or pre-relea testing, bug fixing and unpredictable events. Even with buffers, most development schedules are 30%-50% compresd. If the reliability of your ship date is important, increa 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 does | Reviews 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 databa. Migrates postponed bugs from previous versions. Adds bugs reported by Product Support. | |
What Ur Education does | Reviews the spec for issues such as usability, completeness, relationship to other product features, ur 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 | Asss the postmortem from the previous project and decides how to improve their process in this project. 初二学习计划 |
Asss what they would like to learn in this project and ts up metrics collection for that purpo (e.g. bug causal analysis, labor tracking, techniques for reducing the bugs expod to testing, etc.) | |
Defines how deliverables between groups (ie. Testing and Development) will be handled. | |
Agrees to the project schedule. | |
Purpos | Develop the product |
Keep the code stable and the active bug count low | |
Starts | When coding begins |
Ends | When Testing certifies that the code meets the Project Plan抯 goals for schedule and quality |
Standard terms | Test Specification defines the testing requirements for an area of the product |
游园不值Test Cas defines how to test a feature or t of features | |
Test Scripts a keystroke by keystroke description of a test ca (most automated testing consists of test scripts) | |
Unit Testing tests developed and run by Developers to find bugs before code is relead to Testing | |
Testing Relea 无踪无影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 relea. | |
Check-in the process of inrting newly written or modified code from the developer抯 machine into the rest of the project on a public rver. Check-in Test a test run by an individual developer prior to check-in to determine whether their code will cau 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 tho 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 cas can be run, whether test data can be loaded, or whether there are any other impediments to effect and efficient testing. | |
Pre-relea testing and private builds informal testing done by testers before a formal relea is made. Pre-relea testing may be ud 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 purpo of a daily build is to keep the code ba 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 t may be revid bad on the Milestone Postmortem. | |
Bug Committee a committee consisting of a reprentative from Program Management, Development, Testing, Ur 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 does 多希望你在 | Designs, documents and writes code. Tests code through unit testing, smoke testing, daily builds and BVT抯. Writes TRD for formal relea. Resolves reported bugs. Tracks development progress against schedule |
What Testing does | Designs and documents test specifications and test cas. Writes automated scripts. Runs acceptance tests on code submitted for formal testing, runs test cas on milestone releas. Reduces bugs to the minimum reproducible steps, reports them in RAID, clos them, if appropriate, after they are resolved. Asss and reports on product quality and feature completeness, certifies when code meets project goals. May also review ur documentation. |
What Ur Education does | Writes content for all documentation, learning aides, and any other assistance included with the product. Works cloly with program management and development to access success of features bad on ur 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. |
Purpo | To complete feature development and code optimization, to test the product as a system with all features in place |
Starts | When the Code Complete milestone code is accepted by Testing |
Ends | When the active bug count hits zero for the first time (Zero Bug Bounce) |
Standard terms | Alpha testing (Internal Beta) a relea of a code complete product within Microsoft for the purpo of allowing more people to u the product and find defects Marketing Beta testing a relea of a code complete product to lected customers for the purpo of demonstrating product stability and features Technical Beta testing a relea of a code complete product to lected urs for the purpo 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 Pass a complete execution of all test cas for a given product Zero Bug Bounce (ZBB) the first time development releas a version which has resolves all active defects when it was made. This occurs after code complete. From Zero Bug Bounce to Relea to Manufacturing, Development will make releas almost daily which fixes all outstanding defects. | 出国留学推荐信
Purpo | Stabilize code and relea |
Starts | With Zero Bug Bounce |
Ends | With relea to manufacturing (RTM) |
Standard terms | 矿物材料Relea Candidates a preliminary relea of the software on distribution media (diskettes, CD-ROM) which may become the relead product. Relea candidates are usually numbered, and start after Zero Bug Bounce. The last relea candidate is the one that is ud for duplication in manufacturing. Code Reviews review of code changes by people other than the developer who made them. Changes to the product after Zero Bug Bounce may de-stabilize the product. Since there is not enough time before RTM for a full test pass, code reviews are ud to make sure late changes to do not cau unintended defects. Golden Masters Relea candidates that are ud for duplication Sign-off the approval of Testing, Development, Program Management and Product Support that a relea candidate is ready for Relea to Manufacturing. Signatures are collected on a form distributed by Manufacturing. |
本文发布于:2023-05-14 13:47:47，感谢您对本站的认可！
本文链接：https://www.wtabcd.cn/fanwen/fan/82/627931.html
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。
| 留言与评论（共有 0 条评论） |
