Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

1. Roadmap and Feature Planning

Based on OpenSUSE section 1.

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.

Entry Criteria

  • E1-1 Previous release version of the distribution was released.

Tasks

  • T1-1 Create the roadmap and platform functional requirement specification. 

A detailed description about the rules used to build the roadmap and platform functional requirement is in [xx]. These document need to be written in AGL confluence.

  • T1-2 Lifecycle calendar. 

The following milestones should be determined at this stage.  In order to complete each milestone, each exit criteria must be achieved and the deliverable released.

M1. Roadmap and feature planning complete (section 1).

M2. Architecture design complete (section 2).

M3. Detail design complete (section 3).

M3-1. Software interface freeze.

All interface specification shall final freeze such as ABI version, kernel version, compiler version, etc..  Same as current AGL M1 and M2.

M3-2. Software internal design freeze.

        All software internal design shall freeze.

M3-3. Demo software freeze.

       All demo software (ex. demo ui) shall freeze.  The demo software is developed outside this development process.

M4. Unit testing and creating unit test evidence is complete.

M5. Architectural testing and creating evidence is complete.

M6. Release.

M7. End of life.

10 or 5 years after release.


  • T1-3 Determine the new features.

On the AGL Instrument Cluster Expert Group the new features expected for this release are discussed and defined. As a result new version of the platform functional requirement specification will be released.  This spec must be created before architecture development phase.

Verification

  • V1-1 Review the platform functional requirement

The platform functional requirement needs to be approved by at least half of the reviewers.

  • V1-2 Review the roadmap.

The roadmap needs to be approved by the Product Manager(Walt?) and the Instrument Cluster Expert Group Leader(Haraki-san?).

  • V1-3 Platform functional requirement and roadmap maintenance.

Small changes in the roadmap are not communicated, just executed.  But if a delay threatens the release day, an announcement is expected, and if the delay is serious we need to communicate it widely.
When the platform function is dropped from initial platform functional requirement, it must be approved by at least half of the SAT (System Architecture Team) core members.  After that platform functional requirement specification must be update.

Exit Criteria

  • X1-1  The platform functional requirement specification and the roadmap calendar are fixed and froze.

Deliverable

  • 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 reason for the change in platform functional requirements is published in AGL confluence.
  • 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?

2. Architecture Design

Purpose

  • Identify which software requirements are to be allocated to which architectural elements of the software.
  • Evaluate the software architectural design against defined criteria.

Entry Criteria

  • E2-1 Roadmap and Feature Planning phase was completed.

Tasks

  • T2-1 Create/update software architecture block diagram

First step of the architecture design shall create and update software architecture block diagram such as this.  Typically, adding/removing architecture blocks is only allowed by adding/removing functional requirements or refactoring.  This block diagram need to be written in AGL confluence.

  • T2-2 Create/update software component list and component block diagram

The software architecture block diagram shall break down to software component list and component block diagram.  Element of software component list shall be linking to platform functional requirement. 

Each software component divide to 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.

Verification

  • V2-1 Review the software architecture block diagram

TBD.

  • V2-2 Review the component list and component block diagram

TBD.

2. 1. Architecture Design for the AGL development software

Purpose

  • 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 extraction of the relevant software components shall be completed.

Tasks

  • T2.1-1 Create/update software component use case diagram and description
  • T2.1-2 Create/update software component activity diagram and description
  • T2.1-3 Create/update software component state machine diagram and description
  • T2.1-4 Create/update software component interface description
  • T2.1-5 Create/update software component test specification


Verification

  • V2.1-1 Review the each diagram and description

TBD.

  • V2.1-2 Review the interface description

TBD.

  • V2.1-3 Review the test .

TBD

Exit Criteria

  • X2.1-1  Completed review and accepted the documents for software component.

Deliverable

  • 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  TBD
  • D2.1-4  All review record is published in AGL confluence.


2.2. Architecture Design for the reusing existing opensource software

Purpose

  • Determine the role of that software component in the AGL instrument cluster software platform.

Entry Criteria

  • E2.2-1 The extraction of the relevant software components shall be completed.

Tasks

  • T2.2-1 Create/update software component use case diagram and description

Create a use case document to show why the that OSS is needed.  This document shall be including all of assigned platform functional requirement.

  • T2.2-2 Assess to the reusing existing opensource software

OSS assess and certify based on the AGL Instrument Cluster Distribution Criteria.

  • T2.2-3 Determine a major version of the OSS

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.

AGL should select and refer to downstream of one distribution (RedHat/CentOS or Debian or Ubuntu or OpenSUSE or other), not select Yocto code base.

Verification

  • V2.2-1 Review the use case diagram and description

TBD.

  • V2.2-2 Review the assessment result

TBD.

  • V2.2-3 Review the test .

TBD

Exit Criteria

  • X2.2-1  TBD

Deliverable

  • D2.2-1  TBD
  • D2.2-2  TBD
  • D2.2-4  All review record is published in AGL confluence.


3. Detail Design and Code Development/Certification for existing OSS

Based on OpenSUSE section 2.

3.1 Detail Design and Code Development

Purpose

  • Create/update software

Entry Criteria

  • E3.1-1 AGL development process section 2.1 has been completed.
  • E3.1-2 
  • E3.1-3



Tasks

  • T3.1-1 
  • T3.1-2 
  • T3.1-3 
  • T3.1-4 
  • T3.1-5 


3.2 Certification and importing for existing OSS

Purpose

  • Create, update or fix packages/recipes.

Entry Criteria

  • E3.2-1 AGL development process section 2.2 has been completed.
  • E3.2-2 
  • E3.2-3 







  • No labels