Agile Software Quality. |
|
Article Purpose
This article looks at the Agile software development process and discusses the role of Software Quality Assurance (SQA), Software Quality Control (SQC), Software Process Improvement (SPI) and CMMi within Agile.
Agile overview.
A quick overview of Agile is given here although there are many Agile process sites on the web that provide more in-depth information.
The Agile approach to software development is based on four principles:-
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In many ways the Agile process embodies two previous methodologies, namely Joint Application Development (JAD) and Rapid Application Development (RAD), via prototyping. Agile extends JAD and RAD into an encompassing development process that includes iterative development, pair programming as well as other extreme programming (XP) techniques.
At first glance it would be easy to dismiss Agile as nothing new and a rehash of previously identified processes and techniques as solutions to the essential difficulties of working with software (and the abstract modeling representations that are difficult to visualize). However, Agile and XP are both attempts to move the software development process away from the manufacturing process, to which it has been tied for years via analogies and metaphors. That is to come up with a development process that has better practical consequences (in terms of the delivered software product) than existing processes.
|
Agile Software Metrics.
The real question is What are the practical consequences of using Agile? and this requires the existence of Software Process Improvement (SPI).
Consider any process: The value of the process needs to be measured, in other words it is not enough to say this process is the best and by following this process I will achieve my goals. This statement holds for any process.
This brings us to our first conclusion:-
Agile does not impact how we measure the value of our software development processes, we still have Software Metrics and these do not change with the development process.
What is still needed with Agile is to set up causal analysis between any process and the desired outcomes (as measured by Software Metrics).
|
|
|
Agile Software Process Improvement.
We still need a Software Process Improvement (SPI) initiative that relates our processes to outcomes (i.e. our Software Matrixes or Measures).
Having established that we need SPI with any software process, including Agile, the question moves to What SPI ? and we need to examine CMMi as a possible SPI for Agile.
|
Agile CMMi.
In many regards CMMi should not be considered as a suitable SPI for Agile as CMMi is targeted at larger development groups (over 25) and Agile is more suited to smaller development teams. That said there is value in looking at CMMi and determining which Process Areas would be suitable for an Agile SPI.
CMMi is mainly concerned with managing, measuring and controlling software development rather than a how to description of the actual Engineering process. Agile is mainly concerned with the core engineering processes of :-
Requirements Development (RD) (Performed as JAD sessions)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
This observation can be stated another way, in that the non-engineering processes of CMMI, namely:-
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Integrated Project Management +IPPD (IPM+IPPD)
Measurement and Analysis (MA)
Organizational Innovation and Deployment (OID)
Organizational Process Definition +IPPD (OPD+IPPD)
Organizational Process Focus (OPF)
Organizational Process Performance (OPP)
Organizational Training (OT)
Product Integration (PI)
Project Monitoring and Control (PMC)
Project Planning (PP)
Process and Product Quality Assurance (PPQA)
Quantitative Project Management (QPM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Requirements Management (REQM)
could be applicable to Agile but since they are targeted at larger organizations it might be better to seek out the essential contribution these CMMi process areas make to SPI then seek alternatives that achieve the same goals (i.e. Causal Analysis) but on a smaller scale, for Agile.
It is useful, for this discussion, to make one point clear about CMMi and that is:-
CMMi does not assume, or only work with, a water fall SDLC. That is RAD and JAD techniques could become a part of a CMMi SPI. The caveat (or assumption in using CMMi in an iterative development SDLC) is however that if RAD\JAD techniques are used they are used to iteratively flush out or define the requirements which at some point will exist.
|
Agile Software Quality Assurance.
Software Quality Assurance is the process of ensuring that the established guidelines, procedures and processes are followed. SQA and Agile co-exists with out issue. The real concern is SPI, and these issues are examined in our conclusions.
|
Conclusions.
If, in using Agile, you buy into that fact that the artifact (i.e. software) becomes the requirements and these requirements are never stated (or restated) outside of the software (or prototype) then CMMi is not a suitable SPI for your Agile process development. If, however, you are going to document requirements independently of the actual software then it is possible to use CMMi (including the core engineering process areas) as your SPI.
In the cases where separate requirements do not exist, in other words the software is what it is and becomes the requirements then CMMi is not suitable and you need to look at other ways to measure the value of the software when it is placed in its environment. That is What is the basis for measuring whether or not this software adds value? if no requirements exist.
It would be possible to benchmark key software metrics with one solution then produce an alternative and measure that.
In this way (of comparison) requirements may not be needed to implement an SPI, although as previously stated CMMi would not make a suitable SPI without requirements.
In conclusion all of the current processes within Software Quality (i.e. SQA, SQC and SPI) could be applied in an Agile environment. If, however CMMi is being used as your SPI then there are two major draw backs: namely CMMi is not well suited for smaller projects and the CMMi processes assume the existence of a separate and traceable requirements specification.
|
No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-
|