home

Glossary

Skip Navigation Links
 
Skip Navigation Links.

At the start of a project, regardless of whether it's something as simple as an application to measure broadband speed or something as complicated as a commercial payroll system, there are often subtle differences between people’s understanding of the same terms. However, in time, a common language develops so that everyone is able to communicate more effectively.

Words put in an italic font are defined elsewhere in the glossary. The acronym a.k.a. means also known as and is used to indicate other terms that share a similar meaning. The meaning of the letters A, V, M and X given in the key at the bottom of the list

List of Definitions

big design upfront A Approach to software development that requires a team to produce a complete design before writing any code (see Chapter 17); a.k.a. BDUF. Contrast with simple design.
big visible charts A Display of the team’s metrics on charts drawn on large sheets of paper attached to office walls and windows (see Chapter 31).
build drop folder V Directory used for storing build products (see Figure 12-1 in Chapter 12); a.k.a. drop folder.
build environment   Common place for a team to build and test its software that is separate from the team’s individual development environments and the eventual production environment (see Figure 11-1 in Chapter 11); a.k.a. Build Lab, integration environment.
build process   Steps taken to create build products. An Agile team will usually define a number of different build processes, such as its Integration Build and its Daily Build (see Chapter 11).
build products   Files generated during the execution of a particular build process. In VSTS, the build products of a given Team Foundation Build type are deposited in its build drop folder and may include such things as the executable binary files (.exe, .dll), help system file (.chm), installation program, a build log, and Build Validation Test (BVT) results (see Chapter 12).
Build Validation Test V Run at the end of the build process to confirm that the latest changes to the software work as intended and do not have any undesirable side effects on the existing code (see Chapter 12); a.k.a. BVT.
CAL M Licence required to access certain Microsoft servers, e.g. SQL Server, Team Foundation Server. You can buy a CAL for a person or a device. When a CAL is bought for a device (like a PC) then access is permitted for anyone using the device. When a CAL is bought for a person then he or she can access the server from any device. a.k.a Client Access Licence
CASE tools   Computer-aided software engineering tools are usually concerned with helping people to produce Unified Modeling Language (UML) diagrams from which source code can be automatically generated (forward engineering). However, the more sophisticated of these tools may also allow you to generate UML diagrams from the code (reverse engineering) and so are termed round-trip tools.
change-set V Collection of files in a developer’s workspace that have been altered since they were last synchronized with the repository. A change-set is eventually checked in as a single atomic change to the team’s shared code base (see Chapter 9).
check-in policies V Validation performed before a change-set is applied to the repository. For example, you might not be able to check in your change-set without first adding some notes and linking it to a work item (see Chapter 10).
cloaked V Projects (and directories) in your workspace marked as cloaked are effectively ignored when version control commands such as Check-in and Get Latest Version are applied to parent directories (see Figure 9-2 in Chapter 9).
code churn V Measure that reflects the number of lines added, modified, or deleted between one version of a file and another. Code churn data is automatically gathered when people check in their change-sets and this information is used with other metrics to help identify problems.
code coverage   Measure that reflects the number of lines of code executed when a test suite is run against the number of lines of code that are not executed, usually expressed as a percentage (see Chapter 16).
code smell A Unquantifiable indication that something is wrong with the organization of some code (see Chapter 15); a.k.a. hunch, smell
Context menu   Menu that opens when you click your right mouse button after selecting an object in a window.
cross-functional team   Group of people with different types of expertise, but who share a common goal so that their objectives align to their team rather than to their department (see the Whole Team practice and Chapter 4).
customer A Representative of the business who gets to say “what” the product must do. This may be someone who is considered a full-time member of the team or it may be treated simply as a role which is then split among a customer group (see Chapter 4).
customer acceptance test A Functional test to verify that the software meets a particular business requirement (see Section 7); a.k.a. user acceptance test, acceptance test, customer test.
customer story A Defines a particular feature that has value to the business funding the project. It mainly takes the form of a conversation between the team’s customer and a developer, but it is also summarized on an index card and confirmed by a customer acceptance test (see the Customer Story practice and Chapters 3 and 25); a.k.a. user story, story.
Daily Build   Build process that runs overnight in order to generate the build products required for creating a release of the team’s software (see Chapter 11).
declarative programming   Style of programming characterized by setting the properties and events associated with objects using a visual editor (see Exercise 17-1 in Chapter 17).
delta encoding   Records different versions of the same file in terms of their differences rather than as separate files. Therefore, you can recover any version of a file by starting from the original file and then successively applying the required number of deltas (see Chapter 7); a.k.a. delta.
deployment   Activities associated with preparing a build product for use in its production environment, often expressed in terms of a formal release process (see Chapter 28).
developer   Technical person who gets to say “how” the needs of the business will be implemented, usually combining the roles of analyst, designer, programmer, and tester.
development environment   Place for individuals (or pair programmers) to write and test their code that is separate from the team’s common build environment and the eventual production environment (see Figure 11-1 in Chapter 11).
domain expert   Someone with knowledge, skills, and experience in some particular area, usually related to the business funding the project.
domain specific language   Language and terms used by a domain expert. Domain specific languages allow domain experts to produce programs expressed in their own domain language rather than having to write them in a computer language such as C# (see Chapter 21); a.k.a. DSL.
elective process   Requires people to decide for themselves how best to complete their work. For example, Extreme Programming (XP) is an elective process because the team can decide whether it should adopt a particular practice (see Chapter 5).
Extreme Programming A Practices and values for an Agile team, as described in Kent Beck’s book. This approach to software development forms the basis for our book.
functional test   Treats the software under test as a black box which exists in a number of defined states, such that for each state the application of certain inputs should result in particular measurable outputs. In other words, the test seeks to prove that the software conforms to its external specification, that it does what the customer intended (see Chapter 22). Contrast with structural test.
group security account M Grants access rights and privileges to someone performing a particular role. Typically, user accounts are made members of the various group security accounts which correspond to their roles in an organization.
ideal day A Time available to a developer during a normal office day for working on the implementation of customer stories, assuming there are no interruptions and everything needed is readily available. Stories are often estimated in ideal days (see Chapter 25).
incremental   Reaching some objective by taking a series of small steps rather than taking the big-bang approach of trying to achieve everything in one try. Agile teams usually take an incremental approach to things such as development, deployment, and integration. See iterative, later in this glossary.
Integrated Development Environment   Collection of tools typically used in the development environment that interoperate in such a way that a developer can work from a single user interface. For example, Visual Studio integrates a set of tools from various sources so that you can edit files, build programs, and debug programs (see Chapter 1); a.k.a. IDE.
integration   Process of adding different people’s code changes to the team’s shared code base in order to create a tested build product that contains everyone’s work (see Chapter 11). See single code base, later in this glossary.
Integration Build A Build process run frequently during the day to integrate the changes made by different developers to the team’s shared source code files (see the Ten Minute Build and Continuous Integration practices, and Chapter 11).
iteration A Fixed period during which the team will completely implement a given collection of stories and prepare its software for deployment. It typically lasts one or two weeks (see Chapters 3 and 26).
iteration burn rate X Cost of running the project for an iteration. Essentially, it is the sum of a project’s fixed costs (salary, office rent, etc.) apportioned over the time scale of an iteration (see Chapter 25).
iteration plan A Collection of stories that a team intends to complete during the iteration. It is often created by pinning customer story index cards against specific developers’ names on an iteration planning board (see Figure 26-2 in Chapter 26).
iteration zero A Preparation work done before a team starts performing fixed-length iterations; in other words, setup of the version control system, development environments, and build environment (see retrospective).
iterative   Repeating a given sequence of steps in order to complete an incremental move toward some objective. Agile teams take an iterative approach to things such as development and deployment (see the Weekly Cycle practice).
managed team   Gives people little responsibility for deciding how or when their work should be done because their activities are controlled by someone in a supervisory role, such as a project manager (see Chapter 4). Contrast with a self-organizing team.
metamodel   Meta comes from the Greek verb to build, so a metamodel is a model that allows you to build other models (see Chapter 5).
methodology   Common set of methods, practices, and rationale that form the basis of the processes adopted by teams in an organization. This provides a general strategic approach for undertaking software projects.
metrics A Measurements made by a team in order to better understand the problems associated with its work. In VSTS, metrics are specifically gathered by team through the creation of work items, but they are also implicitly gathered during activities such as checking files into version control (see Chapter 31).
mothball A Process of archiving a project prior to its closure so that it can be restarted at some future date without too much difficulty (see Chapter 3).
multiple checkout   Synchronizes updates made by different people to a file held in the team’s repository so that you are prevented from checking in your changes only when someone else has already checked in a new version of the file before you (see Chapter 7); a.k.a. optimistic locking. Contrast with single checkout.
nonfunctional requirement   Requirement that relates to the operation of the software product rather than to the implementation of some specific feature. Nonfunctional requirements are concerned with matters such as performance, availability, reliability, and so forth; a.k.a. Quality of Service (QoS).
personas   Fictitious characters created to help personify a role that has a need for some particular feature under development. It is often helpful to link a persona to a photograph, as we did when describing the OSPACS team in the Introduction.
phased development   Divides the work of software development into distinct phases which are completed in a set sequence. For example, the analysis phase leads to the design phase, which leads to the coding phase, and so on.
preproduction environment   Place where the team’s build products are deployed so that they can be subjected to further testing before being moved into the production environment (see Chapter 28).
prescriptive process   Sequence of activities required to transform a work product from one state into another, described in such detail that there is little possibility for variance from the plan (see Chapter 5). Contrast with an elective process.
process   Common set of methods, practices, and rationale which guide a team during the execution of a project. Typically, a team’s process is based on its organization’s methodology, but is adapted to meet the specific needs of the team and the project. This provides a specific tactical approach for undertaking a particular software project. Contrast with methodology.
Process Framework V Defines the work item types, Process Guidance, and so forth for a Team Project that is intended to support a particular type of software development process. VSTS provides process a framework for MSF Agile and MSF CMMI, but other frameworks are available from third parties (see Chapter 5); a.k.a. Process Template.
Process Guidance V Explains to team members the basic concepts of the process they are following as well as giving specific guidance about how they should perform the roles assigned to them. It is provided as a Web site which is part of the Project Portal created for a specific Team Project.
process technician M Person responsible for ensuring the success of the team’s various build processes (see Chapter 12); a.k.a. build coordinator, build master, integration coordinator.
production code   Code that is intended for eventual deployment into the production environment as opposed to code that is written to support testing or other aspects of development. Typically, production code is subjected to certain policies and standards set by the team (see Chapter 10).
production environment   Place where the team’s build products will eventually be deployed and used for business purposes. This environment usually is separate from the team’s development environments and build environment (see Figure 11-1 in Chapter 11).
programmer tests A Structural tests written by a developer during test-driven development. In VSTS, these are formed by adding unit tests to a Visual Studio Test Project (see Exercise 14-1 in Chapter 14); a.k.a. unit tests.
programming episode X Period lasting a couple of hours during which a pair of developers will implement some part of a story. Typically, it ends when the developers check in their change-set and complete a successful Integration Build (see Chapters 9, 12, and 27).
Project Portal V Helps a team communicate during the completion of its project by providing the team with an editable Web site. The Project Portal created by VSTS contains areas for people to make announcements and share documents, and it has links to other sites such as the team’s Process Guidance site (see Chapter 1); a.k.a. project Web site.
Quality of Service M A.k.a. QoS. See nonfunctional requirement, earlier in this glossary.
refactoring A Aims to improve the design of existing code without changing its behavior. Refactored code is simpler, easier to understand, and not duplicated elsewhere in the code base (see Chapter 15).
release plan A High-level plan showing the number of iterations available to the team (as calculated from its iteration burn rate) and the individual stories scheduled for completion by the end of specific iterations during this period (see Chapter 26).
release process   A defined sequence of actions that are taken when deploying the team’s build products into the production environment (see Chapter 28).
Report Site V Provides reports that analyze the metrics generated by the team as it completes its project (see Chapter 31).
repository   Central place for holding files that is located in the Team Foundation Server Data Tier and is accessed using the Team Foundation Version Control system (see Chapter 7).
retrospective A Time set aside for the team to reflect upon their performance so they might find ways to improve. Retrospectives are usually held after the team has reached a significant milestone.
security group M See group security account, earlier in this glossary.
self-organizing team   Gives its members full responsibility for deciding how or when their work should be done (see Chapter 4). Contrast with managed teams.
shelveset V Allows people to save their work in the repository without it being integrated or shared with others on their team (see Chapter 9); a.k.a. shelve.
simple design A An approach to software development that defers making many design decisions until after the team has gained a better understanding of the problem by implementing parts of the solution. It aims to provide simple solutions by just solving today’s problems without making tomorrow’s any worse (see Chapter 17). Contrast with big upfront design.
single checkout   Synchronizes updates made by different people to a file held in the team’s repository so that only one person at a time is allowed to check out a file for editing (see Chapter 7); a.k.a. pessimistic locking, strict locking. Contrast with multiple checkout.
Smoke Test   Collection of tests applied to new build products that aim to identify any obvious problems before conducting further testing. Typically, a Smoke Test is performed part automatically and part manually (see Chapter 11).
Software Project Environment X Provides a set of tools that are controlled from a common interface to help a group of people work together. For example, VSTS integrates version control, team build, planning, metric gathering, reporting, and so on (see Chapter 1); a.k.a. SPE.
Source Control   a.k.a. version control, revision control.
spike A Time-limited exploration of a particular aspect of the software under development in order to solve a perceived problem or quantify some identified risk; a.k.a. prototype.
story A a.k.a. customer story.
structural test   Approach to testing that relies on measuring the response of the software to certain inputs applied at specific points in the code (see Chapter 13). That is to say, the test seeks to prove that the software conforms to its internal specification; it does what the programmer intended.
system metaphor A Unifying concept applied to the software under development in order to help people understand how its parts come together as a whole. For example, a shopping cart may be a good metaphor for a Web site that sells consumer goods (see Chapter 20).
task card A Summary of the work required to implement a story produced to help a team plan the iteration. These cards are typically written on an index card and then pinned to a task board (see Figure 27-3 in Chapter 27).
task point X Relative measure of the work required to implement a story expressed in terms of a nonlinear scale. Similar measures used by Agile teams for sizing a story include ideal days and story points (see Chapter 25).
Team Foundation Build V Components of VSTS concerned with the execution of a Team Foundation Build type in order to generate a set of build products (see Figure 12-1 in Chapter 12); a.k.a. TFB.
Team Foundation Build type V Special XML file defining the steps of a particular build process which is listed in the Team Builds folder of your Team Project. Teams usually create a number of build types for different purposes, such as their Integration Build and their Daily Build (see Chapter 12).
Team Foundation Server V Components of VSTS that form its Application and Data Tiers are installed on one or more physical servers (see Chapter 1); a.k.a. TFS.
Team Foundation Version Control V Components of VSTS which provide a repository on the TFS Data Tier as well as the various tools needed to provide version control for the files it stores (see Chapter 8); a.k.a. TFVC.
Team Project V Organizes a collection of people who are collaborating in the development of some software and who share a common schedule. A team will usually create a Team Project at the start of its software project (see Chapter 5).
test environment   Environment that emulates the production environment for the purposes of testing a set of build products. Typically, the test environment is made part of the build environment and is separate from the team’s development environments and the production environment (see Figure 11-1 in Chapter 11).
test list V Collection of tests that are executed together during a Build Validation Test as well as during other forms of testing (see Chapter 12); a.k.a. test suite.
test list A Collection of tests written down as a to-do list which drives the development during TDD (see Table 14-1 in Chapter 14).
treeview M Windows control that displays a collection of items in a treelike structure, such as the list of directories displayed by Windows Explorer.
unit test   a.k.a. programmer test.
use case   Collection of one or more scenarios relating to a particular form of interaction between a user (actor) and the system under development (see Chapter 20). Contrast with customer stories.
user story A a.k.a. customer story.
velocity A Measure of the team’s progress in terms of the sum of story sizes for stories that were completed during the previous iteration. We recommend stories be sized as task points.
Version Control System   Controls changes to a collection of files stored in a repository and shared by a team of people. In particular, it resolves any conflicts that arise due to several people altering the same file at the same time (see Chapter 7); a.k.a. Source Control, revision control. Contrast with multiple checkout.
Visual Studio M Microsoft’s Integrated Development Environment (IDE).
Visual Studio Team System V Microsoft’s Software Project Environment that is composed of Team Foundation Server (Data and Application Tiers), Visual Studio Professional with Team Explorer (Client Tier), Project Portal and Report Sites, and Team Foundation Build (see Chapter 1); a.k.a. VSTS.
work item V Instance of some metric that the team wants to measure as stored in the Team Foundation Server Data Tier.
work item type V Work items are categorized by types such as Task or Bug. The types available to you depend upon the Process Framework selected when your Team Project as well as any additional types added during the course of the project (see Chapters 5 and 6).
workspace   Set of directories in a development environment which are mapped to folders in a repository such that a version control command such as Get Latest Version will update the developer’s workspace with the latest versions of the files in the repository, and a command such as Check-in will update the repository with the changes the developer has made to the files in his or her workspace (see Chapter 9).

Key

A Term with meaning in the Agile community. For example, customer has a specific meaning when used in regard to an Agile team.
V Term with meaning in the context of Visual Studio Team System (VSTS). For example, you might create a test list to run a collection of unit tests in a Visual Studio Test Project.
M Term with meaning in the Microsoft community. For example, Visual Studio is Microsoft’s Integrated Development Environment (IDE).
X Term that we have defined or something that is not in common use
Information about the use of this website is contained in the legal notices page		 1-1-30-0