Acceptance test
Acceptance tests verify that the system works properly as a whole. They are black-box tests that verify that the customer requirements are being met. They may be written directly by the customer or by testers attached to the customer, possibly QA. They are usually associated with user stories specifying system requirements.

Adaptive process
A software development process whose activities are able to change and adapt to changing system requirements.

Agile manifesto
A document written by the main proposers of agile methodologies, who met in Snowbird, Utah, on February 11-13, 2001. The manifesto summarizes the main idea behind agile methodologies. It can be found at http://agilemanifesto.org/

Agile Modeling
Agile Modeling is a collection of values, principles, and practices for effective modeling and documentation of software-based systems, proposed by Scott Ambler. See: http://www.agilemodeling.com/.

Agile planning
Project planning activities when an agile methodology is used. It is a key activity of AMs, and its practices, that depends upon the specific AM used, must be strictly followed .

AM
Acronym for agile methodology. Sometimes, it is also used as an acronym for Agile Modeling.

Changing requirements
A characteristic of most information systems of the Internet age. The difficulty of building software systems with changing and fuzzy requirements was the force driving the birth of AMs.

Coach
One of the roles of XP development. The coach maintains the vision of the project and makes sure the XP practices are followed by the team. S/he also helps team members when in difficulty. In more traditional terms, s/he is the Project Leader.

Coding standards
One of XP practices. Since in XP the main system documentation is in the code, the code must be easily readable by every team member. Hence the need to strictly follow coding standards.

Collective code ownership
One of XP practices. XP considers code to belong to the project, not to an individual developer. As developers develop required functionality, they may browse into and modify any module of the code. This can be done, provided that after the modification all unit tests are still running.

Communication
One of the four values of XP is communication between the actors involved in software development process: customers, programmers, management.

Continuous integration
A build and test process that allows the members of team to build and test their software even many times a day. The integration is typically made on an integration machine. Tools are available allowing continuous integration on a remote machine. See for instance Cruise Control (http://cruisecontrol.sourceforge.net/).

Continuous testing
An XP practice requiring that the system to be developed is provided a set of automated tests. These tests are continuously run by developers, to assure that the frequent modifications do not break the system. If a test fails, the bug must be fixed before proceeding.

Courage
One of the four values of XP. This value is also called “fearlessness”. It is the attitude to make even big changes to the software system under development, if needed, without fear.

Crystal methodologies
A self-adapting family of "shrink-to-fit," human-powered software development methodologies based on the principles: (i) every project needs a slightly different set of policies and conventions, or methodology; (ii) the workings of the project are very sensitive to people issues; (iii) better communications and frequent deliveries communication reduce the need for intermediate work products. Crystal methodologies were proposed by Alistair Cockburn (http://www.crystalmethodologies.org/).

Customer
The user and stakeholder of the software system to be built. The customer is the individual or group responsible for steering the project by defining its requirements and feeding them to the team in the order of business value. AMs prescribe a high customer involvement in the development process, to get a continuous and consistent feedback.

Customer on site
The XP practice to have a customer available full-time on the development site. Such a customer drives the development and answers to questions about the features of the system to be implemented.

Design phase
The period of time in the software life cycle during which the designs for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements

Developer
The engineer who develops the system. In AMs, s/he also has the role of analyst, designer and tester, since there is no clear distinction among the analysis, design, development and testing phases.

Documentation of the system
With AMs, the amount of system documentation is not considered a value, but a cost. System documentation must therefore be written and maintained to the extent it adds real value to the system, but not more.

DSDM
Acronym for Dynamic Systems Development Method.

Dynamic Systems Development Method
An agile methodology, whose roots go back to Rapid Application Development (RAD) techniques. It is applicable both to IT projects and to business change projects and programmes. More information can be found in: http://www.dsdm.org.

Eliciting and managing requirements
Involves all life-cycle activities devoted to identification, analysis, documentation, and validation of user requirements. In AMs, requirement elicitation is made in close contact with the customer. Most AMs call for requirements expressed as a list of simple features, whose implementation drives the system development process.

Extreme Programming
Extreme programming, known as XP, is by far the most popular AM. Albeit not the first AM to be proposed, the interest drawn by XP was instrumental to the interest in all AMs. XP was proposed by Kent Beck, and is based on four values and twelve practices. It was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. See for instance the site http://www.xprogramming.com/ and links thereof.

FDD
Acronym for Feature Driven Development.

Feature Driven Development
An AM proposed by Peter Coad and Jeff De Luca. It combines the key advantages of other agile approaches with model-centric techniques that scale to much larger teams and projects. FDD is also characterized by an emphasis on quality throughout the process, and straightforward, low-overhead, accurate, progress tracking. More information available in the site: http://www.nebulon.com/fdd/.

Feedback
One of the four values of XP. It means getting concrete feedback early and often from the customer, from the team, from real end users, and from the system itself (through testing). This keeps system development on track even in the presence of changing requirements.

Iteration
All AMs are iterative. This means that the system is developed in a succession of iterations, each yielding a system with more functionalities than the preceding one. In XP, the system is developed in releases, each made of typically four to six short iterations.

Lean Programming
Also known as Lean Software Development, it is an AM inspired by Toyota’s Lean Manufacturing and Total Quality Management. It is based on ten “Lean Rules”, and was proposed by Mary Poppendieck. More information available in the site: http://www. poppendieck.com/lean.htm/.

Manager
One of the roles of XP. The manager ensures that the project delivers, schedules the meetings, provides reporting, removes project obstacles, and insulates the development team from upper management.

Maintenance Metric
A software feature or characteristic that address how easily a system can be repaired or changed.

Pair Programming
A practice of XP requiring that all the development is made by pair of developers, sitting at the same workstation. Pair programming ensures that code inspection is made from the very beginning of the coding phase, leverages higher developers’ concentration and helps in spreading knowledge about the system among developers. More information on: http://www.pairprogramming.com/.

Planning Game
The XP practice to drive system development through iterations. The main idea behind the Planning Game is to make a rough plan quickly and to refine it as development proceeds and things becomes clearer. It is based on a stack of User Stories, and a plan for the next release or two. The customer makes business decisions and the development team make technical decisions.

Process Metric
Measure of the software development process, such as overall development time or the average level of experience of the programming staff.

Refactoring
It is one of XP practices. It is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is one of the main design tools of XP. More information on: http://www.refactoring.com/.

Scrum
An AM proposed by Ken Schwaber and Jeff Sutherland. Scrum is an agile, lightweight process that can be used to manage and control software and product development. Wrapping existing engineering practices, including XP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum claims significant increases in productivity while facilitating adaptive, empirical systems development. More information available in the site: http://www.controlchaos.com/.

Short iterations
AMs prescribe that development iterations be short (from a couple of weeks to a couple of months, with a preference to the shorter timescale. In this way, it is possible to get continuous feedback from the customer, and to make proper adjustments to system requirements.

Simplicity
One of the four values of XP. It is “the art of maximizing the amount of work not done. The practice is also stated as “do the simplest thing that could possibly work”. The idea is that simple code means low up-front investment, and ease of change.

Stakeholder
An institution, organisation, or group that has some interest in the system to be developed.

Sustainable development
An XP practice formerly known as “No Overtime” or “40 hour week”. The stakeholders, developers, and users should be able to maintain a constant pace indefinitely. To this purpose, it is important that the development team is able to concentrate and is not tired.

Tester
The developer who helps the customer define acceptance criteria, writes and runs system acceptance tests, and reports the results.

Test Driven Development
A development practice of XP. Unit tests are designed and written before starting to write the code that is tested. This is a powerful design practice, since to write the tests, the developer is forced to solve ambiguities about the problem. It also ensures that every module has its own unit tests.

Tracker
One of the XP roles. S/he tracks the teams’ progress, helping them to solve problems and warning the manager and the coach of any potential problems.

Unit Test
Unit tests verify that the small elements of the system work as they are expected to. They are black-box tests that verify the individual mechanism of the system. They are written by developers, usually before writing the code itself.

Up front analysis and design
Analysis and design of the whole system, carried before programming. These activities may last for many months, or years, without showing the customer anything working.

User stories
The way system requirements are gathered and expressed in XP. User stories are a short description, written on an index card, of a possible interaction of an external user with the system. They are written and explained by the customer, who assesses their business value and priority and who can change them during the project. They drive system development, since every iteration implements a subset of the user stories of the system.

XP
Acronym for extreme programming.