Software Processes Critique
To give you some food for thought about software processes I want to state a few things which I experienced in the past 20 or more years.
- Software developers usually do not like processes. They feel it restricts their way of working too much and cuts down their creative work to formal activities. Therefore you have to take care of this! Eventually it means that you can define a perfect process but nobody is going to use it. Sometimes I had the impression that it would have been better to employ a marketing expert instead of yet another process engineer, to promote the processes in a company.
- A process does not stand or fall with the process model which is the background of it. I was in meetings with process engineers where they kept discussing the advantages of the V-model vs. the waterfall model for hours, days and weeks. Those guys then defined a process, which took them months with the outcome that nobody used it, because it was completely away from reality.
- High CMMI or SPICE levels of a company do not imply that their products are any good. It just tells that they have passed the assessment and the assessor was satisfied with the defined process and the answers he heared and the documents he saw. Still the products may be of bad performance because an assessment level does not tell anything about the technical qualitiy of the products. It tells only something about the quality of the process.
- Processes are often taken as synonym for tools. Too many companies define their processes around tools. The better way would be to define a process which is good and simple and which is accepted and used, and then look for tools to support it at the places where tools can improve handling and save time. Sometimes a tool is used to support a part of the process and another tool to support another part. However the tools can not be linked and the complete process suffers from it. The result is worse than if no tool would have been used at all. Also you have to consider that tools need administration and have bugs. You also should consider that your tools have to have good interfaces to each other to be really helpful in a process.
- I came across many cases where little things made a big improvement in processes. Not the big things like introducing big quality groups, formalized review meeetings or the introduction of a requirements database caused an improvement. It was a simple release checklist, a code handover sheet for testing or integration, a mailing list to distribute information, etc. which did the trick, made work easier and more organized. These things reduced the development, testing and integration times and improved the quality of the output.
- There is no clear rule which guides you regarding which process standard you have to comply with. Sometimes your main customers enforces the compliance with certain standards on you. Currently there are two main standards. The first one is the CMMI (which is not an official standard) the second one is the ISO 15504 (SPICE).
To some extend they both say the same, but the ISO 15504 has finer grades of assessment. Both of these standards are very young compared to the history of technology. I can remember that we had processes and so called mini-processes when I worked for IBM 40 years ago. And we were doing great products at that time. Also mankind
managed to fly to the moon without one of these standards guiding them.