Assess Completeness

At the end of the iteration, the team assesses their completeness by asking: Are you ready to deliver? Or said another way: Are we done?

This is a direct copy of the AssessScenario for the purposes of analyzing the detailed scenario and what can be accomplished with common vocabularies.

Scenario

1. Assess development status
   1. All in-plan requirements are implemented
      

      ?oslc_cm.query= type="requirement" and assignedTo="{development line}" and status="resolved"

   2. All / expected Development tasks are complete
      

      ?oslc_cm.query= dc:type="task" and assignedTo="{development line}" and status="close"

   3. Notify owners to close open tasks
      

      ?oslc_cm.query= dc:type="task" and assignedTo="{development line}" and status="open" 
       & oslc_cm.properties=owner{*},status,dc:identifier,dc:title

   4. Repeat until expected completeness reached
2. Assess test status
   1. Test execution complete per plan
      View test status per plan items (need to query on link relationship to requirements)
      

      ?oslc_cm.query= dc:type="testexecution" and assignedTo="{development line}" and status="close"
      

   2. Notify owners to close open tasks
   3. Repeat until expected completeness reached
3. Assess Exit Criteria
   1. Defects fixed / expected quality met
      Quality goal: all high severity defects have been fixed

      ?oslc_cm.query= dc:type="defect" and assignedTo="{development line}" 
       & oslc_cm.properties=status,dc:identifier,dc:title,component,owner

   2. Exit criteria met (if any)
   3. Assign tasks & owners to meet exit criteria.
   4. Repeat until expected completeness reached
4. Identify possible assets to distribute
5. Optional: Approve
6. Optional: demonstrate iteration

Pre-conditions

Post-conditions

Possible Resource Definition

In reviewing the scenario above, we'll expand on this to define a common vocabulary to meet the needs of that scenario.

Example of extended ChangeRequest definition:

<ChangeRequest>
  <dc:identifier>Bug123</dc:identifier>
  <dc:title>Some Bug Title</dc:title>
  <status>complete</status>
  <dc:type>defect</dc:type>
  <assignedTo>release1.0_milestone3</assignedTo>
  <owner rdf:resource="bob@myemail.here" />
  <severity rdf:about="#sev1" xml:lang="en">High</serverity>
  <component>server</component>
</ChangeRequest> 

This definition introduces 3 new properties (or 2 properties and a reference to a User resource type). This also assumes there is a single resource type (ChangeRequest? ) that has varying types: Defect, TestExecution? , Task and Requirement. We can assume that TestExecution? and Requirements will most likely be a different resource type, with a different set of prioperties.

There additional properties we have:

status - current state, or status, of the given resource. Possible values:

• close - this often means that no further work or modifications on this resource will occur: code delivered, built, tested, verified
  Some need to have a futher resolution property to qualify the status.
• resolved - indication that the core "work" has been done but yet to be validated
• open - means that resource is currently ongoing changes

assignedTo - (need better name) the containment of an organization that resources are assigned (can be project, interation, release, product, etc). It would most likely not be a simple string property but a reference/link to another resource.

owner - individual responsible for the resource, either directly or indirectly, to ensure that it eventually reaches a closed "done" status. This is most likely a complex resource type which references/links to the user resource.

component - a context for the plan item to assist in building reports with grouping of plan items

severity - a qualification of the impact or severity of the associated work, used to build reports focusing on appropriate data sets.