This rule applies to Instrument cluster software stack only.
1. Roadmap and Feature Planning
...
- D1-1 The platform functional requirement specification is published in AGL confluence.
- D1-2 The roadmap calendar is published in AGL confluence.
- D1-3 The reason for the change in platform functional requirements is published in AGL JirraJira. These release information will be published in Confluence at end of development.
- D1-4 All review record is published in AGL JirraJira.
2. Architecture Design
Purpose
...
- V2.1-1 Review the each diagram and description
- Two or more reviewers must approve this design.
- This document must be including description for tasks from T2.1-1 to T2.1-6.
- All review records must be written in AGL jirraJira.
- V2.1-2 Review the interface description
- The method of providing an interface should use for standard method of the own architectural layer.
Interface spec shall describe by standard format of the method.
ex. In case of C functional interface should be use doxygen. In case of REST interface should be use OpenAPI.- All review records must be written in AGL jirraJira.
- V2.1-3 Review the test .
- The correct and abnormal behavior of all interfaces must be defined.
- The performance requirements in the reference environment must be specified. ex. Interface A : response tome less than 1ms in R-Car M3.
- The resource requirements in the reference environment must be specified with limitations. ex. Runtime memory usage less than 20MByte in R-Car M3 (at 2 Guest container).
- All review records must be written in AGL jirraJira.
Exit Criteria
- X2.1-1 Completed review and accepted the documents for software component.
...
- D2.1-1 The software component use case diagram and description, activity diagram and description, state machine diagram and description and interface description is published in AGL confluence.
- D2.1-2 All review record is published in AGL jirraJira.
2.2. Architecture Design for the reusing existing opensource software
...
- V2.2-1 Review the use case diagram and description
- Two or more reviewers must approve this definition.
- This document must be including description for tasks from T2.2-1.
- All review records must be written in AGL jirraJira.
- V2.2-2 Review the assessment result
- The selected OSS must meet the assessment criteria.
- Risk information for the selected OSS must be provided. It should be updated during the detailed design phase.
- All review records must be written in AGL jirraJira.
- V2.2-3 Review the test .
Selected OSS have test suite that fit the use case is available.
and/or the test cases is defined based on the defined use case.
- The performance requirements in the reference environment must be specified.
- ex. AES encryption processing : more than 10 MByte/sec in R-Car M3.
- All review records must be written in AGL jirraJira.
Exit Criteria
- X2.2-1 Completed review and accepted the documents for software component.
...
- D2.2-1 The software component use case diagram and description is published in AGL confluence.
- D2.2-2 Assessment documents published in AGL confluence.
- D2.2-4 All review record is published in AGL jirraJira.
3. Detail Design and Code Development/Certification for existing OSS
...
- T3.1-1 Create source code
- That source code must be able to cross building
- If that code include assembler code, must include generic implementation code for other architecture.
- That source code must conform to the AGL coding rules.
- AGL must define coding rule. Coding rule is refer to systemd Coding Style.
- External interface spec shall describe by standard format of the method in that source code.
- ex. In case of C functional interface should be use doxygen.
- Internal interface spec should describe by standard format of the method in that source code.
- That source code must be able to cross building
- T3.1-2 Scan developed code using static analysis tool, findings from tools should be fixed.
- When static analysis tool detected "Must Fix" error, developer must fix this error.
- When static analysis tool detected "Need Evidence" error, developer must create "no problem evidence".
- Static analysis tools are subject to many miss detection. Developers need to show that it is miss detection.
- T3.1-3 Check for coding rules by static analysis tools
- Code developed in AGL must conform to the AGL coding rules.
- AGL coding rule is refer to systemd Coding Style.
- T3.1-4 Create release note
...
- V3.1-1 Review the detail design and source code
- Two or more reviewers must approve this design.
- Two or more reviewers must approve this source code.
- All review records must be written in AGL jirraJira.
- V3.1-2 Review the assessment result
- Asses to static analysis result and "no problem evidence".
- That evidence must be written in AGL static analysis infrastructure.
- All review records must be written in AGL jirraJira.
- Asses to static analysis result and "no problem evidence".
- V3.1-3 Review the test .
That code need to include test suite. It need to fit the use case.
- It does not have to be in sync on a per-commit basis at all times.
- All review records must be written in AGL jirraJira.
Exit Criteria
- X3.1-1 Completed review and accepted the documents.
- X3.1-2 Completed code development.
- X3.1-2 Completed Yocto recipe development.
...
- D3.1-1 The software component use case diagram and description is published in AGL confluence.
- D3.1-2 Assessment documents published in AGL confluence.
- D3.1-3 All review record is published in AGL jirraJira.
3.2 Certification and importing for existing OSS
...
- V3.2-1 Review the assessment result
- Two or more reviewers must approve this assessment.
- That evidence must be written in AGL static analysis infrastructure.
- All review records must be written in AGL jirraJira.
- Two or more reviewers must approve this assessment.
- V3.2-2 Review the test
- All review records must be written in AGL jirraJira.
Exit Criteria
- X3.2-1 Completed review and accepted the documents.
- X3.2-2 Completed code development.
- X3.2-2 Completed Yocto recipe development.
...