ASPICE VER. 3.0 is a domain specific version of ISO/IEC 15504 for evaluating the efficiency of development processes in the automotive industry. It assesses processes in three categories - primary, organizational, and supporting. Capability levels range from 0 to 5 based on process attributes. Processes are evaluated using process performance and capability indicators. The document outlines various engineering and management processes like requirements elicitation, project management, configuration management etc. categorized under different process groups.

1. ASPICE VER. 3.0
Presented by : Srinivas Nawali

2. GENERAL
ASPICE – Automotive Software Process improvement and capability determination
This is a domain specific version of ISO / IEC 15504
Purpose: To evaluate the efficiency of development processes of ECU suppliers in the automotive industry.
Processes in ASPICE are divided into 3 process categories:
ASPICE
Primary Organizational Supporting
3 Process
Categories

3. Primary
Acquisition Process Group[ACQ]
Supply Process Group[SPL]
Engineering Process Group[ENG]
Organizational
Management Process Group[MAN]
Process Improvement Process
Group[PIM]
Reuse Process Group[REU]
Support
Supporting Process Group

4. GENERAL
These processes are grouped at second level into process groups according to the type of activity they address

5. CAPABILITY LEVELS & PROCESS ATTRIBUTES
Level 0 : Incomplete
Level 1 : Performed
PA 1.1 : Process Performance
Level 2 : Managed
PA 2.1 : Performance Management
PA 2.2 : Work Product Management
Level 3 : Established
PA 3.1 : Process Definition
PA 3.2 : Process Deployment
Level 4 : Predictable
PA 4.1 : Quantitative Analysis
PA 4.2 : Quantitative Control
Level 5 : Innovating
PA 5.1 : Process Innovation
PA 5.2 : Process Innovation Implementation

6. PROCESS INDICATORS
Level of implementation of ASPICE can be determined by 2 types of indicators
•Exclusively for Capability Level 1
•Indicates the extent of fulfilling the process outcome
•Types of process performance indicators (PPI)
• Base practices : activity oriented indicators
• Work products : Result oriented indicators
•PPIs are specific to process
Process
Performance
indicators
•Exclusively for Level 2 to 5
•Provide an indication of process attribute fulfillment
•Types of process capability indicators (PCI)
• Generic Practices (GP) : activity oriented indicators
• Generic Resources (GR) : infrastructure oriented indicators
•PCIs apply to any process
Process
Capability
indicators

7. LEVELS AND PROCESS ATTRIBUTES
PCL0 : Process is not
implemented or fails to achieve
its purpose
PCL1: Implemented process
achieves its outcome
•Process Attribute:
•Process Performance
Process
Performance
Achieve process
outcome

8. GENERIC PRACTICE
Performance
Management
Identify the objectives for performance
of process
Plan the performance of process to fulfill
objectives
Monitor the performance
Adjust the performance
Define responsibilities and authorities
Perform the process as per the plan
Manage interfaces b/w involved parties
Work
product
Management
Define requirements for WPs
Define requirements for documentation
and control of WPs
Identify, document and control WPs
Review and adjust work products to
meet defined requirements
PCL2 : Process is implemented in a managed way (planned, monitored and adjusted)
Work products are established and controlled
•Process Attributes :
•Performance Management
•Work Product Management

9. GENERIC PRACTICE
Process Definition
Define and maintain set of standard
process which will support deployment
Sequence and interaction of process
Identify roles, responsibilities,
competencies and authorities
Infrastructure and work environment
Suitable methods and measures to
monitor process performance
Process Deployment
Deploy defined process
Identify roles, responsibilities,
competencies and authorities
Competency
Provide information and resources
Provide process infrastructure
Collect and analyze data about
performance
•Process Attributes :
•Process Definition
•Process Deployment
PCL3 : Managed process is
now implemented using
defined process that is
capable of achieving
process outcome

10. GENERIC PRACTICE
Quantitative
analysis
•Identify Business Goals
•Process information needs
•Derive Measurement Objectives
•Identify measurable relationships b/w
processes
•Establish Quantitative objectives
•Establish process measures that
support achievement of objectives
•Collect measurement results Quantitative
Control
•Select analysis technique
•Control limits
•Assignable causes
•Corrective action for assignable causes
•Understand the variation of process
performance under the influence of
assignable causes
PCL4 : Process now operates predictively within the defined limits to
achieve the intended process outcome
Process Attributes :
•Quantitative analysis
•Quantitative Control

11. GENERIC PRACTICE
Process Innovation
•Define process innovation objectives to support
business goals
•Analyze data to identify innovation opportunities
•Analyze new technologies and process concepts
•Define and maintain implementation strategy
Process Optimization
•Assess the impact of each proposed change
•Manage implementation of accepted change
•Evaluate effectiveness of the change
PCL5 : Process now is continually improved to respond to the change
as per org. goals
Process Attributes :

12. PRIMARY LIFE CYCLE PROCESSES CATEGORY
Primary Life Cycle Processes
•Processes that may be used by Customer when acquiring products from Supplier
•By Supplier while responding and delivering products to Customer
Acquisition
•Processes performed by
Customer while
acquiring product or
service
Supply
•Processes performed by
the supplier to supply
the product or service
S/m Engg
•Processes addressing the
elicitation and
management of
customer and internal
requirements, defining
the architecture,
integration and testing at
s/m level
S/w Engg
•Processes addressing the
elicitation and
management of
customer and internal
requirements, defining
the architecture,
implementation
integration and testing at
s/w level

13. SUPPORTING AND ORGANIZATIONAL LIFE CYCLE PROCESSES
CATEGORY
Supporting Life Cycle Processes
•Processes that may be used by any other processes during the various phases of life cycle
Organizational Life Cycle Processes
•Processes that develop processes, products and resource assets which when used by the
project’s in the organization helps the org. to achieve its business goals
Management
•Processes that can be
used by anyone who
manages the project or
process within life cycle
Process Improvement
•Process that contains
practices into improve the
processes performed in
the org.
Reuse
•Process to systematically
exploit reuse
opportunities in the org.

14. SOFTWARE/SYSTEM ENGINEERING PROCESS
GROUP[SWE/SYS]
SYSTEM[SYS] SOFTWARE[SWE]
SYS 1: Requirement Elicitation
SYS 2: System Requirement Analysis
SYS 3: System Architectural Design
SYS 4: System Integration And Integration
Test
SYS 5: System Qualification Test
SWE 1: Software Requirement Analysis
SWE 2: Software Architectural Design
SWE 3: Software Detailed Design & Unit
Construction
SWE 4: Software Unit Testing
SWE 5: Software Integration & Integration Test
SWE 6: Software Qualification Test

15. REQUIREMENTS ELICITATION
Purpose
•To gather, process and track evolving stakeholder requirements through out the
product/service life cycle to establish baseline for further development.
Baseline
Obtain
stakeholder
requirement
Understand
stakeholders
expectations
Agree on
requirements
Establish
Requirements
baseline
Manage req.
changes
Establish query
communication
mechanism

16. REQUIREMENTS ELICITATION TECHNIQUES
Interviews Questionnaire Prototyping
Brainstorming
QFD
Quality Function
Deployment
Reverse
Engineering
Competitive
evaluation
Survey Study of SOW

17. SYSTEM / SOFTWARE REQUIREMENT ANALYSIS
Purpose:
System : To transform Stakeholder requirements to system requirements to guide in the design
of the system
Software : To transform the software related parts of the system requirements to a set of
software requirements

18. SYSTEM / SOFTWARE REQUIREMENT ANALYSIS
Specify System / Software requirements
•Identify required Functions and capabilities of the system
•Identify Functional and Non functional requirements
Structure System / Software Requirements
•Group, Categorize and Prioritize
Analyze System / Software Requirements
•Inter-dependencies and Technical feasibility
•Verifiability
•Risk Identification
•Impact on operating environment
Bi-directional Traceability
Ensure Consistency
Communicate agreed requirements

19. SYSTEM / SOFTWARE ARCHITECTURAL DESIGN
Purpose:
System : To identify which system elements are allocated to System requirements
To evaluate the system architecture against the defined criteria
Software : To identify which software elements are allocated to Software requirements
To evaluate the software architecture against the defined criteria

20. SYSTEM / SOFTWARE ARCHITECTURAL DESIGN
Evaluate alternative System / Software architecture design
Describe dynamic behavior
Define interfaces of the System / Software elements
Allocate System / Software Requirements
Develop System / Software Architectural Design
Specify the elements of the system / software wrt functional and non-functional
requirements
Define resource consumption objectives for all relevant elements of software architectural
design

21. SOFTWARE DETAILED DESIGN AND UNIT CONSTRUCTION
Develop
software
detailed
design
Define
interfaces of
software units
Describe
dynamic
behavior
Evaluate
software
detailed
design,
Bidirectional
traceability,
consistency
and
communicate
Develop
software units
Purpose: To provide an evaluated detailed design for the software units
To produce the software units

22. SOFTWARE UNIT VERIFICATION
Purpose: To verify software units to provide evidence for compliance with
software detailed design and with non functional requirements

23. SYSTEM / SOFTWARE INTEGRATION AND INTEGRATION TEST
Purpose:
System : To integrate the system items to produce an integrated system consistent with
Architectural design
To ensure that the system items are tested (including interfaces)
Software : To integrate the software units into integrated software
To ensure consistency with software architectural design
To ensure that the software items are tested (including interfaces)

24. SYSTEM / SOFTWARE INTEGRATION AND INTEGRATION TEST
Develop System / software
Integration Strategy
•This shall include even regression test strategy
if a system item is changed
Develop System / software
Integration test strategy
Develop specification for
System / software Integration
test
Integrate system / software
items
Select test cases
Perform system / software
integration test

25. SYSTEM / SOFTWARE QUALIFICATION TEST
Purpose:
System : To ensure that integrated system is tested to provide evidence for compliance with
system requirements
To ensure that the system is ready for delivery
Software : To ensure that integrated software is tested
To provide evidence for compliance with software requirements

26. SYSTEM / SOFTWARE QUALIFICATION TEST
Develop System /
Software
qualification test
Strategy
Develop
specification for
System / Software
Qualification test
Select test cases
Perform system
qualification test

27. SUPPORT PROCESS GROUP[SUP]
• SUP 1: QUALITY ASSURANCE
• SUP 2: VERIFICATION
• SUP 4: JOINT REVIEW
• SUP 7: DOCUMENTATION
• SUP 8: CONFIGURATION MANAGEMNT
• SUP 9: PROBLEM RESOLUTION
MANAGEMENT
• SUP 10: CHANGE REQUEST
MANAGEMENT

28. QUALITY ASSURANCE
Purpose: Independent and objective assurance that processes and work products comply to
the set provisions and plans
Ensure non conformances are resolved and prevented
Develop Strategy
Assure Quality of WPs
Assure Quality of
activities
Summarize and
communicate activities
Resolution of NCs
Escalation

29. VERIFICATION
Purpose: To confirm that each work product reflects the specified requirements
Develop
Strategy
Criteria for
verification
Conduct
verification
Track
actions
Report
results

30. JOINT REVIEW
Purpose: To maintain a common understanding with the stakeholders of the progress against
the objectives
To get aid / opinion to satisfy the agreed stakeholders requirement
Both Technical and Project Management activities are reviewed and these reviews are held
throughout the project lifecycle.
Define
review
elements
Handle
review
outcome –
How?
Prepare
Joint
Reviews
Conduct
Joint
Reviews
Determine
actions
Track
Actions
Identify
and
record
problems

31. DOCUMENTATION
Purpose: To develop and maintain the recorded information
Develop
Strategy
Establish
Standards
Specify
requirements
Identify
relevant
documents
Develop
documents
Check,
Distribute
and Maintain

32. CONFIGURATION MANAGEMENT
Purpose: To establish and maintain integrity of all work products
To make them available to concerned parties

33. PROBLEM RESOLUTION MANAGEMENT
Purpose: To ensure that the problems are identified, analyzed, managed and controlled to
resolution
Develop
Strategy
Identify &
record
problems
Record status
Diagnose the
cause
Authorize
urgent
resolution
Raise alert
Initiate
problem
resolution
Track
Analyze
problem
trends

34. CHANGE REQUEST MANAGEMENT
Purpose: To ensure That the change requests are managed, tracked and implemented
Develop Strategy
Identify & record CRs
Record status
Analyze and Assess
Approve CRs
Review implementation
Track CRs
Traceability

35. MANAGEMENT PROCESS GROUP[MAN]
• MAN 3: PROJECT
MANAGEMENT
• MAN 5: RISK MANAGEMENT
• MAN 6: MEASUREMENT

36. PROJECT MANAGEMENT
Purpose: To identify, establish and control the activities and resources necessary for the
project to produce a product (in the context of project’s requirements and constraints)
Define scope of work
Define project lifecycle
Evaluate feasibility of the project
Define, monitor and adjust
activities
Define, monitor and adjust
estimates and resources
Ensure required skills, knowledge
and experience
Identify, monitor and adjust
interfaces and commitment
Define, monitor and adjust
schedule
Ensure consistency
Review and report progress

37. RISK MANAGEMENT
Purpose: To identify, analyze, treat and monitor risks continuously
Risk
Management
Identify
Analyze
Take
Action
Monitor
Control
Scope
Strategy

38. MEASUREMENT
Purpose: To collect and analyze data related to products developed and processes
implemented
To support effective management of processes and objectively demonstrate quality of product
Org.
Commitment
Strategy
Information
needs
Specify
measures
Measurement
Retrieve data
Analyze
Decision
making
Communicate
Evaluate
measurement
activities
Communicate
improvements

39. REUSE PROCESS GROUP[REU]
• REU 2: REUSE PROGRAM
MANAGEMENT

40. REUSE PROGRAM MANAGEMENT
Purpose: To plan, establish, manage, control and monitor organization’s reuse program and to
systematically exploit reuse opportunities
Strategy
Identify
Domains
of reuse
Assess
domains
Assess
reuse
maturity
Evaluate
proposals
Implement
Get
feedback
Monitor

41. PROCESS IMPROVEMENT PROCESS
GROUP[PIM]
• PIM 3: PROCESS IMPROVEMENT

42. PROCESS IMPROVEMENT
Purpose: To continually improve the organization's effectiveness and efficiency through
processes and aligned with business need
Commitment Identify issues PI goals Prioritize Plan changes
Implement
Confirm
improvement
Communicate
Evaluate

43. ACQUISITION PROCESS GROUP[ACQ]
• ACQ 3: CONTRACT AGREEMENT
• ACQ 4: SUPPLIER MONITORING
• ACQ 11: TECHNICAL REQUIREMENTS
• ACQ 12: LEGAL AND ADMINISTRATIVE
REQUIREMENT
• ACQ 13: PROJECT REQUIREMENTS
• ACQ 14: REQUEST FOR PROPOSALS
• ACQ 15: SUPPLIER QUALIFIACTION

44. CONTRACT AGREEMENT
Purpose: To negotiate and approve a contract / agreement with supplier
Negotiate
contract
Specify rights
and duties
Supplier
capability
Risk Mitigation
Approve
Award
Communicate

45. SUPPLIER MONITORING
Purpose: To track and access the performance of the supplier against the agreed requirements
Agree on Joint
review process
Exchange info.
Review
technical dev.
Review
progress
Act to correct
deviations

46. TECHNICAL REQUIREMENTS
Purpose: To establish the technical requirements of the acquisition
To elicit functional and non-functional requirements
Elicit needs
Define tech.
requirements
Identify
acquisition
needs
Ensure
consistency
Identify
affected
groups
Communicate
Establish
change
mechanism
Track impact
of changing
technology
Identify
constraints
and standards
Ensure
compliance to
req.

47. LEGAL AND ADMINISTRATIVE REQUIREMENTS
Purpose: To define the awarding aspects such as expectations, liabilities, legal and other
issues
Comply to national and international laws of contract

48. PROJECT REQUIREMENTS
Purpose: To specify the requirements to ensure the acquisition project is performed with
adequate planning, staffing, directing, organizing and control over tasks and activities
Identify
relevant
groups
Communicat
e
Define org.
req.
Define
Mgmt. req.
Identify
competency
Identify
responsibiliti
es and goals
Information
needs
Define info.
exchange
Criteria for
interim WPs
Establish
payment
req.
Identify and
communicat
e risks
Define rights
for use and
distribution
Establish
support &
maintenance
req.

49. REQUEST FOR PROPOSALS
Purpose: To prepare and issue the necessary acquisition requirements. The documentation
shall include, but not limited, to the contract, project, finance and technical req. To be provided
in Call for Proposal / Invitation for tender
RFP
Define
rules
Assemble
req.
Establish
T &C
Establish
Fin. Terms
Establish
project
terms
Establish
technical
terms
Identify
regulation
s
Prepare &
Issue CPF

50. SUPPLIER QUALIFICATION
Purpose: To evaluate and determine if the potential suppliers have the required qualification for
entering the proposal / tender evaluation process
The technical background, quality system, servicing, user support capabilities will be evaluated
Supplier
Selection
Establish
Qual.
criteria
Evaluate
supplier
Shortlist
Evaluate
shortfalls
Perform
Corrective
actions

51. SUPPLY PROCESS GROUP[SPL]
• SPL 1: SUPPLIER
TENDERING
• SPL 2: PRODUCT RELEASE

52. SUPPLIER TENDERING
Purpose: To establish an interface to respond to customer inquiries and RFP
Prepare and submit proposals
Confirm assignment though establishment of agreement
Establish
com.
interface
Customer
inquiry
screening
Establish
proposal eval.
criteria
Need for
preliminary
pre-study
Identify and
nominate
staff
Prepare
response
Establish
confirmation

53. PRODUCT RELEASE
Purpose: To control the release of product to the intended customer
Define Functional
content of release
Define release
products
Release classification
and numbering
Define build
activities and build
environment
Build and release
from CIs
Communicate type,
service level and
duration of support
Determine delivery
media type
Identify packing
Define and produce
product release
documentation
Approval before
delivery
Ensure consistency Provide release note Deliver the release

54. THANK
YOU