1. Roadmap and Feature Planning
...
Purpose
- To create the initial time-line for the release: the roadmap.
- To define/update the platform functional requirement.
- To identify the main technical goals for the new release.
...
- 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 3 The reason for the change in platform functional requirements is published in AGL confluenceJirra. These release information will be published in Confluence at end of development.
- D1-4 All review record is published in AGL confluence.
TO J.S.
Can you create example (D1-1,D1-3,D1-4) based on this Audio Service spec in jira?
- in AGL Jirra.
2. Architecture Design
Purpose
...
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
Entry Criteria
- E2-1 Roadmap 1 Roadmap and Feature Planning phase was completed.
Tasks
- T2-1 Create/update software architecture block diagram
...
- V2-1 Review the software architecture block diagram
...
The created architecture must conform to the requirements. Shall check for "all requirement is including" and "non requirements component is excluding".
- ex. afm-binder shall be excluding instrument cluster stack. agl-compositor should be modified based on instrument cluster requirement such as screen layout.
- V2-2 Review the component list and component block diagram
...
- Should check for "This component need to develop? Difficult to reuse existing OSS?", "This new component is better than current component? Need to replace?" in the review.
- ex. This new init process is better than systemd?
- Should check for "This component need to develop? Difficult to reuse existing OSS?", "This new component is better than current component? Need to replace?" in the review.
2. 1. Architecture Design for the AGL development software
...
- Determine the role of that software component in the AGL instrument cluster software platform.
- Determine the criteria for AGL development software.
- The starting point of the AGL development software.
Entry Criteria
- E2.1-1 The 1 The extraction of the relevant software components shall be completed.
Tasks
- 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.
...
The major version of the OSS shall be selected with a maintenance lifecycle that meets the roadmap creating in section 1. When it OSS is not provided Long Term Support/Stable by upstream, should select downstream that is maintained by distribution.
In case of downstrem downstream maintenance, AGL shall select and refer to downstream of one distribution (RedHat/CentOS or Debian or Ubuntu or OpenSUSE or other), not select Yocto code base.
...
- 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.
- 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.
- 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. Interface A : response tome less than 1ms in R-Car M3.
- ex. Runtime memory usage less than 20MByte AES encryption processing : more than 10 MByte/sec in R-Car M3 (at 2 Guest container).
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 jirra/confluence.
3. Detail Design and Code Development/Certification for existing OSS
...
3.1 Detail Design and Code Development
...