Software Engineering 2 lecture slide

Software Engineering (II)Lecture 1

(Software Process & Project Metrics)

By

Abdur Rehman

Institute of Information Technology,Kohat University of Science & Technology,

Kohat, KPK, Pakistan

• Measurement is fundamental to any engineering discipline, and soft-ware engineering is no exception.

• Measurement enables us to gain insight by providing a mechanism for objective evaluation.

[When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind]

Lord Kelvin

• Software metrics refers to a broad range of measurements for computer soft-ware.

• Measurement can be used throughout a software project to assist in estimation, quality control, productivity assessment, and project control.

• Measurement can be applied to the software process with the intent of improving it on a continuous basis

Who does it ?

• Software metrics are analyzed and assessed by software managers. Measures are often collected by software engineers.

Why is it important?

• If you don’t measure, judgment can be based only on subjective evaluation.

• With measurement, trends (either good or bad) can be spotted, better estimates can be made, and true improvement can be accomplished over time.

Measures, Metrics, And Indicators

• Although the terms measure, measurement, and metrics are often used interchange-ably, there are subtle differences between them.

• Because measure can be used either as a noun or a verb, definitions of the term can become confusing.

Measure

• Within the software engineering context, a measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process.

Measurement • It’s the act of determining a measure.

Metric

• The IEEE Standard Glossary of Software Engineering Terms defines metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”


(Software Process & Project Metrics)

By

Abdur Rehman



9

10

Quote

“Not everything that can be counted counts, and not everything that counts can be

counted.”Einstein

10

Definition

•The IEEE Standard Glossary of Software Engineering Terms defines metric as

“a quantitative measure of the degree to which a system, component, or process possesses a

given attribute.”

11

Metrics In The Process And Project Domains

•Measurement is commonplace in the engineering world. We measure power consumption, weight, physical dimensions, temperature, voltage etc.

•Unfortunately, measurement is far less common in the software engineering world.

•We have trouble agreeing on what to measure and trouble evaluating measures that are collected.

12

Software Metrics Etiquette (Guidelines)

• Use common sense and organizational sensitivity when interpreting metrics data.

• Provide regular feedback to the individuals and teams who collect measures and metrics.

• Don’t use metrics to assess individuals.

• Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.

13

• Never use metrics to threaten individuals or teams. • Metrics data that indicate a problem area should not

be considered “negative.” These data are merely an indicator for process improvement.

• Don’t obsess on a single metric to the exclusion of other important metrics.

14


(Direct and Indirect Metrics)

By

Abdur Rehman



15

• Measurements in the physical world can be categorized in two ways:

(a) direct measures (e.g., the length of a Missile) (b)indirect measures (e.g., the "quality" of Missile produced by counting the rejected ones)

16

Direct Measures of The Software Engineering

• cost • effort applied.• lines of code (LOC) produced,• execution speed,• memory size, • defects reported over some set period of time

17

Indirect Measures of The Software Engineering

Indirect measures of the product include :• functionality • quality• complexity• efficiency• reliability • Maintainability, and many other "–abilities

18

Size Oriented Metric

19

• The table lists each software development project that has been completed over the past few years and corresponding measures for that project.

e.g for project alpha reveals that :• 12,100 lines of code were developed • with 24 person-months of effort • at a cost of $168,000• 365 pages of documentation were developed• 134 errors were recorded before the software was

released• 29 defect were encountered after release to the

customer within the first year of operation• Three people worked on the development of software

for project alpha.

20

From the basic data contained in the table, a set of simple size-oriented metrics can be

developed for each project:

• Errors per KLOC (thousand lines of code).• Defects per KLOC.• Cost per LOC. • Page of documentation per KLOC.

21

In addition, other interesting metrics can be computed:

• Errors per person-month.• LOC per person-month.• $ per page of documentation.

22


(Software Quality Metrics)

By

Abdur Rehman



23

McCall and Cavano’s Framework for Software Quality

• It was presented in 1978. • These factors assess software from three

distinct points of view: (1) product operation (using it)(2) product revision (changing it), and (3) product transition (modifying it to work in a

different environment; i.e., "porting" it)

24

Measuring Quality

Correctness

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

• The most common measure for correctness is defects per KLOC, where a defect is defined as a verified lack of conformance to requirements.

• Defects are those problems reported by a user of the program after the program has been released for general use. For quality assessment purposes, defects are counted over a standard period of time, typically one year

25

Maintainability.• Software maintenance accounts for more effort than

any other software engineering activity.

• Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirement.

26

• There is no way to measure maintainability directly; therefore, we must use indirect measures.

• A simple time-oriented metric is mean-time-to-change(MTTC), the time it takes to analyze the change request, design an appropriate modification, implement the change, test it, and distribute the change to all users.

• On average, programs that are maintainable will have a lower MTTC (for equivalent types of changes) than programs that are not maintainable.

27

Integrity

• Software integrity has become increasingly important in the age of hackers and firewalls.

• This attribute measures a system's ability to with-stand attacks (both accidental and intentional) to its security.

• Attacks can be made on all three components of software: programs, data, and documents

28

Usability

29

• It is interesting to note that nearly every aspect of computing has undergone radical change as the years have passed since McCall and Cavano did their influential work in 1978.

• But the attributes that provide an indication of software quality remain the same.

30


(Software Quality Assurance)

By

Abdur Rehman



31

Quote

“People forget how fast you did a job but they always remember how well you did it.”

Howard Newton

32

All the software engineering approaches described strive to achieve a single goal:

to produce high-quality software

33

What is it?• You have to (1) explicitly define what is meant when you say

“software quality,” (2) create a set of activities that will help ensure that

every software engineering work product exhibits high quality

(3) perform quality assurance activities on every software project

(4) use metrics to develop strategies for improving your software process and, as a consequence, the quality of the end product

34

Who does it?

Everyone involved in the Software engineering process is responsible for

quality

35

Why is it important?• You can do it right, or you can do it over again.

• If a software team stresses quality in all software engineering activities, it reduces the amount of rework that it must do.

• That results in lower costs, and more importantly, improved time-to-market.

36

What are the steps?• Before software quality assurance activities can

be initiated, it is important to define ‘software quality’ at a number of different levels of abstraction.

• Once you understand what quality is, a software team must identify a set of SQA activities that will filter errors out of work products before they are passed on

37

What is the work product?• A Software Quality Assurance Plan is created

to define a software team’s SQA strategy. • During analysis, design, and code generation,

the primary SQA work product is the formal technical review summary report.

• During testing, test plans and procedures are produced.

• Other work products associated with process improvement may also be generated.

38

How do I ensure that I’ve done it right?

• Find errors before they become defects! That is, work to improve your defect removal efficiency thereby reducing the amount of rework that your software team has to perform

39

• Some software developers continue to believe that software quality is something you begin to worry about after code has been generated.

• Instead Software quality assurance(SQA) is an umbrella activity that is applied throughout the software process.

40


(Software Quality Assurance – Continued)

By

Abdur Rehman



41

Quote

“It takes less time to do a thing right than explain why you did it wrong”

Henry Wadsworth Longfellow

42

Quality Concepts(1) Quality

• The American Heritage Dictionary defines quality as

“a characteristic or attribute of something”

• As an attribute of an item, quality refers to measurable characteristics.

• Things we are able to compare to known standards such as length, color, electrical properties etc.

• However, software, largely an intellectual entity, is more challenging to characterize than physical objects.

43

software quality

software quality is defined as

“Conformance to explicitly stated functional and performance requirements, explicitly documented

development standards, and implicit characteristics that are expected of all professionally developed

software”

44

The definition serves to emphasize three important points: 1. Software requirements are the foundation from which

quality is measured. Lack of conformance to requirements is lack of quality.

2. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result.

3. A set of implicit requirements often goes unmentioned (e.g., the desire for ease of use and good maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is doubtful.

45

(2) Quality Control• Quality control involves the series of inspections,

reviews, and tests used throughout the software process to ensure each work product meets the requirements placed upon it.

• Quality control activities may be fully automated, entirely manual, or a combination of automated tools and human interaction.

46

(3) Quality Assurance

• The goal of quality assurance is to provide management with the data necessary to be informed about product quality, thereby gaining insight and confidence that product quality is meeting its goals.

47

(4) Cost of Quality• The cost of quality includes all costs incurred in the

pursuit of quality or in performing quality related activities.

• Quality costs may be divided into costs associated with

–prevention, –appraisal, and– failure.

48

Prevention costs include

• quality planning• formal technical reviews• test equipment• training

49

Appraisal costs• It include activities to gain insight into product

condition the “first time through” each process.

Examples of appraisal costs include• in-process and inter process inspection • equipment calibration and maintenance• testing

50

Failure costs• It’s the cost that would disappear if no defects appeared

before shipping a product to customers.

• Failure costs may be subdivided into internal failure costs and external failure costs.

• Internal failure costs are incurred when we detect a defect in our product prior to shipment. Internal failure costs include

– rework– repair– failure mode analysis

51

External failure costs• These are associated with defects found after the

product has been shipped to the customer.

Examples of external failure costs are–complaint resolution–product return and replacement–help line support–warranty work

52

As expected, the relative costs to find and repair a defect increase dramatically as we go from prevention to detection to internal failure to external failure costs.

53

Another example:• Anecdotal data reported by Kaplan, Clark, and Tang

[KAP95] reinforces earlier cost statistics and is based on work at IBM’s Rochester development facility:

• A total of 7053 hours was spent inspecting 200,000 lines of code with the result that 3112 potential defects were prevented. Assuming a programmer cost of $40.00 per hour, the total cost of preventing 3112 defects was $282,120, or roughly $91.00 per defect.

54

• Compare these numbers to the cost of defect removal once the product has been shipped to the customer. Suppose that there had been no inspections, but that programmers had been extra careful and only one defect per 1000 lines of code [significantly better than industry average] escaped into the shipped product.

• That would mean that 200 defects would still have to be fixed in the field. At an estimated cost of $25,000 per field fix, the cost would be $5 million, or approximately 18 times more expensive than the total cost of the defect prevention effort.

55