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="implemented"

   2. All / expected Development tasks are complete
      

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

   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
      

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

   2. Notify owners to close open tasks
   3. Repeat until expected completeness reached
3. Assess Exit Criteria
   1. Defects fixed / expected quality met
      Note: need to elaborate on this more, typical criteria based on status,severity,category/component,owner

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

   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" />
</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:

• complete - 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.
• implemented - one could argue this is just closed, with a qualified status of implemented
• 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.