Het spreekwoord "voorkomen is beter dan genezen" geld ook voor software. Veel software fouten zijn niet nodig; veel problemen kunnen voorkomen worden. Een techniek die helpt om te leren van fouten, en ze te voorkomen, is Root Cause Analysis.
This second posting on "What Drives Quality" investigates factors that drive the quality of requirements. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
Many methods for product quality improvement start by investigating the problems, and then working their way back to the point where the problem started. For instance audits and Root Cause Analysis work this way. But what if you could prevent problems from happening, by building an understanding what drives quality, thus enabling to take action before problems actually occur?
Wouldn’t it be nice if you could have more insight into the quality of a product, while it is developed, instead of afterwards? If you could measure the quality of your product, and take action when there is a risk that the quality would become lower than required by your customer?
I have described a process and a checklist to help organizations that want to start with it, and I´m providing a report with an example in a handy booklet on RCA: Tools for Root Cause Analysis.
Root Cause Analysis (RCA) has been used for many years to determine a fault’s first or “root” causes in order to identify process improvement opportunities. The CMMI V1.3 has increased the possible deployment of RCA.
In november 2010 heeft het Software Engineering Institute (SEI) een nieuwe versie uitgebracht van het Capability Maturity Model Integration (CMMI): V1.3. Dit artikel geeft een overzicht van de wijzigingen, en gaat in op de waarde van deze nieuwe CMMI versie.
In two previous posting on the CMMI roadmaps for CMMI V1.3, I described how the project roadmap and the product and product integration roadmaps have been improved. This posting covers the last 2 roadmaps: process and measurements.
In a first posting on the CMMI roadmaps for CMMI V1.3, I described how the project roadmap has been improved to deliver an even better result. In this posting I’m covering the product and the product integration roadmap.
Delivering product with the right quality, on time, can be difficult. Testing decisions are crucial to reach this. Are there ways to improve your testing decision capabilities? Yes there are, and they have been used and have shown to be valuable.
When I started this website back in july, I mentioned that my main reason to start blogging was to share my experiences.
Version 1.3 of the Capability Maturity Model Integration (CMMI) has been released by the SEI. The main changes mentioned in the SEI News are clarifications of the high maturity process areas, alignment of the representations (staged and continous) and the addition of modern engineering practices like agile.