How a supplier of automotive electronics, chips, IP or software builds, runs and proves process capability to Automotive SPICE: agreeing the assessment scope and target profile with the customer, a gap assessment against the process reference and assessment model, process definition and an improvement plan, deployment of the processes, tools and training, project execution against the management, support, system, software and hardware engineering processes with the cybersecurity plug-in where it applies, the formal assessment, the capability level outcome and the improvement actions and reassessment that follow.
Automotive SPICE process and assessment lifecycle: 12 stages and 16 gates, from Scope, Target Profile & Sponsorship to Improvement Actions & Reassessment.
12 stages and 16 gates. Each stop opens its stage; each sign opens its gate. Point at a stop or tab to it to read what the stage is for. What the codes mean
In collaboration with The Digital Electronics Blog (opens in a new tab)
In collaboration with The Digital Electronics Blog (opens in a new tab)
Deciding why an assessment or improvement program is needed (a customer requirement in a sourcing or development contract, a supplier selection, or the organisation's own improvement goal), which processes are in scope, the capability level targeted for each, which organisational unit and projects are covered, which plug-ins apply, who sponsors the work and how it is funded.
Measuring where the organisation stands today against the processes in scope: an informal or pre-assessment by a competent assessor, interviews with practitioners, a sample of real project evidence, a rating of each process against its base practices and the generic practices of the target level, and a baseline list of gaps ranked by risk to the target profile.
Defining or repairing the organisation's standard processes so they meet the assessment model in a way that suits how the teams really work: process descriptions, roles, templates, work product definitions, a traceability and consistency strategy, a tailoring guideline, and an improvement plan that orders the work by gap priority and the customer's timetable.
Rolling the processes out: role-based training, coaching, the tool chain for requirements, architecture, configuration, change, problem and test management, a pilot project that uses the processes end to end, and an evaluation of the pilot before the process set is released to every project in scope.
Starting a project on the released processes: tailoring the standard process for the project, the project plan with scope, estimates, schedule and resources, risk management, the quality assurance plan with independent reporting, configuration management with baselines, problem resolution and change request management, and the agreements and monitoring for suppliers.
Turning what the customer and other stakeholders ask for into agreed stakeholder requirements, then system requirements, then software and hardware requirements, each analysed for correctness, feasibility and verifiability, each with verification criteria, and each traceable both ways to its source and consistent with it, with cybersecurity requirements where the plug-in applies.
Designing the system architecture and allocating requirements to hardware and software elements, then the software and hardware architectures with their static and dynamic views, interfaces, resource budgets and design decisions with the alternatives considered, each evaluated against agreed criteria and traced to the requirements it implements.
Writing the software detailed design and the units that implement it, and verifying each unit by static analysis, review and unit tests against a unit verification strategy and criteria, with results recorded, traced to the detailed design and kept under configuration control; hardware detailed design and its verification run in the same way where the hardware plug-in or process group is in scope.
Integrating software units and components, then software and hardware into the system, each step verified against the architecture, followed by software and system verification against their requirements (called qualification testing in earlier versions of the model), and validation that the product meets its intended use, with regression, traceability to test cases and results, and release notes under configuration control.
The assessment itself, led by a certified lead assessor with a co-assessor: the assessment plan and confidentiality agreement, a kick-off with the sponsor and project, interviews with practitioners, review of work products and records, rating of each process attribute on the agreed rating scale, consolidation of ratings across the team and instances, and feedback of strengths and weaknesses before the team leaves.
Turning the ratings into the capability profile, a capability level for each process in scope, and an assessment report that records scope, team, evidence, ratings, strengths and weaknesses, then reviewing the outcome with the sponsor and the customer, who decides whether the result meets the contract and what conditions or follow-up apply.
Closing the weaknesses the assessment found with an improvement action plan, checking that the actions work in real projects, carrying the lessons into the standard process set, preparing a follow-up or reassessment where the customer requires it, and keeping capability up as people, tools, projects and model versions change.
The full lifecycle detail, with its charts, flows, tables and every section, is for registered members. Registration is free and takes a minute. You come back to this page afterwards.