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="resolved"
- All / expected Development tasks are complete
?oslc_cm.query= dc:type="task" and assignedTo="{development line}" and status="close"
- 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
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"
- Notify owners to close open tasks
- Repeat until expected completeness reached
- Assess Exit Criteria
- 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
- 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" />
<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.