Download Software Process And Project Metrics-Methods Of Software Engineering-Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!
Score As:
0 None of the above. 1 Any one of the above. 2 Any two of the above. 3 Any three of the above. 4 Any four of the above. 5 All five of the above.
Adjusted FP Count
Each of these factors is scored based between 0-5 on their influence on the system being counted. The resulting score will increase or decrease the Unadjusted Function Point count by 35%. This calculation provides us with the Adjusted Function Point count.
Degree of Influence (DI) = sum of scores of 14 general system characteristics
Value Adjustment Factor (VAF) = 0.65 + DI / 100 The final Function Point Count is obtained by multiplying the VAF times the Unadjusted Function Point (UFP).
FP = UFP * VAF
Lecture No. 12
Software Process and Project Metrics
Everyone asks this question: how do I identify the problem? The answer is measure your process. Measurement helps in identification of the problem as well as in determining the effectiveness of the remedy.
Measurement is fundamental for providing mechanisms for objective evaluation of any process or activity. According to Lord Kelvin:
When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of a science.
In order to understand what your problems are, you need to measure. Only then a remedy can be applied. Take the example of a doctor. He measures and monitors different types of readings from a patient (temperature, heart beat, blood pressure, blood chemistry, etc) before proposing a medicine. After giving the medicine, the doctor monitors the effect of the medicine through the follow-up visits and makes the necessary adjustments. This process of measurement, correction and feedback is inherent in all kinds of systems. Software is no exception!
The idea is to measure your product and process to improve it continuously. Now the question is: how can we measure the quality of a software process and system?
Software project management primarily deals with metrics related to productivity and quality. For planning and estimation purposes, we look at the historic data – productivity of our team and the quality of their deliverables in the past projects. This data from the previous efforts is used to determine and estimate the effort required in our current project to deliver a product with a predictable quality. This data is also used to analyze the system bottlenecks and helps us in improving the productivity of our team and the quality of our product.
Measures, Metrics and Indicators
Before we can talk about the measurement process, we first need to understand the terms measure, metrics, and indicators. The terms measure, measurement, and metrics are often used interchangeable but there are significant differences among them. Within the software engineering domain, a measure provides a quantitative value of some attribute of a process or a product. For example, size is one measure of a software product. Measurement is the process or mechanism through which the measure is taken. For example, FP analysis is a mechanism to measure the size of software. Measurement involves taking one or more data points related to some aspect of the product or process. Software metric relates individual software measures to provide a normalized view. For example, defects per function point are one metric which relates two individual measures, that is, defects and size, into one metric.
Lecture No. 13
Software Quality Factors
In 1978, McCall identified factors that could be used to develop metrics for the software quality. These factors try to assess the inner quality of software from factors that can be observed from outside. The basic idea is that the quality of the software can be inferred if we measure certain attributes once the product is put to actual use. Once completed and implemented, it goes through three phases: operation (when it is used), during revisions (when it goes through changes), and during transitions (when it is ported to different environments and platforms).
During each one of these phases, different types of data can be collected to measure the quality of the product. McCall‘s model is depicted and explained as follows.
Factors related with operation
- Correctness
- The extent to which a program satisfies its specifications and fulfills the customer‘s mission objectives
- Reliability
- The extent to which a program can be expected to perform its intended function with required precision.
- Efficiency
- The amount of computing resources required by a program to perform its function
- Integrity
- Extent to which access to software or data by unauthorized persons can be controlled.
- Usability
- Effort required to learn, operate, prepare input, and interpret output of a program
Factors related with revision
- Maintainability
- Effort required to locate and fix an error in a program
- Flexibility
- Effort required to modify an operational program
- Testability
- Effort required to test a program to ensure that it performs its intended function
Factors related with adaptation
- Portability
- Effort required transferring the program from one hardware and/or software system environment to another.
- Reusability
- Extent to which a program can be reused in other applications
- Interoperability
- Effort required to couple one system to another.
It is interesting to note that the field of computing and its theoretical have gone through phenomenal changes but McCall‘s quality factors are still as relevant as they were almost 25 years ago.
Measuring Quality
Gilb extends McCall‘s idea and proposes that the quality can be measured if we measure the correctness, maintainability, integrity, and usability of the product.
Correctness is defined as the degree to which software performs its function. It can be measured in defects/KLOC or defects/FP where defects are defined as verified lack of conformance to requirements. These are the problems reported by the user after release. These are counted over a standard period of time which is typically during the first year of operation.
Maintainability is defined as the ease with which a program can be corrected if an error is encountered, adapted if environment changes, enhanced if the customer requires an enhancement in functionality. It is an indirect measure of the quality. A simple time oriented metric to gauge the maintainability is known as MMTC – mean time to change. It is defined as the time it takes to analyze the change request, design an appropriate modification, implement the change, test it, and implement it.
A cost oriented metric used to assess maintainability is called Spoilage. It is defined as the cost to correct defects encountered after the software has been released to the users. Spoilage cost is plotted against the overall project cost as a function of time to determine
In this research, they tried to measure the effectiveness of 4 different activities namely design inspection, code inspection, quality assurance function, and testing. It is important to note that testing alone only yields a DRE of 40% on the average. However, when it is combined with design and code inspection, the DRE reaches 97%. That means, code and design inspection are extremely important activates that are unfortunately not given their due importance.
Lecture No. 14
Metrics for specification quality
As mentioned earlier, the quality of the software specification is of extreme importance as the entire building of software is built on this foundation. A requirement specification document is measured in terms of lack of ambiguity, completeness, consistency, correctness; understand ability, verifiability, achievability, concision, traceability, modifiability, precision, and reusability.
Metrics to assess the quality of the analysis models and the corresponding software specification were proposed by Davis in 1993 for these seemingly qualitative characteristics.
For example, the numbers of requirements are calculated as:
nr = nf + nnf
where nr – total number of requirements nf – functional requirements nnf – non-functional requirements
Now lack of ambiguity in the requirements is calculated as:
Q 1 = nui/nr
Where nui – number of requirements for which all reviewers had identical interpretation (i.e. unambiguous requirements)
Similarly, completeness is measures as follows:
Q 2 = nu/ [ni x ns]
nu – unique functional requirements ni – number of inputs (stimuli) ns – number of states specified
On the similar lines, the quality of design is also measured quantitatively. The quality of the architectural design can be measured by measuring its complexity as shown below:
- Structural complexity S = (fout)^2
- Data complexity D = v/(fout + 1)
- ‗v‘ is the number of input and output variables
- System complexity C = ∑ (Si + Di)
Project Size (FP)
Effort (Pm)
Cost Rs. (000)
Pages of documentation
Pre- shipment errors
Post- shipment defects
People
abc 120 24 168000 365 134 29 3
def 270 62 440000 1224 321 86 5
ghi 200 43 314000 1050 256 64 6
This data is then normalized on per function point basis as follows:
Project Size (FP)
Effort (Pm)
Cost Rs. (000)
Pages of documentation
Pre- shipment errors
Post- shipment defects
People
abc 120 0.2 1400 3.04 1.12 0.
def 270 0.23 1629 4.53 1.19 0.
ghi 200 0.22 1570 5.25 1.28 0.
We are now ready to use this data to analyze the results of process changes and their impact on the time to implement change requests.
