White Paper

White Paper

Auto Spice-

Agile…Hand in

Hand

November 2016

Ruchika Sachdeva

AGENDA

INTRODUCTION

ASPICE-

INSIGHT &

ASSESSMENT

PERSPECTIVE

AGILE

STRUCTURE

AGILE BEST

PRACTICE IN

PRODUCT

DEVELOPMENT

FITMENT OF

SDLCS

RESPONDENTS

DEMOGRAPHICS

BENEFITS CONCLUSION

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

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.

ASPICE MODEL

STRUCTURE

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.

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

MultimetdiaApplications

IntegratedSystem/Services

*ECU-Electronic Control Unit

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 Devnon Agile

Agile Dev

35%

approx

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

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

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

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

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

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

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

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 Devnon Agile

Agile Dev

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.

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

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.

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.