The app development process shown is a combination of a the waterfall and iterative development approaches. Iterative development is still considered a better method of developing a working app (creating the actual code) and is recommended for the development phase.

Design is a process of defining what the app should look like and its behavior. Design will create requirements, UI layouts, UI flow diagrams, initial test plan and test cases.

Develop is a process of creating the actual app, testing it on the HU, and validating that all of the requirements have been met. The development phase will iteratively create and test versions of the app until a version is available that the development team feels comfortable letting others outside the development team evaluate.

Test is a process where qualification engineers evaluate the completed app for proper function in a vehicle. The test process evalutes the app as part of the whole Uconnect^® infotainment experience looking at connectivity, driver distraction, and potential failure modes.

Release is for production ready apps. The app end-to-end SDP data flows will be verified along with a component’s operational readiness. Testing in the Release process tests functionality, usability, reliability, performance, and supportability in a production environment. After verifying that all testing has been performed the app is certified for use in a production radio.

Top

Design is a process of defining what the app should look like and its behavior. Design will create requirements, UI layouts, UI flow diagrams, and initial test plan and test cases.

Document New App Idea describes the app using context diagrams, use cases, defines what hardware and model years the app is intended for, what languages will be supported, what markets the app will be used in, and what the app will look like (branding). This process may also require business reasons and a competitive analysis.

Compliance Criteria Selection determines which compliance criteria categories to apply using the Compliance Criteria Category Selection List contained in the Compliance Criteria document available in Downloads.

Head Unit Applications engage specific components of the Uconnect system in specific ways (e.g. HU, Web, handset, SDP, etc.). There are common criteria that hold regardless of the component engaged. In other cases, there are component specific criteria. The Compliance Criteria Categories attempt to provide all Head Unit Application criteria: both the common Head Unit Application criteria and the component specific criteria that can be used while assessing a Head Unit Application.

The general methodology for evaluating the compliance of a Head Unit Application is to determine which Compliance criteria to apply and then test the Head Unit Application against the applicable Compliance criteria.

Examples:
Privacy test will be relevant for a Head Unit Application that requires customization for the user’s preferences, but will not be relevant for a Head Unit Application that only reports on data about the engine or suspension on the Head Unit.

Driver Distraction Testing applies for a Head Unit Application with a customer facing User Interface (UI), but not for a Head Unit Application that lacks a UI because it only runs in the background.

Pre-Development Compliance Testing evaluates the submitted app using the selected compliance criteria and record the results in the Compliance Criteria Categories contained in the Compliance Criteria document which is available in Downloads. All test failures should have a description of the failure.

Compliance Reference allows the developers of the app idea and the team that selected the compliance criteria to be used as references during the compliance testing.

App Spec Development and Approval creates an app spec based on the documented app idea. The app spec contains functional requirements, use cases, vehicle sensor usage, special calculations, and user interface design.

Help Write Spec, help should be solicited from all parties involved. This step is here to benefit from lessons learned in prior projects and to give all of the parties involved in creating, testing, and releasing the app an understanding of the app.

Submit Request(s) Resources that have been identified in the spec. The implementation of sensors and other resources required by the app are controlled through the CR process. A request will need to be created and prioritized at this point so the resource will be available during development.

It is a good idea at this time to create a mitigation plan in case the resource is not available when required.

Develop Validation and IOT Test Plans and test cases are started after the app Spec is completed during the design phase of software development. The test plans and test cases at this time are not all inclusive but should test the requirements and functionality in the app Spec.

The completed test plans and test cases are updated / modified during construction by the app development company and by the Chrysler App Engineer.

The test plans should:

An example test plan and test cases are available in Downloads.

Review and Provide Feedback for the test plans and test cases.

Incorporate Feedback into Validation and IOT Test Plans. This step is here as a reminder that the test plans, test cases, and maybe the app spec need to be updated.

Top

The develop process creates and tests the actual application (the code). It is considered a best practice to develop the code and test cases iteratively and test as components are completed. The iterative processes are denoted in the diagram as a box containing multiple process steps.

Order Bench Head Unit at this time. It could be a 6 to 8 week turn around time so if this step can be pulled ahead it should be.

Consult your Chrysler engineer for the best way to get a bench head unit.

Initial Set-up of Bench Head unit is done by the Chrysler engineer to ensure that the bench HU set-up is complete and the unit is functioning prior to sending it out. Reference Harman Bench Tester Set-Up.

Complete Bench Head Unit Set-up executes the remaining steps in Harman Bench Tester Set-Up.

Develop the App, Exec component testing on Emulator creates the app and tests it using the emulator and sensor simulator. See Set-Up to Develop Apps for the Harman Radio for an explanation on how to use the emulator and simulator.

Execute IOT tests on Bench Head Unit testing components against each other to determine how well they integrate into the run time environment. Inter-Operability testing is run on a Bench Top Head Unit with simulated inputs. To pass IOT all of the high level test cases need to pass. See Bench Tester for the Harman Radio for instructions on how to build, load, and test an app on the bench tester.

Test New CAN APIs that may have been created by the radio manufacturer. It is importaint to understand at this point what release of the Kona API your new APIs have been added to and verify that your bench tester is running that release.

You can verify the software release you bench tester is running from the System Information page as shown in this screen shot.

 

Refine the App fix any issues that appeared in IOT.

Apply UAA or SDP Updates is a step that would need to be executed if the app uses wireless (i.e.Via-Mobile) or other feature that would use Sprint's infrastructure.

Source Code Review is required to ensure compliance with standards, lessons learned have been applied, and no destructive code is built into the vehicle.

Resolve Issues revealed by the source code review.

Validation Testing accesses the app to ensure that it meets the intent of the app spec and requirements. Validation tests are first run on a Bench Top Head Unit and then tested in one or more of the targeted vehicles.

Track Issues that have been discovered during Validation Testing. This step is necessary to ensure that all issues have been closed or mitigated prior to proceeding to the next step. The app will not be certified unless all of the issues have been addressed.

Improve code fixes the discovered issue.

Test on Bench Head Unit tests the discovered issue.

Test in Vehicle tests the discovered issue.

Create App Id and provide login ID to sign for test allows the app to be prepared for NRT.

Top

The test process evalutes an app as part of the whole Uconnect^® infotainment experience looking at connectivity, driver distraction, and potential failure modes.

Distracted Driving is a check to see if the Distracted Driving test needs to be run. If the app will not run while the vehicle is in motion then the Driver Distraction test does not have to be run.

Assemble Test Protocol includes test plan, test cases, and how the tests will be run. Each in-vehicle feature should be tested.

Help write Test Protocol provides another perspective when creating the test plan and cases.

Approve Test Protocol is a review and approval from the compliance group.

Driver Distraction Testing is executed by the selected test provider.

Approve AAM Report if the driver distraction test has been successful. The AAM Report is prepared by the driver distraction test provider.

A copy of the report should be stored with the app in the Uconnect^® SharePoint site.

DFMEA, Design Failure Mode Effect Analysis is required for all apps. DFMEA is an analysis process that identifies potential failure modes, the severity of their effect, and the likelihood they will occur.

The DFMEA worksheets should be stored with the app in the Uconnect^® SharePoint site.

Update Level 2 Spec to resolve any issues discovered during DFMEA.

Improve Code to resolve issues to resolve any issues discovered during DFMEA.

Sign app for testing is the Sprint production signing process.

Road / Drive Test is where Chrysler engineers will evaluate the app in vehicles on the road. These tests will cover real world type scenarios as well as edge cases.

Improve Code to resolve issues discovered during the Road / Drive Test.

Sign app for NRT creates a jar file that will execute in Sprint's NRT environment.

Load App on NRT loads and executes the app in NRT. This step is simply to get the app to run in NRT.

Test and resolve App Issues that resulted from loading and running the app in NRT.

Top

The Release Phase certifies and approves an app for release into the production environment.

All issues that occur during the release phase are tracked in Sprint's issue tracking system and must be closed of mitigated for the app to be certified.

Verification One Round NRT verifies end-to-end SDP data flows and a component’s operational readiness in the NRT lab environment. The goal of this testing is to make sure all SDP components interact with each other successfully according to interface specification requirements.

Component testing tests functionality, usability, reliability, performance, and supportability.

Improve Code to Resolve Issues that resulted from executing the NRT and FIT tests.

Verification One Round FIT verifies SDP end-to-end data flows and applications functionality along with overall operation readiness in the FIT environment Operational readiness tests involve testing of platform installation/upgrade process, management console, alarm generation, change control and customer care escalation process validation. The goal of this testing is to make sure that all applications are working as expected in a production environment (no emulators are used).

Prior to app certification Service Level and Operational Support Agreements between Sprint and the 3rd party developers should be in place. An app will not be allowed in the production environment without the agreements being in place.

Certification is an official review of all Compliance, Verification, and Validation tests, execution of post development compliance reviews, and verification that all prerequisites have been completed and the application is ready for submission to the Chrysler app store.

Prod sign & Stock the App in the store for selected VINs (Soaking) allows the selected VINs to install the app from the app store. The app will remain in this phase for a period of time that the qualification engineers have determined.

Approval that the app is complete and all issues from soaking have been resolved.

Prod sign & Stock the App in the Store removes the app from soaking and allows for general distribution.

Top