| Term | Definition or Formula |
| A/FR | Appraisal to failure ratio. A/FR = (appraisal time) / (failure time) |
| Appraisal time | Time spent appraising the product, either in personal reviews or inspections. |
| Assemblies | When a program has several parts, it is called an assembly. |
| Balanced plans | Team plans in which every engineer plans to complete his or her personal tasks at the same time. With a balanced plan, the schedule is minimized. |
| Baseline | The collection of documents and other materials that officially represent the product at any point in time. |
| Black-box testing | Testing that is done without knowledge of the program's internal structure. |
| Build | The build process assembles the system's parts for integration and system testing. One such assembly is called a build. |
| Capture-recapture | A method for estimating the size of a population. In TSPi, this method is used to estimate the number of defects remaining in a product after an inspection. |
| CCB | See configuration control board. |
| Checklist | A list of items to check in a review. In PSP and TSPi, checklists identify the most likely defects to look for. |
| Configuration change request (CCR) | The official means for transmitting to the CCB a requested change to the product baseline. |
| Configuration control board (CCB) | An engineering committe that reviews and approves the product baseline and proposed changes to it. |
| Configuration item list | The approved list of items to be included in the product or system baseline. It typically includes the product name, when baselined, the owner, and where stored. |
| Configuration management | The total set of activities used to manage the content of the product (the baseline) from the beginning to the end of the development process. |
| Configuration management plan | This plan includes, at a minimum, the configuration identification plan (configuration item list), the configuration control procedures, and the CCB membership. |
| Configuration | The CSR summarizes the status of the configuration status report (CSR) management system at any point in time. |
| Cyclic development | A development process that builds products in steps, each of which produces a working subset of the final product. |
| Defect | A requirements, design, or implementation element that, if not changed, could cause improper design, implementation, test, use, or maintenance. |
| Defect prevention | The process, method, tool, or other actions needed to prevent specific defect types from recurring. |
| Defect profile | A graph of the defect-removal history of a program by phase. It is typically given in defects/KLOC. |
| Defect-prone modules | Those modules in a system that, absed on their defect-removal history, are judged likely to have defects remaining. |
| Defect ratio | The ratio of the numbers of defects found in a review phase and a compile or test phase. Low ratios typically indicate low-quality reviews. |
| Defects/KLOC | The number of defects in a program, normalized by the number of KLOC in the
program. Defects/KLOC = 1000*(defects found)/LOC |
| Development cycle | The development activity that builds one product increment in a cyclic development process. |
| Earned value (EV) | The percent the estimated task hours are of the total project hours. EV is earned only when the task is fully completed. |
| Estaimated defects remaining | useing the capture-recapture method, the estimated remaining defects are T = A*B/C, where A is the number of major defects found by one engineer, B the number found by another engineer, and C the number found by both. |
| Facilitator | A person who helps teams hold efficient and effective team meetings. The principal responsibilities are to keep the meeting focused on the agenda and ensure that everyone participates. |
| Failure time | The time spent finding and fixing defects. In PSP and TSP, it is the total time an engineer spends compiling and unit-testing a program. |
| Inspection | A process in which several engineers review a product produced by another engineer to help find defects. |
| Integration test | The test that verifies that the system is properly built, that all the parts are present, and that they function together. |
| Issue | A known problem or concern that must be addressed. |
| KLOC | Thousands of lines of code, or LOC. |
| LOC | Lines of code, as defined in the team's lines-of-code standard. |
| Major defects | These are the problems that, when fixed, would change the executable program. |
| Minor defects | All defects that are not major. |
| Module | Modules are typically composed of mulitple objects or functions, and they are the smallest testable program element. |
| part | Any part of a system. It could be an object, module, component, product, or subsystem. Parts may also be assemblies of lower level parts. |
| Percent defect-free | |
| Peer review | See inspection |
| Percent defect-free | The percent of a system's parts that have no defects in a specified defect-removal phase. |
| Phase | Aprocess typically has several steps or phases, each one generally described by one or more scripts. |
| Phase yield | The percentage of teh defects in a product that are removed during a specified phase. Compile phase yield refers to the percentage of the defects in the product at compile entry or injected during compile that are removed during compile. See also yield. |
| PIP | The process improvement proposal, a TSPi form |
| Planned value (PV) | The percentage of the total job that is represented by a single task. |
| Prediction interval | The limits within which an estimate is likely to fall. Typical prediction intervals include a percentage, say 95%, of the items being estimated. |
| Process yield | The percentage of the defects injected before a phase that are removed before that phase. Yield before compile referes to the percentage of the defects injected before compile that are removed before compile. See also yield. |
| Product owner | The engineer responsible for maintinaing product design integrity and recording and tracking its efects, typically the developer. |
| Project notebook | The official record of all the team's estimates, work products, reports, plans, and forms. |
| Quality plan | The planned and actual quality performance of every part and assembly in the system. |
| Rates, inspection, and review | One measure of the quality of a review or an inspection. Typically, rates are measured in LOC or pages per hour. |
| Record | The person who documents meeting results, principally the decisions and planned actions. |
| Regression test | When programs are modified, functions that were previously tested may not longer work. Regression testing checks for such problems. |
| Reuse | The use of unmodified previously developed program elements in a new proggram. Typically, reused program elements are taken from a reuse library that is designed specifically for reuse. |
| Review | In the PSP and TSPi, reviews are done by engineers to find defects in their personally produced products. |
| Risk | A problem that may or may not occur. |
| Role | A defined area of responsibility for a team member. |
| Script | A listing of the actions required to accomplish a specific process or portion of a process. |
| SCM | Configuration management |
| SDS | Software design specification |
| Size standard | This specification how size is to be measures for each product tpye. It typically inclues the LOC counting method, the page standard, and design size measures. |
| Software configuration managment | See configuration managment |
| Software design specification | The rpgoram's or system's design, typically including the high-level design, the program architecture, interface definitions, and other important specifications. |
| Software requirements specification (SRS) | A description in the engineers' words of the product they plan to develop, typically reviewd by teh customers or users to ensure agreement on the needs. |
| System test | A test that stressted the system to deterin whether or not it functions properly in all important respects. |
| Task | An element of work in the development plan. In TSPi, the work is typically broken into tasks that can be done in about 10 engineer hours or fewer. |
| Test plan | Test test plan defines the tests t obe run, the expected test results, the materials needed for testing, and the plan for producing these materials. |
| Unit test | This white-box test verifies that the program structure is correct and that operation is proper with all normal and abnormal variable and parameter values. |
| White-box testing | Test that is done with knowledge of the program's internal logic and structure. |
| Yield | The percentage of the defects in a program that are removed from the program. See also phase yield and process yield. |