SOFTWARE MEASUREMENT – CPSC 547:
ESTABLISHING A SOFTWARE MEASUREMENT PROCESS
Draft: Version 1
Date: June 10, 2009
Authors: Amin Bandeali (amin.bandeali@csu.fullerton.edu)

Establishing a to Software Measurement Process 1
This paper provides a very cohesive framework for establishing a measurement process
as part of an organization’s overall software process. This is very essential because software
engineering is a young discipline and so its theories, methods, models, and techniques still need
to be fully developed and assessed. Other engineering branches rely on older, well-consolidated
scientific disciplines. This report starts off with illustrating a four step architecture for designing
a software measurement process.
This report focuses on software measurement process elements which are software
estimation, software design, code, unit test, peer reviews and measurement. Using a process
definition method called ETVX, it develops an operational definition of the measurement
process. A Measurement Process contains of activities which include
• identifying what data to be collected,
• defining how the data are to be collected and reported,
• defining how the data are to be used to make decisions,
• defining how the process is to evolve and improve,
• collecting and analyzing the data,
• making decisions and starting over by continuing and/or adjusting the process [1].
Planning the measurement process involves the first two activities of the architecture and
the author applies the EVTX process definition method to all the rest of activities which help
determine the scope and purpose of the measurement effort, implementing and evolving the
process.
The next section, illustrations of use, describes different ways or methods that an
organization can apply at various levels. A baseline measurement process should communicate
clearly and throughout the different organizational levels and also be consistent. The methods
described in the initial section of the paper could be used to design processes that could include
common management objectives and issues, size, effort and problem measurements, etc. With a
baseline in place, a solid foundation for collecting measures is established. These measurements
could evolve; for example, problem reports could be expanded to track statuses, type, severity
and priority.
Using the above baseline measurements, managers can better manage projects by for
example, use historical data to calibrate software estimation models and then re-plan projects
based on deviations in status, progress, or renegotiations of requirements. The manager can also
describe the products more efficiently by describing how good a product is, or to classify product
characteristics by focusing on the basic measures like maintainability, reliability and problem
densities. A developer can use product descriptions to help them understand the quality of their
work and identify potential strengths and weaknesses in the process while the customers can
describe the products in their requirements specifications to indicate the desired level of quality.
A manager can improve processes of an organization by understanding and focusing on
the basic measures being used for managing their existing processes and products. By
aggregating measurement data across the organization, senior management can identify and
define measures that will help them make decisions with respect to organizational goals and
objectives. With measurement they can better understand the software process and organizational
capabilities, and get involved with the business aspects of software.
As projects and organizations evolve, they hire new staff and those staff needs to be part
of the dynamic changes that the company is going through. They will have to be part of the ever
changing measurement process so that the measurements are up to date and reflect the correct
organizational procedures.

Establishing a to Software Measurement Process 2
The last section of this paper completes the measurement process by building upon the
flagship section of this paper – designing the process. This section concentrates on the steps that
necessitate starting a software measurement program. It recommends creating a focal group by
allocating dedicated resources to this end. This group could provide the executives with the
insight to the projects that would otherwise be impossible to have.
The focal group should then meet the objectives set by the management. These objectives
may be the result of process assessment findings and recommendations or some other process
improvement activity. Once objectives are set, a process must be designed to leverage current
measurement capabilities to collect and define the future measurements to achieve
management’s objectives. Once designing is completed, a proof of concept prototype should be
created so that the process could be tested on actual projects focusing on current project
performance with respect to the organizational objectives, benefits and lessons learned from the
existing measurement process, and scope of the effort and resources necessary to initiate and
maintain the measurement process on projects.
Results of the above prototype should be documented and results should be discussed
with management, addressing the benefits and lessons learned and how measurements can
support the organization. Once measurement is documented, it should be implemented across the
organization by integrating measurement process with the software process. The focal group can
then proceed to find opportunities to integrate measurement with other process improvement
activities in the organization.
This paper emphasizes the need for visibility into the software development life cycle and
what better way than measurement? It gives a clear and concise framework for developing,
collecting, analyzing, maintaining and evolving a measurement process for an organization. I
liked the way it went into detail for the first couple of activities and then quickly moved into the
rest of the topics. Personally, I liked the presentation and the material of the paper; however it
could have been presented in a more interesting way. I had to go through the paper multiple
times to understand the depth of the concepts. Also, it seemed to me that the paper was more
tailored for big organizations rather than medium or small software development firms?