This is part of the supporting material from our first book, Applied Software Project Management, which was published by O’Reilly in 2005. You can see all of the material here: https://www.stellman-greene.com/applied-software-project-management/
This glossary contains terms defined in Applied Software Project Management.
| accountability | A person is accountable for a task if failure to adequately perform that task carries professional consequences. These professional consequences can take one or more of four possible forms: • His reputation is damaged among his peers and in the organization • His manager gives him a poor performance review • His compensation is reduced • His responsibilities are changed (or taken away altogether if he is fired) |
| actual | Most scheduling software packages track two kinds of schedules. One is a fixed baseline version which is kept as a reference, and the other is an actual version of the schedule which is updated to reflect what actually happened over the course of the project. The baseline schedule never changes over the course of the project. |
| alpha build | A high-quality, feature-complete build of the software. |
| alternative paths | In use cases, an alternative path provides behavior which is similar to the basic course of events but which differs in one or more key behaviors. |
| assumptions | Used in estimation to deal with incomplete information. By making assumptions, team members can leave placeholders for information that can be corrected later, in order to make the estimate more accurate. |
| authority | A person has authority to perform a task only if he is has adequate control over the resources necessary to complete the task. Giving a project manager authority to carry out a project means giving him control over the resources (people, office space, hardware, software, etc.) required to complete it. Since resources cost money, sufficient budget for the project must be allocated within the organization. |
| baseline | A baseline is a fixed schedule which represents the standard that is used to measure the performance of the project. Every time a change to the scope of the project is approved, the schedule should be adjusted and a new revision of the baseline should be used instead. Many project management software packages have a feature which allows the project manager to maintain a baseline schedule and track revisions to it. |
| basic course of events | Consists of a series of steps. The first step will generally be the action that the user takes in order to initiate the use case. The remaining steps are a series of interactions between the user and the software. Each interaction consists of one or more actions that the user takes, followed by a response by the software. In this case, the software is responding to the user entering the search term and replacement text and indicating that the replacement should occur. |
| boundary conditions | Inputs at the edge of the range of acceptable values. There are many kinds of boundary conditions, including: • Zero values, null values or other kinds of empty or missing values • Very large or very small numbers that don’t conform to expectations (like a rate of 10000%, or an account that has been active for a million years) • Arrays and lists that contain duplicates or are sorted in unexpected ways • Events that happen out of order, like accessing a database before it’s opened • Badly formatted data (like an invalid XML file) |
| buffer | A buffer is a task added to the schedule with no specific purpose except to account for unexpected delays. This practice involves either adding extra tasks or padding existing tasks at strategic points in the schedule where overruns are “expectedâ€. There are times when buffers are useful. For example, on a year-long project, if every programmer has two weeks of vacation and on average takes one week of sick days, then the project is guaranteed to lose three person-weeks of effort over the course of the year. The project manager could sprinkle three person-weeks of buffers at strategic points in the schedule in order to accommodate for this known loss. The use of buffers in this case is appropriate, because the size of the loss is known. However, there are many times when buffers are abused. The idea that overruns are expected means that there is an implicit assumption that the estimate is incorrect. Buffers should not be used to add time to compensate for an inaccurate estimate. |
| Capability Maturity Model (CMM) | A process improvement method that was developed by the Software Engineering Institute at Carnegie Mellon University. It provides a set of best practices meant to address important aspects of software development: productivity, performance, costs, predictability, and stakeholder satisfaction. The purpose of the CMM is to define the characteristics of a mature, capable process in a way that can be measured and compared to processes at other organizations. |
| change control | A method for implementing only those changes that are worth pursuing, and for preventing unnecessary or overly costly changes from derailing the project. Change control is essentially an agreement between the project team and the managers that are responsible for decision-making on the project to evaluate the impact of a change before implementing it. Many changes that initially sound like good ideas will get thrown out once the true cost of the change is known. The potential benefit of the change is written down, and the project manager works with the team to estimate the potential impact that the change will have on the project. This gives the organization all of the information necessary to do a real cost-benefit analysis. If the benefit of the change is worth the cost, the project manager updates the plan to reflect the new estimates. Otherwise, the change is thrown out and the team continues with the original plan. |
| change control board | The change control board analyzes the impact of requested changes to the software and has the authority to approve or deny any change requests once development is underway. Before the project begins, the list of CCB members should be written down and agreedupon, and each CCB member should understand why the change control process isneeded and what their role will be in it. |
| COCOMO II | The Constructive Cost Model, or COCOMO, is a software cost and schedule estimating method developed by Barry Boehm in the early 1980s. Boehm developed COCOMO empirically by running a study of 63 software development projects and statistically analyzing their results. COCOMO II was developed in the 1990s as an updated version for modern development lifecycles, and it is based on a broader set of data. The COCOMO calculation incorporates fifteen cost drivers, variables which must be provided as input for a model that is based on the results of those studied projects. These variables cover software, computer, personnel and project attributes. The output of the model is a set of size and effort estimates that can be developed into a project schedule. |
| code review | A special kind of inspection in which the team examines a sample of code and fixes any defects in it. In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved (for example, it could be made more readable or its performance could be improved). In addition to helping teams find and fix bugs, code reviews are useful for both cross-training programmers on the code being reviewed and for helping junior developers learn new programming techniques. |
| cost performance index (CPI) | CPI is calculated by dividing BCWS / ACWP (budgeted cost for work scheduled/actual cost for work performed) and multiplying by 100 to express it as a percentage. A CPI of 100% means that the estimated cost was exactly right and the project came in exactly on budget. If it is under 100%, the work cost less effort than planned; a CPI greater than 100% means that the estimate was not adequate for the work involved. CPI can be used either to compare projects with each other or to compare phases within a project. For example, if the programming tasks took twice as long as estimated but every other type of task in the project took less time than estimated, the total variance for the project might still be low. However, the problem can still be pinpointed by calculating the CPI for each phase of development. |
| defect | Behavior that is counter to specified software requirement. |
| defect triage | Minimally, the defect workflow should track the interaction between the testers who find the defect and the programmers who fix it, and it should ensure that every defect can be properly prioritized and reviewed by all of the stakeholders to determine whether or not it should be repaired. This process of review and prioritization referred to as triage. This somewhat dramatic name comes from triage of patients in an emergency room: the patients with the most severe injuries must get medical attention first. It is the same way with software defects, where the most severe defects are given the highest priority. |
| dependency | A task has a dependency if it involves an activity, resource or work product which is subsequently required by another task. Dependencies come in many forms: a test plan can’t be executed until a build of the software is delivered; code might depend on classes or modules built in earlier stages; a user interface cannot be built until the design is reviewed. If Wideband Delphi is used to generate estimates, many of these dependencies will already be represented in the assumptions. |
| deskcheck | A simple review in which the author of a work product distributes it to one or more reviewers. In a deskcheck, the author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author. |
| duration | The amount of time that elapses between the time the task is started and the time it is completed, measured in hours (or days, weeks, etc.). It does not take into account the number of people performing the task. |
| earned value management | Tracks the project by considering effort “earned†against a budget only after it has actually been performed. For software projects, the variance is a measurement in person-hours (or person-days, person-years, etc.) that shows the difference between the effort planned to date on the baseline and the effort completed on the actual schedule. The budgeted cost for work scheduled (BCWS) is the estimated effort of the actual tasks that appear on the schedule to date. The actual cost of work performed (ACWP) is the effort spent on the tasks in the schedule that have actually been completed by the development team members. The data required to calculate this information can be gathered by comparing the effort represented in the baseline schedule (to find the budgeted cost) with the effort in the actual schedule. (Many project management software packages will calculate these numbers automatically.) The variance is the difference between these two numbers (BCWS – ACWP). (BCWS and ACWP are standard acronyms used in most earned value calculations.) If the variance is positive, then the project cost fewer person-hours than were budgeted; if it is negative, then the project overran the budget. |
| eXtreme Programming (XP) | XP consists of a set of rules and practices that govern all areas of software development: planning, designing, coding and testing. These practices emphasize interaction and collaboration between the engineering team and the stakeholders and users, as well as the ability to respond quickly to changes in order to produce working software. The goal of XP is to lower the cost of change. Uncontrolled changes are the most common cause of software project failure; by putting basic XP principles and practices in place, a project team can control the changes. |
| feature | A cohesive area of the software that fulfills a specific need by providing a set of services or capabilities. Any software package—in fact, any engineered product—can be broken down into features. |
| functional requirements | Outward behavior required of the software project. Functional requirements are gathered by requirements engineers and listed in the software requirements specification. |
| inspection | One of the most common sorts of review found in software projects. The goal of the inspection is for all of the inspectors to reach consensus on a work product and approve it for use in the project. Commonly inspected work products include software requirements specifications and test plans. In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document which an inspector disagrees with. The goal of the inspection is to repair all of the defects so that everyone on the inspection team can approve the work product. |
| ISO 9000 | A family of quality management standards defined by the International Standards Organization and implemented by over half a million organizations around the world. Quality management refers to the practices performed by an organization in order to fulfill the customer’s requirements (and any legal or regulatory requirements). The goal of quality management is to improve customer satisfaction, while at the same time continually improving the performance of the organization. |
| Key Process Areas (KPA) | Both the CMM and CMMI are divided into key process areas (or KPAs) which define specific goals and practices. Each KPA addresses a specific area of software engineering. There are several dozen KPAs, including requirements management, project planning, project monitoring, configuration management, and training. |
| knowledge transfer | Giving background information on software projects to people who do not have it. |
| main stakeholder | The person who will be most impacted by the project, either because he plans on using it or because he is somehow responsible for it being developed. |
| milestone | in scheduling, a task with no duration |
| milestone reviews | meetings which the project manager schedules in advance to coincide with project events. The most common for project managers to handle milestone reviews is to schedule them to occur after the last task in a project phase (such as the end of design or programming). |
| nonfunctional requirements | Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. The nonfunctional requirements define these aspects about the system. (The nonfunctional requirements are sometimes referred to as “non-behavioral requirements†or “software quality attributesâ€.) |
| over-allocation | A resource is more than 100% allocated to multiple tasks simultaneously. If any resource is over-allocated, it means that there is a dependency between two tasks which was not discovered. When this happens, the schedule is guaranteed to be inaccurate. |
| overhead | Overhead is any effort that does not go to the core activities of the task but is still required in order for the people to perform it—a sort of “real world†cost of actually doing the work. For example, two people performing a task will require more effort than one person doing the same task: if the duration of a task is 12 days, it may require seven days for two people to finish it, because they need an additional day to compare and integrate their work. The tradeoff is that, while assigning two people to the task requires more effort, the task has a shorter duration. |
| pair programming | A technique in which two programmers work simultaneously at a single computer and continuously review each others’ work. Although many programmers were introduced to pair programming as a part of eXtreme Programming, it is a practice that can be valuable in any development environment. Pair programming improves the organization by ensuring that at least two programmers are able to maintain any piece of the software. Pair programming also helps programmers’ professional development, because they learn from each other during the review. Pair programming is like having a continuous code review, without the extra time or effort of holding individual code reviews. It encourages a redundancy among the team members, and everyone is cross-trained on various parts of the code. |
| performance plans | A list of standards and goals to be met by individuals within a specific time period. The list is agreed upon by manager and employee and sets the standard for performance throughout the project. |
| person-hours | Effort is measured in person-hours (or person-days, person-weeks, etc.), and represents the total number of hours that each person spent working on the task. For example, if three people worked on a task together for a total of two working days, the duration required to complete the task was 16 hours (at 8 hours per day, with only five or six of those hours actually devoted to software engineering work). However, since each of the three people spent 16 hours on the task, the total effort required was 48 person-hours (keep in mind that some tasks are not divided evenly between resources; the total effort should reflect the actual time worked per resource). |
| postcondition | The state that the software is left in after the use case is completed. In the use case, each of these states can be described in words (“the word processor is loaded but no document is being editedâ€), although it is also possible to create a name for each state and refer to it by name. |
| postmortem report | an overall account of the team’s experience in building the software, and of the experience of the users and stakeholders in working with the team. The report should contain an honest assessment of how the team members, users, and stakeholders perceived the end product, and assessed the decisions made throughout the project. The purpose of the post-mortem report is to highlight the team’s successes and identify any problems which should be fixed in future releases. |
| precondition | In use cases, the state of the software at the beginning of the sequence of steps to be described. This represents the entry criteria for the use case: if the software is not in that state, the use case does not apply. |
| predecessor | In scheduling, a task that must be begun, in progress, or completed, for another task to begin. |
| PROBE | Proxy Based Estimating, is the estimation method introduced by Watts Humphrey (of the Software Engineering Institute at Carnegie Mellon University) as part of the Personal Software Process (a discipline that helps individual software engineers monitor, test, and improve their own work). PROBE is based on the idea that if an engineer is building a component similar to one he built previously, then it will take about the same effort as it did in the past. |
| process documents | A description of a process to be followed within the software project. Process documents help each person on the project understand how their work fits into the big picture, and reassures them that they are doing the right tasks. Process documents also give them the ability to compare the team’s performance from project to project to determine whether the organization is improving over time. |
| process script | Step-by-step instructions to guide you through a particular tool, technique or practice. In “Applied Software Project Management” process scripts include the following: name, list of work products used labeled as input and output, entry criteria, basic course of events, alternative paths, and exit criteria. |
| progress reviews | meetings held regularly to check the progress of a project versus it’s scheduled progress. |
| project plan | Defines all work in a project and who will do it. A typical project plan consists of: a statement of work, a resource list, work breakdown structure, a project schedule and a risk plan |
| project schedule | A calendar that links the tasks to be done with the resources that will do them. Before a project schedule can be created, the project manager must have a work breakdown structure (WBS). It is usually part of a project plan. |
| quality | Every use case,functional requirement and other software requirement defines a specific behavior that the software must exhibit. Conformance to these requirements is software quality. |
| Rational Unified Process (RUP) | The activities of RUP are based around the idea of highly iterative development. After an initial planning phase, the software project enters a cycle of iterations, each of which results in an executable release. Each of the iterations contains distinct activities for planning, requirements specification, analysis and design, implementation, testing, and stakeholder evaluation. The advantage of iteration is that it allows the project team to identify and correct misunderstandings early on in the project, keep the stakeholders up to date with deliverables to help them gauge the progress of the project, and distribute the project’s workload more evenly over the course of the project. |
| refactoring | To refactor a program is to improve the design of that program without altering its behavior. Refactoring is a programming technique in which the design of the software is improved without changing its behavior. There are many different kinds of improvements—called refactorings—that can be performed. A comprehensive catalog of refactorings can be found at http://www.refactoring.com/catalog. |
| regression test | a test designed to make sure that a change to one area of the software has not caused any other part of the software which had previously passed its tests to stop working. Regression testing usually involves executing all test cases which have previously been executed. In other words, it’s not enough to verify that the software has been altered: it’s also necessary to ensure that the change did not break any other part of the software which previously worked. |
| repository | A database or directory which contains each of the files contained in the system. Bringing a group of files under control means that someone can pick a point at any time in the history of the project and see exactly what those files looked like at the time. |
| requirements elicitation | the process through which a requirements analyst gathers, understands, reviews, and articulates the needs of the software project’s stakeholders and users. Elicitation involves fact-finding, validating one’s understanding of the information gathered, and communicating open issues for resolution. The objective of this activity is to create a complete list of what the users believe are important requirements. |
| resource | A person, hardware, room or anything else that is necessary for the project but limited in its availability. |
| resource list | Part of a project plan that lists all of the resources that will be needed for the project and their availability. |
| responsibility | A person has responsibility for a task only if he is given sufficient authority to perform the task and is held accountable for the results of the task. |
| review | Any activity in which a work product is distributed to reviewers who examine it and give feedback. Different work products will go through different kinds of reviews: the team may do a very thorough, technical review of a software requirements specification, while the vision and scope document will be passed around via e-mail and have higher-level walkthroughs. |
| risk plan | Part of a project plan, it is a document that identifies any risks that might be encountered and indicates how those risks would be handled should they occur. To produce the document, the project team meets and brainstorms any possible threats to the project, estimates the impact of each risk, and creates a mitigation plan for them. |
| scope | The features that will be developed and the work that will be done to implement those features. It often also includes an understanding of the features that will be excluded from the project. |
| scope creep | Allowing changes to be made to software in the course of development that turn out to be difficult to implement, subsequently throwing the project off track. This problem is usually referred to as scope creep, because the scope of the project slowly drifts over the course of many small changes. Scope creep is so common that many project managers don’t realize that it’s a problem at all. They feel that refusing any change request would be considered “inflexible†by others in the organization, and that any project manager or team member who refuses to make a change is not being a team player. But in a team that does not control changes, progress on the project starts to slow as the changes pile up. |
| Six Sigma | A family of quality management standards defined by the International Standards Organization and implemented by over half a million organizations around the world. Quality management refers to the practices performed by an organization in order to fulfill the customer’s requirements (and any legal or regulatory requirements). The goal of quality management is to improve customer satisfaction, while at the same time continually improving the performance of the organization. |
| slack | In scheduling, the amount of time which any of the tasks can be delayed without causing the due date of the final task in the sequence to be delayed as well. A tight schedule has very little slack; a delay in any task will cause a delay in the due date. |
| smoke test | a subset of the test cases that is typically representative of the overall test plan. For example, if there is a product with a dozen test plans (each of which has hundreds of test cases), then a smoke test for that product might just contain a few dozen test cases (with just one or two test cases from each test plan). The goal of a smoke test is to verify the breadth of the software functionality without going into depth on any one feature or requirement. (The name “smoke test†originally came from the world of electrical engineering. The first time a new circuit under development is attached to a power source, an especially glaring error may cause certain parts to start to smoke; at that point, there is no reason to continue to test the circuit.) |
| Software Engineering Process Group (SEPG) | A team of software engineering professionals and/or managers within the organization who are dedicated either part- or full-time to improving the software process. They identify problems and inefficiencies, define the practices needed to address those problems, and implement them in the project teams. |
| software process | A software process is a set of activities which, if done, will result in software. It’s important to recognize that all of the organizations that make software do have a software process—but not all of them have a formal, or documented and repeatable, process. |
| software process improvement | The art and science of changing an organization’s software process in order to build better software. |
| software requirements | documentation that completely describes the behavior that is required of the software being built. |
| software requirements engineering | Software requirements engineering is the art and science of developing an accurate and complete definition of the behavior of software that can serve as the basis for software development. Like project management, programming, and testing, software requirements engineering encompasses a set of skills that require training and practice. |
| software requirements specification | A complete description of the behavior of the software to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. In addition to use cases, the SRS contains functional requirements, which define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied. It also contains nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints). |
| stakeholder | Anyone with an interest (stake) in the project’s successful completoin |
| standards documents | Programming standards may include naming conventions for variables or files. A testing standard might specify that a test plan must be executed by somebody other than the person who wrote it. Acceptance criteria and release readiness criteria are useful standards to help the organization make unbiased and objective decisions about when to release the software into test or to the general public. In addition, inspection checklists are also a kind of standards document. |
| statement of work | Part of a project plan that describes all work products (specifications, test plans, code, defect reports and any other product of work performed over the course of the project) that will be produced and a list of people who will perform that work. |
| templates | Templates ensure that all of the information that is needed in the document is included, and that important omissions are noted by the person writing the document. For example, a template might require that a vision and scope document always have a section for future releases. For projects that are only expected to have a single release, this section will contain “N/A†or a placeholder. This will prevent the reader from wondering whether the author meant that there would be a single release, or whether it was an oversight. |
| test plan | The overall approach to the test. In many ways, the test plan serves as a summary of the test activities that will be performed. It shows how the tests will be organized, and outlines all of the testers’ needs which must be met in order to properly carry out the test. |
| test report | When a test has been run, a list of all test cases which failed or were not executed. The purpose of the report is to give the project team a good idea of how much of the application was exercised in the test. |
| test-driven development | A programming technique where a programmer writes the unit tests before he writes the unit that they verify. By writing the tests first, the programmer ensures that he fully understands the requirements. It also guarantees that the tests will be in place, so that they aren’t left until after all of the other programming activities are completed (and then possibly dropped, due to schedule pressure). |
| The Planning Game | The software project planning method from eXtreme Programming (XP), a lightweight development methodology developed by Kent Beck in the 1990s at Chrysler. It is a method used to manage the negotiation between the engineering team (“Developmentâ€) and the stakeholders (“Businessâ€). It gains some emotional distance from the planning process by treating it as a game, where the playing pieces are “user stories†written on index cards and the goal is to assign value to stories and put them into production over time. |
| transparency | Publishing all information created in a software project so that it is freely accessible to all team members and project stakeholder. |
| unit tests | The purpose of unit testing is to create a set of tests for each unit to verify that it performs its function correctly. Each unit test should be automated: it should perform a test without any input or intervention, and should result in a pass (meaning that the test generated the expected results), failure (the results of the test differed from what were expected) or error (meaning the code reached an error condition before the test could pass or fail). Many people require that unit tests have no dependencies on external systems (networks, databases, shared folders, etc.). |
| use cases | A simple, straightforward tool that can be used to completely describe all of the behavior of a piece of software. It contains a textual description of all of the ways that the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show how the steps that the user follows to use the software to do his work. All of the ways that the users interact with the software can be described in this manner. |
| variance | This is a calculation that dates back to the early 1900s, when it was used by factories to track the difference between their budgeted costs and their actual costs. Variance is now the core of a project management system called earned value management, which tracks the project by considering effort “earned†against a budget only after it has actually been performed. |
| vision and scope document | A record of all of the preliminary conversations between the project manager and the stakeholders. A good vision and scope document will help a project avoid some of the costliest problems that a project can face. The “vision†part of the vision and scope document refers to a description of the goal of the software.The scope of a project usually refers to the features that will be developed and the work that will be done to implement those features. It often also includes an understanding of the features that will be excluded from the project. |
| walkthrough | An informal way of presenting a technical document in a meeting. Unlike other kinds of reviews, the author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments and ensuring that everyone present understands the work product. It typically does not follow a rigid procedure; rather, the author presents the work product to the audience in a manner that makes sense. Many walkthroughs present the document using a slide presentation, where each section of a work product is shown using a set of slides. Work products that are commonly reviewed using a walkthrough include design specifications and use cases. |
| Wideband Delphi | a consensus-based estimation technique developed by the Rand Corporation in the 1940’s. It in which a team is chosen to produce a Work Breakdown Structure, A list of assumptions and a range of effort estimates. |
| work breakdown structure (WBS) | Part of a project plan that lists the tasks that comprise the final product. A useful rule of thumb is that any project can be broken down into between ten and twenty tasks. For large projects (for example, a space shuttle) those tasks will be very large (“Test the guidance systemâ€); for small projects (like writing a simple calculator program) the tasks are small (“Build the arithmetic object which adds, multiplies or divides two numbersâ€). The team must take care in generating the WBS—if the tasks are incorrect, they can waste time going down a wrong path. |