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
- Assess development status
- All in-plan requirements are implemented
?oslc_cm.query= type="requirement" and assignedTo="{development line}" and status="implemented"
- All / expected Development tasks are complete
?oslc_cm.query= dc:type="task" and assignedTo="{development line}" and status="complete"
- 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
- Repeat until expected completeness reached
- Assess test status
- Test execution complete per plan
?oslc_cm.query= dc:type="testexecution" and assignedTo="{development line}" and status="complete"
- Notify owners to close open tasks
- Repeat until expected completeness reached
- Assess Exit Criteria
- Defects fixed / expected quality met
Note: need to elaborate on this more, typical criteria based on status,severity,category/component ?oslc_cm.query= dc:type="defect" and assignedTo="{development line}"
& oslc_cm.properties=status,dc:identifier,dc:title,
- Exit criteria met (if any)
- Assign tasks & owners to meet exit criteria.
- Repeat until expected completeness reached
- Identify possible assets to distribute
- Optional: Approve
- 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
- 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.