Skip to end of metadata
Go to start of metadata

Overview of "Define Resource Life Cycle" Use Case


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Describe obligatory state model for given resource type.

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors State Model Developer
References  
Uses UC.R2.08 Manage Instrument Lifecycle
Is Used By  
Extends  
Is Extended By  
In Acceptance Scenarios AS.R2.01B Define Marine Observatory Policies, AS.R2.02C Instrument Life Cycle Support, AS.R2.04B Curate Data Products
Technical Notes Although many of these are development steps rather than system operation steps,
the final steps show system execution using the resulting product.
Lead Team COI
Primary Service Resource Lifecycle Services
Version 1.4
UC Priority 4
UC Status Mapped + Ready
UX Exposure PGM

Summary

This information summarizes the Use Case functionality.

Define a state model with activities for one specific type of Integrated Observatory resource, such that all resources of this type then follow this state model and activity flow. (A 'resource' is any system entity with capabilities or state.) Take a resource of the chosen type through the activities and states. Integrate with UI (e.g., for display and control) and processing (e.g., leverage the resource type using policy).

Assumptions

  1. There is a life cycle model (template) upon which the individual resource type's life cycle is based.
  2. The resource life cycle model is a necessary approach to allow us to manage life cycle issues across all our assets.

Initial State

A resource type (the 'target resource') has been identified for which life cycle states are to be identified.

Scenario for "Define Resource Life Cycle" Use Case

  1. <2> State Model Developer starts with generic Resource Life Cycle state model, and identifies new states or substates appropriate to the particular target resource.
  2. <2> State Model Developer also determines new permitted transitions between states (and any applicable constraints).
  3. <2> State Model Developer encodes states and state transitions in appropriate specification format to create a Life Cycle State Model for that resource type.
  4. <2> State Model Developer triggers the State Model repository service to register or reload the defined state model.
    1. This step can occur after the software development steps below.
    2. A technique to directly submit the newly defined state model is also acceptable.
  5. <3> State Model Developer creates software components/services that appropriately transition the resource through its different states.
    1. GUIs enable operator control of most transitions (i.e., a user commands the resource to change its state), while some transitions may occur as a result of internal system operations.
    2. An Integrated Observatory Operator can demonstrate application states and substates (possibly on a test system).
    3. In later releases, policy and governance may be automatically applied on each state transition, to confirm it is appropriate and consistent with the state model for the target resource.
  6. After the necessary software components/services are deployed, the Integrated Observatory Operator moves a resource of the selected type through its life cycle states.
    1. In later releases, policy and governance may cause a resource's state transitions.
    2. UC.R2.08 Manage Instrument Lifecycle is a specific example of a resource type moving through its life cycle states.
  7. Integrated Observatory Operator monitors the resource state in a user interface that displays the states.

Final State

Resource Life Cycle state model for that resource type is shown to be fully accessible and operational.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

This use case should be extended to satisfy various DOORS requirements regarding resource lifecycle; include all of the states defined in the generic lifecycle (swim lane diagram ) and any others specifically mentioned in the requirements; also include notification for resource activation and ensuring no resource interference.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.