The State Of The Art Software Development Process
Did you know it actually exists?
To a lot of people in the business it will come as a great surprise to learn that almost all software professionals I meet online or at agile conferences are not aware of the fact that a state of the art software development process actually exists. At this point you must be thinking “So what? Why should they? Why does it matter?” Well, the state of the art is quite important when it comes to defending against liability claims. By following a recognized state of the art process when doing your work you can defend against claims of negligence, as described in the following Wikipedia article:
For software professionals, the state of the art development process is defined and published by ISO, the International Organization for Standardization, together with IEEE, the Institute of Electrical and Electronics Engineers. As of today, you will find it in the ISO/IEC 12207 international standard. This standard breaks down the software implementation process into the following sub-processes (or activities):
- Software Requirements Analysis
- Software Architectural Design
- Software Detailed Design
- Software Construction
- Software Integration
- Software Qualification Testing
Every sub-process is meticulously described in the standard - it spends 10 pages to describe the 6 sub-processes listed above. If you want to dig deeper and read the complete standard, you’ll need to purchase it. But you can also gain insight by downloading one of the freely available industry-specific standards derived from ISO/IEC 12207, like this one from the automotive industry.
Many agile software thought leaders and coaches might dislike the process defined in ISO/IEC 12207 and outlined above. Some of them might even inadvertently tell you to fully or partially ignore it, like in this example. Unfortunately, if one follows their advice, one may have to face aviodable legal consequences as you or your company could be sued for damages or injuries caused by bugs in you software.
Please don’t get me wrong: I am a big fan of most agile methodologies and ideas - they really resonate with me. I just wanted to point out that there are some leftovers from the last dinner that we just can’t ignore. This year the Agile Manifesto is celebrating its 15th anniversary. I think it is about time for us and especially for all agile thought leaders out there to either accept the current state of the art or get involved in the corresponding standardization committees, in order to influence and shape the future state of the art.
