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.
...
- E3.1-1 AGL development process section 2.1 has been completed.
- E3.1-2
- E3.1-3
Tasks
- T3.1-1 Scan developed code using static analysis tool, findings from tools should be fixed.
- T3.1-2
- T3.1-3
- T3.1-4
- T3.1-5
...
- E3.2-1 AGL development process section 2.2 has been completed.
Tasks
- E3T3.2-2
- E3.2-3
...
- 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- 1 Scan developed code using static analysis tool, findings from tools should be XXXX..
- 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.
T.5 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.
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)
D.2 Release note(T.6)