For this entry we’re talking about a more specific topic that I said we were going to talk about more in depth: Models and Standards for Software Process Improvement. As I said in the last entry, there is a wide range of different models and Standards to use during QA of your process, so now we’re going to talk about 5 of them, so get ready.
CMMI stands for: Capability Maturity Model Integration, this model stands out for being a process and a behavioral model for quality assuring. This model was developed by the Engineering Institute at Carnegie Mellon University as a collaboration from the US government and DoD in 1987 and the first version was released in 1997. As a side fact this model is the one used in US governmental software development.
This model starts by creating an evaluation on three different areas: process development, establishment & management and product acquisition. For the evaluation method the SCAMPI appraisal method is used and is divided in three different evaluation classes A, B, C.
Class A: Is the most rigorous appraisal as it must be performed by a certified appraisal leader. This type of SCAMPI is the only one that results in an official rating and it is used as a benchmark for various business.
Class B: This type of SCAMPI analysis is less formal, it finds a CMMI maturity level and gives a predicted success on the processes used
Class C: This analysis is more flexible and cheaper than the previous ones but riskier, this SCAMPI method evaluates the organization practices and if these align in the CMMI practices.
Now, CMMI method evaluates the organizations that embraces CMMI into 5 levels, level 5 being the highest, the breakdown of these levels is:
- Initial (Level 1): This is the worst level as it shows that processes in the organization aren’t, well, good, this is described as: “work gets completed but it’s often delayed and over budget.”
- Managed (Level 2): This level shows that there are at least some decent processes getting implemented, as this level describes the process as: “planned, performed, measured and controlled”.
- Defined (Level 3): Here the business is described as proactive, there’s usually a set of “organization-wide standards”. Businesses understand their shortcomings, how to address them and what the goal is for improvement.
- Quantitatively managed (Level 4): In this stage the company is pretty much in good term in their process quality. The organization is working off quantitative data to determine predictable processes that align with stakeholder needs.
- Optimizing (Level 5): Here, an organization’s processes are stable and flexible. At this final stage, an organization will be in constant state of improving and responding to changes or other opportunities.
Now for a closing part on CMMI, there has been a constant evolution in their model, as there is now a version 2, which implement more maturity models into its framework, which shows its adaptability to apply in various organizations.
For even more info on CMMI you can check: https://www.cio.com/article/2437864/process-improvement-capability-maturity-model-integration-cmmi-definition-and-solutions.html
This model is made from 2 frameworks that are technically one but two as the same time(?) this will get clearer in a bit. TSP is based on PSP. PSP stands for: Personal Software Process and TSP stand for: Team Software Process, kinda similar right? Well, technically, this framework is pretty much one, as TSP is PSP based and it requires that the developers in the team are already educated in PSP. PSP and TSP were created by Watts Humphrey, A.K.A the father of QA, in 2005 and 2006 respectively, he also created the first version of CMM in 1989, so he’s kinda a big deal.
PSP follow and linear improvement approach as it rates the developer in 3 different phases:
PSP0 which introduces the developer to discipline and measurement with concepts such as: planning, development and postmortem.
PSP1 which prepares the developer for estimating how large would a new program be and how to create a test case for it, as well as schedule planning and estimation.
PSP2 which helps the developer to review design and code through quality management and design.
PSP also emphasizes the use of historical data to analyze a process, this data collection is based on four concepts: Scripts, measures, Standards, Forms.
Side note: I once lost a friend’s PSP in a 6x6 mtrs classroom and to this day, the fact that nobody was able to find it, haunts me, all this PSP talk made me want to get a PS Vita to play some console locked games, like Persona 4, but maybe it should be better to emulate it. All this PSP talk is distracting me, I’ll continue.
Now we can talk about TSP, which is textually a lot easier to explain, this is basically a team of experts in PSP maintaining a self-directed team. Applying all PSP lessons a team can, and will, cover the role and tasks of a manager by themselves, for example, a TSP working team can: plan and track their work, manage the quality of their work, develop software in a proactive way to meet their goal, etc.
If you are curious in this topic you can learn more at: https://explainagile.com/agile/team-software-process/
Ok two out of five so far, let’s get started with the next one!
ISO-15504 also known as SPICE(Software Process Improvement and Capability Determinator, great name by the way, is another framework for quality assessment, this one is helpful when we wish to analyze the capability of the process and services, this framework was initially developed in a draft in 1993 and the first conference of this framework was in Limerick in 2000 called, as you guessed it, SPICE.
As the previous framework CMMI, this framework also works with assessment and evaluations, which assesses(?) the process capability level in 6 levels as follows:
- Incomplete (Level 0): This process is either non-functional or incomplete
- Performed (Level 1): This process is implemented.
- Managed (Level 2): The process is managed, and the results are specified and maintained
- Established (Level 3): The process is standardized and used throughout the organization
- Predictable (Level 4): This process is constant, and the outputs are within the expected limits
- Optimizing (Level 5): This process is constantly improved to maximize optimization withing the organization
The capability of the processes is measured through attributes, which in this case are nine:
Process performance, Performance management, Work product management, Process definition, Process deployment, Process measurement, Process control, Process innovation, Process optimization
And these attributes are assessed with a four-point scale:
- Not achieved (0–15%)
- Partially achieved (>15–50%)
- Largely achieved (>50–85%)
- Fully achieved (>85–100%).
Did I already make a stupid process processing joke? As you can see this methodology help us evaluate the process in so many ways, and this makes it a truly viable framework to help our QA. But technically this framework in not implemented anymore, as it evolved into ISO 33000 in 2015, which encapsulates even more concepts and models from other ISO/EIC models, but, as I’ve said before this method is still viable.
If you would like to read more about at: https://www.turcert.com/en/belgelendirme/sistem-belgelendirme/iso-15504-yazilim-surec-degerlendirme-sistemi
Now we’re talking about another process standard and this is a curveball, this one is called MoProSoft and it was created in Mexico in a collaborative effort by the Mexican Association for Software Engineering Quality and the Universidad Nacional Autónoma de México headed by Dr. Hanna Oktaba (A badass in the software engineering field) in 2005.
This model stands for “Modelo de Procesos para la Industria del Software” or Processes Model for the Software Industry in English. And it was developed with the intention to elevate the capability of Mexican software organization to compete in an international level. This model has a somewhat clear and long list of criteria that explains the elaboration of this model, but the only part that really is important for us (or for this topic at least) is the process categorization, which this model specifies that you must have a set of processes to cover with all of the types of categories, which are the following:
· Top management Category
o Business management: It must have a process that takes into consideration the organization’s strategic plans, objectives and goals
· Management Category
o Process management
o Project management
o Resources management
· Operative Category
o Specific project administration
o Software maintenance and development
With these set of processes, we can open the door to adopt a more rigorous model as ISO 9000 or CMMI
If you want to read a bit more about this topic (and you know/want to learn Spanish) here a good post about MoProSoft: https://www.ana2lp.mx/desarrollo-de-software/moprosoft-modelo-mexicano/
Now for our last model we have the IDEAL methods which, as you might have guessed, is another acronym, which stands for: Initiating, Diagnostic, Establishing, Acting & Leaning, this model was published under the Software Engineering Institute at Carnegie Mellon University by Bob McFeeley in 1996 and it consists in a 5 phase cycle.
This model is considered an organizational improvement for CMMI and the SPICE methodologies as it salvages some of the framework infrastructure. The name of the method itself is the 5 phases of the cycle, which it cycles after the fifth step and goes back to the second and so on. Now the specifics for the phases are:
- Initiating: In this step and necessity and a sponsor must be found to start the diagnosis.
- Diagnosing: This is an analysis phase as you want to innovate the current practices in processes, to compare it to other models, it would be like and SCAMP or an appraisal.
- Establishing: Here we create specific solutions from the result of our diagnosis and finish a concrete plan.
- Acting: Act according to the plan.
- Learning: Learn and adapt to improve the next cycle of the model
Now each for the phases, these have a defined set of activities which makes this model even more developed that it would be initially assumed. The activities are:
- Initiating: Establish context, build sponsorship and charted infrastructure.
- Diagnosing: Characterize current and desired state, Develop recommendations.
- Establishing: Set priorities, Develop approach, Plan actions.
- Acting: Create solutions, Test/Pilot Solution, Refine Solution, Implement Solution
- Learning: Analyze and validate, Propose future actions.
While this method seems like it could be a methodical problem solving employed in various sectors of any business it goes to show how much does the actual processes of QA need to be in the spotlight as it is a REALLY important part of QA.
AND THAT’S A WRAP. This one was longer than expected an somehow I kinda want to explain more things in this topic, but it’s already longer than expected so I might make and extra entry just for a model or two of these, and so I can dive deeper in a couple of the most interesting ones. Well I hope you enjoyed this one!