1. Roadmap and Feature Planning
...
- 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-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
- 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.
- 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 jirra.
- V3.1-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.
- The performance requirements in the reference environment must be specified.ex. AES encryption processing : more than 10 MByte/sec in R-Car M3
.
- It does not have to be in sync on a per-commit basis at all times.
- All review records must be written in AGL jirra.
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.
- 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.
...