all rights reserved by guangdong mobile communications co., ltd. team software process 张笑燕...

of 187 Why Study TSPi? TSPi guides students in effective teamwork and process methods. TSPi provides defined team roles. When students team members have explicit roles and the role responsibilities are clearly defined and visible, instructors can provide fairer and more specific grades.

of 187 Reference Introduction to the Team Software Process Watts S.Humphrey Tsinghua University Press Dec. 2002 TSPLeading a Development Team Watts.Humphrey Posts & Telecom Press Jul.2006 Managing the Software Process Watts.Humphrey Tsinghua University Press Aug. 2002 PSP A Self-Improvement Process for Software Engineers Watts.Humphrey Posts & Telecom Press Apr.2006 Introduction to the Personal Software Process Watts.Humphrey Posts & Telecom Press Oct.2002.

of 187 Prerequisites Introduction to the personal Software Process The C Programming Language

of 187 The Criteria of Grading Unannounced quiz 10 Midsemester 20 Final 70

of 187 Contents What is TSPi? The TSPi design. The TSPi structure and flow. The TSPi development strategy.

of 187 Vocabulary Postmortem

of 187 What Is TSPi TSPi Introduction to the Team Software Process provides a structured set of steps, shows engineers what to do at each step, and demonstrates how to connect these steps to produce a completed product. TSPi is a reduced-scale version of TSP. It does, however, retain the same basic concepts and methods.

of 187 TSPi Design Provide a simple framework that builds on the foundation of Personal Software Process PSP . Develop products in several cycles. Establish standard measures for quality and performance. Provide precise measures for teams and students. Use role and team evaluations. Require process discipline. Provide guidance on teamwork problems.

of 187 TSPi Structure and Flow Cycle 1 Launch Strategy 1 Plan 1 Requirements 1 Design 1 Implementation 1 Test 1 Postmortem 1 Cycle 2 Launch Strategy 2 Plan 2 Requirements 2 Design 2 Implementation 2 Test 2 Postmortem 2 Cycle 3 Launch Strategy 3 Plan 3 Requirements 3 Design 3 Implementation 3 Test 3 Postmortem 3

of 187 Development Strategy When you start a cyclic development strategy, the best plan is to begin with the smallest viable product version. In deciding the size and content of each cycle, you should consider the following constraint. Each cycle should produce a testable version that is a proper subset of the ultimate product. Each cycle should be small enough to be readily developed and tested in the available time. When combined the cycle products should produce the desired final product.

of 187 Vocabulary Teamwork Knit Procrastination Cohesion Jell Arbitrary , , ,

of 187 Contents Why projects fail. Why projects fail. Common team problems. Common team problems. What is a team? What is a team? Effective teams. Effective teams. How teams develop. How teams develop. How TSPi builds teams. How TSPi builds teams.

of 187 Why Projects Fail A poor or ineffective response to pressure is often the cause of project failure. The apparent source of pressure in software projects is the need to meet a tight schedule. By guiding teams through a strategy and planning process, the TSPi shows teams how to handle pressure. TSPi can help teams manage their projects more effectively. Teams are much more likely to do a quality job.

of 187 Common Team Problems Ineffective Leadership Failure to Compromise or Cooperate Lack of Participation Procrastination Poor Quality Ineffective Peer Evaluation

of 187 Common Team Problems Ineffective Leadership Without effective leadership, teams generally have trouble sticking to their plans and maintaining personal discipline. Although effective leadership is essential, few people are natural leaders. Most of us need to develop our leadership skills and to get practice using them. Chapter 11 gives you helpful pointers on how to perform the team leaders role most effectively.

of 187 Common Team Problems Failure to Compromise or Cooperate Occasionally one or more team members may not be able to work cooperatively with the team. Peer pressure can often resolve such problems.

of 187 Common Team Problems Lack of Participation Although some degree of variation in participation is normal, it is important that all team members strive to meet the teams goals. If it is clear that someone is not making a serious effort, team spirit generally suffers.

of 187 Common Team Problems Procrastination Some teams dont set deadlines or establish goals and milestones. Others set deadlines they never meet. Such teams generally dont track performance and often fail to make decisions in a timely or logical way. They take excessive time to get started, and they drift through their projects rather than attacking them.

of 187 Common Team Problems Poor Quality Quality problems can come from many sources. For examples: a superficial requirements inspection, a poorly design, or sloppy implementation practices. When teams dont use personal reviews or team inspections, they usually have quality problems. The results are extensive testing, delayed schedules, long hours and an unsatisfactory final product.

of 187 Common Team Problems Ineffective Peer Evaluation Experience has shown that peer evaluation can be invaluable for student teams. Students are often reluctant to grade their teammates and rarely do so with complete candor. As a result, students often feel that the grading in team courses is not entirely fair, particularly to the highly motivated students.

of 187 What is a Team? A team consists of at least two people, who are working toward a common goal/objective/ mission where each person has been assigned specific roles or functions to perform, and where completion of the mission requires some form of dependency among the group members.

of 187 Effective Teams An effective team is a group of people so strongly knit that the whole is greater than the sum of the parts.

of 187 Effective Teams Team Cohesion Members of highly cohesive groups communicate freely and often. Although they need not be good friends, they work closely together and respect and support each other. In less cohesive groups, members tend to function as individuals. They have trouble compromising and dont have common values and goals.

of 187 Effective Teams Cont. Challenging Goals First, these goals must be specific and measurable. Second, the teams goals must represent a significant challenge.

of 187 Effective Teams Cont. Feedback Goal tracking and feedback are critically important. Effective teams are aware of their performance and can see the progress they are making toward their goals.

of 187 Effective Teams Cont. Common Working Framework All team members must feel that the tasks are achievable, must understand their roles and responsibilities, and must agree on how to accomplish them.

of 187 How Teams Develop At the outset, most teams start with individuals who have diverse goals. As teams jell, the members come to accept a common set of team goals. The TSPi supports this jelling process by walking teams through a launch procedure. Even though the goals may be arbitrary, the team members will pursue them with enormous energy.

of 187 How TSPi Builds Teams Goals The TSPi helps members accept the team goals by having all team members participate in defining them.

of 187 How TSPi Builds Teams Roles Immediately after goals, the next issue is responsibilities. How can teams get all members to take responsibility for their parts of the job? The TSPi addresses this issue by establishing team member roles.

of 187 How TSPi Builds Teams Plans After the team agrees on its goals and roles, it next agrees on a strategy and a plan for achieving these goals.

of 187 How TSPi Builds Teams Communication among team members When team members dont know the status of each others work, they can not coordinate their work. The TSPi addresses this problem by calling for regular weekly team meetings. With their defined goals, roles and plans, teams members can communicate crisply and concisely.

of 187 How TSPi Builds Teams External Communication Often, teams communicate with the manager or the instructor when they are in trouble. Managers and instructors see only problems and not successes, and that puts the team in a poor light. The team cannot take advantage of the instructors or managers knowledge and experience. TSPi calls for the team leader to make weekly summary reports to the instructor.

of 187 Summary Why projects fail. Common team problems. What is a team. Effective teams. How teams develop. How TSPi builds effective teams.

of 187 Homework Impact of TSPi on Software Projects Cuevas, G.; Calvo Manzano, J.; San Feliu, T.; Electronics, Robotics and Automotive Mechanics Conference, 2007. CERMA 2007 25-28 Sept. 2007 Page(s):706 711 Electronics, Robotics and Automotive Mechanics Conference, 2007. CERMA 2007 Chapter 1115

of 187 Contents Student information Product Objectives Team Roles Team Goals Goal Setting for TSPi Team Member Goals The Role Goals Team Meetings The First Team Meeting Data Requirements

of 187 Student Information To be most effective, teams need a mix of talents and abilities. Team members also need to spend time together and have complementary interests and abilities. To provide the necessary information, the students need to complete the INFO form. The instructor uses this information to make the team and role assignments.INFO

of 187 Product Objectives Please refer to Project Practice .

of 187 Team Roles Team Leader Development Manager Planning Manager Quality/Process Manager Support Manager To the extent practical, every student should be exposed to several roles.

of 187 Team Goals Goals setting is an essential step in team formation and should usually be done at the start of every project. The goals establish the framework for strategy and the plan. Without defined goals, there is no orderly way to settle arguments, negotiate strategies, or plan the work. Why Team Goals?

of 187 Set aggressive but realistic goals; Set specific and measured goals; Goal-setting Consideration Team Goals

of 187 Goal Setting for TSPi Team Goal 1: Produce a quality product. Measure 1.1 Percent of defect found before the first compile Process Yield 80 Measure 1.2 Number of defects found in system test 0 Measure 1.3 Requirements functions included at project completion 100 Team Goal 2 Run a productive and well-managed project. Measure 2.1 Error in estimated product size

of 187 Defect Ratios provide insight into the quality of the design and code review. Code review/compile defect ratio (>2) when engineers find twice as many defects in a code review as they find in compiling, they have generally done a good code review. Design review/unit test defect ratio (>2) TSPi Planning Process

of 187 Development time ratios Requirement inspection / requirement >= 25 HLD inspection / HLD >= 50 DLD / code >= 100 DLD review/DLD >= 50 Code review / code >= 50 TSPi Planning Process

of 187 A/FR Appraisal to Failure Ratio is the ratio of the time spent in appraisal-type activities (such as reviews and inspections) to the time spent in failure-type activities (such as compile and test). In PSPi A/FR>2 In TSPi A/FR=1. TSPi Planning Process

of 187 Requirement reviews and inspections: < 2.0 single- spaced text pages/hour HLD reviews and inspections:

of 187 Defect-injection Rates When you have data on defect-injection rates, you have a basis for estimating how many defects you will inject during each phase of a programming job. TSPi Planning Process

of 187 Defect-removal Rates When you have data on defect-removal rates, you have a basis for estimating how many defects you will remove during each phase of a programming job. TSPi Planning Process

of 187 Phase Yields refers to the percentage of the defects in a program that were removed during a given phase. Ex If you had 19 defects in a program at code review entry, injected 1 defect during the code review, and found 15 of these defects in the review, then Code review yield = (defects found) / (defects in the product) =15 / (19+1) =75% TSPi Planning Process

of 187 Process Yields measures the percentage of the defects removed before a given phase. Ex 30 defects were injected and 20 defects were removed before compile. Thus the process yield before compile is 66.7% (20/30). You must strive for the process yields of 75 before the first compile and 85 before the first unit test. TSPi Planning Process

of 187 Use the TSPi tool to generate the final quality plan on form SUMQ the team-level quality plan . P88 SUMQ TSPi Planning Process

of 187 7. Fill in the blanks in form SUMP according to form SUMQ and form TASK. P93 SUMP 8. Produce the individual engineer plans. 9. Balance team workload. TSPi Planning Process

of 187 Team TASK form Team SCHEDULE form Engineer TASK form Engineer SCHEDULE form Team SUMP form Team SUMQ form Team SUMS form. 10. Exit Criteria TSPi Planning Process

of 187 Contents Why We Need Requirements? The SRS Why the SRS is Important? Requirements Process

of 187 Why We Need Requirements Through requirements development, your team gains a common understanding and agreement on what to build.

of 187 The SRS Focus the SRS (Software Requirements Specification) on what the product is to do and avoid specifying how it will be designed and built. For TSPi, you will concentrate on the functional and operational requirements. Functional requirements External interface requirements Design constraints Attributes Other requirements

of 187 Why SRS is Important Users generally cannot know precisely what they need until they try to use the finished product. Thus the requirements almost always change, and they keep on changing until they are frozen in a product. There is no such things as a free requirements change. All changes cost time and money. The SRS helps you to manage changes. After the customers have read the SRS and agreed with its contents, you can argue that any changes will cost time and/or money.

of 187 Requirements Process Need statements Development strategy Development plan. 1. Entry Criteria

of 187 2. Need Statement Review The development manager leads the team in reviewing the product need statement and ensures that all questions are clarified among the team members or noted for discussion with the customer. Requirements Process

of 187 3. Need Statement Clarification The development manager reviews the list of questions and the team clarification notes with the customer who discusses the answers with the team. Requirements Process

of 187 The development manager leads the team through outlining the SRS document and the work to produce it The team leader allocates the tasks among the team members and obtains commitments for when they will complete these tasks. 4. Requirements Task Allocation Requirements Process

of 187 Each team member Produces and reviews his or her portions of SRS document; Provides these to the development manager. The development manager produces the SRS draft. 5. Requirements Documentation Requirements Process

of 187 6. System Test Plan The development manager leads the team in producing and reviewing the system test plan. Requirements Process

of 187 The quality/process manager leads the team through Inspecting the SRS draft and system test plan Identifying questions and problems Defining who will resolve each question and problem and when Documenting the inspection in form INS.INS 7. Requirements and System Test Plan Inspection Requirements Process

of 187 The development manager obtains the updated SRS and system test plan sections and Combines them into a final SRS and system test plan Verifies traceability to the need statement or other sources. 8. Requirements Update Requirements Process

of 187 9. User SRS Review Have the end users read the SRS and agree that it describes what they want. Requirements Process

of 187 10. Requirements Baseline The support manager baselines an official SRS copy, which the team can now change only by using the change control procedure (form CCR).CCR Requirements Process

of 187 The completed, inspected and updated SRS and system test plan under configuration control All personal time, defect and size data entered in the TSPi forms and support system (LOGT LOGD SUMS TASK SCHEDULE SUMP SUMQ) The completed inspection form (INS) from the requirements inspection Updated project notebook. 11. Exit Criteria Requirements Process

of 187 Contents Design Principles Using the Entire Team Design Standards Designing for Reuse The SDS Design Process

of 187 Design Principles After the requirements have been defined, the entire software process concerns various levels of design. The high-level design must produce a SDS Software Design Specification which includes the complete functional specifications of each component, its interface and its state behavior. The detailed design defines the logical structure, all the loop initialization and stepping conditions, the detailed state structure, and the state transitions for every program. High-level design differs from detailed design only in scope and detail. In TSPi, the high-level design process is described in the design phase. The detailed-design process is described in the implementation phase.

of 187 Using the Entire Team The entire team brainstorms the initial design ideas. After the team has picked a general approach, only one or two engineers are usually needed to document the highest level design, specify the interface, allocate system functions among the components, and define the overall program structure and logic Other engineers can do other tasks: design studies, standards development, and reuse.

of 187 Design Standards Naming conventions Interface formats System and error messages Defect standards LOC counting Design representation standards

of 187 Designing for Reuse Reuse interface standards Reuse documentation standards Reuse part quality Application support. Reuse is a potentially powerful way to increase team productivity. By establishing a reuse program, you can often save engineering time in development cycles. During the high-level design phase, a team should identify likely common functions and proposing an initial set of reusable parts.

of 187 The SDS Decide on the overall product structure Allocate product functions to components Produce the component external specification Decide which components and functions to develop in each development cycle. The design process produces the SDS (Software Design Specification), which defines the overall product structure.

of 187 Design Process A development strategy A development plan A completed and inspected SRS 1. Entry Criteria

of 187 Defining the cycle-1 product structure Naming the product components Allocating use cases to these components Identifying the design tasks to be completed and documented. 2. High-level Design The development manager leads the team through Design Process

of 187 3. Design Standards The quality/process manager leads the effort to produce the name glossary and design standards. Design Process

of 187 4. Design Task Allocation The development manager leads the team through outlining the SDS document and the work to produce it. The team leader allocates the tasks among the team members and obtains commitments for when they will complete these tasks. Design Process

of 187 Each team member Produces and reviews his or her portions of the SDS document Provides these to the development manager The development manager produces a composite SDS draft. 5. The Design Specification Design Process

of 187 6. Integration Test Plan The development manager leads the team in producing and reviewing the integration test plan. Design Process

of 187 Every use case is covered and referenced in the design The design is complete and correct The integration test plan is adequate Each problem is recorded and fix responsibility assigned 7. Design and Integration Test Plan Inspection The quality/process manager leads the team through inspecting the SDS draft and integration test plan so that The inspection is documented in form INS and defects are recorded in LOGD. INSLOGD Design Process

of 187 The development manager obtains the updated SDS and integration test plan sections and Combines them into a final SDS and integration test plan Verifies traceability to the SRS 8. Design and Integration Test Plan Update Design Process

of 187 The support manager baselines an official SDS copy, which the team can now change only by using the change control procedure (form CCR). 9. Design Baseline Design Process

of 187 The completed, inspected and corrected SDS The completed, inspected and corrected integration test plan The design standard and name glossary The completed inspection forms (INS) Updated SUMP and SUMQ forms Updated the project notebook 10. Exit Criteria Design Process

of 187 Contents Design Completion Criteria Implementation Standards Implementation Strategy Reviews and Inspections Implementation Process

of 187 Scrap , , Vocabulary

of 187 Design Completion Criteria For large systems, high-level design often requires several stages At the first level, you subdivide the system into subsystems, components, or modules If these subsystems are reasonably large, repeat the high-level design process for each subsystem or component At the end, you should have the external specifications for each subsystem, component, or module and should also have the detailed design of the highest level logic for the system.

of 187 Implementation Standards Standards review Naming, interface, and message standards Coding standards Size standards Defect standards Defect prevention The implementation standards add to and extend the standards defined during the design phase

of 187 Review the name, interface and message standards developed during the design phase Check that the list of the reusable routines is complete and that all the team members are using it Review the name glossary Check the component and subelement names and review the shared variable, parameter and file names for consistency Check the standard interfaces and messages. Standards Review Implementation Standards

of 187 Pick the defect types that seem to be causing the most trouble. These defects may waste the most test time, be hardest to diagnose and fix, or otherwise be most annoying Examine a number of defects of this type to identify particular defect causes and divide which ones to address When you see a defect you think you can prevent, make a process change to prevent it Assuming this action is effective, start looking for the next defect category and handle it the same way. Defect Prevention Implementation Standards

of 187 Implementation Strategy Review Reuse Testing The implementation strategy should generally conform to the design strategy

of 187 Reviews and Inspections Many implementation defects are simple transcription mistakes that result from random keystroke errors Finding some of these errors in test can be exceptionally hard Reviews and inspections can consider all the paths and data values for a logical program segment. That is why reviews and inspections are much more efficient than testing.

of 187 Design Inspections It is hard to find sophisticated design defects when doing a review or inspection of a source program To produce quality programs, you must produce thorough and complete design documents and then review, inspect, and fix them before you start coding.

of 187 Implementation Process A completed development strategy and plan Completed, reviewed and updated SRS and SDS specifications A defined and documented coding standard Available copies of routine functional specification list, name glossary, and all the other standards the team has adopted. 1. Entry Criteria

of 187 The development manager leads the work to Define and plan the implementation tasks ( SUMP, SUMQ). 2. Implementation Planning The team leader allocates the tasks among the team members and obtains commitments for when they will complete these tasks. 3. Task Allocation Implementation Process

of 187 The engineers produce the detailed design Do a design review using thorough design review methods Complete forms LOGD and LOGT. 4. Detailed Design and Design Review Implementation Process

of 187 The engineers produce the unit test plans The engineers follow script UT to develop the unit test cases, test procedures and test data. 5. Unit Test Plan Implementation Process

of 187 The quality/process manager leads the team in a DLD inspection of each component Complete forms LOGD and INS. 6. Detailed-Design Inspection Implementation Process

of 187 The engineers produce the component source code. Do a code review using a personal checklist Compile and fix the code until it compiles without error Complete forms LOGD and LOGT. 7. Code, Code Review and Compile Implementation Process

of 187 The quality/process manager leads the team in a code inspection of each component Complete forms INS, LOGD and LOGT. 8. Code Inspection Implementation Process

of 187 The engineers, following script UT Conduct the unit tests Complete forms LOGD and LOGT. 9. Unit Test Implementation Process

of 187 If so, the component is accepted for integration testing If not, the quality/process manager recommends Either that the product be re-inspected and reworked Or that it be scrapped and redeveloped. The quality/process manager reviews each components data to determine if component quality meets established team criteria. 10. Component Quality Review Implementation Process

of 187 When the components are satisfactorily implemented and inspected, the engineers release them to the support manager The support manager enters the components in the configuration management system. 11. Component Release Implementation Process

of 187 Completed, inspected, configuration-controlled components Completed INS forms for the design and code inspections Unit test plans and support materials Updated LOGT LOGD SUMS TASK SCHEDULE SUMP and SUMQ forms Updated project notebook. 12. Exit Criteria Implementation Process

of 187 Contents Testing Principles The TSPi Testing Strategy Build and Integration Strategy System Test Strategy Test Planning Tracking and Measuring Testing Documentation The Test Process

of 187 Regression Delve Stub Scaffold Terminology Vocabulary

of 187 Testing Principles In TSPi, the purpose of testing is to assess the product and not to fix it. You should have found and fixed almost all the defects before the testing phase. The quality of a product is determined when it is developed. When you put a poor-quality product into test, you generally get a poor-quality product out of test.

of 187 TSPi Testing Strategy Build the System Using the developed and unit-tested parts, build the system Integration Test Integration-test the system to verify that it is properly built, that all the parts are present, and that they function together System Test System-test the product to validate that it does what the system requirements call for Regression Test In subsequent cycles, regression tests are also needed to ensure that the development work for this cycle has not unintentionally changed the functionality or performance produced in prior cycles.

of 187 Build and Integration Strategy The purpose of the build process is to ensure that all needed parts are present, to assemble a working system, and to provide this system to integration and system test. Integration testing should merely check that all the components are present and that all their calls and other interactions work. You should not test the components functions.

of 187 Put all the parts together and see whether they work. Advantage it requires the least amount of test development Disadvantage it is rarely successful, particularly with poor-quality systems. 1. Big-Bang Strategy Build and Integration Strategy

of 187 Advantage With each addition, you look for problems with the newly added parts Disadvantage This strategy requires more test development work. 2. The One-at-a-time Strategy Build and Integration Strategy

of 187 This strategy is to add parts in clusters. You identify a class of related components and integrate them. 3. The Cluster Strategy Build and Integration Strategy

of 187 Advantage You can detect system-wide issues early Disadvantage it usually requires large numbers of stubs or special scaffolding to provide dummy returns for all the functions that are not yet available. 4. The Flat-system Strategy This strategy is to integrate all the highest level parts first and then delve down into successive system layers in parallel. Build and Integration Strategy

of 187 System Test Strategy Firstly, test each of the systems intended functions Check operation under stress conditions, evaluate usability Finally, measure performance. 1. The Function-first Strategy

of 187 Cover all aspects of each functional area before moving to the next functional area. You might start by testing Numerical calculations for normal and adverse operation Usability Performance Quality 2. The Functional Area Strategy System Test Strategy

of 187 Test lower level functions for normal, abnormal and stress behavior Move to the next higher level and test functional aggregates to ensure that they work together. Check them under various normal and stress conditions Continue testing at progressively higher levels until you have covered the full system. 3. Combining the Preceding-two Strategy System Test Strategy

of 187 Test the highest level functions and work down, doing normal and stress tests 4. Reversing the Preceding Strategy System Test Strategy

of 187 Test Planning A list of all the testing steps to be performed The supporting materials required for each test The results that the tests are to produce An estimate of the defect-free run time, the defects to be found, and total time for each test An estimate of the work required to develop each item in the test plan. The completed testing plan should have

of 187 Tracking and Measuring Testing The test log (LOGTEST FORM) contains a summary of the tests run and the results obtained LOGTEST FORM With the test log data, you can readily determine which tests were run and which found the most defects You can also determine the test run time and the defects found per testing hour Data from this log can help you select the most efficient strategy for regression-testing modified programs.

of 187 Documentation In the TSPi test phase, part of the team drafts and reviews the user documentation while the rest of the team conducts the tests. A well-designed manual should be organized around the readers needs and not the products structure. Generally The first section should address what the user needs to know first how to get started Next, you might explain what the user can do with the product Finally, make it easy for people to find what they want to know.

of 187 Write short sentences Use simple words and phrases Use lots of lists and bulleted items. Documentation Writing Style

of 187 Document Organization Document Terminology Document Content Accuracy Readability Understandability Document Review Documentation

of 187 The Test Process You have the completed and inspected SRS and SDS specifications You have the implemented, inspected and unit-tested components under configuration controll For TESTn, you have a configuration- controlled prior version of the product. 1. Entry Criteria

of 187 Define any required build processes and procedures Develop the integration test procedures and facilities Develop the system test procedures and facilities Measure the size and running time for each test Review the test materials and correct errors. 2. Test Development The Test Process

of 187 Check all the needed parts to ensure that they are on hand and meet their dependency requirements Review the items supplied for the build and identify any missing pieces Check the proposed build for consistency and completeness. Build the product and provide it to integration test Record all defects in the defect log (LOGD) and all times in LOGTEST form. 3. Build The Test Process

of 187 Check the completeness of the built product Run the planned integration tests Record the test data in form LOGTEST If defects are found, complete a LOGD entry for every defect The quality/process manager should determine whether testing should continue or abort integration testing and conduct a complete inspection of these defective components. 4. Integration Test The Test Process

of 187 Test the product for normal and stress conditions Test the product for installation Record all test activities in form LOGTEST Record all defects in form LOGD. 5. System Test The Test Process

of 187 Produce the user-documentation outline and tasks Allocate these tasks to the documentation team Review the outline with the test team for completeness Draft the first-cycle user documentation Review, correct and produce the user documentation. 6. Documentation The Test Process

of 187 A completed, integrated and system-tested product version A complete test record in form LOGTEST Completed LOGD entries and a defect analysis for every defect found Completed and reviewed user documentation Updated SUMP, SUMQ, TASK, SCHEDULE and LOGT forms A copy of all the test data and forms in the project notebook. 7. Exit Criteria The Test Process

of 187 Contents Why We Need a Postmortem? The Postmortem Process

of 187 Why We Need a Postmortem The postmortem provides a structured way to improve your personal and team processes The TSPi uses form PIP (Process Improvement Proposal) to note any improvement ideas that occur to you.

of 187 Postmortem Process The team has completed and tested the product The engineers have gathered all the data and completed all the required forms. 1. Entry Criteria

of 187 Analyze project data and identify problem and improvement areas Compare both teams and each engineers personal performance with the quality plan. Assess where the process fell short and what could be done to improve it in the future Submit PIPs on these improvement suggestions. 2. Review Process Data Postmortem Process

of 187 Where they were effective Where there is room for improvement. Team leader leads the team in evaluating the effective of the team roles 3. Evaluate Role Performance Postmortem Process

of 187 Contents Summary Roles Reports Leadership Development Planning Quality/Process Support Engineer Reports 4. Prepare Cycle-1 Report Postmortem Process

of 187 Each engineer completes an evaluation of the team and of each team role using form PEER.PEER 5. Role Evaluation Postmortem Process

of 187 The team has produced a high-quality product, together with all the required documentation The completed product is under configuration control The process data have been evaluated, and PIPs have been completed and submitted The role evaluations have been completed (PEER) All TSPi forms have been completed The project notebook is updated. 6. Exit Criteria Postmortem Process

of 187 THANK YOU

all rights reserved by guangdong mobile communications co., ltd. team software process 张笑燕...

Documents