Paper presented in VDS Sys conference: Process & quality assurance strategy for infotainment platform team

1. PROCESS & QUALITY ASSURANCE STRATEGY FOR
INFOTAINMENT PLATFORM TEAM
SURESH BABU SATHIYAKUMAR, HARMAN INTERNATIONAL INDIA PRIVATE LIMITED.

2. ABOUT SPEAKER
 Around 15 years of experience in IT industry
 Worked in various domains, started as BIOS developer in American Mega
Trends, Product Quality Manager in Huawei Telecom, Senior Principal
Engineer in Harman International.
 Currently handling an Android IVI Platform team with 350+ members.
 Certified iNTACS ASPICE Assessor, SAFe Agilist, Six Sigma Black Belt,
Agile Scrum Master
 Published papers on Quality Assurance in Continuous Delivery in iEEE,
Springer Journals.
 Active Members in BSPIN and ASQ, provided talks on Continuous
Delivery in Big Data, Industry 4.0 in Connected Cars.
 https://www.linkedin.com/in/suresh-babu-sathiyakumar-638b0021/

3. INTRODUCTION TO IVI
 This paper sharing is from IN VEHICLE INFOTAINMENT
(IVI) team which refers to Vehicle systems that combines
entertainment and information that are provided to
drivers and passengers. IVI systems uses Audio/Video
interfaces, touchscreens and keypads to provide these
types of services.
 Some of the common tasks that can be performed using
IVI systems are managing and playing audio contents;
navigation for driving; providing entertainments such as
movies, Reading Incoming SMS and sending outgoing
SMS text messages; making phone calls, etc.
Pic source: https://www.allion.com/in-vehicle-infotainment-ivi-system-drives-
you-to-the-new-technology/

4. WHY PLATFORM
 Platforms are building reusable assets which can be
customized to multiple products.
 IVI Platform is required to resolve the following challenges:
 OEMs are looking for ways to bring new features forward
without increasing system costs;
 OEMs don’t have the budgets to create products from scratch at
the necessary pace;
 In-vehicle systems need to be supported through the entire
lifecycle – not just to SOP;
 The expertise required for next generation features does not
reside inside of most OEMs.
Pic source: https://www.appway.com/screen/appway-
platform-reusable-components

5. CHALLENGES
 Challenge 1: The IVI Platform need to support
multiple System on Chip (SoC), multiple Android
Variants, and supporting different Customer
Programs.
 Challenge 2: The Platform need to support
multiple customers and there are many
release commitments. Average need to
support 5-6 customer releases in a month.
Intel, MediaTek,
etc.
Intel, Qualcomm,
etc.
Intel, Qualcomm,
MediaTek, etc.
Qualcomm, etc.

6. CHALLENGES
 Challenge 3: The team developing the IVI
platform is distributed across 5 different
Geographic locations working 200+ Engineers.
Timing and communication were always
challenging.
 Challenge 4: Platform development is parallel
to Customer Program development, not able
assess the Release Readiness as Program
team integrates platform code based on
regular basis and few Customer Projects
request for daily tags.

7. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 1: Requirements Reuse analysis (RRA) to support multiple Programs
Fig: Gap Analysis
 Platform thinking is the process of identifying and
exploiting similarities between products.
 When any New program is awarded, clear gap analysis is
performed to check what all requirements developed in
the Platform can be reused in the new programs.
 If the requirements are not already delivered in the
Platform but if it founds to be one of reusable asset, then
new requirements will be implemented in the platform.
 For the existing features supported from Platform, reused
requirements will be configured as one of the supported
programs and will be tracked for testing scope if the HW
environment or SOC is different

8. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 2: Develop RoadMap and Business Need Features:
 As we have Platform develops the reusable assets to multiple programs, Strategic
investments to be made in platform to develop the Roadmap or Business need features
based on the new trends, technologies and business needs.
 These features may not have immediate customers but on a long run this can served to
multiple programs.
 This can follow the Innovation process as mentioned in the below flow

9. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 3: Time boxed feature delivery through Platform Program Increments (PI):
Fig: PI-Sprint Cycle
 Platform Backlog is prepared based on the
Platform requirements, Customer Program (CPM)
requirements.
 Every year 6 Program Increments (PI’s) are
planned, where each PI comprises of 5 Sprints.
Requirements that will be implemented will be
taken from the Platform Backlog.
 Customer Program milestones are aligned with
the Sprint releases. All the customer programs are
asked to align

10. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 4: Program Increments (PI) planning workshop to resolve
multi domain dependency:
Fig: PI Workshop
 The Agile manifesto says “The most efficient and
effective method of conveying information to and
within a development is a face-face conversation”.
 PI planning workshop helps to achieve this with a
face-to-face event, For the geographically distributed
domain teams, the event occur at multiple locations
by maintaining audio communications.
 Business context in the PI, Team planning Breakouts –
where team discuss on the multi domain
dependencies and come with the sprint plan and
objectives.
 The team breakout session in PI workshop helps
domain teams to identify dependencies and risks, For
Understanding complexities, For Optimizing efforts
and come with the plan.

11. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 4: Program Increments (PI) planning workshop to resolve
multi domain dependency:
Fig: PI Workshop
 PI Planning workshop preparation activities are
planned in the last Sprint of previous PI which is
called as Hardening and Planning Sprint.
 The focus of Hardening and Planning sprint will be
preparing the activities required for the next PI like
Dependency workshops, Architecture and Design,
Feature Grooming activities, and Fixing the defects
to improve the stability.

12. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 5: Software Branching Strategy:
 As Platform supports multiple customer
programmer, it is very essential to maintain a
strong branching strategy.
 As part of Branching strategy 2 code bases are
maintained. All the Platform requirements
implementation are maintained as ORANGE
LINE, where the Automotive specific features
are added on top of the Android pastry
releases from Google. All domain teams
working as part of platform team will be Check-
in into the ORANGE LINE platform code base.
 ORANGE LINE platform code base is merged to
customer Programs GREEN LINE, which has the
Scope set by delta between Platform
Requirements and customer specs
Fig: Branching Strategy

13. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 6: Quality Assurance Strategy using PMVAi model:
Fig: PMVAi Quality Assurance Model
 Quality assurance is very critical step in the
Platform development mode. As it supports
multiple customer programs, the quality assurance
needs to be flexible and meets the customer
expectations.
 PMVAi mode is followed in the Quality assurance,
where all the Quality Assurance activities are
Planned, Monitored, made the Quality health
Visible to all the stakeholders and Act on the
improvements and make continuous
improvement. Finally the “i” aspect is to innovate
in each of this areas.

14. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 6: Quality Assurance Strategy using PMVAi model:
Fig: Feature Maturity
 The Feature maturity must be evaluated continuously
at every state. Level of Maturity is defined against the
DONE criteria at every state. Starting from the
Requirements collection to till Launch to the
customer, every individual feature is evaluated on its
maturity.
 The key aspects checked in the Level of Maturity for
each feature are: 1. Whether the Requirements
analysis/Grooming is completed, 2. System/Software
Requirement specification is available, 3. Architecture
update, High/Low level design is available, 4. Every
feature is scheduled, 5. Implementation – Peer/Expert
Review, Static code analysis, unit testing completed,
6. Integration Testing done verifying all the interfaces,
7. Software/System testing is completed.

15. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 7: Continuous Integration:
Fig: Feature Maturity
 Continuous integration is effectively followed to strengthen
the gating. Gerrit system is used for Code review and after
the code review is passed with CR+1, CR+2 is provided and
then Domain expert code review completed DCR+1 is
provided.
 Once the code review is completed, Smoke test cases and
Pre-Integration test cases are run and +1 is for provided
after which the code is merged to ORANGE LINE. The code
from the main line is further tested as part of Software and
System Testing.
 Unit Test Tools GTest, JUNIT were used and GCov and
JaCoCo coverage tools are used to measure the unit test
coverage. Code Sonar static code analyzer used to verify the
MISRA coding rules. Pre-Commit hooks are developed to
make sure if there are any increase in the Code Sonar
warnings or if any Unit test case is failing then the check-in
will not be allowed.

16. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 8: Technical Debt Improvement:
 Technical debt is the implied cost of additional rework
caused by choosing an easy solution now instead of
using a better approach that would take longer.
 Technical Debt improvement is very important activity
in Platform development as the features and code is
reused by multiple products, any critical issue/defect
will high impact.
 Typical Technical Debt improvement parameters can be:
Static code analysis (SCA) warnings, UT improvements
(Automation & Coverage), Functional Test automation
improvements, Code Refactoring (based on buggy
modules).
 Technical Debt improvement activities are planned at
every Sprint and dedicated effort (~10%-15%). It is also
monitored as one of DONE criteria.
Pic courtesy: https://www.atlassian.com/blog/jira-software/3-steps-taming-
technical-debt

17. PROCESS AND QUALITY ASSURANCE STRATEGY
Strategy 9: Monitor the Reuse of Platform:
Pic: https://www.klipfolio.com/blog/kpi-metric-
measure
 One of the success parameters of Platform is how much
the platform is reused, measure and monitor the Reuse
% of platform in the Products. The higher the platform
reused in the multiple products denotes the Platform is
intensively used.
 Reuse can be monitored in terms of Feature Reuse -
ratio of number of features delivered by Platform out of
Total features delivered by Product. Ratio of Code reuse
from the Platform to Product can also be monitored.

18. PROCESS AND QUALITY ASSURANCE STRATEGY - BENEFITS
 Reuse % is improving in products.
 Able to support multiple variants (SOC’s, OS, Products)
from the Platform.
 Voice of Customer is improved.
 On time releases to Products/customers.
 Improved the Quality by strong gating and Tech Debt
improvements.
 ASPICE Level 2 certified, processes are managed effectively.
(SAFe agile practices are also implemented).