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 :-
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 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.
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
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..
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.
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)
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.
1. SIZE-ORIENTED METRICS
Before ReleaseSize Oriented Metrics are derived by normalizing Quality and/or Productivity Measures by considering the Size of the Software that has been produced.
DP DOC (pages)
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.
– 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 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 argues that most of the controverts swirls around the use of LOC as the
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. )
Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.View our services
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
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
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)
No. of User Input
No. of User Output
No. of User Enquires
No. of Files
No. of External Interfaces
âˆ‘ COUNT TOTAL
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
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
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:
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
VISUAL BASIC 32
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:
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 :-
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.
Although there are many Measures of Software Quality the following Four measures provide useful indicators for the Project team.
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 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
A simple Time-Oriented Metric is MTTC (Mean Time To Change).The time it takes to Analyze t
Cite This Work
To export a reference to this article please select a referencing stye below:
Related ServicesView all
DMCA / Removal Request
If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: