The Day the CPK Report Came Out, the Whole Room Fell Silent for Three Seconds
I still remember a while ago, our team had a new project, and the client was a certain European car manufacturer. In the initial stages of the project, everyone was very excited, feeling that we could finally collaborate with an international major player. What happened next? Halfway through product development, the client suddenly parachuted in an audit team, explicitly asking to see our software development process. At that time, our PM looked completely bewildered and came to ask me: "Lao Su, have you heard of that 'what's-it-called SPICE'? They said we haven't even reached Level 1, and the entire project will be halted!" Honestly, I was also dumbfounded at that time, thinking, "What's this new trick?" In the past, for wafer manufacturing, it was at most ISO 9001, IATF 16949; now even software needs to be assessed?
Where Did the Problem Lie?
To put it simply, ASPICE is a standard for evaluating the "maturity" of your software development process. Imagine you're developing a chip for a car manufacturer today; besides stable hardware quality, software is the soul. You certainly wouldn't want the software in the car to suddenly crash while driving, or for the accelerator to be unresponsive, would you? This could lead to fatalities. Therefore, car manufacturers have exceptionally high demands for software development processes. They scrutinize whether every step, from requirements planning, design, implementation, and testing to maintenance, is properly executed and sufficiently rigorous.
In other words, it's not judging how "flashy" your code is, but rather whether the "process" by which you write code follows the rules. For example, if your requirements document is unclear, the subsequent design will inevitably go awry; or if test reports are written haphazardly, who knows if you've tested what needed to be tested? This standard breaks down these processes into several items and then scores your performance.
How Is It Actually Done?
ASPICE divides process assessment into six levels, from Level 0 (Not Performed) to Level 5 (Optimizing). I'm telling you, at first, we weren't even close to Level 1. The most basic requirement for Level 1 is "Performed." Sounds simple, right? But just the act of "having documentation" stumps a lot of people.
For instance, our Software Requirements Specification (SRS). During a client audit, they would randomly select a few features and then ask: "Where did the requirement for this feature come from? How did you confirm that this requirement is correct?" If you just say, "Oh, the PM told me verbally," then that's an immediate "GG" (Game Over). What they want to see is:
- Is there version control for the requirements document? (Document title, version number, date, author)
- Are requirements clearly defined? (Cannot write vague terms like "smooth operation"; should specify "screen tap response time less than 100ms")
- Have requirements been reviewed? (There must be reviewer signatures or records)
- Can requirements be traced to test cases? (Each requirement must correspond to at least one test case to ensure it has been verified)
At that time, many requirements in our team were communicated by word-of-mouth or finalized with a quick message on Slack. As soon as the audit team arrived, they saw our requirements documents, which didn't even have version numbers, and immediately rejected them. They weren't looking at what you wrote, but "how" you wrote it.
The Most Common Pitfall
The biggest pitfall is "finding it troublesome." Many engineers feel that spending so much time writing documents and following processes is less productive than writing a few more lines of code. But honestly, if you're lazy now and don't write documents, you'll know what "pain" truly means when problems arise in the future.
We once had a bug where the screen would occasionally freeze after the product went live. After half a day of investigation, we discovered it was due to a requirement change that was only verbally communicated and not updated in the requirements document, causing this step to be missed in subsequent development and testing. If ASPICE Level 1's documentation management had been properly executed then, this pitfall would not have appeared at all. To fix that bug, we spent nearly an extra month going back and forth. Calculating the labor costs, it was definitely several times higher than spending a few more hours writing documents initially.
So the key point is, this isn't about writing documents for the sake of writing documents; it's about making the entire development process more transparent and controllable, ultimately achieving better product quality.
One Thing You Can Do Today
Add a version number and date to your current software requirements document.