MONITOR DATA PROCESS DEFINITION
Link to Table of Contents: tablel.doc
Description:
This document formally defines the process of monitoring the conduct of an organization’s software engineering projects The purpose of this process is to collect data from the various activities of a project. It combines this data with data from other projects for use in evaluating the effectiveness of the present and subsequent software engineering projects.
Entry Conditions:
The organization is committed to supporting an adaptable, standardized software engineering process that is subject to quality control.
Input Summary:
1)Data concerning the ongoing, software engineering projects in the organization Database standards document.
Implementation Conditions:
1)Develop, or acquire if available, an organization-wide, Monitor Data Definition Document, which specifies the data to be collected in monitoring projects, and subject it to change control on approval.
2)Develop, or acquire if available, an organization-wide, Monitor Data History Archive database that satisfies the conditions:
2.1)Stores the data described in the Monitor Data Definition Document.
2.2)Satisfies the organization’s standards for secure, long-term data storage and for rapid, short-term data retrieval.
3)Repeat for each software engineering project that is initiated:
3.1)Carry out the activities of gathering the information specified in the Monitor Data Definition Document.
3.2)Incorporate the data into the Monitor Data History Archive.
Output Summary:
1)Monitor Data Definition Document.
2)The Organization’s Monitor Data History Archive
Exit Conditions:
1)The Entry Conditions are no longer satisfied.
Notes:
The software engineering project staff perform the activities in step 3, except for the data generated by a Quality Assessment Team. Such a team is responsible for recording the data it generates.
MONITOR DATA DEFINITION
Description:
This document defines the data about the software engineering project that is to be collected for evaluating the organization’s software engineering process. It also specifies the times at which the software engineering process is to sample the data.
Data Type Definitions for the Processes in the Project Activity Template 1:
Id NumberPhase
1Monitor Data Type Definition for the Project Schedule Plan Process
2Monitor Data Type Definition for the Project Tracking Plan Process
3Monitor Data Type Definition for the Product Requirements Process
4Monitor Data Type Definition for the Objectives Process
5Monitor Data Type Definition for the Prototype Process
6Monitor Data Type Definition for the Quality Control Process
7Monitor Data Type Definition for the Specifications Process
8Monitor Data Type Definition for the High-level Design Process
9Monitor Data Type Definition for the Publication Contents Plan Development Process
10Monitor Data Type Definition for the Test Plan Development Process
11Monitor Data Type Definition for the Low-level Design Process
12Monitor Data Type Definition for the Coding Process
13Monitor Data Type Definition for the Unit Test Process
14Monitor Data Type Definition for the Function Test Process
15Monitor Data Type Definition for the Component Test Process
16Monitor Data Type Definition for the First-draft Publications Process
17Monitor Data Type Definition for the System Test Process
18Monitor Data Type Definition for the Second-draft Publications Process
19Monitor Data Type Definition for the Acceptance Test Process
20Monitor Data Type Definition for the Packaging Process
21Monitor Data Type Definition for the Delivery Process
22Monitor Data Type Definition for the Maintenance Process
1. Monitor Data Type Definition for the Project Schedule Plan Process
1) Project Scheduling Process Definition
It is essential to collect and/or compute the following data:
1) The initial and termination dates of the Initial Project Schedule Plan.
2) The initial and termination dates of the Final Project Schedule Plan
3) The initial and termination dates of each step of the Initial Schedule Project Plan.
4) The initial and termination dates of each step of the Final Schedule Project Plan.
5) The amount of person-hours for the Initial Project Schedule Plan
6) The amount of person-hours for the Final Project Schedule Plan.
7) The amount of person-hours for each step of the Initial Project Schedule Plan.
8) The amount of person-hours for each step of the Final Project Schedule Plan.
9) Number of Kickoff Initial Project Schedule Planning Meetings held., if more than one
10) Number of Kickoff Final Project Schedule Planning Meetings held, if more than one.
11) It is essential to collect and/or compute the following data for the Scrub Data from Each Submitted Step for the Initial Project Schedule and the Final Project Schedule Plan:
11.1) Average number of revisions per review.
12) Number of Full Review Meetings held for Initial Project Schedule Plan, if more than one.
13) Number of Full Review Meetings held for Final Project Schedule Plan, if more than one.
14) It is essential to collect and /compute the following data for the Review Results with Each Owner Step for the Initial Project Schedule Plan and the Final Project Schedule Plan:
14.1) Number of revisions made to Project Schedule draft.
15) It is essential to collect and/or compute the following data for the Update Project Schedule
Plan Step:
15.1) Average number of revisions per review.
16) It is essential to collect and/or compute the following data for the Approve Project Schedule Plan Phase:
16.1) Total number of reviews by project manager.
16.2) Average number of revisions in Project Schedule Plan for each review.
17) Total number of Severe and Moderate changes to the Initial Project Schedule Plan occurring in each standard period once the Plan has been subjected to the Schedule Change Plan at the termination date of the Initial Project Schedule Plan Phase. It is recommended that the standard period be one week.
18) Total number of Severe and Moderate changes to the Final Project Schedule Plan occurring in each standard period once the Plan has been subjected to the Schedule Change Plan at the termination date of the Final Project Schedule Plan Phase. It is recommended that the standard period be one week.
19) The total score from the Quality Assessment Report on the Initial Project Schedule Plan
that is produced in the Quality Assessment process.
20) The total score from the Quality Assessment Report on the Final Project Schedule Plan
that is produced in the Quality Assessment process
21) The Quality Assessment Report for the Initial Project Schedule Plan must be placed in the
Monitor Data History Archive for use by management.
22) The Quality Assessment Report for the Final Project Schedule Plan must be placed in the
Monitor Data History Archive for use by management.
2. Monitor Data Type Definition for the Project Tracking Process
Input Summary:
1) Project Schedule Plan.
2) Documentation Standards.
3) Quality Assessment Report on Project Tracking.
It is essential to collect and/or compute the following data:
1) The initial and final termination dates of the Project Tracking Process.
2) The initial and termination dates of each phase within the Project Tracking Process.
3) The amount of person-hours for the Project Tracking Process.
4) The amount of person-hours for each phase of the Project Tracking Process.
5) Repeat.
5.1) Compute the Productivity Number
PN = Np/Nh
where
Np = The number of persons working on the Project Tracking Process.
Nh = The number of person-hours worked on the Project Tracking Process.
For the Project Tracking Process as a whole, then for each process within Project Tracking.
6) The number of and average length of Project Tracking Team Meetings Held.
7) The number of and average length of Project Tracking Team Conduct Work / Escalation Meetings Held.
8) It is essential to collect and/or compute the following data for Assignment of a Project Tracking Team Leader:
8.1) The number of candidates for the position.
8.2) The amount of person-hours spent interviewing potential candidates.
9) It is essential to collect and/or compute the following data for Identify Tools and Forms:
9.1) The number of tools and forms considered.
9.2) The number of tools and forms chosen to implement.
9.3) The number of persons-hours spent creating tools and forms.
10) It is essential to collect and/or consider the following data for Prepare for Project Tracking Team Training Process:
10.1) The amount of person-hours spent in preparation for training.
11) It is essential to collect and/or consider the following data for Conduct Project Tracking Team Training:
11.1) The amount of person hours spent in training.
12) It is essential to collect and/or consider the following data for Prepare Project Tracking Team Meeting
12.1) The amount of person hours spent in preparation for the meeting.
12.1) The number of revisions made to the meeting material.
13) It is essential to collect and/or compute the following data for Conduct Project Tracking Team Meeting.
13.1) The amount of person-hours spent in during a Project Tracking Team Meeting.
13.2) The total amount, and average length of Project Tracking Team Meetings conducted.
13.3) The number of problems to arise.
13.4) The number of problems requiring escalation.
13.5) It is essential to collect and/or compute the following data for all problems requiring escalation:
13.5.1) The initial and termination dates for resolution of the problem.
13.5.2) The amount of person-hours spent working on the resolution to the problem.
13.5.3) The actual resolution date for the problem.
14) It is essential to collect and/or compute the following data for Conduct Work and Escalation Meetings:
14.1) The number of open problems to be discussed.
14.2) The number and average length of Work and Escalation Meetings held.
14.3) The total number of person-hours spent at each meeting.
14.4) The number of problems resolved, and unresolved.
15) It is recommended to collect and/or compute the following data for Distribute Project Tracking Team Minutes:
15.1) The number of person-hours spent preparing the minutes for distribution.
16) Place the Quality Assessment Report into the Monitor Data History Archive.
3.Monitor Data Type Definition for the Product Requirements Process
Input Summary:
1)Project Schedule Plan
2)Documentation Standards
4)Quality Assessment Report on Product Objectives
It is essential to collect and/or compute the following data:
1)The amount of time it takes to complete the Requirements phase, calculated in Calendar days.
2)The number of requirements which are divided in a logical “single” idea format as specified by the Requirements phase.
3)The estimated number of person-hours for the phase based loosely on the number of requirements where
total hours to complete requirements phase = (Number of Requirements) * .15
4)The actual amount of person-hours for the phase and its deviations from the amount in point 3.
5)The number of deviations from the Documentation Standards.
6)For each review during the phase and each update while under change control, compute the Document Maturity Text Metric for the Product Requirements Document:
DMP = [ Pt - (Pa + Pc + Pd) ] / Pt
where
Pt is the number of paragraphs in the latest version of the document,
Pa is the number of paragraphs added since the last version,
Pc is the number of paragraphs that appear in both the old and new version but have changed,
Pd is the number of paragraphs deleted since the last version.
7)For each review during the phase and each update while under change control, compute the Document Maturity Flow Diagram Metric for the Product Specifications Document:
DMF - [ Ft - (Fa + Fc + Fd) ] / Ft
where
Ft is the number of data flow diagrams (DFDs) in the latest version of the document,
Fa is the number of DFDs added since the last version,
Fc is the number DFDs that appear in both the old and new version but have changed,
Fd is the number of DFDs deleted since the last version.
9)For each review during the phase and each update while under change control, compute the Document Data Dictionary Metric for the Product Requirements Document:
DMD = [ Dt - (Da + Dc + Dd) ] / Dt
where
Dt is the number of data items in the latest version of the data dictionary,
Da is the number of data items added since the last version,
Dc is the number of data items that appear in both the old and new version but have changed.
Dd is the number of data items deleted since the last version.
10)The Total Score from the Quality Assessment that will be saved in the Monitor Data History Archive when it is created, as the entire Quality Assessment Report
11)The number of “Passes and Fails” as described by the Requirements Quality Control plan.
7. Monitor Data Type Definition for the High Level Design Process
Input Summary:
1) High Level Design Document
2) Project Schedule Plan
3) Documentation Standards
4) Quality Assessment Report on High Level Design.
It is essential to collect and/or compute the following data for High Level Design:
1) The initial and final schedule dates of the High Level Design phase.
2) The initial and final termination dates of the High Level Design phase.
3) The amount of person-hours estimated for the High Level Design phase.
4) The actual amount of person-hours for the High Level Design phase and its deviation from the amount in point 3.
5) Compute the Productivity Number
PN = Np/Nh
where
Np = The number of persons working on the High Level Design phase.
Nh = The number of person-hours worked on the High Level Design phase.
6) The number of deviations from the Documentation Standards and from the Requirements Document that are found at each review of the High Level Design document.
7) The number of severe and moderate changes to the High Level Design document during a recommended standard one week period once the document has been subjected to change control.
8) Repeat
8.1) Compute the Document Maturity Metric for the High Level Design document using the formula:
DM = [Pt - (Pa + Pc + Pd) / Pt]
where
Pt = The number of paragraphs in the latest version of the document.
Pa = The number of paragraphs added since the previous version.
Pd = The number of paragraphs that have been deleted from the previous version.
Pc = The number of paragraphs that appear in both versions of the document but that have been changed.
For each review during the High Level Design Phase and each update while under change control.
9) Determine the feasibility of each of the diagrams, tables in High Level Design. Scale these figures on an arbitrary feasibility scale.
10) Determine the feasibility of each of the diagrams, tables in High Level Design. Scale these figures on an arbitrary feasibility scale.
11) The total score from the Quality Assessment Report on the High Level Design that is produced in the Quality Assessment process.
12) Store the entire Quality Assessment report on the High Level Design for general reference.
13) Place the Quality Assessment Report into the Monitor Data History Archive.
8. Monitor Data Type Definition for the Publication Contents Plan Process
Input Summary:
1) Final Project Schedule Plan
2) Documentation Standards
3) Product Specifications Document.
4) Quality Assessment Report on Publication Contents Plan
It is essential to collect and/or compute the following data:
1) The type of publications produced (User Manual, On-Screen Help, etc.
2) The initial and termination dates of the phase estimated in the Final Project Schedule Plan.
3) The actual initial and termination dates of the phase and their deviations from the corresponding dates
4) The amount of person-hours for the phase estimated in the Project Schedule Plan.
5) The actual amount of person-hours for the phase and its deviation from the amount in point 5.
6) The number of reviews conducted on the Publications Content Plans.
7) The number of deviations from the Documentation Standards and from the Specifications and
Objectives Documents that are found at each review of the Publication Contents Plan during this phase.
8) It is essential to collect and/or compute the following data after the first Usability Walkthrough:
8.1) Number of reviews.
8.2 Average number of revisions made per review.
9) It is essential to collect and/or compute the following data after the second Usability Walkthrough:
9.1) Number of reviews.
9.2 ) Average number of revisions made per review.
10) It is essential to collect and/or compute the following data after the second Customer Approval:
10.2) Average number of revisions made per review
11) The total number of Severe and Moderate changes to the Publication Contents Plan occurring in each standard period once the document has been subjected to change control at the termination date of this phase. It is recommended that the standard period be one week.
12) For each review during the phase and each update while under change control, compute the Document Maturity Metric for the Publication Contents Plan: