MBA management

Software Measurement and Measurement Analysis topics:

Software Measurement Needs

Software measurement is a quantified attribute a characteristic of a software product or the software process. It is a discipline within software engineering. The content of software measurement is defined and governed by ISO Standard ISO 15939 (software measurement process).

The use of measurement in the software life cycle requires the development and use of software metrics, which are standardized through the use of defined units of measurement program enables management to control and manage software throughout its entire life.

Both the software product and the process by which it is developed can be measured. The software product should be viewed as an abstract object that evolves from an initial statement of need to a finished software system, including source and object cod and the various forms of documentation produced during development. The software metrics are studied and developed for use in modeling the software development process. These metrics and models are used to estimate and predict product costs and schedules, and to measure productivity and product quality. Information gained from the measurements and models can be used in the management and control of the development process, leading to improved results.

There is no clearly defined, commonly accepted way of measuring software products and services. A large number of measures and metrics exist, but only a few have had widespread use or acceptance. Even with those widely studied, such as LOC or T.J. McCabe’s cyclomatic complexity, it is not universally agreed what they mean. Some studies have attempted to correlate the measurements with a number of software properties, including size, complexity, reliability (error rates), and maintainability.

Additionally, many measurements are done subjectively, such as product type or level of programming expertise. They are difficult to evaluate because of the potentially large number of factors involved and the problem associated with assessing or quantifying individual factors.

As for the proposed process models, few have a significant theoretical basis. Most are based upon a combination of intuition, expert judgment, and statistical analysis of empirical data. Many software measures and metrics have been defined and tested but used only in limited environments. There is no single process model that can be applied with a reasonable degree of success to a variety of environment. Generally, significant recalibration is required for each new environment in order to produce useful results. Furthermore, the various models often use a wide variety of basic parameter sets.

The above considerations make it difficult to interpret and compare quoted measurement results, especially with different environments, languages, applications, or development methodologies. Even simple measures, such as LOC, have differences in underlying definitions and counting techniques making it almost impossible to compare quoted results. Metrics involving LOC values across different program languages can lead to incorrect conclusions and thereby conceal the real significance of the data. For example, the productivity metrics LOC per month, and cost per LOC suggest that assembly language programmers are more productive than high-level language programmers (higher LOC per month and lower $ per LOC), even though the total programming cost is usually lower for high-level languages, Similarly, defects per LOC and cost per defect values have been used as quality or productivity indicators. Again, with different levels of programming languages, using these measurements may obscure overall productivity and quality improvements by systematically yielding lower defect per LOC and cost per defect values for lower- level languages, even though total defects and costs are actually higher.

Despite these problems, applying software metrics and models in limited environments can help improve software quality and productivity. Defect density and McCabe’s complexity have been found to be reasonably good predictors of other characteristics, such as defect counts, total effort, and maintainability. There are many useful products for measurement and modeling available on the market today. Additional experience with current models and a better understanding of underlying measurements and their application to the software process will improve the results.

Measurement System Planning

Quantitative measurement occurs at all levels of IT maturity. As an organizations mature, their use of measurement changes with the maturation of the management approaches. Immature organizations typically measure for budget, schedule, and project status, and management relies on project tams to determine when requirements are done. When work processes are optimized, management relies on the quantitative data produced from the processes to determine whether or not the requirements are complete, and to prevent problems.

There are four major uses of quantitative data (I.e., measurement):

1. Manage and control the process.
A process is a series of tasks performed to produce deliverables or products.IT processes usually combine a skilled analyst with the tasks defined in the process. In addition, each time a process is executed it normally produces a different product or service from what was built by the same process at another time. For example, the same software development process may be followed to produce two different applications. Management may need to adapt the process for each product or service built, and needs to know that when performed, the process will produce the desired product or service.

2. Manage and control the product.
Quality is an attribute of a product. Quality level must be controlled from the start of the process through the conclusion of the process. Control requires assuring that the specified requirements are implemented, and that the delivered product is what the customer expects and needs.

3. Improve the process.
The most effective method for improving quality and productivity is to improve the processes. Improved process gains from the improvement. Quantitative data gathered during process execution can identify process weaknesses, and therefore, opportunities for improvement.

4. Manage the risks.
Risk is the opportunity for something to go wrong- for example, newly purchased software will not work as stated, projects will be delivered late, or workers assigned to a project do not possess the skills needed to successfully complete it. Management needs to understand each risk. Know the probability of the risk occurring, know the potential consequences if the risk occurs, and understand the probability of success based upon different management actions.

The same database of quantitative data is employed for these four uses, but different measures and metrics may be utilized. The blow table illustrates how the four uses of measurement can be achieved.

Use   Questions Answers   Measurement Category   Examples of Measures/Metrics
Manage and Control the process   - How much have we made?
- How much is left to make?
  Size   - Lines of code (LOC)-Boxes
- Procedures-Units of output
  How much progress have we made?   Status   - Earned Value - Amount of scheduled work that is done-%of ach activity completed
  How much effort has been expended?   Effort   Labor hours that differentiate requirements, design, implementation and test.
  When will the product be completed?   Schedule   Calendar times (months, weeks)of activity complete.
Manage and Control the Product   How good is the product?   Quality   - Number of defects found-Mean time to failure-Mean time to repair.
  How effectively does the product perform?       - Technical performance- Measures specified by customers specified by customers and management.
Improve the Process   - How cost-efficient is the process?-What is the current performance?   Time and effort   - Unit costs - Time to complete
Manage the Risks   What are the risks?   Risks   Probability of exceeding constraints or not meeting requirements.

Measurement Approach

Installation of a measurement program in a software organization is a four-phased approach, with each phase containing multiple steps. The following section details this four phased approach:

1. Build the Measurement base.

The objective of this phase is to create an environment in which the use of quantitative data is an accepted component of the management process. The four steps for accomplishing this are:

• Define the objectives for the measurement program- how it is to be used. Consider how to implement the four uses of measurement, given the maturity level of the organization. The use of measurement should be tied to the organization’s mission, goals and objectives.

• Create an environment receptive to measurement. Begin with the prerequisites listed earlier in this section. Establish service level agreements between IT and the users to define quality and productivity that must be defined before they can be measured. People involved with the measurement should help develop the measure.

• Establish a quality management environment and ensure the work processes being used have been implemented.

• Define the measurement hierarchy, which has three levels of quantitative data: measures, metrics, and a strategic results dashboard (also called key indicators). This measurement hierarchy maps to a three level IT organizational tier: staff, line management and senior management. IT staff collects basic measures, such as product size, cycle time, or defect count. IT line management uses fundamental metrics, such as variance between actual and budgeted cost, user satisfaction or defect rats per LOC to manage a project or part of the IT function. Senior management uses a strategic results dashboard, where the metrics represent the quantitative data needed to manage the IT function and track to the mission, vision, or goals, For example. A mission with a customer focus should have a customer satisfaction metric. A metric of the number of projects completed on time gives insight into the function’s ability to meet short and long-term business goals.

• Define the standard units of measurement.

2. Manage towards results.

In this five-step phase, goals for the desired business results are identified in the form of a strategic dashboard, and the means for measuring those results are determined. The business results need to b prioritized and communicated to the entire IT function so that decisions will be made in a manner that will facilitate achieving those results. This is particularly critical when the third phase is implemented, as the process results should link to the desired business results.

• Identity desired business results, beginning with a mission or vision statement. Turn operative phrases in the mission or vision (such as “deliver on time” or “satisfy customer”) into specific objectives (such as “all software will be delivered to the customer by the date agreed upon with the customer”), and then rank these objectives in order of importance. When objectives are written with a subject, action, target value, and time frame it is much easier to identify the actual metric that will serve as the results metrics or key indicator.

• Identify current baselines by determining the current operational status for each of the desired business results /objectives.

• Select a measure or metric for each desired business result or objective, and determine whether it has been standardized by the IT industry (such as cycle time, which is measured as elapsed calendar days from the project start date to the project and date). If not, explore the attributes attainable, easy to understand and collect, and a true representation of the intent. Ideally there should be three to five metrics, with no more than seven. Convert the business results metrics into a strategic dashboard of key indicators. Examples of indicators includes productivity, Customer satisfaction, motivation, skill sets, and defect rates.

• Consider tradeoffs between the number on ranked business result and the other desired results. For example, the# 1 result to complete on time will affect other desired results, such as minimize program size and develop easy to read documentation.

• Based on the baseline and desired business result or objective, determine a goal for each result metric. Goals typically specify a subject (such as financial, customer, process or product, or employee) and define an action that is change or control related (such as improve or reduce, increase or decrease or control or track). If a baseline for on time projects is 60%, the goal might be to increase to 80% by next year. Benchmarking can also be useful prior to setting goals, as it allows an understanding of what is possible given a certain set of circumstances.

3. Manage by process.

Managing by process means to use processes to achieve management’s desired results. When results are not achieved, a quality management philosophy tells organization to look at how the system (i.e., its processes) can be improved rather than reacting, making emotional decisions, and blaming people. Quantitative feedback, which provides indicators of process performance, is needed in order to operate this way. Various processes usually contribute jointly to meting desired business results, and therefore, it is important to understand and identify what things contribute to, or influence, desired results. This phase consists of four steps to implement measurement in a process, and to identify the attributes of the contributors, which if met will achieve the desired process results. These steps provide the information to manage a process and to measure its status.

• Develop a matrix of process results and contributors to show which contributors drive which results. The contributors can be positive or negative, and involve process, product, or resource attributes. Process attributes include characteristics such as time, schedule, and completion.

Product attributes include characteristics such as size, correctness, reliability, usability, and maintainability. Resource attributes include characteristics such as amount, skill, and attitude.

• Assure process results are aligned to business results. Processes should help people accomplish their organization‘s mission. Alignment is subjective in many organizations, but the more objective it is, the greater the chance that processes will drive the mission.

• Rank the process results and the contributors from a management perspective. This will help workers make tradeoffs and identify where to focus management attention.

• Select metrics for both the process results and contributors, and create two tactical process dashboards: one for process results and one for contributors. These dash-boards are used to manage the projects and to control and report project status. Normally results are measured subjectively and contributors are measured objectively. For example, for a result of customer satisfaction, contributors might include competent resources, an available process, and a flexible and correct product, Sometimes, as with customer satisfaction, factors that contribute to achieving the result can actually be used to develop the results metric. In other words, first determine what contributes to customer satisfaction or dissatisfaction and then it can be measured.

4. Management by fact.

Management by fact uses quantitative data produced from, and about work processes to make informed decisions regarding the operation of those work processes. Quantitative data can be objective (such as the number of defects produced) or subjective (such as the customer’s perception of the quality of the products or services produced by the process).Typically the focus of decisions is common cause problems and special cause problems.

The management by fact process contains two components:

• Meeting desired results
• Managing the processes to drive the results

Choice of Measurement

Software measurement possesses a number of challenges, from both a theoretical and practical points of view. To face these challenges, we can use a number of techniques that have been developed over the years and/ or have been borrowed from other fields. First, we need to identify, characterize, and measure the characteristics of software processes and products that are believed to be relevant and should be studied. This is very different from other engineering branches, where researchers and practitioners directly use measures without further thought. In those disciplines, there no longer is a debate on what the relevant characteristics are, what their properties are, and how to measure these characteristics. In software engineering measurement, instead, we still need to reach that stage. There is not as much intuition about software product and process characteristics (i.e., software cohesion or complexity) as there is about the important characteristics of other disciplines. Therefore, it is important that we make sure that we measuring the right thing, i.e., it is important to define measures that truly quantify the characteristic they purport to measure. This step called theoretical validation is a difficult one, in that it involves formalizing intuitive ideas around which there is limited consensus. To this end, one can us Measurement Theory, which has been developed in the social sciences many in the last 60 years, or property based approaches, which have been used in Mathematics for a long time.

Second, we need to show that measuring these characteristics is really useful, via the so-called empirical validation of measures. For instance , we need to show if and to what extent these characteristics influence other characteristics of industrial interest, such as product reliability or process cost .It is worthwhile to measure them and us them to guide the software development process only if they have a sufficiently large impact. To this need, experiments must be carried out and threats to their internal and external validity must be carefully studied .In addition, the identification and assessment of measures may not be valid in general. Nothing guarantees that measures that are valid and useful in one context and for some specified goal are as valid and useful for another context and goal. Goal oriented frameworks that have been defined for software measurement can be used. Before illustrating the various aspects of software measurement, we would like to explain that the term “metric” has been often used instead of “measure” in the software measurement field in the past. As it has been pointed out,” metric” has a more specialized meaning, i.e., distance, while “measure” is the general term.

Therefore, we use “measure” in the remainder of this unit. This unit also describes a framework for goal oriented measurement (the Goal /Question /Metric paradigm). This unit introduces the basic concepts of software measurement. This unit illustrates how Measurement Theory and axiomatic approaches can be used to carry out the so called theoretical validation of software measures, i.e., to show that a measure actually quantifies the attribute it purports to measure. It describes some of the measures that have been defined for the intrinsic attributes (i.e., size, structural complexity) of the artifacts produces during software development. This unit concisely reports on external software attributes (e.g., reliability, maintainability), i.e., those that refer to the way software relates to its development or operational environment. Process attributes are discussed in this unit. Remarks on the practical application of software measurement and possible future developments are also discussed in this unit.

Goal-oriented Measurement

It is fundamental that all measurement activities be carried out in the context of a well-defined measurement goal. In turn, the measurement goal should be clearly connected with an industrial goal, so the measurement program responds to a software organization’s needs. The Goal/ Question/ Metric (GQM) paradigm provides a framework for driving measures from measurement goals. The idea is to define a measurement goal, with five dimensions, as follows:

Object of Study: the entity or set of entities that should be studied, e.g., a software specification, or a testing process:

Purpose: the reason/ the type of result that should be obtained: e.g., one may want to carry out/ obtain a characterization, evaluation, prediction, or improvement:

Quality Focus: the attribute or set of attributes that should be studied, e.g., size (for the software specification, or effectiveness (for the testing process):

Environment: the context (e.g., the specific project or environment) in which measurement is carried out.

The following is an example of a GOM goal: Analyze the testing process (object of study) for the purpose of evaluation (purpose) with respect to the effectiveness of causing failure (quality focus) from the point of view of the testing team (Point of view) in the environment of project X (environment).GQM goals help clarify what needs to be studied, why, and where. Based on the goal, the relevant attributes are identified via a set of question (an intermediate document between the goal and the questions, the Abstraction Sheet, has been recently introduced to provide a higher- level view of the questions). As a simple example, a question related to the study of testing effectiveness may ask: How much is defect density? Each question is then refined into measures that can be collected on the field. For instance, defect density may be defined as the ratio of the number of defects found to the number of lines of code.

Conversely, interpretation of results proceeds bottom-up, i.e., the measures collected are used and interpreted in the context and for the objectives that have been initially defined. The GOM paradigm has been successfully used in many industrial environments to increase the knowledge of software organizations about their own practices and lay the quantitative foundations for improvement of software processes and products.

The GOM paradigm is a part of an organized approach to the improvement of software products and processes, the Quality Improvement Paradigm (QIP), which can be concisely described as an instantiation of the scientific method tailored for the needs of Software Engineering. The QIP is based on the idea that improvement can be achieved and quantified via the acquisition of knowledge on software processes and products over time. The Experience Factory (EF) is another central aspect of the QIP. The EF is the organizational unit that collects, stores, analyzes, generalizes, and tailors information from software development projects, so it can be used in future ones.

Measurement Process

In software organizations, measurement is often equated with collecting and reporting data and focuses on presenting the numbers. The primary purpose of measurement is to focus more on setting goals, analyzing data with respect to software issues, and using thee data to make decisions. Measurement process is part of the software development process that provides for thee identification, definition, collection, and analysis of measures that are used to understand, evaluate, predict, or control software processes or products.

The measurement process thus developed has to be documented and the process document must put communicable meaning into the concepts and express the measurement process in operational terms to:

• Identify what data are to be collected,
• Define how the data are to be collected and reported,
• Define how the data are to be used to make decisions,
• Define how the process is to evolve and improve,
• Collect and analyze the data,
• Make decisions, and
• Start over by counting and/or adjusting the process

An effective measurement process must achieve a result nearest to what is needed for achieving a particular goal. With measurement, projects collect only those measures that are needed to provide enough data to make decisions. Because data collection can be expensive, the measurement process must be feasible with respect to the time and costs associated with collecting data.

Documentation of this process may vary considerably from organization to organization and project to project. It may result in plans or procedures that organization to organization and project to project. It may result in plans or procedures that organizations present in their own ways. Regardless of how the process is documented (i.e., whether as a department instruction, a standard practice, or a formal procedure), the basic tasks described I n the following sections should be included or at least addressed.

Plan the process

Planning the measurement process involves two activities that are

1. Identify the measurement scope
2. Define procedures

Identifying the Scope

The measurement process originates with a need with a need for measurement. The need could be large or small. For example: an organization may need to measure corporate- wide project performance: a small project may need to assess and evaluate their design and code inspections; or SEPGs may need to focus and evaluate process improvement activities. The need for measurement typically will involve different audience perspectives; that is, various functional groups will us or give inputs to the measurement process. Before designing a measurement process, it is important to understand what the needs for measurement are, and who the audiences are.

Once the need for measurement has been established, the first activity of the measurement process that must be addressed is the Identify Scope Activity. This activity helps to establish the purpose for measurement. The Identify Scope Activity includes identification of objectives that measurement is to support, issues involved to meet these objectives, and measures that provide insight into these issues .While identifying the scope only measures that support decision making with respect to goals and objectives are identified.

The Sequence of tasks to be performed to complete an Identify Scope Activity is:

1. Identify the needs for measurement. A measurement need could be as board as providing insight into the achievement of the organizational mission; or it could be as focused as providing insight into a change in project performance due to the implementation of a new software tool. For any measurement need, it is important to recognize that there may be several audiences or users of the measurement data, each with different perspectives and needs for measurement (e.g., SEPGs, project management, quality assurance). All audiences or users should be identified, including those who will receive the measurement reports, these who will make decisions based on the data, and those who will provide the data.

2. Identify the objectives of the organization that each measurement need is going to address. This task ensures that measurement is aligned with and will support decision making with respect to the business objectives of the organization.

3. Identify the methods that will be used to achieve the objectives stated in task 2 above. This task will help to ensure that there are methods to achieve the objectives, and that the objectives are feasible. Also, these are the methods that need to be measured in order to give the measurement users insight to make decisions.

4. Identify the issues that need to be managed, controlled, or observed. These issues should refer to products, processes, and/or resources that are traceable, and relate to the methods identified in task3. Some common issues are size, cost, and schedule.

5. Translate ach measurement issue into precise, quantifiable, and unambiguous measurement goals. These goals may involve measurement to help individuals understand an issue (i.e., to evaluate, perfect, or monitor) or to address a need for improvement (i.e., to increase, reduce, achieve, or stabilize).

Define Procedures

The complete set of identified measures is obtained from the Identify Scope Activity. Once measures have been identified, operational definitions and procedures of the measurement process should be constructed and documented. The tasks for the Define Procedures Activity include:

- Define each of the identified measures completely, consistently, and operationally;

- Define the collection methods, including how the data are to be recorded and stored; and

- Define the analysis techniques to be used to determine status relative to the identified measurement goals. These analysis techniques will most likely evolve and expand through ach reporting cycle as the user gains more insight into the data.

The procedures documented during this activity should be reviewed and revised if necessary during each reporting cycle.

Execution of the Identify Scope and Define Procedures Activities should result in a documented, operational plan and procedures for measurement. The plan should identify the scope and purpose of the measurement effort, together with the roles, responsibilities, resources, and schedules for the measurement process.

Implementing the Measurement Process

The activities that are the focus of implementing the measurement process are

1. Collect Data
2. Analyze data

Collect Data

This activity implements the collection procedures, defined in the Define Procedures Activity. Using the operational definition of the measurement procedures, data are collected, recorded, and stored. In addition, the data are validated and the procedures are reviewed for adequacy.

Analyze Data

After implementing the collection procedures, the process continues with the Analyze Data Activity. This activity consists of analyzing the data to prepare the reports, presenting the reports to the audience, and reviewing procedures for accuracy and adequacy. The procedures may need to be updated if the report is not providing insight into the issues, or the report is not understood. In either case, feedback is collected to update the measurement procedures to analyze data.

Evolve the Process

On a continuous basis monitor the effectiveness of the measurement process by obtaining fed backs. This may raise additional issues, or indicate that certain data are no longer available. This feedback, in addition to the feedback from the other activities, is addressed during the review of the measurement process and used to re-identifying and redefining the measurement process.


Good automation is essential to minimizing the cost of measurements. With good automation, the actual cost of data collection can be reduced to a few minutes a day and simple measurement errors virtually eliminated. However, automation is even more important for data analysis than for data recording. Manual systems tend to produce “write-only” data repositories. Information must be accessible in real time. Basic analysis must be available at the click of a button. Any system that requires manual data aggregation and analysis is going to b defect-prone, costly, and underutilized.

Process Measurement

A process can be measured by Attributes of the process, such as overall development time, type of methodology used, or the average level of experience of the development staff.

Accumulating product measures into a metric so that meaningful information about the process can be provided. For example, function points per person month or LOC per person month can measure productivity (which is product per resources), the number of failures per month can indicate the effectiveness of computer operations, and the number of help desk calls per LOC can indicate the effectiveness of a system design methodology.

There is no standardized list of software process metrics currently available. However, in addition to the ones listed above, some others to consider include;

- Number of deliverables completed on time
- Estimated costs vs. actual costs
- Budgeted costs vs. actual costs
- Time spent fixing errors
- Wait time
- Number of contract modifications
- Number of proposals submitted vs. proposals won
- Percentage of time spent performing value- added tasks

Product Measurement

A product can be measured at any stage of its development. For a software product, the requirements, the complexity of the software design, the size of the final program’s source or object code, or the number of pages of documentation produced for the installed system can be measured.

Most of the initial work in measuring products has dealt with the characteristics of source code. The experience with measurements and models shows that measurement information available earlier in the development cycle can be of greater value in controlling the process and results. Thus, a number of papers have dealt with the size or complexity of the software design.

The following examples show various ways of measuring a product. These were chosen because of their wide use or because they represent a particularly interesting point of view.


LOC is the most common way of quantifying software size; however, this cannot be done until the coding process is complete. Function points have the advantage of being measurable during the design phase of the development process or possibly earlier.

Lines of code

This is probably the most widely used measure for program size, although there are many different definitions. The differences involve treatment of blank lines, comment lines, non-executable statements, multiple statements per line, multiple lines per statement, and the question of how to count reused lines of code. The most common definition counts any line that is not a blank or a comment, regardless of the number of statements per line. In theory, LOC is a useful predicator of program complexity, total development effort, and programmer performance (debugging, productivity). Numerous studies have attempted to validate these relationships.

Function Points

A.J. Albrecht proposed a metric for software size and the effort required for development that can be determined early in the development process. This approach computes the total function points (FP) value for the project, by totaling the number of external user inputs, inquiries, outputs, and master files, and then applying the following weights:

• Inputs (4),
• Outputs (5),
• Inquiries (4), and
• Master Files (10).

Each FP contributor can be adjusted within a range of +- 35% for a specific project complexity.


More merits have been proposed for measuring program complexity than for any other program characteristic. Two examples of complexity metrics are:

Cyclomatic Complexity------V(G)

Given any computer program, draw its control flow graph, G, where each node corresponds to a block of sequential cod and each edge corresponds to a branch or decision point in the program. The cyclomatic complexity of such a graph can be computed by a simple formula from graph theory, as v(G) = -n+2, where e is the number of edges, and n is the number of nodes in the graph.


Calculate program knots by drawing the program control flow graph with a nod for very statement or block of sequential statements. A knot is defined as a necessary crossing of directional lines in the graph. The same phenomenon can be observed by drawing transfer- of- control lines from statement to statement in a program listing.


There is a long list of quality characteristics for software, such as correctness, efficiency, portability, performance, maintainability, and reliability. While software quality can theoretically be measured at every phase of the software development cycle, the characteristics often overlap and conflict with one another. For example, increased performance or speed of processing (desirable) may result in lowered efficiency (undesirable). Since useful definitions are difficult to devise, most efforts to find any single way to measure overall software quality have been less than successful.

Although much work has been done in this area, there is still less direction or definition than for measuring software size or complexity. There areas that have received considerable attention are program correctness, as measured by defect counts; software reliability, as computed from defect data; and software maintainability, as measured by various other metrics, including complexity metrics.


The number of defects in a software product should be readily drivable from the product itself. However, since there is no easy and effective procedure to count the number of defects in the program, the four alternative measures listed below have proposed. These alternative measures depend on both the program and the outcome, or result, of some phase of the development cycle.

Number of design changes
Number of errors detected by code inspections
Number of errors detected in program tests
Number of cod changes required


It would be useful to know the probability of a software failure, or the rate at which software product, it can only be estimated from data collected on software defects as a function of time. If certain assumptions are made, this data can be used to model and compare software reliability metrics. These metrics attempt to indicate and predict the probability of failure during a particular time interval or the mean time to failure {MTTF) and man time between failure (MTBF).


Efforts have been made to define ways to measure or predict the maintainability of a software product. An early study by Bill Curtis, and others, investigated the ability of Halstead’s effort metric, E, and v(G) to predict the psychological complexity of software maintenance tasks. Assuming such predictions could be mad accurately, complexity metrics could then be profitably used to reduce the cost of software maintenance. A carefully detailed experiment indicated that software complexity metrics could effectively explain or predict the maintainability of software in a distributed computer system.

Customer Perception of product Quality

Determining the customer’s perception of quality involves measuring how the customer views the quality of the It product. It can be measured in a number of ways, such as using customer survey, service level agreements, loyalty, and recommendations to others.


With measurement used consistently on projects, managers can aggregate data across projects. This can be used to help senior management 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.
Copyright © 2014         Home | Contact | Projects | Jobs

Review Questions
  • 1. Explain in detail about Measurement System Planning?
  • 2. Explain the measurement approach in detail?
  • 3. When we will use Goal oriented measurements?
  • 4. Explain the measurement process with a neat diagram?
  • 5. How will you implement the measurement process?
  • 6. Explain briefly about process measurement and product measurement?
Copyright © 2014         Home | Contact | Projects | Jobs

Related Topics
Software Measurement and Measurement Analysis Keywords
  • Software Measurement and Measurement Analysis Notes

  • Software Measurement and Measurement Analysis Programs

  • Software Measurement and Measurement Analysis Syllabus

  • Software Measurement and Measurement Analysis Sample Questions

  • Software Measurement and Measurement Analysis Subjects

  • Software Measurement and Measurement Analysis Syllabus

  • EMBA Software Measurement and Measurement Analysis Subjects

  • Software Measurement and Measurement Analysis Study Material

  • BBA Software Measurement and Measurement Analysis Study Material