Software Metrics For Process And Projects Information Technology Essay
Software Process and Project Metrics are Quantitative measures that enable Software People to gain insight into the efficacy of the Software Process and the Project that are conducted using the Process as a framework.
Basic ”Quality and Productivity Data” are collected. These data are then analyzed, compared against past Averages and assessed to determine whether quality and productivity improvements have accrued.
Metrics are also used to pinpoint problem areas so that remedies can be developed and Software Process can be improved.
WHO DOES IT ?
Software Measures are often collected by Software Engineers/ Practitioner. Software Metrics are analyzed and assesses by Software Managers.
WHY METRICS IS IMPORTANT?
If you do not measure your judgment can be based only on subjective evaluations.
With measurement, trends (either good or bed) can be spotted, better estimates can be made, and true improvement can be accomplished over time.
WHAT ARE THE STEPS?
Begin by defining a limited set of Process and Project measures that are easy to collect.
(These measures are often normalized using either Size or Function-oriented metrics.)
The result is analyzed and compared to ”Past Average” for similar Project performed within the organization.
Trends are assessed and conclusions are generated.
WHAT IS WORK PRODUCT?
A set of Software Metrics that provide insight into the Process and understanding of the Project.
Within the Context of Software Engineering we are concerned with :-
Productivity metrics
Quality metrics
For Project planning and Estimating purpose our interest is historical.
What was software development productivity on past products?
What was the quality of software produced?
How can past productivity and quality data be extra polated to the present?
How can it help us plan estimate more accurately?
WHAT ARE THE REASONS FOR MEASURING ?
There are four reasons for Measuring Software Process, Product and resources:-
TO CHARACTERIZE
TO EVALUATE
TO PREDICT
TO IMPROVE
To Characterize to gain understanding of Processes, Products, Resources and Environments and to establish Baselines for comparisons with future assessments.
.
To Evaluate to determine the status with respect to Plans.
To Predict by gaining understandings of relationships among Processes and Products and building models of these relationships.
To Improve by identifying roadblocks, root causes, inefficiencies, and other opportunities for improving Product Quality and Process performance.
Measurement is a Management tool. If conducted properly, it provides a Project Manager with insight. And as a result, it assists the Project Manger and the Software Team in making decisions that will lead to a successful Project.
Project Metrics are collected across all Projects and over long periods of time. Their intent is to provide a set of Process Indicators that leads to long-term Software Process improvements
Project Metrics enable a Software Project Manager to :-
Assess the status of an ongoing Project
Track potential Risks
Uncover Problem areas before they “Go critical”
Adjust work flow or Tasks Software work Products.
Evaluate the Project Team’s ability to Control Quality of Software Work Product.
Measures that are collected by Project Team and converted into Metrics for use during a Project can be transmitted to those with responsibility for Software Process improvement. For this reason, many of the same Metrics are used in both the Process and Project domain.
PROCESS METRICS AND SOFTWARE PROCESS IMPROVEMENT
The only rational way to improve any Process is to:-
– Measure specific attributes of the Process,
– Develop a set of meaningful metrics based-on these attributes
– Use the metrics to provide indicators that will lead to strategy for improvement.
It is important to note that Software Process is only one of a number ”Controllable Factors” in improving Software Quality and Organizational performance.
PROCESS
BUSINES CONDITIONS
CUSTOMER CHARACTERISTICS
DEVELOPMENT ENVIRONMENT
PEOPLE
TECHNOLOGY
PRODUCT
Fig. DETERMINANT FOR SOFTWARE QUALITY AND ORGANIZATIONAL EFFECTIVNESS
Process is in the center of triangle connecting there factors that have a profound influence on Software quality and Organizational performance.
The Shill and Motivation of people has been shown as the single most influential factor in quality and performance. The Skill and Motivation of People has been shown to be single most influential factors in Quality and Performance.
The Complexity of product can have substantial impact on Quality and Team Performance.
The Technology that populates the Process also has an impact.
The Process Triangle exists whether a circle of environmental conditions that includes the Development Environment (CASE Tools), Business conditions and Customer characteristics.
We measure the efficacy of Software Process indirectly. That is we derive a set of Metrics based on the outcome that can be derived from the Process.
Outcomes include Measures of:-
– Errors uncovered before release of Software,
– Defects delivered to and reported by end-users,
– Work products delivered (Productivity),
– Human effort expanded,
– Calendar time expanded,
– Schedule conformance
– Other measures.
We also derive Process Metrics by Measuring the Characteristics of Specific Software Engineering tasks. (e.g.We might measure the ”Effort” and they spent performing the Generic Software Engineering Activities.)
There are “Private and Public” uses for different types of Process data. Because it is natural that Individual Software Engineers might be sensitive to the use of metrics collected on an individual basis, these data should be Private to the individual and serve as an indicator for the individual only.
(eg. Defect Rates by individuals, Defect Rates by Software component and errors found during Development)
Some Process Metrics are private to the Software Project Team but Public to all Team members.
(eg. Defects reporting for major software functions, Errors found during formal technical reviews
and Lines of Code (LOC) or Function Points (FP) per components or function.
These data are reviewed by the Team to uncover indicators that can improve Team performance.
Public Metrics generally assimilate Information on that originally was private to individuals and teams. Project level Defect Rates, Effort, Calendar Times and related data are collected and evaluated in an attempt to uncover indicators that can improve organizational Process Performance.
BENEFITS OF PROCESS METRICS
Software Process Metrics can provide significant benefit as an Organizational work to improve its overall level of Process Maturity. However, like all Metrics these can be misused, creating more problems then they solve.
SOFTWARE METRICS ETIQUETTE (Suggested by Grady)
Use common sense and organizational sensitivity, where interpreting metrics.
Provide regular feedback to the individual and teams who collect measures and metrics.
Do not use metrics to appraise individual.
Work unit partitions and teams to set clear goal and metrics that will be used to achieve them.
Never use metrics to threaten individual on team.
Do not consider metrics data indicating a problem area as negative. Consider it as and indicator for
process improvement.
Don’t obsess on a single metrics to the exclusion of other important metrics.
As an organization become more comfortable with the collection and use of Process Metrics, the derivation of simple indicators give way to a more rigorous approach called “STATISTICAL SOFTWARE PROCESS IMPROVEMENT” (SSPI). .
SSPI in essence, uses Software Failure Analyses to collect information about the Errors and Defects encountered as an Application System or Product is developed and used..
PROJECT METRICS
Unlike Software Process Metrics that are used for Strategic purpose, Software Project Metrics are used for Tactical purpose.
Project Metrics and the ‘Indicators’ derived from them are used by a Project Manger and Software Team to adopt workflow and Technical Activities.
APPLICATION OF PROJECT METRICS
The first application of Project Metrics occurs during ”Project Estimation”.
Metrics collected from the past Projects are used as a basis from which
”Effort and Time Estimates” are made for current Software work.
As a Project proceeds, Measures of Effort and Calendar Time expended ( Actual Times) are compared to Original Estimates. The Project Manager uses these data to Monitor and Control Progress.
As technical work commences other Project Metrics rates begin to have significance.
Such rates include:
– Production Rates (represented in terms of Models created),
– Review Hours,
– Function Points
– Delivered Line of Source Codes (LOC)
Also ”Errors uncovered during each Software Engineering tasks” are tracked.
As the Software evolves from Requirements into Design, Technical Metrics are collected to assess Design Quality and to provide indicators that influence the approach taken to
Code Generation and Testing.
THE PURPOSES OF PROJECT METRICS –
Project metrics are used to Minimize the Project Development Schedule by making the necessary adjustments to avoid delays and mitigate potential problems and risks.
b) Project Metrics are used to Asses Product Quality on an ongoing basis and, when necessary,
modify the technical approach to improve Quality.
As quality improves the Defects are minimized and as the Defect counts goes down, the amount of rework is also reduced. This leads to a reduction in overall Project Costs.
SOFTWARE MEASUREMENT
Direct Measurement
Indirect Measurement
DIRECT MEASUREMENT ( For Process and Product )
Process Measurements include:
– Cost and Effort applied.
Product Measurements include:
– Lines of Code (LOC) Produced,
– Execution Speed
– Memory size
– Defect reported over a set period of time.
INDIRECT MEASUREMENT (For Product)
– Functionality
– Quality
– Complexity
– Efficiency
– Reliability
– Maintainability
etc.
Direct Measurements such as Cost, Efforts, LOC are easy to collect as long as specific conventions of Measurements are established in advance.
Indirect Measurements such as:- Quality and Functionality of Software or Software Efficiency or Maintainability are more difficult to asses and can be measured only indirectly.
——————————————————————–
DERIVE ORGANIZATIONAL AVERAGES FROM METRICS
Product Metrics are Private to an individual and are often combined to develop Project Metrics that are Public to Software team.
Project Metrics are then consolidated to create Process Metrics that are Public to the Software organization as a whole. To be able to do that we should ”Normalize the Measurement”, so that we create a Measurements to enable us to compare ”Organizational Average”.
Both Size and Functional-oriented Metrics are Normalized in this manner.
SOFTWARE METRICS
1. SIZE-ORIENTED METRICS
After Release
Before ReleaseSize Oriented Metrics are derived by normalizing Quality and/or Productivity Measures by considering the Size of the Software that has been produced.
METRICS TABLE
Project
LOC
Effort man/month
Cost $(000)
DP DOC (pages)
Errors
Defects
People
A
12,100
24
168
365
134
29
3
B
27,200
62
440
1224
321
86
5
C
20,200
43
314
1050
256
64
6
The table lists 3 Software Development Projects namely Project A, B and C that have been completed over the past few years and corresponding Measures for each Projects.
For Project A: 12,100 Lines of Code were developed with 24 Person-month of Effort at a
Cost of $168,000. (It should be noted that Effort and cost includes Analysis,
Design, Code and Testing of Software)
– 365 Pages of Documentation has been produced.
– 134 Errors were recorded before the Software was released.
– 29 Defects were encountered after the release of Software to Customer
within the first year of operation.
– 3 People worked on the Development of Project A.
In order to Develop Metrics that can be assimilated with similar Metrics from other Projects. In this case we chose Lines Of Code (LOC) as Normalization Value.
From the rudimentary Data contained in the above Metrics table, a set of simple Size-Oriented Metrics can be developed for each Project.
SIZE-ORIENTED METRICS
– Errors / KLOC
– Defect / KLOC
– $ / KLOC
– Page of Document / KLOC
Note: KLOC (Thousand of Lines of Code)
other interesting Metrics can be computed such as:-
– Errors / Person-Month
– LOC / Person-Month
– $ / Pages of Documentation
WHY SIZE-ORIENTED METRICS ARE NOT UNIVERSALLY ACCEPTED?
Size Oriented Metrics are not universally accepted as the best way to measure the Process of Software Development. The Proponent (Supporters) and the Opponent arguments about the Size Oriented Metrics are as follows:-
PROPONENTS
Proponents argue that LOC is an “Artifact” of software development projects. That can be easily counted, that many existing software estimation model use LOC or KLOC as the input and that a large body of literature and data predicted on LOC already exists.
OPPONENTS
Opponents argues that most of the controverts swirls around the use of LOC as the
key measure.
According to this argument LOC measures are Programming Language dependent, that when Productivity is considered, they penalize well designed but shorter Programs, that they can not easily accommodate Non-procedural Languages, and that their use in Project Estimation require a level of detail that may be difficult to achieve. (i.e. The Planner must estimate the LOC to be produced long before the Analysis and Design have been completed. )
2. FUNCTION-ORIENTED SOFTWARE MERTICS
Function-Oriented Software Metrics use Measure of Functionality delivered by the Software Application as a Normalization value.
The most widely used Function-oriented Metrics is FUNCTION POINT (FP)
Computation of Function Point is based on characteristic of the Software’s Information Domain and complexity.
The Function Point Measure is also controversial like LOC Measures. The Arguments of Proponents and Opponents are as follows:
PROPONENTS Claim that Function Point (FP) is Programming Language independent, making it ideal for applications using Procedural (conventional) and non-procedural Programming Languages, and that it is based on data that are more likely to be known early in the evolution of a project, making FP more attractive as an estimation approach.
OPPONENTS claim that the method requires some ”sleight of hand” in that computation is based on subjective rather than objective data, that counts of the information domain can be difficult to collect after the fact, and that FP has no direct physical meaning – It’s just a number.
Function Points (FP) are derived using an Empirical Relationship based on countable measures (Direct measures) of Software’s Information Domain and assessments of Software Complexity.
Function Points (FP) are computed by completing ”Five Information Domain Characteristics” that are determined and Counts are placed in the table.
THE FIVE INFORMATION DOMAINS
1. Number of Inputs
Each User Input that provides distinct application oriented data to the software is counted.
Inputs should be distinguished from what from Enquires. Enquires is counted separately).
2. No. of User Outputs
Output refers to Reports, Screens, Error messages etc.(individual data items within a report is not
counted separately).
3. No. of User Enquires
Usually each enquires (on line) generate On-line Output.
4. No. of Files
Each ”Logical” Master file (Logical grouping of part of large database on a separate file is
counted).
5. No. of External Interfaces
All machine readable Interface (i.e Data, file or storage media) that are used to transmit
Information to another Systems are counted.
FUNCTION- POINT TABLE
Function Points (FP)
Weighting Factor
Measurement Parameters
Count
Simple
AVG
Complex
TOTAL
FP
1
No. of User Input
8
X
3
4
6
=
32
2
No. of User Output
X
4
5
7
=
3
No. of User Enquires
X
3
4
6
=
4
No. of Files
X
7
10
15
=
5
No. of External Interfaces
X
5
7
10
=
∑ COUNT TOTAL
COMPLEXITY FACTOR
Organizations that use FP Method develop criteria for determining whether a particular entry is Simple, Average or Complex. Nevertheless the determination of complexity is subjective. A Complexity Value is associated with each Count..
To compute the Function Points (FP) the following relationship is used:-
FP = COUNT TOTAL * [0.65 + 0.01 * ∑ ( Fi )]
Complexity Adjustment Factor
Where:-
The Count Total is the sum of (FP) entries in the table
The (Fi) is Complexity Weighting Value, based on responses to the followings assumptions:-.
Each of these answers is assigned a complexity Value on a scale of (0 to 5).
COMPLEXITY FACTOR ASSUMPTIONS (Based on the answers to the following 14 questions)
FACTOR VALUE (Fi).
1. Back-up and Recovery ? 4
2. Data Communication ? 2
3. Distributed Processing ? 0
4. Performance Critical ? 4
5. Existing Operational Environment ? 3
6. On-line Data Entry ? 4
7. Input transactions over multiple Screens? 5
8. Online Updates ? 3
9. Information Domain Values Complex ? 5
10. Internal Processing Complex? 5
11 Code Designed for reuse? 4
12. Conversion / installation in Design? 3
13. Multiple Installations? 5
14. Application Designed for change ? 5
===========================================
∑ (Fi)
Once Function Points (FP) have been calculated they are used in a manner corresponding (analogous) to LOC as a way to Normalize Measures for Software Productivity, Quality and other attributes:
FUNCTION-ORIENTED METRICS
ERROR / FP
DEFECTS / FP
$ / FP
PAGES / FP
FP / PERSON MONTHLY
RECONCILING LOC and FP METRICS
The relationship between LINES OF CODE and FUNCTION POINTS depends on Programming language that is used to implemented the software and the Quality of the design.
For example rough estimates of Average Number of LOC required to build one FP in various Programming Languages areas follows :
Programming Language LOC/FP AVERAGE
C 128
C++ 64
VISUAL BASIC 32
SQL 12
As you can see Visual Basic provides 4 times the functionality of a LOC for P/L C.
LOC and FP measure are often used to derive Productivity Metrics.
However it is debatable to appraise the Performance of individual by using these metrics, since many factors influence Productivity.
FP and LOC based Metrics have been found to be relatively accurate Predictors (Estimates) of Software Development Effort and Cost.. In order to use LOC and FP for Estimation, a historical baseline of information must be established.
3. OBJECT-ORIENTED PROJECT METRICS
Conventional Software Project Metrics such as LOC and FP Metrics can be used to estimate Object-
Oriented Software Projects. However, these Metrics do not provide enough granularities for the
Project Schedule and Effort Adjustments that are required as we iterate through Evolutionary or
Incremental Process Method. (Incremental Development Methodology).
The following set of Metrics are suggested for Object-Oriented Projects :-
No. Of Scenario Scripts
No. Of Key Classes
No. of Support Classes
Average No. Of Support Class / Key Class
No. Of Sub-systems
NO. OF SCENARIO SCRIPTS
The Number of Scenario Scripts is directly correlated to the Size of the Application Software and to the number of Test Cases that must be developed to exercise the System once it is constructed.
NO. OF KEY CLASSES
Since Key Classes are central to the problem domain, the Number of such Classes is an indication of the amount of Effort required to develop the Software and also an indication of the potential amount of Reuse to be applied during System development.
NO. OF SUPPORT CLASSES
Support Classes are required to implement the System but are not immediately related to the problem domain. (e.g. User Interface Classes, Database Access and Manipulation classes). Also Support Classes can be prepared for each Key Class. No. of Support Classes is also an indicator of the amount of Effort required to develop the Software and Indication of Reuse to be applied during System Development.
AVERAGE NO. OF SUPPORT CLASSES PER KEY CLASS
In Graphical User Interface (GUI) Applications the Average number of Support Class per Key Class Ratio is 2 or 3 class (i.e. For 1 Key class 2 or 3 Support Class will be developed.) For non-GUI Application the ratio is 1 or 2 .
NO. OF SUB-SYSTEMS
A sub System is an aggregation of Classes that support a Function that is visible to the end-User. Once Sub-systems are identified it is easier to lay out a reasonable Project Schedule in which the work will be partitioned among Project development staff.
To be used effectively in an Object-Oriented Software Engineering Environment, metrics similar to those noted above must be collected along with the Project Measurers such as:
Effort Expanded
Errors and Defects uncovered
Models or Document Pages produced.
As the Database grow (after a few Object-oriented Project completed) relationships between O-O
Measures and Project Measures will provide Metrics that can aid in Project Estimation.
4. USE-CASE ORIENTED METRICS
It is reasonable to apply the Use-Case as a Normalization Measurers similar to LOC or FP.
Like FP the Use-Case is defined early in the Software Process allowing it to be used for Project
Estimation before significant Modeling and Construction activities are initiated.
The Use-case is also independent of Programming Languages. Moreover, the Number of Use-
case is directly proportional to the Size of the Application in LOC and the number of Test Cases
that will have to be designed to fully exercise the Application.
Because Use-case can be created at many different levels of abstraction, there is no standard Size
for a Use-case. Without a Standard Measure of what a Use-case is, its application as a
Normalization measure (e.g. Effort expanded per Use-case) is suspect.
Although a number of researchers have attempted to derive Use-case Metrics, much work remains
to be done.
WEB ENGINEERING PROJECT METRICS
The Objectives of all Web Engineering Projects is to build a Web Application (WebApp) that delivers a combination of Content and Functionality to the End-users.
Measures and Metrics used for Traditional Software Engineering Project are difficult to translate directly to Web-Apps. Yet a Web Engineering organization will have to collect Measurers and build a Database that allow it to assess its internal Productivity and Quality over a number of Projects. Among the Measurers that can be collected are:-
No. of Static Web Pages
No. of Dynamic Web Pages
No. of Internal Page Links
No. of External System interfaces
No. of Persistent Data Objects
No. of Static Content Objects
No. of Dynamic Content Objects
No. of Executable Functions
NO. OF STATIC WEB PAGES
Web Pages with Static content are the most common of all Web Applications. These Pages represent ”Low relative complexity” and generally require less effort to construct than Dynamic pages.
This measure provide the overall Size of the Application and the Effort required to develop it.
NO. OF DYNAMIC PAGES
Are essential for e-commerce Applications an Search Engines, Financial Applications and may other
WebApps. These pages represents ”Higher relative Complexity” and thus require more Effort to
construct than Static pages.
This measure also provide the overall Size of the Application and the Effort required to develop it.
NO. OF INTERNAL PAGE LINKS
Are Pointers that provide a Hyperlink to some other Web pages within the WebApp. This measure provides an indication of the degree of Architectural coupling within the WebApp. As the Link pages increases, the Effort expended on designing and constructing Navigations.
NO. OF EXTERNAL SYSTEMS INTERFACED
WebApps must often interface with ”Backroom Business Applications”. As the requirements for External interfacing grow, System complexity and development effort increases.
NO. OF PERSISTENT DATA OBJECTS
One or more Database files may be accessed by a WebApp. As the number of required files grow, the complexity of WebApp also grow and Effort to Implement it increases proportionally.
NO. OF STATIC CONTENT OBJECTS
A Static content objects may contain text, graphic, video, animation and audio information. A Multiple content Objects may appear on a single Web Page increasing the complexity.
NO. OF DYNAMIC CONTENT OBJECTS
Dynamic Content Object are generated based on User actions and encompasses internally generated text, graphic, video, animation and audio information that are incorporated within WebApp. Multiple content Objects may appear on a single Web Page.
NO. OF EXECUTABLE FUNCTIONS
An Executable function (also called Script or Applet) provides some conceptual service to the end-user. As the number of Functions increases, Modeling and construction Effort also increases.
Each of the above Measures can be determined at a relatively early stage of the Web Engineering Process.Web Application Metrics can be computed and correlated with Project Measures such as :-
Effort Expanded
Errors and Defects uncovered
Models or Document Pages produced.
WebApp Measures and Project Measures provide Metrics that can aid in Project Estimation.
METRICS FOR SOFTWARE QUALITY
The overriding goal of Software Engineering is to produce a High-quality Application System or Product within a ”Timeframe that satisfy a market need.
To achieve this goal, Software Engineer must apply effective Methods coupled with modern tools within the context of a mature Software Process. In addition a good Software Engineer must measure if high quality is to be realized.
Private Metrics collected by individual Software Engineers are assimilated to provide Project- Level results.
Although many Quality Measures can be collected primary thrust at the Project -level is to measure ”Errors and Defects”.
Metrics derived from Errors and defects provide an indication of the
effectiveness of individual and group Software Quality assurance and Control activities.
The following Metrics provide insight into the efficacy of each of the activities implied by the Metrics.
– Work Product Errors Per FP (Function Point)
Errors uncovered per review hours
Errors uncovered per Testing hour
Error data can also be used to compute the ”Defect Removal Efficiency” for each Process Framework activity.
MEASURING QUALITY
Although there are many Measures of Software Quality the following Four measures provide useful indicators for the Project team.
Software Correctness
Software Maintainability
Software Integrity
Software Usability
CORRECTNESS
A program must operate correctly or it provides little value to its Users. Correctness is the degree to which the software programs its required function.
Most common measures for Correctness is Defects / KLOC, where a Defect is defined as a verified lack of conformance to requirements. Defects are these problems that are reported by users after the program has been released for general use.
For quality assessments, defects are counted over a standard period of time, typically for one year.
MAINTAINABILITY
Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if its environments changes, or enhanced if the customer desires a change in requirements. There is no way to measure Maintainability directly so we must use
indirect measurements.
A simple Time-Oriented Metric is MTTC (Mean Time To Change).The time it takes to Analyze the change required, Design the appropriate modification, Test it, Implement the change, and distribute the Change to all Users.
On average, Programs that are maintainable will have a lower MTTC than the Programs that are not Maintainable.
INTEGRITY
Integrity has become extremely important in the age of ”Hackers and Firewalls”. This attribute measures System ability to withstand attacks (both accidental and intentional) to its security. Attacks can be made on all three components a Software i.e. Programs, Data and Documents.
To measure Integrity two other attributes need to be defined.
THREAT Probability
SECURITY Probability
– Threat is Probability that an attack of a specific type will occur within a given time
– SECURITY is the probability that the attack of a specific type will be repelled.
The Integrity of a System can be defined as.
INTEGRITY = ∑ [(1 – (THREAT) * (1 – (SECURITY))]
Where Threat and Security are summed Over each type of attack.
Example:- If Threat probability is 0.25 and Security (Likelehood of repelling an attack) is
0.95, the integrity of System is 0.99. Which is Very High.
If Threat is 0.50 and the Security is 0.25 then the System’s Integrity is 0.63
which is unacceptably low.
USABILITY
Usability is an attempt to quantify User-friendliness and can be measured in terms of team of four characteristics.
USABILITY CHARACTERISTICS
The physical and / or intellectual skill required to learn the system.
The time required to become moderately efficient in the use of the system.
The net increase in productivity measured when the system is used by someone who is moderately efficient.
A subjective assessment of Users’ attitudes toward the System.
If a Program is a not User-friendly it is doomed to failure, even its functions are valuable.
DEFECT REMOWAL EFFICIENCY (DRE)
A Quality metrics that provides benefits of both the Project and Process level is Defect Removal Efficiency (DRE).
DRE in essence is a Measure of filtering ability of Quality assurance and Control activities as they are applied through all process framework activities.
DRE = E / (E+D)
Where;
E – No of Errors before delivery to uses.
D – No of Defects found by users after delivery.
The ideal DRE value is “1” that is no Defect found in Software.
Realistically (D) will be greater than 0, but the value of DRE can still approach 1.
As “E” increases it is likely that the overall Value of “D” will decrease.
DRE, encourages a Software Project team to institute technique for finding errors as many as errors before delivery.
DRE can also be used within the Project to Asses a Team’s ability to found Errors before they are passed to the next Framework activity of Software Engineering task.
Those Errors that are not found during the Reviews of Analysis phase are passed on to the Design task.
When DRE is used in this context:- . DRE i = Ei(Ei + E(i+1))
Ei: Number of errors found deriving analyze activity.
Ei+1: Are traceable to errors that were not discovered in S/E activity.
A Quality objective for a software team (or member) is to achieve a DRE that approvals to 1. That is errors should be filtered out before they are passed on the next Project Phase..
INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
Majority of Software Developers still do not measure, and sadly, most have little desire to begin. The problem is cultural! Attempting to collect measures often precipitates resistance.
In order to instituting a Metrics Program we have to consider some arguments and present an approach to Software Metrics.
ARGUMENTS FOR SOFTWARE METRICS
Why is it important to measure the Process of Software Engineering and the Product that it produces?
The answer is relatively obvious. If we do not measure, there is no real way of determining
weather we are improving and if we not improving we are lost.
By requesting and Evaluating Productivity and Quality measures, Senior Management can establish goals for improvement of the Software Engineering Process.
To establish Goals for improvement the current status of Software Development must be understood. Hence, Measurement is used to establish process Baseline from which improvements can be assessed.
The Day-to-day rigors of Software Project work leaves little time for Strategic thinking. Software Managers are concerned with more mundane issues such as :-
– Developing meaningful Project Estimates,
– Producing Higher Quality Systems,
Getting Product out of door on time.
By using Measurement to establish a Project Baseline, each of these issues become more manageable. Project Baseline serves as a basis for Estimation.
The collection of Quality Metrics enables an organization to ”Tune” its Software Process to remove the vital few causes of Defects that have the greatest impact on Software Development.
ESTABLISHING A BASELINE
By establishing a Baseline, benefits can be obtain at the Process, Project and Product (technical) levels. Yet the information that is collected need not be fundamentally different. The some metrics can serve many masters.
The Metrics Baseline consists of data collected from past Software development Projects and can be very simple to vary complex and comprehensive database containing dozens of Project metrics derived from them.
To be an effective aid in Process improvement and/or Cost and Effort Estimation the Baseline data must have the following attributes.
BASELINE DATA ATTRIBUTTES
Data must be reasonable accurate (Avoid guestimates)
Data should be collected from as many Projects as possible
Measures must be consistent.
Application should be similar to work that is to be estimated.
It makes little sense to use a Baseline for Batch information systems work to estimate a Real time, embedded application.
METRICS COLLECTION AND EVALUATION
The ideal way of collecting Baseline data should be an ongoing activity. Sadly, this is nearly the case. Therefore, data collection requires a historical investigation of past Project to reconstruct required data.
Once, measures have been collected then Metrics computation is possible. Depend on the collected measures, Metrics can span a broad range of Application-Oriented Metrics (e.g. LOC or FP, O-O metrics WebApp) as well as Quality and Project-Oriented Metrics.
Finally, Metrics must be Evaluated and applied during;-
– Project Estimation,
– Technical work, (Analysis, Design, Programming etc….)
– Project Control
– Process improvement.
Metrics Evaluation focuses on the underlying reasons for the results obtained and produces a set of ”Indicators” that guide the Project or Process.
SOFTWARE METRICS COLLECTION PROCESS
PROCESS
PROJECT
PRODUCT
DATA COLLECTION
MEASURES
METRICS COMPUTATION
METRICS
METRICS EVALUATION
INDICATORS
METRICS FOR SMALL ORGANIZATION
It is unreasonable and unrealistic to expect the small organizations to develop comprehensive. Software Metrics Programs. However it is reasonable to suggest that Software organization of all size measure and then use the resultant Metrics to help improve their local Software Process and the Quality and Timelines of products they produces.
A small organizations might selected the following set of easily collected measures:-
Time (hours / day) elapsed from the time a Change Request (Also called Systems Request) is made until Evaluation is complete.
Effort ( person/ hours) to perform the Evaluation
Time (hours / days) elapsed from completion of Evaluation to assignment of Change Request to personnel.
Effort Required to make the Required change
Time to make the Change
Errors uncovered during work to make Change
Defect uncovered after Change is released to the Customer base.
Once these Measures have been collected for a number of Change Request, it is possible to compute the total elapsed time from Change Request to Implementation of the Change and the percentage of Elapsed time absorbed by initial queering, evaluation and change assignment and complementation.
Similarly the EFFORT % required for evaluation and implementation can be determined.
These Metrics can be assessed in the Context of Quality of data, Error change (Ec) and Defect change (Dc)
The Percentage provides insight into where the System / Change Request process shows down and many lead to Process improvement steps.
The Defect removal efficiency can also be computed.as :
DRE = Ec / (Ec + Dc)
DRE can be compared to ELAPSED TIME and TOTAL EFFORT to determine the impact
of Quality Assurance (QA) activities or the Time and Effort required to make a change.
The Cost of Collecting measures and Computing Metrics for a small group, ranges from
3-8 % of Project budged during the learning phase, and then drops to less then 1% of Project budged after the Software Engineers and Project Managers have become familiar with the Metrics program.
These Costs can show a substantial Return On Investment (ROI) if the insight derived from metrics data lead to meaningful Process improvements for Software organization.
ESTABLISING A SOFTWARE METRICS PROGRAM
The software Engineering Institute has developed a comprehensive guidebook for establishing a Goal-Driven” Software Metrics Program that suggests Steps and prioritized business goals. See Software Engineering Book page 668 for further detail.
Order Now