autospice agile hand in hand
Post on 13-Apr-2017
43 Views
Preview:
TRANSCRIPT
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.
top related