The document discusses combining Agile development practices with Automotive SPICE (ASPICE) for software development in the automotive domain. It notes that while ASPICE provides rigorous processes for safety and quality, Agile allows for more flexibility and adaptability to changing requirements. The document proposes some ways to integrate aspects of Agile, such as iterative development, customer involvement, and prioritizing features, within the overall ASPICE framework to gain benefits of both approaches. It also acknowledges challenges in ensuring functional safety requirements are met with an Agile approach.

1. White Paper
White Paper
Auto Spice-
Agile…Hand in
Hand
November 2016
Ruchika Sachdeva

2. AGENDA
INTRODUCTION
ASPICE-
INSIGHT &
ASSESSMENT
PERSPECTIVE
AGILE
STRUCTURE
AGILE BEST
PRACTICE IN
PRODUCT
DEVELOPMENT
FITMENT OF
SDLCS
RESPONDENTS
DEMOGRAPHICS
BENEFITS CONCLUSION

3. The intended objective for any organization is to be recognized for its capabilities ,which
embarks its business goals on attainment of highest Possible maturity and capability
levels in its processes.
The capability & maturity is trending more towards Domain specific rather than
conventional types. One of the coveted domain is that of an Automotive industry
wherein customer demands perpetually increasing number of innovative vehicle
functions .
There has been growing demand relating to protection of environment, security, safety,
economic efficiency and user friendliness, that too in a shortest development period .
This can only be achieved by introduction of complex & highly networked software
systems.
Nevertheless, the story doesn't ends here. With the growing competition and user
demands, change is inevitable. Henceforth agility is utmost expected .
With a flair of Agile development , the change is accepted with a simple reason that “Its
expected", along with other rewarding features such as early and regular releases, agile
development requirements to emerge and evolve, and „perpetual beta‟. Thus a change
from defined to adaptive development.
INRODUCTION

4. AUTOSPICE…INSIGHT
Automotive SPICE is a process model developed by Automotive SIG (Special Interest
group) for performing and assessing software development in automotive domain in
accordance with ISO/IEC 15504. Implementation of ASPICE leads to better processes
and better product quality. It also helps to improve the cooperation among complex supply
chains and between globally distributed development and engineering centers. All major
OEMs have specified requirements and scope of implementation of ASPICE for their
suppliers.
Triggers for opting ASPICE?
Owing to an ever increasing market demand and associated shorter period of
development ,together with greater demands of quality and reliability, make it essential to
improve software development process involved in building up of any automotive system.
Henceforth the application of ASPICE is now a prerequisite for sustaining as a supplier of
most of the coveted European car manufacturers. The results of assessment and specific
guidance provided by the model are used for process design and identification of process
improvements at a supplier as well as a criterion for supplier selection.

5. ASPICE MODEL
STRUCTURE

6. AGILE INTO PRODUCT
DEVELOPMENT
MODEL STRUCTURE
Agile Manifesto Equivalent
in Product Development:
 Organize Engineers into
best teams.
 Working Prototypes
 Involvement of Customer
or equivalent
representative in
Validation & Verification
activities through the
Product Development life
cycle
 Responding to
development issues
during product
development.

7. SURVEY..AGILE USED IN ALL DOMAINS??
ECU /Application Types:
Multimedia Applications:
 Location‐based Services Applications
 Telematics
 Radio Navigation
Body Electronics:
 Body Controller
 Sensors (Light, Battery, …)
 Instrument Cluster
Powertrain and Chassis Control:
 Braking Systems
 Engine Management
Integrated Systems/Services:
 Intelligent Mirror System
 Active Safety
 Driving Assistance / Automatic Driving
Which Subdomain(s) / ECU Types are covered by Agile projects?
Survey ..respondents
from leading automotive
companies
Tier 1- Piloting &
transformation
Tier 2- Already Agile
since years.
27.80%
44.40%38.90%
33.30%
ECU Applications
Power Train &
Chasis Control
Body Electronics
Multimetdia
Applications
Integrated
System/Services
*ECU-Electronic Control Unit

8. AGILE IN PRODUCT DEVELOPMENT
About 65% of the respondents considered the
implementation of Agile principles successful.
Product Development in Product
Engineering Services Domain-
• Development Iterative Model
• Development V-Model
• Development-Agile-65% 35%
65%
Development Agile Vs
Development Iterative/ V Model
Product Dev
non Agile
Agile Dev
35%
approx

9. SURVEY as per InfoQ.
IS AGILE COMPATIBLE WITH AUTOMOTIVE SPICE??
3G/4G
communica
tion
capabilities
• new services like stolen
vehicle tracking, car
sharing, emergency calls
and dealer services
Large
variability in
hardware –
software
combinations
• Module to be used in
many different car
brands around the
world.
Continuous
Requirements
changes
• Specification
• Blurriness
Combined Agile and Automotive SPICE by
using “a custom version [of agile] integrated in
current project life-cycles”.
 Using Kanban with pseudo sprints
 Automotive SPICE processes kept for
satisfying safety requirements and auto-
documented testing.
 Followed an agile process with daily
meetings, demos with the customers and
retrospectives.
 Tasks from ASPICE included in the backlog.
 Tailoring of review process to fit into Small
iterations in Agile.
Benefits realized
 Light Process vs Automotive
classical approach
 Fitted more to the needs of
software developers or users
rather than projects managers
 Fast & Flexible to changes
Challenges
SCRUM mainly supports MAN.3, partly
SWE.4 and SWE.6.
Kanban actually improved the compliance
with some Automotive SPICE practices
(SUP.9, SUP.10)
SAMPLE: Car Telematics Project

10. FEASIBILITY CHECK..
Fitment of SDLCs…ASPICE Vs AGILE
ASPICE MODEL AGILE DEVELOPMENT
Requirement Elicitation
System Requirement Analysis
System Architectural Design
System Integration and
integration test
System qualification test
Software Requirement Analysis
Software Architectural Design
Software Detailed Design and
unit construction
Software Unit Verification
Software Integration and
integration test
Software qualification test
Product Release
Envision-Arriving at
Product backlog
Analyze user
stories
Sprint Planning
/Design
Perform coding &
integration
Conduct Testing
Release to market
Envision-Arriving
at Product backlog
Analyze user
stories
Sprint
Planning/Design
Perform coding &
integration
Conduct Testing
Release to market
Envision-Arriving at
Product backlog
Analyze user
stories
Sprint Planning
/Design
Perform coding &
integration
Conduct Testing
Release to market
Sprint 1 Sprint 2 Sprint 3….
Grey
Areas

11. GREY AREAS…BARRIERS IN FUNCTIONAL SAFETY
REQUIREMENTS WITH ASPICE & AGILE
Concept Development Product Development (System,
Hardware, Software)
Production &
Operation
Support
 ASIL(Automotive Safety
Integrity level)
 Hazard & Risk analysis
 System Design
,integration & Testing
 Hardware Design,
architectural metrics
 Software Design ,
testing
 Operation &
decommissioning
 Qualification of software
tools,
 Hardware components,
software components
 Change/,Configuration
management
management, verification
Management of functional safety
 Overall Safety Management
during development & after
Release or production
ASIL/safety oriented
analysis
 Dependent
failure/Safety
Analysis
ASPICE
AGILE
ASPICE
AGILE
ASPICE
AGILE
ASPICE
AGILE
ASPICE
AGILE
ASPICE
AGILE
Functional safety Life cycle(ISO 26262)
Weakly supporting
Not supporting
Strongly supporting

12. SOME SUBSTITUTES IN ASPICE & AGILE TO ADDRESS
FUNCTIONAL SAFETY BARRIERS
Functional safety Life cycle(ISO 26262)
ISO 26262 PHASE ASPICE AGILE Mitigation
Management of functional
safety
 Overall Safety Management
 Continuous Improvement
 Safety case
 Safety manager-responsible for the
planning and coordination of the
functional safety activities in the
development phases of the safety
process.
 Definition of done-include Formal
compliance with ISO 26262 ,clause
6.4.6, requirement of work product
safety Clause 6.5.1, 7.5.1
 Safety Product owner
 Safety requirements in backlog
 CI tools- Jenkins ,Buildbot ,travis CI,
Go, Integrity
Concept Development
 ASIL(Automotive Safety
Integrity level)
 Hazard & Risk analysis
 ASIL based safety requirements

13. SOME SUBSTITUTES IN ASPICE & AGILE TO ADDRESS
FUNCTIONAL SAFETY BARRIERS
Functional safety Life cycle(ISO 26262)
ISO 26262 PHASE ASPICE AGILE Mitigation
Product Development
System Design ,integration &
Testing
Automated integration test scripts
Production & Operation
Operation & decommissioning
Retirement activities
Support
Qualification of software tools,
Tool Qualification group DO -330 can be
referred to address tool qualification
related issues.
ASIL/safety oriented analysis
Dependent failure/Safety
Analysis
 Traceability helps to establish
compliance to standards and
regulations
 Adding traceability links. Links are
automatically established as
developers check in code that
implements a certain task

14. AGILE CHERRY PICKING…MANAGEMENT
& SUPPORT AREAS
Some of the Agile aspects that can be used in Product Development along with ASPICE Rigor
Planning Monitoring
Release and
Deployment
Change
Management
Configuration
Management
Collaborative
Environment
Product Development
planning combined with
Agile planning
-Time boxed Sprint
Planning meeting
-Use desirable sprint
length- 3 weeks is the
average.
Burn down chart s for
Progressive planning
with focus on Deliver on
Time
Release Burndown Change Analysis-Typical
analysis criteria are:
resource requirements,
scheduling issues, risks,
benefits, etc.
Configuration Management
to be automated to support
frequent changes, frequent
build, status accounting
integrity check
Collaboration
forums
Estimates-Planning
Poker/Agile effort
Converter tool can be
leveraged
User story tracker
updation as necessary
based on any changes
to keep the sprint on
schedule
Tagging Product
feature as part of
Product backlog to
release
Establish criteria for
confirming
implementation.
Collaboration
tools
Emphasizing on Problem
resolution & Change
management
Sorting out
Problems/impediments
Stories ordered by
business value and
estimated in story
points.
Establishing traceability
between change
requirement & work
product and problem
report incase its initiated
by problem
Defect tracking
tools
Elaborated Test
Strategy for Release ,in
agreement with the
customer
End of Sprint-Sprint
Review/ Demo followed
by Retrospective
Release approval
criteria
Sprint schedule is not
changed with the
changes.
Switching focus
from management
of teams to self
organized teams.
Sprint planning based on
user stories from Product
backlog.
-Prioritizing items in
sprint backlog.
Velocity / key learnings
from previous sprint are
referred
Delivering working
software every 4
weeks(Demonstrabl
e Release)
Adaptive change
management. Product
backlog undergoes
changes and owned up by
product owner

15. AGILE CHERRY PICKING…SDLC
Some of the Agile aspects that can be used in Product Development along with ASPICE rigor
Requirement Gathering Design Code Construction & Testing
Preferable in the form of user stories
Application parameter influencing
functions and capabilities being part
of the system requirements.
Design activities carried out on “Just
in time” basis
Collective Code ownership
Shift focus from writing to talking. Evaluation of alternative
architectures, considering
interoperability, interaction, criticality,
technical complexity, risks and
testability
Establish Verification criteria
Validation through POC
Continuous refactoring
Requirement framework-Stakeholder
analysis, requirement trawling
Design modeling tools instead of
Design documents
Test Driven Environment
Highest priority items taken into
sprints
Application parameter configuration Automated regression testing
Application parameters in Requirement
Specification/user Stories
Dynamic behavior objectives defined. Establishing Unit Verification Criteria

16. BENEFITS OF AGILE IN PRODUCT
DEVELOPMENT
About 78% of the respondents considered the
implementation of Agile principles successful.
 Faster Time to Market
 Visibility to WIP (through Kanban)
 Early business value
 Better Quality
 Improved Productivity
 Improved Predictability
 Business Engagement/Customer Satisfaction
 Better Team satisfaction
 Value Driven
 Better Adaptability
 Reduction in aggregate project risk
 Don't need a half a year of requirement analysis and design
 Flexibility/Agility
Fact: No pure Agile
development is carried
out , but Agile aspects
can be included in
standard processes
35%
65%
Benefits of Agile
Product Dev
non Agile
Agile Dev

17. CONCLUSION
• Agile , specifically Scrum may not be fitting As-is for Automotive, however it must be
adapted to automotive environment wherein some cherry picking can be done by the
practitioners and implement Agile practices that are useful for the project success; most
popular incumbents being Planning meetings, Daily scrum and Retrospectives along with
roles such as Product Owner, Scrum master.
• Co-Location is not a mandate, communication among the members matter the most.
• Agile projects are increasingly covering mainly software development processes, with
exception of playing a minor role in System Requirements Analysis ,System Design and
system integration. The gap may be filled over the coming years with stabilization even
in system related areas.
• Functional safety being the major grey area. Extension of ASPICE to functional safety
would bridge the gap over time.
• Full benefits of Agile can be reaped by extending beyond the software development
world and applying it to OEM/system integrators.
• Agile is competitive weapon for Automotive with some tailoring of its manifesto and
methods.
• De facto moving between those Agile Vs Traditional must be avoided.

18. REFERENCES
• Automotive_SPICE_PAM_3.0
• Agile manifesto- Agilemanifesto.org
• ISO 26262 Functional Safety Standard.
• www.kuglermaag.de/agile2014- Survey
• InfoQ-Ben Linders-Agile Testing for Automotive Systems,Oct,2014
• DO-330 Tool Qualification Document
http://www.adacore.com/uploads_gems/do-330-ed-215-tool-
qualification-document.pdf

19. ANNEXURE I
Key Transitions from ASPICE V2.5 to V3.0
 Automotive SPICE 3.0 has been harmonized with the new Measurement
Framework in ISO/IEC 33020.
 PRM and PAM has been merged into single document.
 Structural changes like realigning System & Software Engineering Processes,
Clarifications (with notes) added.
 Utilization of traceability by adding one BP as "Ensure consistency“.
-Traceability of change requests to affected work products
-Additional traceability between test specifications and test results
 Concept of “agree, summarize and communicate” added to ensure information
flow.
 Rating concept been introduced as "outcome rating for process & process
attributes" Rating of outcomes is not mandatory but rating method to be decided
as the time of process assessment planning.


20. ANNEXURE II
Assessment scope
The organizational unit shall have deployed all of the processes within the scope
of the assessment.
Exclusions-
When an organization has legacy products that are to be maintained, or
development projects that are well advanced in time and which pre-date the
deployment of relevant processes, then the organization shall provide a policy
statement on the applicability of the processes to these products and projects
especially in the context of maintenance and any re-qualification that needs to be
addressed. Such legacy projects may be subject to exclusion from the scope of
assessment.