Agile
See Agile Manifesto. A software development methodology which delivers working software iteratively. Requirements and solutions evolve through collaboration between self-organizing teams. Agile methodologies include Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM).
CMM
The Capability Maturity Model (CMM) was the fore-runner of the CMMI. It is based on the process maturity framework first described by Watts Humphrey in Managing the Software Process (1989). The CMM was originally developed as a tool for the US Department of Defense to objectively assess the ability of government contractors’ processes to perform a contracted software project.
CMMI
Stands for Capability Maturity Model Integration, a suite of process improvement frameworks developed by the Software Engineering Institute that provides organizations with the essential elements of effective processes. The product suite includes:
- CMMI for Services : for service provider organizations seeking to improve their ability to establish, manage, and deliver services
- CMMI for Acquisition: for client organizations seeking to improve their ability to acquire products and services.
- CMMI for Development: for organisations seeking to improve product and service development processes.
COCOMO
The COCOMO (COnstructive COst MOdel) estimation method was one of the first reliable methods for predicting the resources necessary for software development projects. COCOMO II, brought out in 2000, contains a very sophisticated understanding of software project behaviour in modern development conditions such as incremental development and rational unified process. It has been successfully used to explore and explain unsatisfactory characteristics of software-intensive projects (eg poor productivity, predictability, etc.)
COSMIC FP
aka COSMIC FFP, COSMIC Software Size Units. International Standard ISO/IEC 19761:2003 for sizing the functional requirements of software. See COSMICON. COSMIC was designed to measure the functional size of real-time, multi-layered software such as used in telecoms, process control, and operating systems, as well as business application software, all on the same measurement scale. Such wide applicability is unique and a breakthrough for better software project performance measurement and estimating. Agile User Stories can also be easily related to COSMIC size measures. Benchmark data on project performance measured using COSMIC is available from ISBSG (International Benchmarking Standards Group)
DSDM
Dynamic Systems Development Method. An agile software development methodology originally based upon the Rapid Application Development methodology.
Extreme Programming (XP)
An agile software development methodology which stresses customer satisfaction. It is intended to improve software quality and responsiveness to changing customer requirements, even late in the life cycle.
Function Point
The functional size of any piece of software can be measured by counting the number of data movements it handles. This is the software’s information processing size.
We can move data into a system, or out of the system, remember it for later use, or retrieve previously remembered data for use now. So we can move data in four directions, in, out, and to or from long-term memory. Just as the metre provides us with a standard scale to measure length, the function point provides a standard scale to measure the quantity of information processing required from/provided by any piece of software. The ‘quantity of information processing required’ is described as the functionality of the software.
In COSMIC, 1 fp = movement of 1 group of data about 1 object.
Functional Size Measurement
FSM measures the functionality delivered by software to the user – ie the output. Most other software measurement methods, including concepts such as Story Points, are essentially measuring input. While the output of software projects is not of itself a measure of value delivered, it can be used by management teams as a factor in determining value.
Internationally recognised standard measures of functional size (COSMIC, IFPUG) can be benchmarked against comparative project performance data which can be used to identify and justify improvement opportunities.
GQM
The Goal/Question/Metric method is an effective method for determining which measurements are appropriate to put in place in an organisation. Carried out through observation, interviews and workshops, this process is iterative, systematic and proven. It provides rapid identification of the structure for a software improvement programme and creates a foundation of repeatable procedures for single projects or the entire organisation.
IFPUG
See International Function Point User Group. IFPUG FPA is the original functional size measurement method and represented a significant advance when developed by Alan Albrecht in the 1980s. It has limited value for measuring complex modern software systems.
Lean
See The Lean Enterprise Academy. Lean is a different business model, focusing all activity on delivery of value to the customer. The fundamental insight behind Lean is understanding that customer value is created by lots of different people across different departments and organisations. Lean transformation is about eliminating steps that do not add value (“waste”) and aligning delivery to customer need (‘just in time”). An organisation is truly Lean when every employee can take the initiative in providing solutions that deliver value for the customer and prosperity to the organisation.
Output-Based Agreements. Output-based contracts treat software like any other commodity. They separate out the basic price of the ‘raw ingredient’ from the value-added services that the good supplier brings to the partnership, allowing both parties to focus on developing what the customer really needs.
When buying commodities (such as potatoes or logs of wood) we don’t try to specify the detail of each potato or log. We agree the nature of the commodity and an acceptable unit-price. Then the customer specifies the quantity of the commodity they want and a fixed price is agreed, calculated by multiplying the quantity by the unit-price. Simples. Variations in the individual potatoes and logs are accommodated during the delivery, which is subject to appropriate, fast, cheap, unobtrusive quality controls and progress tracking.
Instead of forcing the customer to issue detailed specifications up-front, or accept unsupported assurances of value for money from the supplier, the parties to an output-based agreement determine acceptable unit-prices for whatever kinds of software functionality are needed (usually there are a small number of software ‘types’, maybe 2 to 8 kinds). Then for each new development or enhancement project, the parties jointly agree the required quantity of software functionality, expressing the scope in terms of the ‘functional size’ of the requirements measured e.g. in COSMIC Function Points. Then a simple contractual arrangement is agreed. The need for detailed specification and prioritisation is deferred.
Many large contracts for outsourced software development work this way; especially large framework agreements, both in the public and private sectors.
In such a scheme, an onus is placed on the supplier to measure, understand and have confidence in its process performance. While in turn the customer must be prepared, during the project, to allocate the resources necessary to explore the detail requirements and provide the rapid feedback and collaboration that the developers need. Quantifying functional requirements using COSMIC makes visible the effect of additional requirements on the cost of development. This is how risk is minimised for all concerned. It is also how trust is established and sustained, resulting in better, longer-running business relationships.
Output-based agreements are best based on a standard measure of functionality which is appropriate to the customer’s business domain. This enables price comparisons to be made against benchmarks, and independent audits of measurement practice to be carried out to ensure confidence in the credibility of the measures used.
Rightshifting
Analysis of effectiveness (in achieving business goals) in product and service development activity reveals a significant bias towards low performance. On a 5-point scale of effectiveness, 80% of organisations are clustered to the left, scoring less than 1. Conversely, a small number of market leaders achieve levels of effectiveness which disappear off the top, right-hand end of the 5-point scale. This indicates a huge opportunity for improvement in most public and private sector organisations summed up by the term “right-shifting”.
Scrum
Scrum is a framework for managing agile projects using a succession of sprints to deliver iteratively. Tasks are prioritised in a product backlog and the team is co-ordinated by a ScrumMaster. The term originates from a rugby scrum and is not an acronym.
SPI : Software Process Improvement
SPI is activity focused on improving software development capability. It is driven by defined business objectives such as faster delivery, increased responsiveness, lower cost, better quality, better predictability etc. SPI is systematic, inclusive, collaborative, exploratory, ongoing, open-ended and rooted in reality. It is not an add-on “improvement project” but rather part of “business as usual” continuously building knowledge and adding value to everyday work.
Sprint
A sprint is a defined period of time (usually two to four weeks) in which agile teams using scrum have to complete their work. The sprint ends with a sprint review and retrospective. As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives.
VSM: Value Stream Mapping
A Lean technique for identifying activities which add value and those which don’t. It is used to analyse workflow and value chains to identify root causes of issues experienced with delivery of value.