ECSE 6770- Software Engineering - 1 - HO 2 © HY 2012 Lecture 2 Managing the Software Process We...

ECSE 6770- Software Engineering

- 1 -HO 2

© HY 2012

Lecture 2

Managing the Software Process

We learnt that software engineering is a coordinated set of activities. Any coordinated set of activities must be managed if it is to yield results.

We must manage the software process.

Management is continuous and pervasive.

Management and control require adequate understanding of the environment and the item under management. This implies a need for measurement.


- 2 -HO 2

© HY 2012

Lecture 2

MeasuringWhat do we need to measure?

We need to measure:

Attributes of the product

Attributes of the process

Let us look at some fundamental questions a project manager might be asked:

“When would the project be completed?”

“How much would it cost?”

“How good would the end product be?”


- 3 -HO 2

© HY 2012

Lecture 2

Measuring

When a project would be completed depends on the size of the project, the technology used and how many are working on it.

How much would the project cost also depends on the size of the project and the resources involved or committed; again including technology and people.

How good a product would be is a question regarding its quality and depends on how the user perceives certain important attributes of the final product.


- 4 -HO 2

© HY 2012

Lecture 2

Measuring

So we need measures for:

Product size

Process resource utilization

Product quality


- 5 -HO 2

© HY 2012

Lecture 2

As with the physical world, in the world of software we need a small set of measures that are:

Simple

Orthogonal

Fundamental

Universal

Valid (repeatable)

Measuring


- 6 -HO 2

© HY 2012

Lecture 2

What is the size of a software product?

Size:Length?

Functionality?

Complexity?

Originality (newness)*?

Measuring Size


- 7 -HO 2

© HY 2012

Lecture 2

Many criticize the simple measures of software size on the grounds that they do not adequately reflect effort, productivity, cost or similar notions. This is naive and reflects a misunderstanding of the basic measurement principles. Those who reject simple size measures expect too much of such measures.

Example:

If human size is measured say by height, then it would be useful as it can tell if x would bump his head when entering the doorway. The fact that it can not predict if a person is obese, smart or good looking does not disqualify it as a measure.

Measuring Size


- 8 -HO 2

© HY 2012

Lecture 2

Length Complexity

Functionality Originality

We said size was often measured in terms of:

We now wish to examine these proposed dimensions in terms of our requirements of:

Simplicity Orthogonality

Fundamentality Universality

Validity

Measuring Size


- 9 -HO 2

© HY 2012

Lecture 2

Measures of LENGTH:

There are three major software development products whose length would be useful to know. These are the:

Specification

Design, and

Code

The length of a specification may be the domain assessment measure in a prediction system to predict length (size) of design.

Measuring Size


- 10 -HO 2

© HY 2012

Lecture 2

The length of design may be a predictor of the length of the code to be written which in turn may be a predictor of the amount of effort needed for the project.

It may however be that there might be a direct relationship between the length of the specification and the amount of effort needed to complete the project!!

We shall investigate length measures for these artifacts

Measuring Size


- 11 -HO 2

© HY 2012

Lecture 2

SPECIFICATION AND DESIGN

The traditional measure has been : Number_of_pages.

What are the obvious problems with this measure?

Simple? Orthogonal? Fundamental? Universal? Valid?

Other suggestions have been along the lines of separating text from diagrams and then again separating text into different types and diagrams into different ones also.

Let us work out a potential measure for the length of specification and design together.

Measuring Size


- 12 -HO 2

© HY 2012

Lecture 2

Workshop 1

A measure of length for Specification and design

Measuring Size


- 13 -HO 2

© HY 2012

Lecture 2

CODE

The traditional measure has been: Number_of_Lines_of_Code

What are the obvious problems with this measure?

Simple? Orthogonal? Fundamental? Universal? Valid?

Do we include comments? Blank Lines? Data Declarations?

How do we count lines that have more than one separate instruction?

What about the language? What about reused (imported)code?

Measuring Size


- 14 -HO 2

© HY 2012

Lecture 2

Workshop 2

A Coding Standard

Measuring Size


- 15 -HO 2

© HY 2012

Lecture 2

There are alternatives to Lines_of_Code as a measure of length of a program. An early attempt is Halstead’s work published in his book “Software Science”, a book with lasting impact and many citations but a work that is fundamentally confused and flawed.

A program P is a collection of tokens. These tokens are either operands or operators. The basic metrics then are:

operands of occurances Total

operators of occurances Total

operands unique ofNumber

operators unique ofNumber

2

1

2

1

N

N

Measuring Size


- 16 -HO 2

© HY 2012

Lecture 2

Then, a statement (he used FORTRAN):

A(I) = A(J)

Has one operator (=) and two operands (A(I) and A(J) ).

The Length of P is defined to be whilst the Vocabulary of P is .The Volume, that is a measure of the number of mental comparisons needed to write a program of length N, is . The level of difficulty is:

21 NNN

21

2logNV */VVD

The effort required to generate P is:2

221

2

log

NN

VDE

Dividing by 18 (Halstead’s figure for the number of elementary discriminations per second!! We get:

2

221

36

log

NN

T

Measuring Size


- 17 -HO 2

© HY 2012

Lecture 2

Workshop 3

Critique Halstead’s approach and measures

Measuring Size


- 18 -HO 2

© HY 2012

Lecture 2

Dealing with non-text and “visual” programs.

How do we account for objects that are not textual?

How do we account for the components that are “external”?

Measuring Size


- 19 -HO 2

© HY 2012

Lecture 2

Object oriented development environments.

What might be a good measure for the length of an object oriented program?

Measuring Size


- 20 -HO 2

© HY 2012

Lecture 2

FUNCTIONALITY

Some researchers and many practitioners believe that the idea of length is misleading and the amount of functionality of the program is a better measure for its size. We shall introduce one major attempt at such metrication based on the notion of function points which are intended to measure the functionality of the system as described by a specification.

This is principally the work of Albrecht (1979).

Measuring Size


- 21 -HO 2

© HY 2012

Lecture 2

To compute the number of function points FP, we first compute an unadjusted function point count UFC. To do so, we determine the following:

External inputs, those items provided by the user that describes the distinct application oriented data (such as file menus and menu selections).

External outputs, those items provided by the user that generate distinct application-oriented data (such as reports and messages)

External inquiries, interactive input requiring response

External files, machine readable interfaces to other systems

Internal files, logical master files in the system

Measuring Size


- 22 -HO 2

© HY 2012

Lecture 2

Next, each item is assigned a subjective “complexity” rating on a three-point ordinal scale: “simple”, “average”, or “complex”. Then a weight is assigned to the item based on the following table:

Item Simple Average ComplexExternal Inputs 3 4 6

External Outputs 4 5 7

External Inquiries 3 4 6

External Files 7 10 15

Internal Files 5 7 10

Measuring Size


- 23 -HO 2

© HY 2012

Lecture 2

So, in theory there are 15 kinds of items. We can now compute the UFC by:

iW

iN

WNUFC

i

i

iii

itemfor weight theis

and , variety of items ofnumber theis where

15

1

We now calculate the function point count, FP, by multiplying UFC by a technical complexity factor, TCF, involving 14 contributing factors. These are:

Measuring Size


- 24 -HO 2

© HY 2012

Lecture 2

F1 Reliable back-up and recovery F2 Data Communications

F3 Distributed functions F4 Performance

F5 Heavily used configuration F6 Online data entry

F7 Operational ease F8 Online update

F9 Complex interface F10 Complex processing

F11 Reusability F12 Installation ease

F13 Multiple sites F14 Facilitate change

Measuring Size


- 25 -HO 2

© HY 2012

Lecture 2

COMPLEXITY

What are we measuring? Complexity of a problem, or complexity of a solution?

The complexity of a problem measures the amount of resources required to provide the optimal solution. Solution complexity is the amount of resources required for a particular solution.

The first is very difficult if not impossible to even decide, let alone measure.

For the latter, there are two attributes: time complexity and space complexity.

Measuring Size


- 26 -HO 2

© HY 2012

Lecture 2

Measuring algorithmic complexity: The big O notation

Recurrence relation

log2n, n, cn (c>0), n2, nm (m>2), 2n, n!,nn

Measuring Size


- 27 -HO 2

© HY 2012

Lecture 2

Measuring SizeOriginality:

Does reuse impact product size?

Which product is “bigger”?

A product with 100,000 lines of code of which 50,000 is written originally, 20,000 have been modified and 30,000 are reused as is.

A product with 100,000 lines of code of which all has been written originally.


- 28 -HO 2

© HY 2012

Lecture 2

Functionality

Reliability

Usability

Maintainability We seek “correctness” of the product in relation to these attributes.

Measuring Product Quality


- 29 -HO 2

© HY 2012

Lecture 2

Correctness is lack of defects.

We can assess the correctness of a product with respect to each of the quality attributes mentioned.

A fundamental measure for correctness (or lack of it) is defect density.

Defect density =Number of known defects

Product size



- 30 -HO 2

© HY 2012

Lecture 2

We could say that a product is practically correct when the defect density for the product is lower than a certain limit.

One can never say that a product is absolutely correct, as that requires knowledge of ALL defects in the product.

Given the above, we can now say about levels of correctness and change in correctness.

t

d

t

d

t

d

N

N

S

NS

N

dtN

tN

dt

N

tN

dt

td

t

dt

d

)(

)(

)(



- 31 -HO 2

© HY 2012

Lecture 2

Now if we consider a particular type of defect, we could measure correctness and its change with respect to that specific type.

Types we might consider are:

Functionality type defects (F-type)

Reliability type defects (R-type)

Usability type defects (U-type)

Maintainability type defects (M-type)

These types are non-orthogonal



- 32 -HO 2

© HY 2012

Lecture 2

But how will the product actually behave?

We need measures of expectations of performance with regards to our basic quality attributes. In other words we need to know how

Reliably, Functionally, usably and maintainably

Does the product actually behave in the field of operation.

This is a measure of perception.

But ultimately this is the most important measure to the customer (and to you).



- 33 -HO 2

© HY 2012

Lecture 2

USABILITY

The probability that the operator will not experience a user interface problem during a given period of operation under a given

operational profile.

Virtually impossible to measure in such as way to arrive at a probability distribution. We can however look at possible measures for components of usability as measures of user performance.

Note these metrics measure the performance of the user and not the usability of the system.



- 34 -HO 2

© HY 2012

Lecture 2

efficiencyert

efficiencyuserefficiencyuserrelative

timetask

timeveunproductitimetasktimeproductive

timetask

esseffectiventaskefficiencytemporal

QualityQuantityesseffectiventask

_exp

___

_

___

_

__

100_



- 35 -HO 2

© HY 2012

Lecture 2

MAINTAINABILITY

The extent to which software is easy to understand, enhance and correct.

Corrective maintenance

Adaptive maintenance

Preventive maintenance

Perfective maintenance



- 36 -HO 2

© HY 2012

Lecture 2

Basic measure is: Mean Time To Repair (MTTR).

To calculate the measure, we need careful records of:

Problem recognition time

Administrative delay time

Maintenance tools collection time

Problem analysis time

Change specification time

Change time (including testing)



- 37 -HO 2

© HY 2012

Lecture 2

RELIABILITY

A set of attributes that bear on the capability of the software to maintain its level of performance under stated conditions for a stated

period of time.

The main measures are:

Mean Time Between Failures (MTBF),

and

Mean Time To Failure (MTTF) = MTBF-MTTR



- 38 -HO 2

© HY 2012

Lecture 2

We start with the concept of the probability ( p ) that the product might fail at a particular time. The corresponding probability density function (pdf) will then describe our uncertainty about when the component will fail within time. We show that as

Therefore the probability of failure between time t1 and t2 can be written as:

)(tf

2

1

)(),( 21

t

tdttfttP

The distribution function (how long the product will behave correctly before it fails) is the probability of failure from time 0 to a given time t.



- 39 -HO 2

© HY 2012

Lecture 2

t

dttftF0

)()(

We can say the probability that a product will survive is certainty minus the probability that it will fail:

R(t) is called the reliability function.

On the other hand, Mean Time To Failure (MTTF) is the mean of the probability density function.

)(1)( tFtR

dtttfMTTF )(



- 40 -HO 2

© HY 2012

Lecture 2

Example:

Let us assume that we have a software system operating in the field and that as the software fails, the cause for that failure is eventually identified and removed. In this sense, although we do not know when the next failure will occur, we can predict (under certain conditions) that the overall failure density function will gradually decline in time. This situation can be modeled to yield a failure density function of:

tetf )(



- 41 -HO 2

© HY 2012

Lecture 2

Now, we can calculate the distribution function as:

ttt tt t eedtedttftF 00 0

)()(

Therefore

€

R(t) =1+ e−λt



- 42 -HO 2

© HY 2012

Lecture 2

A direct and a priori determination of product quality is impossible.

But we wish to establish the quality of the product before it is built.

An assessment of product quality from this perspective can only be established via the determination of the abilities of the process

employed in producing it.

Measuring the Process


- 43 -HO 2

© HY 2012

Lecture 2

We must relate these properties (attributes) of the process to either internal or external attributes of the product.

In other words:

process quality underpins product quality.

To do so, we need to have measures for process attributes of software. In other words, we need to measure the development

process.



- 44 -HO 2

© HY 2012

Lecture 2

We first need some attributes to measure, before we can measure them. So what are some aspects of the process that we might want to measure?

Cost Efficiency/Efficacy/Cost effectiveness

TimeEffort Maturity



- 45 -HO 2

© HY 2012

Lecture 2

TIME

On ratio scale

Usually measured in the conventional units of time keeping seconds, minutes, hours, days, weeks, months, and years.

The actual measurement of time is usually non-trivial. Time measurement has to be in the context of the activity being performed. For example:

Inspection time Testing time



- 46 -HO 2

© HY 2012

Lecture 2

COSTActual cost is measured in units of currency.

But cost is usually broken down into two elements of:

Fixed costs Running costs

In most software development situations, cost are bound by the “running” variety. The most significant of these is cost of work done by staff. As such most software measures of process cost are actually measures of :

Effort



- 47 -HO 2

© HY 2012

Lecture 2

Effort

Effort is measured in units of person-time!

This is a measure on the ratio scale.

Effort is usually made to relate to productivity, cost-effectiveness, efficacy, efficiency or similar concepts which are amongst the external measures of a process.

We shall examine this type of relationship later.



- 48 -HO 2

© HY 2012

Lecture 2

Relating the Product to the Process

Let’s now go back to our original three questions:

“When would the project be completed?”

“How much would it cost?”

“How good would the end product be?”

We shall now attempt to provide means to answer these questions.


- 49 -HO 2

© HY 2012

Lecture 2

Process Time EstimationHow long would the project take?

That depends on the size of the product, its complexity, how many people work on it and the quality expected of it to possess.

We now have a new fundamental problem:

How do we know what the size of the product (say in lines of code) will be BEFORE we have written it?

We don’t. We have to estimate this size.


- 50 -HO 2

© HY 2012

Lecture 2

Product Size Estimation

Many approaches all based on utilizing our past experience, so called:

Expert judgment

Or its variations:

The Delphi method

Extrapolation

In order to estimate lines of code or function points to be delivered.


- 51 -HO 2

© HY 2012

Lecture 2

Relating Product Size to Effort

Most investigators acknowledge that product size is one of the most –if not the most- important factor in determining the amount of effort required to complete a project. The other factors such as complexity or the quality required are usually incorporated as modifiers. The basic equation into which most these approaches fit is as follows:

))((1

n

ii

c XbMaE

Where E is effort, a,b and c are constants, M is a metric of product size and Xi is a modifier.


- 52 -HO 2

© HY 2012

Lecture 2

Walston and Felix (1979):

Basili and Bailey (1981):

COCOMO and COCOMO 2.0:

Mainly due to the work of Boehm and his colleagues.

Boehm (1981) Boehm et al. (1995)

COCOMO 2.0 enhances COCOMO by acknowledging that Lines-of_Code estimates are not available early in the development.


16.173.05.5 ME

91.025.5 ME


- 53 -HO 2

© HY 2012

Lecture 2


COCOMO: EAFaME c

Again, E is effort, a and c are constants that depend on the complexity of the project, M is a metric of size, in this case lines_of_code, and EAF is the result of all effort adjustments factors having been multiplied together.

COCOMO recognizes three different types of projects. These are: Organic, Semi-detached, and Embedded, in terms of increasing complexity.

COCOMO also comes in three flavors, Basic, Intermediate and Advanced.


- 54 -HO 2

© HY 2012

Lecture 2


Basic COCOMO only considers size as the variable

Intermediate COCOMO considers size and a set of “cost drivers” .

Advanced COCOMO considers the impact of cost drivers on all intermediate stages (e.g. design) of the project.

We shall look at intermediate COCOMO. EAFaME c Project Type a c

Organic 3.2 1.05Semidetached 3.0 1.12

Embedded 2.8 1.20


- 55 -HO 2

© HY 2012

Lecture 2


COCOMO 2.0

As size in lines of code can not be determined accurately in the early stages of the project, COCOMO 2.0 recognizes three sizing stages in any project,

Stage 1, we size the project using Object points

Stage 2, We size the project using Function points

Stage 3, we size the project using Lines_of_code.

Each of these measures will depend on the complexity of the components involved, personnel factors such as productivity, technology factors and the quality to be achieved.


- 56 -HO 2

© HY 2012

Lecture 2

Relating Product Size to CostHow much would it cost?

Cost is basically bound by variable costs which is a factor of time and number of people. If we have an estimate for the total effort, E, say by using an estimation technique such as COCOMO, and an average cost per person-month, then calculating the total project cost is easy:

C is cost in units of currency, E is effort in Person-month and

is the rate of pay for staff in units of currency per month.

To this of course we must add all the fixed costs of the project.

REC

R


- 57 -HO 2

© HY 2012

Lecture 2

Relating Product Size to TimeWe might ask, how long would this project take?

This is not as easily answered as by dividing the effort figure by the number of staff in the team. Staff members come and go, have different productivity, are specialists that work only in a given phase, etc. Thus more sophisticated, experientially based models are needed and indeed have been developed. For example COCOMO has an effort to time relationship which is as follows:

fdET

Where d and f are constants and E is effort in person-months.

Project Type d f

Organic 2.5 0.38Semidetached 2.5 0.35

Embedded 2.5 0.32


- 58 -HO 2

© HY 2012

Lecture 2

Relating Product Quality to Process

How good will the product be?

We can’t tell before hand but we know that product quality is influenced by process quality, unfortunately, we do not know exactly how,

YET.Therefore, planning, use of methodologies, technologies and management approaches that have been demonstrated to be effective are essential to our success: but that is the definition of Software Engineering!


- 59 -HO 2

© HY 2012

Lecture 2

References

Albrecht, A.J.; “Measuring application development”; Proceedings of IBM Applications Development Joint SHARE/GUIDE Symposium; Monterey, CA; pp 83-92; 1979

Bailey, J.W.; Basili, V.R.; “A meta-model for software development resource expenditure”; Proc. 5th International Conference on Software Engineering; 1981.

Boehm, B.W.; “Software Engineering Economics”; Prentice-Hall, 1981; NJ, USA.

Boehm, B.W.; Clarl, C.;Horowitz, E; Westland; C; Madachy, R; Selby, R.; “Cost models for future life cycle processes:COCOMO 2.0”; Annals of SE, 1(1); November, 1995.

Halstead, M.H.; “Elements of Software Science”; Elsevier; 1975.

Walston, C.E.; Felix, C.P.; “A method of programming measurement and estimation”; IBM Systems Journal; 16(1); 1979

ECSE 6770- Software Engineering - 1 - HO 2 © HY 2012 Lecture 2 Managing the Software Process We...

Documents

Transcript of ECSE 6770- Software Engineering - 1 - HO 2 © HY 2012 Lecture 2 Managing the Software Process We...