Models and Standards for Software Process Improvement
Hello there (General Kenobi). Welcome back to my blog posts. Grab a drink, grab your snacks, ’cause today we’ll be talking about models and standards for software process improvement (woo-hoo?). I’ll try to keep it short, but I can’t promise you anything. In fact, it’s probably gonna be a rather long one.
So uh, what are these models and standards all about? Well, they’re supposed to improve the way we develop software by planning and implementing new activities that are designed to achieve specific goals set by the company you work for. Some of these goals include, but are not limited to:
- Increasing product quality
- Decreasing development/maintenance costs
- Increasing development speed
Now, as you may very well know, there’s no such thing as a “one-size-fits-all” approach to anything software related, so of course, there’s a bunch of people and organizations that have different opinions and different ideas on how we can improve the way we create software. In this blog post, we’ll be talking about a couple of them and see how they stack up against each other.
CMMI
The Capability Maturity Model Integration is a set of “best practices” that measures and improves a team’s performance through a process level improvement training and appraisal program. This model will help you build, improve, and measure the capabilities of your team, increasing your overall performance in the process.
CMMI categorizes organizations based on what they call “maturity levels”. The higher the maturity level, the better. Each level increase is built on top of the previous one by the addition of one piece of functionality.
- Level 1: The organization is unpredictable and reactive. It gets the job done, but going over budget and delays are relatively common. Basically your average college student.
- Level 2: Projects go through planning before doing things, and performance is being measured and controlled, and the deliveries go through some sort of quality assurance.
- Level 3: Projects and programs are guided through an organization-wide standard. Decisions are analyzed before being executed, and risk management plays a bigger role now. The team now prevents things going wrong instead of reacting when something goes downhill.
- Level 4: The organization gathers enough quantitative performance data to become data-driven. This results in a measured and controlled environment where objectives are predictable and the expectations of internal and external stakeholders are constantly achieved.
- Level 5: The organization performs at a stable rate, and is basically unaffected by change thanks to its flexibility, which helps it pivot rapidly and respond to any opportunity that may present itself.
However, this is not something that’s tailor-made for software developers, so it may not be able to tackle some of the things that hold your team back, but it is a great option for companies that have multidisciplinary teams that need to improve.
TSP/PSP
Personal Software Process is tailor-made for software developers, providing a structured process that is designed to help us better understand and improve our performance. Estimation skills improve as a result of learning to make promises that are actually achievable based on real data that helps justify decisions, quality standards are better managed, and development time, defects, and size are measured and analyzed, reducing the faults and imperfections in our code.
There’s a structure to integrate PSP into your process:
- PSP0, PSP0.1: Planning, developing, and post mortem are the three phases of PSP0. The engineer gathers data during these phases (time spent programming, faults injected and removed, program size), and ensures that everything was properly measured in the post mortem phase. PSP0.1 improves over PSP0 by adding a coding standard and an improvement plan.
- PSP1, PSP1.1: Based on the data collected in PSP0 and PSP0.1, PSP1 now prompts you to estimate how large a new program will be and prepares a test report. Previous data is used to better estimate the time it should take to develop this new project. Each new project will follow PSP0 and record data accordingly so that we can get progressively better at estimating and planning schedules in PSP1.1.
- PSP2, PSP2.1: PSP2 adds design and code review to the equation. Defect prevention and their removal are the main focus for this stage, making engineers learn to evaluate and improve their process by measuring how long it takes them to execute certain tasks and how many defects they inject and remove in each of the development phases. PSP2.1 introduces design specification and new analysis techniques to improve what was applied in previous stages.
Team Software Process basically means that every programmer in a team is PSP-trained so that the project is managed by the team itself. Each member gathers personal performance data and the whole team plans, estimates, and controls the quality of the software produced based on said data.
As you might’ve already noticed, data is super important for PSP/TSP to be properly applied. Historical data is continuously analyzed and used to improve. PSP has 4 core measures:
- Size, which is commonly measured in lines of code.
- Effort, which is commonly measured in minutes.
- Quality, which is commonly measured by the number of defects.
- Schedule, which is commonly measured by comparing planned vs actual completion dates.
PSP/TSP basically takes CMMI’s principles and applies them to software development processes, providing specific solutions to specific problems that we most likely will encounter when working on a project.
ISO-15504
You know our friends over at ISO, they’ve got a bunch of standards for quality and performance in a lot of industries. Turns out software is one of those industries. ISO-15504 is also known as SPICE (Software Process Improvement Capability Determination). Although it’s been superseded by ISO 33001, it’s nice knowing a bit of history on how these standards came to be.
The process dimension in the standard’s reference model defines processes divided into five categories: customer-supplier, engineering, supporting, management, and organization. New parts are published constantly, and the process categories are expected to expand.
There are six capability levels:
- Level 0: incomplete process, meaning that performance and results are incomplete and chaotic.
- Level 1: performed process, meaning that processes are intuitively performed, and the input and output work products are available.
- Level 2: managed process, meaning that processes and work products are managed, and the team knows its responsibilities.
- Level 3: established process, a defined process that suits the team’s specific needs is tailored from a standard process and deployed.
- Level 4: predictable process, performance data is available for historic analysis, making future results predictable and controllable.
- Level 5: optimizing process, continuous improvement is being constantly achieved through process innovation and optimization based on previous and current performance data.
Each level has different process attributes, which are evaluated on an NPLF scale (Not achieved, partially achieved, largely achieved, fully achieved). Based on the results attained for each attribute, a level is provided and the team is expected to improve from there.
MOPROSOFT
Modelo de Procesos para la Industria del Software (Process Model for the Software Industry) has the goal of evaluating and improving the software systems development and maintenance processes. It was developed by the Mexican Software Development Quality Association through the UNAM’s accountancy and administration faculty to provide a Mexican norm that was appropriate for the majority of Mexican software development companies.
It is based on ISO’s 9001:2000 process model, CMM-SW’s process area level 2 and 3, ISO’s 15504’s general concept and the best practices provided in PMBOK and SWEBOK.
It defines three main processes that are supervised and controlled:
- High direction: provides strategic planning and promotes the organization’s optimal operation through revision and constant model improvement.
- Management: provides resources, processes and projects, and it’s responsible for making sure that the organization’s strategic goals are accomplished.
- Operation: actual working force, it’s the one that develops the projects set by management and maintains the previously developed.
IDEAL
IDEAL stands for Initiating, Diagnosing, Establishing, Acting, Learning. This model serves as a roadmap for initiating, planning, and implementing improvement actions. There are multiple steps to each phase in the IDEAL method:
- Initiating: Setting a context that takes into account key business drivers, building a sponsorship, and establishing who will be taking action.
- Diagnosing: Characterizing the current state, as well as the desired state, and developing improvement recommendations for each team.
- Establishing: Setting priorities based on business drivers and area impact, developing an approach, and planning for an improvement program based on the recommendations.
- Acting: Creating a solution, testing said solution and observing the results, refining the solution based on said results, and installing a final solution after the refined solution fits the needs of the organization.
- Learning: Analyzing and validating that the results attained line up with the desired state established in the diagnosing stage, and proposing future actions to further improve in the future.
This is perhaps both the most detailed and the most flexible out of the ones listed in this blog post. It provides a very specific and tailored framework that we follow to improve our processes, but nothing is specific enough to the point of being inflexible. On the contrary, IDEAL is recognized for its flexibility, making it easy to pivot if needed.
Of course, depending on your team’s specific needs, you’ll most likely lean towards one of these models more than the others, but the idea is that you should have a clear picture of all the alternatives available to you so that you can take the decision that’ll bring the most benefits to your team.
