...
...
...
...
...
...
...
...
...
...
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
...
- T2.1-1 Create/update diagram and description of software component from use case point of view
- Use case diagram and/or Use case description should be showed in design documents to help understand requirements and to help have common understanding for requirements and,
- Use case diagram and/or Use case description show necessity of software component to be developed.
- T2.1-2 Create/update software component interface description
- This is important information for the component users, so it shall be included in design documents or described as markdown
- Developer shall define and describe meaning, parameter and return value of each interface
- If the order of calling interface function/method is important, we recommend that developer create a sequence diagram.
- T2.1-3 Create/update software component activity diagram
- T2.1-4 Create/update software component state machine diagram and table
- If the software component to be designed has a state, state transition should be represented by state machine diagram and/or state machine table.
- To prevent omission of consideration during design process, we recommend that developer checks his design using state machine table.
- T2.1-5 Create/update deployment diagram
- Developer should clarify related and/or interfering other components or hardware devices to show necessity of these.
- T2.1-6 Create/update software component test specification
- To Design test cases to meet the requirement coverage and
- To describe these as specification document.
...
- 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.
...