...
Each software component will be separated and distinguished into AGL development software and existing opensource software.
The process for AGL development software is set out in Section 2.1. The process for reusing existing opensource software is set out in Section 2.2.
...
- 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 jirra.
- 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.
...
- E3.1-1 AGL development process section 2.1 has been completed.
Tasks
- 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 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-2 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-3
- T3.1-4 T3.1-5
- 4 Create release note
Verification
- 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.
- V3.1-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.
- 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.
Exit Criteria
- X2.2-1 Completed review and accepted the documents for software component.
Deliverable
- 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 jirra.
3.2 Certification and importing for existing OSS
...
- 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
Use static analysis tools to check for new bugs that there are no unintended.
Create the document of check results or write in the release note.
T.4 Check for Coding rules by static analysis tools
Use static analysis tools to check compliance with AGL coding rules.
Create the document of check results or write in the release note.
...
- 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.
T.6 Create the release note
Create a release note and include the following information.
- Date
- Distribution version
- OSS name
- OSS version
- OSS URL
- OSS license
- Summary
- Static Analysis Summary
note) If you have any other need points, please comment anything.
note) ソフトウェア要件との適合性も見るべき？レグレッションテストの観点では必要なので、TestSpec側とどちらかで考えは含めておくこと。
Deliverable
D.1 Report of the above tasks
D.1-1 Verification results about comparing "change logs" and "source code changes"(T.1)
D.1-2 Results about Checking for Fixed bugs(T.2)
D.1-3 Results about Checking for New bugs(T.3)
D.1-4 Results about Checking for Coding rules(T.4)
D.1-5 Results about Checking for Software interface specification(T.5)
...
Deliverable
- D3.2-1 The document of assessment results.
- D3.2-2 New or updated Yocto recipe