Hardware Reference
In-Depth Information
−
Internetbased tools, if the process is supported by a tool. For example, such proc-
esses as defect reporting and issue management can be analyzed by looking at the
discussions stored in a project's bug/issue tracking system.
−
Mailing lists, forums, Wikis, etc, used by community members to collaborate while
performing the process. These repositories are useful, for instance, to track deci-
sion-related processes such as release planning, or to follow the interaction be-
tween developers and testers in preparation for a release.
−
Internet-based repositories used to publish the results of a process, such as version-
ing repositories or download servers.
The procedure used to evaluate how established a process is consists of identifying
specific instances of process execution in the potential process trail:
1.
Determine the period of time the process has been/was active, by looking at the
dates for the identified instances.
2.
Identify instances where the process was successfully completed.
3.
Identify instances where the process was not successfully completed/was left un-
finished.
4.
Identify currently running instances.
5.
Use the identified instances to classify the process (see below).
6.
If the number of instances available is large, the analysis can be performed by ran-
domly sampling a smaller number of them.
The outcome of this evaluation should be one of the following four possible results:
1.
No established process:
no data trail found, or too few instances to be representa-
tive.
2.
Dead process:
tried at some point, but no evidence of continued use, no instances
currently active.
3.
Young/immature process:
introduced recently, few actual instances, but instances
appear active.
4.
Established process:
many successful completed instances, significant number of
active instances.
The third question, which is subordinated to the previous one, refers to the consis-
tency with which a process is executed over time. Clearly, this question can also be
answered by looking at the process trail in order to sample instances of the established
process for consistency. The purpose of this inspection is to look for potential signifi-
cant variations in the way individual instances are executed. The evaluation should
result in one of the following values:
1.
Not applicable:
no established process.
2.
Low consistency:
instances vary strongly in the way they are executed.
3.
High consistency:
relatively few variations between instances.
The fourth question has to do with the degree of coincidence between the documented
process and the process that is actually executed. It is the last question of those con-
cerned with the process maturity in itself, and depends on the previous ones being
answered in a positive way. The evaluation procedure, of course, consists of compar-
ing a representative number of instances of the process with the identified process
documentation. Possible results for this evaluation are:
