Process & Quality Assurance Strategy for Infotainment Platform_Suresh_v2.pptx
- 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).