Software Process Improvement Continues Eternally
how to recognize a good software process
yes, but how do we recognize a good software process?
... and why do we care?
For many of us, software process improvement is so obviously a Good Thing, that the first question perhaps ought to be: why isn't it already happening?
But the fact remains: software process improvement is - perhaps surprisingly - hard work to achieve. Many organizations need help to make it happen: to start it happening and to keep it happening.
Principles of Software Process Interventionsveryard projects > software process improvement > principles
|We distinguish the process-in-use from the process-on-file.
|A good software process is constructed from good components. (This isn't rocket science. The components are well-known. See SEI CMM or SPICE for a checklist.)|
|A good software process is well-connected.
|A good software process is well-managed.
|Some form of metrication
is required to get higher levels of process improvement. All the process
assessment models also demand it. For example, metrication is a crucial
requirement for attaining Level 4 of the SEI Capability Maturity Model,
and ISO 9000 and its derivatives also require some degree of metrication.
Lots of organizations devote considerable effort to collecting the wrong
metrics - the challenge is to define and use the right metrics.
Barriers to Software Process Improvementveryard projects > software process improvement > barriers
|Software developers who are so complacent (or brain-dead) that they think they have nothing more to learn about doing software well.|
|Managers who have so little confidence in the intelligence and creativity of their staff that they are not willing to EVER let them do anything new, in case a fragile process falls apart completely.|
|In many organizations, there is an improvement ceiling: you cannot even think of going any higher/better than this. External consultancy is usually required to recognize the existence of this ceiling, and to help raise the ceiling.|
|Interpersonal conflicts can also get in the way of process improvement. We were working with an organization that employed a high proportion of contractors on a millennium compliance (Year 2000) programme. These contractors had been informed when they joined the project that they were expected to work as if on a production line. But it was clear that any ideas for making the process more effective or efficient would be discouraged. The main source of this discouragement was those staff who had been working there the longest (typically in project leading / supervising positions), who may have felt most threatened by this influx of contractors with their potentially disruptive ideas.|
|1||We check for components of the software process that are missing or weak.||We use CMM and SPICE as checklist.
Quite often we find major holes in the software process - with some of the CMM Level 2 grossly neglected. At the other extreme, some of our clients are already at Level 5, and are looking for further refinement and innovation.
|2||We check for connections that are missing or weak.||Things sometimes get lost in the no-mans-land between projects or departments. We often find major disconnects between separate parts of a process, programme or organization.|
|3||We check for mismatched expectations.||When a project manager tells us that X is someone
else’s responsibility, we like to double-check. We’ve found (and resolved)
lots of issues that way.
Proper use of a programme method such as Prince will capture some of these issues - but not all of them.
|4||We check for risks that are uncontained – in other words, not properly owned, understood or bounded.||Obviously any holes or disconnects in the process represent potential risks. And there may also be external (business) risks that are known about but not properly dealt with.|
When we conduct a brief assessment, our approach is illustrative rather
than comprehensive. Obviously we cannot expect to check everything thoroughly
in a few days. However, we are usually able to get a fairly realistic sense
of the amount of work to be done, as well as identifying the major issues
and some quick wins.
|Context Identification||What are the objectives and strategies?
Who are the stakeholders?
What are the stakeholders' expectations?
|Model Selection||Which software process model (if any) are we going to use as a benchmark?||The software specific models include: SEI Capability
Maturity Model, ISO-SPICE,
Bootstrap, Trillium, ISO 9000-3, TickIT.
General process models applicable to software include: ISO 9001, Baldrige, EFQM.
If the organization is familiar with one of these, or can get comparison data from other organizations (especially direct competitors), then this may be the one to choose. Of course, in some cases, the software organization may be faced with a demand to use a specific model by senior management or by a major customer (such as Government).
|Software Process Assessment||What is the current state of the software process, as measured against the selected benchmark?||A full and formal assessment may be demanded, but often a quick and informal assessment can be just as useful.|
|Identify Improvement Opportunities||What can/should be done to improve the software process?||We like to find a mix of opportunities: small and large,
things that can be done immediately, as well as things that will take longer.
At first, the enphasis is on finding and implementing specific improvements. Gradually the emphasis shifts to establishing a mechanism and culture that goes on finding and implementing improvements.
|Set Process Improvement Target||What level of process improvement do we want to achieve, by when?||For example, it may take 12-18 months to go up one level of the SEI Capability Maturity Model, or to get certification against ISO 9001 or TickIT.|
|Agree Priorities and Plan||Allocate time and resources to selected improvement opportunities, as well as to general improvement mechanisms.|
|Monitor Improvements||Has the improvement been successfully implemented?
Has it had the desired results?
What is the new state of the software process, as measured against the selected benchmark?
|Review Process Improvement System||Is the process improvement system working effectively and cost-efficiently?|
The initial stages are best performed in a workshop with key software staff and stakeholders. The later stages are typically carried out by the management team, or by a person reporting to the management team. Consultancy support is usually required mainly in the initial stages, with mentoring and other support available throughout.
Practical Examples of Software Process Interventionsveryard projects > software process improvement > practical examples
|They had implemented a CASE tool - and were now complaining that they weren't getting the expected improvement in productivity.||But when we explored this complaint, we discovered that there were no clear targets for productivity improvement, and no plan for achieving it. In fact, everyone we spoke to thought it was someone else's responsibility.|
|The account managers were making unrealistic promises to customers.||With our help, the company implemented a soup-to-nuts software process that included proper checking of proposals and contracts before they went out to customers. Unusually, this software process explicitly included the marketing end as well as the programming end.|
|Telecoms Company||Failure to exploit the chosen CASE tool to its perceived potential.||We found several major disconnects in their process.
|Software House||Project slipping. No apparent sense of urgency. Inability to focus on priorities.||We identified a lack of discipline and clarity in the organization, allowing projects to run on unchecked. We also noted poor boundary definition, e.g. between business and IT. We installed a risk management system that helped to pin precise responsibilities onto named individuals, and helped them escape from a collective fascination with commercially unimportant technicalities.|
Web Linksveryard projects > software process improvement > web links
|Information Services||Process Web Centre GDPA (University of Bremen)|
|Process Assessment Models||The software specific models include: Software Engineering Institute Capability Maturity Model, ISO-SPICE, Bootstrap, Trillium, ISO 9000-3, TickIT.|
|Process Descriptions||OPEN (Donald Firesmith)|
|Process Tools||Process Director (Aonix - formerly Select/Princeton Softech)
Process Engineer (Computer Associates)