...
- 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 jirra.
- 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 jirra.
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 jirra/confluence.
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 jirra.
- 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 jirra.
- 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 jirra.
Exit Criteria
- X2.2-1 Completed review and accepted the documents for software component.
...
- 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 jirra.
- V3.1-2 Review the assessment result
- Asses to static analysis 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.
- and "no problem evidence".
- That evidence must be written in AGL static analysis infrastructure.
- All review records must be written in AGL jirra.
- V3.1V2.2-3 Review the test .
Selected OSS have That code need to include test suite that . It need to fit the use case is available.
and/or the test cases is defined based on the defined 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 jirraThe performance requirements in the reference environment must be specified.ex. AES encryption processing : more than 10 MByte/sec in R-Car M3.
Exit Criteria
- X2X3.21-1 Completed review and accepted the documents for software component.
- X3.1-2 Completed code development.
- X3.1-2 Completed Yocto recipe development.
Deliverable
- D2D3.21-1 The software component use case diagram and description is published in AGL confluence.
- D2D3.21-2 Assessment documents published in AGL confluence.
- D2D3.21-4 All 3 All review record is published in AGL jirra.
...
- T3.2-1 Assessment for the change logs (release note, commit log , etc.)
- In initial phase, should update existing OSS frequently. In late phase and maintenance phase, should not update existing OSS frequently excluding to security fix and critical bug fix.
- Shall check to change log, because we need to judge "this change is need in this phase?".
- Create or update to the document of assessment results.
- T3.2-2 Source code check by static analysis tools
- Must check to source code using static analysis tool.
- When static analysis tool detected "Must Fix" error, that OSS must not use.
- When static analysis tool detected "Check by AGL" error, that OSS code must check and judge by AGL community before than adopting this OSS.
- When static analysis tool detected "Check by User" error, developer shall create error report only. AGL community provide risk information for that OSS to user.
- Checker rule as a follow:
- Must check to source code using static analysis tool.
- T3.2-3 Check for Software interface specification
- Check the source code and library software interface specifications provided by OSS.
- The important point is to check compatibility from previous version. When current phase is after M3-1, must not change to incompatible version.
- Create the document of check results or write in the release note.
Verification
- 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 jirra.
- Two or more reviewers must approve this assessment.
- V3.2-2 Review the test
- All review records must be written in AGL jirra.
Exit Criteria
- X3.2-1 Completed review and accepted the documents.
- X3.2-2 Completed code development.
- X3.2-2 Completed Yocto recipe development.
Deliverable
- D3.2-1 The document of assessment results.
- D3.2-2 New or updated Yocto recipe
4.
...