How CMMI Compliant Organizations Can Effectively Adopt ASPICE
May 23, 2022
Story
Well-designed processes based on extensive automotive experience lead to products that are reliable, consistent with the customers’ requirements, and compliant to required standards. As process standards, both CMMI and ASPICE ensure that your organization is able to establish a process model that enable the development of high-quality automotive software.
ASPICE however, is an especially designed process for automotive software development and hence augments the benefits of CMMI. Moreover, ASPICE also shares a few artifacts with ISO 26262 standard that most automotive organizations are now adopting.
Although ASPICE has been around for quite sometime now, it has gained industry-wide acceptance only after automotive software dominance increased substantially. Organizations that worked primarily on automotive embedded solutions also began to understand its importance and relevance. Many such organizations that were earlier CMMI 2.0 or 3.0 compliant started to transition to ASPICE. While both CMMIs provide a generic guideline on how to develop reliable software, ASPICE delves a little deeper. Moreover, CMMI compliance showcases the maturity and capability of an organization a whole, but ASPICE is specific to a project. The activities that are performed to establish ASPICE compliance for one project cannot be reused for another project. The next section will deal with the differences between CMMI and ASPICE in a more detailed manner.
How is ASPICE different from CMMI?
As mentioned earlier, ASPICE is a natural progression for automotive organizations that are CMMI compliant. In order to initiate this progression, the stakeholders must be aware of the differences between the two so that they make informed decisions.
ASPICE 3.1 |
CMMI 2.0 |
ASPICE focuses more on the practice related to the development of the V model. Software development, system engineering, project management, quality assurance, and configuration management come under ASPICE purview.
|
CMMI elaborates project management (PMC, PP) and organizational level practices in more detail. However, there is lesser elaboration of engineering processes.
|
Focusses on how the software, hardware, mechanical components are interlinked (Plug-in), the interface design between various modules, etc. |
System engineering practices cannot be mapped for CMMI 2.0 |
In terms of process area, a long list of artifacts/work products like quality assurance plan, verification criteria in software requirement analysis, system requirement analysis etc. are mandatory in ASPICE. |
For CMMI 2.0, system requirement analysis, system architecture design work products, system integration test etc. are not mandatory as compared to ASPICE. |
A dedicated QA resource is mandatory for any ASPICE compliant project and so is Gap assessment. |
Both these aspects are not mandatory for CMMI 2.0 |
In spite of these differences between CMMI and ASPICE, there are still a few overlaps that must be tapped to make the transition to APSICE smoother and faster.
The Business Case for Moving from CMMI 2.0 and ASPICE 3.1
A CMMI 2.0 Level 3 or Level 5 mature organization can still have gaps with respect to ASPICE 3.1. Therefore, there should be a Business Case for adopting ASPICE for CMMI compliant organization. The questions to be asked are, is it going to benefit the organization, is it really needed for the QMS, do we have such demands from customer or arising from the project type? In today's automotive ecosystem, whether it is a European, Asian, or American market, ASPICE has become a standard business demand and can be a deal breaker.
It is quite important to specify which capability Level is being targeted to achieve in ASPICE, as the action plan, gap analysis, corrective, and improvement actions depends on it. ASPICE L3 is all about having well established QMS (Quality Management System) that can support deploying ASPICE compliant institutionalized procedures, guidelines, and templates in the projects. The organization can aim for Capability Level 2, as a first steppingstone and then aim for CL3. Also, there is no harm in aiming directly for CL3 if the teams are confident. In layman terms, CL2 in ASPICE 3.1 is a combination of project management, verification, configuration management, and quality assurance. At CL3, QMS definitions, procedures, guidelines, and templates must be adhered. Also, entire QMS must be assessed for its assets, artifacts, and capability so that it can dictate to all applicable projects- what needs to be done, how it needs to done.
Performing Gap Analysis- CMMI to ASPICE
Once that need is established, in-depth gap analysis is recommended at Organization level which is process definition, process improvement, and guidelines to implement the processes in the project, and then at the project level, how the organization defined practices are used and implemented within the project scope.
Gap analysis basically evaluates the available designed QMS, resources, policies, manuals, guidelines, templates, implemented practices, and work products. The corrective course and improvement actions are decided among the key stakeholder (lead assessor, co-assessor, organization's senior management, Quality head, Quality team) based on the priority, responsibility, and sequence of activities that shall close the gaps effectively and efficiently.
Pictorial representation of mapping between CMMI 2.0 and ASPICE 3.1
ASPICE, being a project funded by the European Union at the beginning, was created as a counterpart to CMMI (Evolved over the years, adopting multiple ISO standards). Therefore, one can observe somewhat direct and indirect mapping among the terms, concepts, and practices of both the frameworks. Similar concepts like the "Intent" in each "Practice Area" in CMMI 2.0 can be mapped to "Process purpose" identified for each Process in ASPICE 3.1. "Example or Sample Activities and Work products" in CMMI 2.0 corresponds to "Output Work products and Work product characteristics" in ASPICE. Quite similar practices can be found in both frameworks viz. both the frameworks look for upstream traceability from the software requirements. Both the frameworks ask to evaluate the design and related decisions, in order to identify the corrective course. This corrective course is based on the root cause that is a hindrance in achieving targeted objectives or metrics.
To achieve ASPICE 3.1 capability levels over various applicable processes in CMMI 2.0 (or even 1.3), almost all processes would need refinements and human resources need to be trained. The training must cover the structure, concepts, and principles of ASPICE. In addition, the identified gaps need to be fixed, reviewed, and approved. It must be ensured that results from ASPICE assessments or gap fixes have zero impact on CMMI rating for the organization. While fixing the gaps, both framework aspects shall be kept in mind and a middle ground shall be established to avoid redundancy and unnecessary efforts and resources.
A Probable Approach to Moving from CMMI to ASPICE
A CMMI compliant organization that aspires to adopt ASPICE, usually begins by demonstrating ASPICE compliant practices through the CMMI driven processes. It must unify the processes and practices and the best of both world should be adopted into the organizations’ QMS. Any process improvement must be visualized from the eyes of CMMI as well as ASPICE. Of course, there will be many challenges specific to the organization and they must be mitigated by specialized methods and procedures.
Assessment Approach for Transition from CMMI 2.0 to ASPICE 3.1
Once an extensive mapping and segregation is done, the organization can arrive on basic thumb rules when it comes to transitioning from CMMI to ASPICE. For instance, the amount of involvement of QA in the ASPICE compliant project becomes considerably higher than the CMMI projects. The effort and time needed to bring granularity at the traceability and consistency is higher for ASPICE compliant projects. Also, the amount of training and mentoring required for ASPICE project teams and quality team is quite extensive in nature. These pointers definitely help in better planning and execution of the projects, which directly helps us to achieve intended capability levels sooner for all the relevant processes.
Vaibhav Anand – Content Marketing Specialist, Embitel Technologies
Vaibhav is a digital-marketing professional with a deep-rooted interest in everything automotive. Being around automotive tech teams keeps him apprised of all new trends in the industry. Besides digital marketing, Vaibhav is fond of singing. Writing tech content keeps him busy, music keeps him alive!
Shilpa Banerjee - Certified ASPICE Provisional Assessor and Internal Auditor, Embitel Technologies
Shilpa has 10+ years of experience in evaluating various Automotive, Ecommerce, Medical and IoT domain projects and programs. She is an innovative, process driven and result-oriented auditor. Outside of work, she is passionate about the food and culture of different ethnicities and has volunteered for multiple CSR activities.