Difference between revisions of "Viewpoint Advocacy Groups"

From Second Life Wiki
Jump to navigation Jump to search
Line 3: Line 3:
Stakeholders in the Architecture have various agendas, goals, and viewpoints.  These views are critical to the design of the new grid.  This proposal is to create tasks to focus on specific requirements.  The list of Viewpoint Advocacy Tasks may grow and shrink during the course of this project.  The idea here is to provide a framework to address specific concerns in a systematic way.
Stakeholders in the Architecture have various agendas, goals, and viewpoints.  These views are critical to the design of the new grid.  This proposal is to create tasks to focus on specific requirements.  The list of Viewpoint Advocacy Tasks may grow and shrink during the course of this project.  The idea here is to provide a framework to address specific concerns in a systematic way.


 
== Purpose of Viewpoint Advocacy ==


The core goals of the AWG are as follows:
The core goals of the AWG are as follows:


* Document rationale for architectural decisions.
:* Document rationale for architectural decisions.
* Integrate the requirements of each viewpoint from rationale into tasks.
:* Integrate the requirements of each viewpoint from rationale into tasks.
* Advocate and document conflicts between each task.
:* Advocate and document conflicts between each task.
* Integrate feedback from the various viewpoint advocacy tasks.
:* Integrate feedback from the various viewpoint advocacy tasks.
* Produce a coherent architecture.
:* Produce a coherent architecture.


A successful Viewpoint Advocacy Task requires:
A successful Viewpoint Advocacy Task requires:


* To present a set of related concerns about the system in the form of a clear viewpoint.
:* To present a set of related concerns about the system in the form of a clear viewpoint.
* To document architectural specifications that stem from this viewpoint.
:* To document architectural specifications that stem from this viewpoint.
* To consider the architectural needs of likely implementations that fulfill the specifications.
:* To consider the architectural needs of likely implementations that fulfill the specifications.
* To operate in a way that allows for alternate implementations that satisfy the viewpoint.
:* To operate in a way that allows for alternate implementations that satisfy the viewpoint.
* To work with the core goals to document views and requirements that conflict or are inconsistent.
:* To work with the core goals to document views and requirements that conflict or are inconsistent.
* To review the core goals against the work output to ensure that the view's requirements are met.
:* To review the core goals against the work output to ensure that the view's requirements are met.
* The end result of the above is an architectural description which reveals the architecture from this viewpoint.
:* The end result of the above is an architectural description which reveals the architecture from this viewpoint.


== Defining a Viewpoint ==
== Defining a Viewpoint ==

Revision as of 09:59, 12 October 2007

(This is an early draft document, created for feedback purposes. It does not reflect a consensus recommendation, or statement of policy at this time.)

Stakeholders in the Architecture have various agendas, goals, and viewpoints. These views are critical to the design of the new grid. This proposal is to create tasks to focus on specific requirements. The list of Viewpoint Advocacy Tasks may grow and shrink during the course of this project. The idea here is to provide a framework to address specific concerns in a systematic way.

Purpose of Viewpoint Advocacy

The core goals of the AWG are as follows:

  • Document rationale for architectural decisions.
  • Integrate the requirements of each viewpoint from rationale into tasks.
  • Advocate and document conflicts between each task.
  • Integrate feedback from the various viewpoint advocacy tasks.
  • Produce a coherent architecture.

A successful Viewpoint Advocacy Task requires:

  • To present a set of related concerns about the system in the form of a clear viewpoint.
  • To document architectural specifications that stem from this viewpoint.
  • To consider the architectural needs of likely implementations that fulfill the specifications.
  • To operate in a way that allows for alternate implementations that satisfy the viewpoint.
  • To work with the core goals to document views and requirements that conflict or are inconsistent.
  • To review the core goals against the work output to ensure that the view's requirements are met.
  • The end result of the above is an architectural description which reveals the architecture from this viewpoint.

Defining a Viewpoint

A good viewpoint might include the following elements: (borrowing freely from Emery):

Required:
  • Name of the viewpoint
  • List of stakeholders holding this viewpoint
  • List of concerns addressed by this viewpoint
  • Language, modeling techniques, representation method or tools used within this viewpoint
  • Source for the viewpoint
Optional:
  • Consistency/completeness tests for the viewpoint
  • Evaluation/analysis techniques
  • Heuristics, patterns, other guidelines


List of VA-Groups

  • Lorem
  • Ipsum