View TRAK:MVp-02 Architecture Description Design Record Viewpoint

TRAK_logo_60.jpg

Title

MVp-02 Architecture Description Design Record Viewpoint

Version

9

Date

2nd October 2011

Overview

The MVp-02 - Architecture Description Design Record Viewpoint is part of the Management Perspective and one of the 21 TRAK Architecture Viewpoints.

The MVp-02 Architecture Description Design Record Viewpoint provides a way of describing the architecture task, any concerns and the results or findings. It is also therefore an aid to portability, exchange and re-use.

It is the specification for the TRAK::MV-02 Architecture Description Design Record architecture view.

Stakeholders Addressed

  • Owner of Architecture Task
  • User of Architecture Task
  • Developer of Enterprise
  • Maintainer of Enterprise
  • Owner of Enterprise
  • Owner of Concept
  • User of Concept
  • Developer of Concept
  • Owner of Solution
  • User of Solution
  • Maintainer of Solution
  • Developer of Solution
  • Operator of Solution
  • Trainer of Solution
  • Acquirer of Solution
  • Disposer of Solution

mvp02StakeholderConcern_400.jpg
Full size:File:mvp02StakeholderConcern.pdf

It is likely that the developer and builder roles of the architecture task are likely to be performed by the same person.

Covered by TRAK IPR and licenses

Concerns Addressed

Do we understand the scope of the architectural task? What are the issues and findings that resulted?

Covered by TRAK IPR and licenses

Description

Describes the purpose, scope and extent of the architecture task and the architecture description. Describes any findings that arose from the architecture modelling.

Covered by TRAK IPR and licenses

Mandatory Metamodel Tuples

MVp-02_metamodelFragment.jpg

ISO 42010 AD Scope

Defining the scope of the architecture description / task:

Usually the following stakeholders will take at least the role of Sponsor although other roles might be relevant to the architectural task:

Describing how the architecture description addresses the stakeholder concerns:

and reference documents included:

Architecture Task Findings

ISO 42010 AD Scope +

Covered by TRAK IPR and licenses

Optional Metamodel Tuples

Well-Formedness

ISO 42010 AD Scope

A MV-02 view shall contain:

  • at least one stakeholder (represented using Organisation/Job plays Role of Stakeholder)
  • exactly one architecture task (the task)
  • Role of Stakeholder is connected to the task (Role extends to Architecture Task)
  • every stakeholder has at least 1 concern (Role of Stakeholder has Concern - stakeholder concern)
  • every stakeholder Concern is related to at least one thing (Concern about Architecture Description Element)
  • every stakeholder concern is addressed by at least one View
  • references to any task definition documents (Architecture Description Element traces to Document)
  • references to any normative documents - relevant to the task execution (Standard governs Architecture Description Element) including the version of TRAK, for example.

Note: Initially architecture views won’t exist and can be identified by placeholders. These can be replaced by the actual view names or links to the views produced within the architecture description for the task.

Architecture Task Findings

A MV-02 view describing the ISO 42010 AD Scope must exist.

In addition one or more MV-02 views must contain:

  • concerns that arise from the task or the analysis (Concern about Architecture Description Element)
  • each Concern is related to at least one thing (Concern about Architecture Description Element)

Note that the architecture description will itself contain views that, say, contrast the current and proposed architectures or which identify gaps or shortfalls. In this case the MV-02 must make reference to these.

ISO 42010 AD Documentation

Irrespective of any other uses of the [[TRAK:MV-02|MV-02[[TRAK:MV-02| the following must be provided within the AD:

  • task sponsor
  • task scope
  • concerns addressed
  • assumptions & limitations made
  • information sources used
  • architect(s)/modeller(s) involved
  • findings (concerns arising, observations, conclusions)
  • models used & developed for task
  • any model dependencies

The MV-02 must at the very least reference all the above information.

Covered by TRAK IPR and licenses

Presentation

Likely to be a mixture of:

Architecture Task Scope:

MVp-02_presentation_scope_460.jpg

Full size:File:MVp-02 presentation scope.jpg

Architecture Task Findings:

MVp-02_presentation_findings.jpg

Covered by TRAK IPR and licenses

Examples

Initially the MV-02 can be used to capture the scope of the task through the concerns of the task stakeholder.

MV-02_Architectural_Task_-_Scope_400.jpg

Full size: File:MV-02 Architectural Task - Scope.jpg

Views Needed to Construct

See Minimum Allowed View Sets|Minimum Allowed Architecture View Sets|Minimum Allowed View Sets

Covered by TRAK IPR and licenses

Consistency Rules

Comments

ISO/IEC 42010 (IEEE 1471) refers to :

system stakeholders (such as architects, designers, programmers, maintainers, testers, domain engineers, quality assurance staff, configuration management staff, suppliers, and project managers or developers) that use it to assist them to understand, interpret, and analyze architectural descriptions to develop, deliver, and maintain their system

TRAK doesn’t have a Stakeholder stereotype. Using a MVp-02 to define the scope of the architecture description would therefore require the stakeholders for the task to be identified. This is a Role in TRAK and together with Sponsor (another Role) can be represented using the tuples:

The MV-02 can be used in several different ways:

  1. As the Master Architecture view for Concern it collects together all the concerns expressed in the architecture description (model).
  2. To record/capture the nub of the discussions with the sponsor for the task.
  3. In conjunction with a package diagram it can be used (after 2) to plan what models are needed for the task.
  4. To outline the views that present the results and thereby provide directed points of navigation into the other views within the architecture description.
  5. To help document the development of the architecture description for a design record.
  6. To help document considerations that affect or might affect the portability of the architecture description (in conjunction with the MV-01).

Covered by TRAK IPR and licenses

Configuration History

The TRAK Viewpoints project on Sourceforge (trakviewpoints.sourceforge.net) maintains a version-controlled repository. The change record is at trakviewpoints.svn.sourceforge.net/viewvc/trakviewpoints/trunk/?view=log

Comments

References

Other Frameworks

See:


Category:Framework -> Viewpoint
Category:Management
Category:Architecture Perspective -> Management
Category:Framework -> Specification

Categories:

  • Management
  •  

    © 2010 Eclectica Systems Ltd.