SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

1

SOFTWARE METRICSFOR

PROCESS AND PROJECTS

LECTURE NOTES 3

2

SOFTWARE METRICS FOR PROCESS AND PROJECTS

Software Process Metrics and Project Metrics are Quantitative Measures that enable Software Professionals to gain insight into the efficacy of Software Process and the Project that are conducted using the Process as a Framework.

Quality and Productivity data are collected, analysed and compared against past averages to :-

- Assess Productivity improvements.- Pinpoint Problem areas

3


WHO DOES IT ?

• Software Measures are often collected by Software Engineers/ Software 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 can be spotted, - Better estimates can be made, - True improvement can be accomplished

4


WHAT ARE THE STEPS? 1. Defining a limited set of Process and Project that

are easy to collect.

2. The result is analyzed and compared to ‘’Past Average’’ for similar Project performed within the organization.

3. Trends are assessed and conclusions are generated.

WORK PRODUCT?

A set of Software Metrics that provide insight into the Process and understanding of the Project.

- Productivity Metrics - Quality Metrics

5


REASONS FOR MEASURING

1. To Characterize2. To Evaluate3. To Predict4. To Improve

Measurement is a Management Tool. Measurement provides a Project Manager

with insight. It assists Manager and Project team in making sound decision.

6

SOFTWARE METRICS FOR PROCESS AND PROJECTS Project Metrics are collected across all Projects and over long periods of time. Their intent is to provide a set of Process Indicators that lead to long term Software Process improvement.

Project Metrics enable Project Managers to:

• Assess the status of an ongoing Project

• Track potential Risks

• Uncover Problem areas before they “Go critical”

– Adjust work flow or Tasks

– Evaluate the Project Team’s ability to Control Quality of Software Work Product.

• Measures that are collected by a Project team and converted into Metrics for use during a Project can also 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.

7


The only Rational way to improve any Process is to:

a) Measure Specific attributes of the Process b) Develop a set of meaningful Metrics based on these attributes c) Use Metrics to provide Indicator that will lead to strategy for

improvement

However it is important to note that Process is only one of a numberof ‘’Controllable Factors’’ in improving Software Quality andOrganizational performance.

8


PROCESS

BUSINES CONDITIONS

CUSTOMER CHARACTERISTICS

DEVELOPMENT ENVIRONMENTPEOPLE

TECHNOLOGY

PRODUCT

9


The Figure shows the Process in the centre of a triangle connecting three Factors that have profound influence on Software Quality and OrganizationalPerformance.

• The Skills and the Motivation of people has been shown to be the single influential factor in Quality and Performance.

• The Complexity of Product can have a substantial impact on Quality and Project Team Performance.

• The Technology (Methods and Tools) that populates the Process has an impact.

The Process Triangle exists within a circle of Environmental Conditions that include the Development Environment (CASE TOOLS, Business Conditions (Deadlines, Business rules), and Customer Characteristics (ease ofcommunication and collaboration etc)

10


We measuring the efficacy of Software Process “indirectly”.

– We derive a Set of Metrics based on the Outcomes that can be derived from 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 Task.

(E.g. we might measure the Effort and Time spent performing the Generic Software Engineering Activities.)

11

SOFTWARE METRICS FOR PROCESS AND PROJECTS • There are ‘’Private’’ and ‘’Public’’ use of Different Types of Process Data .

• It is natural that individual Software Engineers might be sensitive to use Metrics collected on an individual basis, these data should be Private to the individual and serve as an Indicator for the Individual only.

– e.g. Defect Rates by individual, Defect Rates by Software components, and error found

during Development.

• Some Process Metrics are Private to the Software Project Team but Public to all Team members.

– (e.g. Defects reported for major Software functions that have been developed by a number of Engineers. Errors found during Technical Reviews, and Lines Of Code (LOC) or Function Point (FP) per Component or Function.

• These data are received by the Project Team to uncover Indicators that can improve Team performance.

• Public Metrics generally assimilate information that originally was private to an individual or a Project Team. (e.g. 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.

12


Software Process Metrics can provide significant Benefits as an Organization works toimprove its overall level of Process Maturity.

However like all Metrics,, these can be misused, creating more problems that they solve. SOFTWARE METRICS ETIQUETTE

Suggested by Grady that is appropriate for both Managers and practitioners as they institute a Process Metrics Program.

1. Use common sense and organizational sensitivity, when interpreting Metrics.2. Provide regular feedback to the individual and Teams who collect measures and Metrics.3. Do not use Metrics to appraise individual.4. Work with Practitioners and Teams to set clear goals and Metrics that will be used to achieve them5. Never use Metrics to threaten individual or Teams.6. Do not consider Metrics data that indicate a problem area as negative. These data are merely an indicator for process improvement Consider it as and Indicator for Process improvement.7. Don’t obsess on a single Metric to the exclusion of other important Metrics.

As an Organization becomes more comfortable with the collection and use of Process Metrics, thederivation of simple Indicators gives way to a more rigours approach called (SSPI) “Statistical Software Process Improvement (SSPI).

SSPI uses Software Failure Analysis to collect information about all errors and defects. Encountered as an Application, System, or Product is developed and used.

13

SOFTWARE METRICS FOR PROCESS AND PROJECTS Software Project Metrics are tactical as opposed to the Software Process Metrics which are used for Strategic purposes..

Project Metrics and Indicators are used by a Project manager and a Software Team to adapt Project Workflow and technical activities.

• The first application of Project Metrics on most Software Projects occur during Estimation.

Metrics collected from 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 are compared to original Estimates.

The Project Manager uses data to monitor and Control progress.

• As Technical work commences, other Project Metrics begin to have significance. Production Rates represented in terms of Models created, Review Hours, Function Points, and Delivered Source Code lines are measured. Errors uncovered during each Engineering tasks are tracked.

• As the Software evolves from Requirements into Design, Technical Metrics are collected to assess Design Quality and provide Indicators that will influence the approach taken to Software code generation and Testing.

14


THE PURPOSES OF PROJECT METRICS

a) To Minimize the Project Development Schedule by making the necessary adjustments to avoid delays and mitigate potential problems and risks.

b) 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 required during the Project is also reduced. This leads to a reduction in overall Project Costs.

15

SOFTWARE METRICS FOR PROCESS AND PROJECTS PROJECT METRICS APPLICATIONS

- 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 Project proceeds,

Measures of Effort and Calendar Time expended ( Actual Times) are compared to Planned (Original) Estimates. -As Technical work commences

-Other Project Metrics rates begin to have significance. Such rates include:-

- Production Rates - Review Hours, - Function Points - Delivered Line of Source Codes (LOC)

- As the Software evolves from Requirements into Design,

Technical Metrics are collected to assess Design Quality and to provide indicators that influence approach taken to Code Generation & Testing.

16

SOFTWARE METRICS FOR PROCESS AND PROJECTS Software Project Metrics are tactical as opposed to the Software Process Metrics.

Project Metrics and Indicators are used by a Project manager and a Software Team to adapt Project Workflow and technical activities.

The first application of Project Metrics on most Software Projects occur during Estimation.

THE PURPOSES OF PROJECT METRICS

a) To Minimize the Project Development Schedule by making the necessary adjustments to avoid delays and mitigate potential problems and risks.

b) 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.

17


SOFTWARE MEASUREMENT

1. Direct Measurement 2. Indirect Measurement

Direct Measurements of Software Process includes:

- Cost and Effort applied.

Direct Measurements of Product includes:

- Lines of Code (LOC) Produced, - Execution Speed - Memory size - Defect reported over a set period of time Indirect Measurements Of Product includes - Functionality - Quality - Complexity - Efficiency - Reliability - Maintainability and many others…

18


Size Oriented Metrics are derived by normalizing Quality and/or Productivity Measures by considering the Size of Software that has been produced.

SIZE-ORIENTED METRICS

- Errors / KLOC - Defect / KLOC - $ / KLOC - Page of Document / KLOC

Other interesting Metrics can be computed such as:-

- Errors / Person-Month - LOC / Person-Month - $ / Pages of Documentation

Note: KLOC (Thousand of Lines of Code)

19

SOFTWARE METRICS FOR PROCESS AND PROJECTS SIZE-ORIENTED METRICS

The Table below lists each Software Development Project that has been completed over the past few years and corresponding Measures for that Project.REFERRING TO Project A , 12100 Lines of Code (LOC) were developed with in 24 Person- Months of Effort at a cost of $168000. The Effort and Cost recorded in the table represents all Software Engineering Activities i.e. Analysis, Design, Code, and Test)

Project A also indicates that 365 Pages of Documentation were developed, 134 Errors were recorded before the Software released, and 29 Defects were encountered after release to the Customer within the first year of operation. 3 Software Engineer worked on Project A development.

SIZE ORIENTED METRICS

PROJECT LOC EFFORT $ (000) Pp. Doc ERRORS DEFECTS PEOPLEA 12100 24 168 365 134 29 3B 27200 62 440 1224 321 86 5C 20200 43 314 1050 256 64 6

20


We can calculate the following Size Oriented Metrics from the table or each Projects:

e.g. for Project A

- Errors / KLOC (134 / 12.1 = 11.07) - Defect / KLOC (29 / 12.1 = 2.4 )

- $ / KLOC (168000 / 12.1= 13884) - Page of Document / KLOC (365 / 12.1 = 31.7)

Note: KLOC (Thousand of Lines of Code. (eg 12100 LOC = 12.1 KLOC)

Other interesting Metrics can be computed such as:-

- Errors / Person-Month (134 / 24 = 5.58 ) - LOC / Person-Month ( 12100 / 24 = 504 ) - $ / Pages of Documentation ( 168000 / 365 = 460.27)

21


WHY SIZE-ORIENTED METRICS ARE NOT UNIVERSALLY ACCEPTED?

PROPONENTS

Argues that LOC is an “Artifact” of Software Development Projects that can beeasily counted.

• Many existing software Estimation Models use LOC or KLOC as the input and that a large body of literature and data predicted on LOC already exists

OPPONENTS

Argues that 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. Thus, theiruse in Project Estimation require a level of detail that may be difficult to achieve.

(i.e . The Project Planner must Estimate the LOC to be produced long before Analysis and Design have been completed.

22

SOFTWARE METRICS FOR PROCESS AND PROJECTS FUNCTION-ORIENTED SOFTWARE MERTICS

Function-Oriented Software Metrics use Measure of“Functionality” delivered by the Software Application asa 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 Domains and the complexity F actors.

The Function Point Measure is also controversial like LOC Measures.

23


The Arguments of Proponents and Opponents of Functional-Orientedmetrics:

POPONENTS Claim that Function Point (FP) is Programming Language independent, thus making it ideal for applications using Procedural (conventional) and non-Procedural Programming Languages.

OPPONENTSClaim that the method requires some ‘’slight of hands’’ in that Function Pointcomputation is based on subjective rather than objective data, that the counts of the Information Domain (and other dimensions) 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.

24

SO


Function Points (FP) are computed by completing the ‘’Five Information DomainCharacteristics’’ that are determined and Counts are placed in a table.

THE FIVE INFORMATION DOMAINS for Function Points calculation

1. Number of Inputs2. Number of Outputs

3. Number of User Enquiries 4. No. Of Files 5. No. of External Interfaces

THE COMPLEXITY FACTORS of the System

FP = COUNT TOTAL * [0.65 + 0.01 * ∑ ( fi )]

Complexity Adjustment Factor

25


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) (52)

26


FUNCTION-ORIENTED METRICS

ERROR / FP DEFECTS / FP $ / FP PAGES / FP

FP / PERSON- MONTH

RELATIONSIONSHIP BETWEEN LOC AND FP

The relationship between LINES OF CODE (LOC) and FUNCTIONPOINTS (FP) depends on Programming Language that is used toimplement the Software and the Quality of the Design.

The Average number of Lines of Code required to build one Function Point in various Programming Languages.

Programming Language LOC/FP AVERAGE

C 128C++ 64VISUAL BASIC 32SQL 12

As you can see that one LOC of C++ provides approx. 2.4 times the Functionality as one LOC of C.

27


• 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.

28


Within the context of Process and Project Metrics, we are concerned with Productivity and Quality measurers of ‘’Software Development Output’’ as a Function of Effort and Time applied and measures of the ‘’Fitness For Use’’ of the Work Products that are produced.

However, for the Process improvement and Project Planning purposes 0urinterest is historical.

• What was the Software Development Productivity on past Projects?

• What was the Quality of the of Software that was produced?

• How can the Past Productivity and Quality data extrapolated to present?

• How can it help us improve the Process and Plan new Projects more accurately?

29


OBJECT- ORIENTED PROJECT METRICS

• Conventional Software Project Metrics such as LOC and FP Metrics can be used to estimate O-O Projects

• However, Conventional Metrics do not provide enough granularity for the Project Schedule and Effort Adjustments that are required as we iterate through Evolutionary incremental Process Method for O-O Projects.

Object-Oriented Project Metrics Set :-

- No. Of Scenario Scripts- No. Of Key (Foundation) Classes- No. of Support Classes- Average No. Of Support Class / Key Class- No. Of Sub-systems

30


Number Of Scenario Scripts

A Scenario Script is a detailed sequence of steps that describes the interactionbetween the User and the Application.

The number of Scenario Scripts directly correlated to the Size of the application andto the number of Test Cases that must be developed to exercise the System once it isconstructed.

Number Of Key Classes (Foundation Classes)

Key or Foundation Classes are highly independent Components that are defined in Object-Oriented Analysis.

Because Key Classes are central to the Problem Domain , the Number of such Classes is anindicator of”:

- The Amount of Effort required to develop the Software

- The potential Amount of Reuse to be applied during the development.

31

SOFTWARE METRICS FOR PROCESS AND PROJECTS Number of Support Classes

Support Classes are required to implement the System but are not immediatelyrelated to the Problem Domain. (e.g User Interface Classes, Database Access andManipulation Classes , Computation Classes)

In addition a Support Class can be developed for each of the Key Classes.

Thus, the Number of Support classes is an indication of the amount of Effort to develop theSoftware and an indication of potential amount of Reuse to be applied during Development

Average Number of Support Class per Key Class

- Key Classes are usually known early in the Project. - Support Classes are defined during the development.

- If the Average number is known for a given Problem Domain, estimating would be much simpler.

Lorenz and Kidd suggest that:-

Applications with a GUI have between 2 and 3 times the number of Support Classes as Key Classes.

Applications with Non-GUI have between 1 and 2 times the number of Support Classes as Key Classes.

32


Number of Subsystems

A Sub-system is an aggregation of Classes that support a Function that isvisible to the end-user of a system.

Once Subsystems are identified , it is easier to lay out a reasonable Schedulein which work on Subsystems is partitioned among Project staff.

33

SO


USE OF OBJECT-ORIENTED METRICS

To use Metrics effectively in an Object-Oriented Software Engineering Environment, metrics must be collected along with the Project Measurers such as:

- Effort Expended - Errors and Defects uncovered - Models or Document Pages produced.

• As the Project Database grow with Object-oriented Projects, relationships between O-O Measures and Project Measures will provide Metrics that can aid in Project Estimation.

34

SO

SOFTWARE METRICS FOR PROCESS AND PROJECTS USE-CASE ORIENTED METRICS

Use-Case can be used as a Normalization Measurers similar to LOC or FP.

Like the FP 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.

Use Cases describe User-visible functions and futures that are basic requirements for a system

Use-case is also independent of Programming Languages.

Also 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.

35

SO


CRITICISM ABOUT USE-CASE ORIENTED METRICS

Use-case can be created at many different levels of abstraction thus, 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.

36


WEB ENGINEERING PROJECT METRICS

Measures and Metrics used for Traditional Software Engineering Project aredifficult to translate directly to Web-Apps. Yet a Web Engineering organization willhave to collect Measurers and build a Database that allow it to assess its internalProductivity and Quality over a number of Projects.

Among the Measurers that can be collected for WEB Engineering Projects 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

37



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, FinancialApplications 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.

38


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 ofArchitectural 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 ofrequired files grow, the complexity of WebApp also grow and Effort to Implement it increases proportionally.

39


NO. OF STATIC CONTENT OBJECTS

A Static content objects may contain text, graphic, video, animation andaudio information. A Multiple content Objects may appear on a singleWeb Page increasing the complexity.

NO. OF DYNAMIC CONTENT OBJECTS

Dynamic Content Object are generated based on User actions andencompasses internally generated text, graphic, video, animation and audio information that are incorporated within WebApp. Multiplecontent Objects may appear on a single Web Page.

40



NO. OF EXECUTABLE FUNCTIONS

An Executable function (also called Script or Applet) provides someconceptual 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 ofthe 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.

41

SO


METRICS FOR SOFTWARE QUALITY

The overriding Goal of Software Engineering is to produce a High-quality Application System within a ‘’Time-frame that satisfya market need.

HOW TO ACHIEVE THIS GOAL,

By applying effective Methods coupled with modern Development Tools within the context of a mature Software Process.

Taking measures continuously to ensure high quality.

42



The Primary source of quality measurers at the Project-level is ‘Errors and Defects’.

Metrics derived from Errors and Defects provide an indication of theeffectiveness of Software Quality assurance and Control activities.

Error data can also be used compute the ‘Defect Removal Efficiency (DRE)’

QUALITY METRICS that are derived from Errors / Defects

- Product Errors Per Function Point - Errors uncovered per review hours

- Errors uncovered per Testing hour

43

SO



MEASURING QUALITY

There are many Measures of Software Quality; But the following Four measures provide useful indicators for the Project Team.

- Software Correctness- Software Maintainability - Software Integrity- Software Usability

44

SO



1. SOFTWARE CORRECTNESS

Correctness is the degree to which the software performs its required function.

Most common measures for Correctness is:-

- DEFECTS / KLOC,

Defects are these problems that are reported by Users after the Software has been released for general use.

For Quality assessment, Defects are counted over a standard period of time, typically for one year.

45

SO



2. SOFTWARE MAINTAINABILITY

Maintainability is the ease with which a program can be corrected when an error is encountered, adapted if its environmental 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.

Mean Time To Change Time-(MTTC), which is a simple Time- oriented Metrics can be used to Analyze the changes required, Design the appropriate modification, Test, Implement and distribute the changes to all users.

Programs that are maintainable have a lower MTTC than the programs that are not maintainable.

46

SO



3. SOFTWARE INTEGRITY

This attribute measures a System ability to withstand both accidental and intentional attacks to its security.

Attacks can be made on all three components of a Software (i.e. Programs, Data and Documents.)

Integrity has become extremely important in the age of ‘’Hackers and Firewalls’’

To measure Integrity two other attributes need to be defined.

- THREAT Probability - SECURITY Probability

47

SOFTWARE METRICS FOR PROCESS AND PROJECTS Threat Probability - that an attack of a specific type will

Occur within a given time

SECURITY Probability - that the attack of a specific type will

be repelled.

INTEGRITY = ∑ [1 – (THREAT Probability * (1 – SECURITY))]

Where Threat and Security are summed Over each type of attack.

Example1 :- If Threat Probability is 25% and Security (Likelihood of repelling an attack) is 95% the integrity of System is 99% Which is Very High.

Example 2 If Threat Probability is 50% and the Security is 25% then the System’s Integrity is 62.5%, which is unacceptably low.

Integrity = ∑ [1 - (0,50 * (1 – 0,25))] = [1 - (0,50 * (0,75))] = [1 - (0,375)] = 0,625 or 62,5 %

48

SO

SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY

4. SOFTWARE USABILITY Usability is an attempt to quantify User-friendliness and can be measured in terms of the following four characteristics. USABILITY CHARACTERISTICS

1. The physical and / or intellectual skill required to learn the System.

2. The time required to become moderately efficient in the use of the system.

3. The net increase in productivity measured when the system is used by someone who is moderately efficient.

4. A subjective assessment of Users’ attitudes towards the System.

If a Program is a not User-friendly it is doomed to failure, even its functionsare valuable.

49


METRICS FOR SOFTWARE QUALITYDEFECT REMOVAL EFFICIENCY

Defect Removal Efficiency (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 is a Quality Assurance Metrics that provides benefits of both the Project and Process level.

DRE = E / (E + D)

Where: (E) No. of Errors before delivery to User. (D) No. of Defects found by users after delivery.

The ideal DRE value is “1” or 100% - 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.

Example : 20 errors before delivery to users 8 Defects reported by Users after delivery

DRE = 20 / (20 + 8) => 20 / 28 = 0,714 or 71,4 %

50


DEFECT REMOVAL EFFICIENCY

DRE encourages a Software Project team to institute technique for finding errors before delivery.

DRE can also be used within the Project to Asses a Team’s ability to find Errors before they are passed to the next Process Framework activity of Software Engineering task.

For example: Errors that are not found during the Reviews of Analysis Phase are passed on to the Design Phase.

When DRE is used in this context:-

DREi = Ei / (Ei + E i+1) say (Ei + 1) = y

DREi = Ei / (Ei + Ey)

(Ei) N0. of errors found deriving Analysis Activity.

Ey: No. of errors that were not discovered in Design activity.

A Quality objective for a Software team is to achieve a DRE that approximates to 1.

51

SOFTWARE METRICS FOR PROCESS AND PROJECTS INTEGRATING METRICS WITHIN SOFTWARE PROCESS

Majority of Software Developers still do not measure, and sadly, most have little desire tobegin - The problem is cultural ! Attempting to collect measures often precipitates resistance.

In order to instituting a Metrics Program we have to consider some Arguments

ARGUMENTS FOR SOFTWARE METRICS

Why is it so important to Measure the Process of Software Engineering and Product that is Produced?

The answer is relatively obvious:

If we do not measure, there is no real way of determining weather we are improving!And if we are not improving, we are lost!

By requesting and evaluating Productivity and Quality Measures, a Software Team andtheir Managers can establish meaningful goals for improvement of the Software process.

The day-to-day rigors of Software Project work leave little time for strategic thinking.. Software Project Managers are concerned with more mundane (but equally important) issues:-

- Developing meaningful Project estimates, - Producing higher-quality Systems, - Getting product out of door on time.

.

52


ARGUMENTS FOR SOFTWARE METRICS

By using Measurement to establish a Project Baseline, each of these issues will become more manageable

Additionally, 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.

ESTABLISAHING A BASELINE

By establishing a Metrics Baseline, benefits can be obtained at the Process, Project and Product levels.

The same Metrics can serve many masters.

The Metrics Baseline consisted of data collected from past Software Development Projects and can be as simple a simple table or a comprehensive Database containing dozens of Project measurers and the metrics derived from them.

.

53


ESTABLISHING A BASELINE

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

1. Data must be reasonable accurate (Avoid guestimates)2. Data should be collected from as many Projects as possible3. Measures must be consistent.4. Application should be similar to work that is to be estimated.

Project Baseline serves as a basis for ‘’Cost and Effort Estimation’’.

54


METRICS COLLECTION AND EVALUATION The ideal way of collecting Baseline data should be an ongoing activity. Sadly, this is rarely the case.

Data collection requires a historical investigation of Past Project to reconstruct required data.

Once, Measures have been collected Metrics computation is possible.

Depending on the collected Measures, Metrics can span a broad range of Application-Oriented Metrics, (e.g. LOC or FP, O-O Metrics , WebApp etc.) as well as Quality and Project-Oriented Metrics.

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

55


METRICS FOR SMALL ORGANIZATION

Software organization of all sizes should collect measures and use the resultant Metrics to help improve their local Software Process and the Quality and Timeliness of Products they produce.

Small organizations might selected the following set of easily collected measures:-

• Time (Hours / Days) Elapsed from the time a Change or new 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/ Systems 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.

56


METRICS FOR SMALL ORGANIZATION

The Cost of collecting Measures and computing Metrics for asmall organization, ranges from 3 - 8 % of Project Budget during the Learning phase, and then drops to less then 1%of Project Budget after the Software Engineers and ProjectManagers 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 meaningfulProcess improvements for Software organization.

57


ESTABLISING A SOFTWARE METRICS PROGRAM

The Software Engineering Institute of America (SEI) has developed a comprehensive guidebook for establishing a ‘’Goal-Driven Software MetricsProgram’’ that suggests steps and prioritized business goals.

See Software Engineering Book page 668 for further detail.

SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

Documents

Transcript of SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3