Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. SOFTWARE MEASUREMENT – CPSC 547: ESTABLISHING A SOFTWARE MEASUREMENT PROCESS Draft: Version 1 Date: June 10, 2009 Authors: Amin Bandeali (
  2. 2. 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.
  3. 3. 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?