CS 594 Software Engineering

T. E. Potok - University of Tennessee

CS 594Software Engineering

Lecture 2

Dr. Thomas E. [email protected]

865-574-0834

Software Engineering CS 594


2

Agenda

Review Requirements, JAD, and Use Case Modeling

Project Size Estimates Software Development Life-Cycles Software Development

Productivity



3

Admin

Power point files accessible? Articles accessible? AMI - American Magnetics

• Main requirements • Estimate how much time the project will

take • Estimate the cost of the project



4

What is relevant?

Test are open book and open notes Know CMM

– What are the benefits to a company adopting CMM?

Know requirements modeling– What is the fundamental difference

between the output of a JAD session and use cases?


Review



6

Entity Relationship Modeling Entities represent things Attributes represent characteristics of

the things Relationship represent associations

between things Entities: Cat, Dog, Person, Car,

Building Attributes: name, age, height, weight Relationships: owns, drives, pets, builds


Project Size Estimations



8

Metrics Measuring the output of a process is the first step to

analyzing the process. Automobile companies measure how many

manufacturing hours go into producing a car. As with any measurement, there are problems. You are

trying to summarize a great deal of information into a single or small number of values.

How much does the high and low temperatures really tell you about the weather, or the barometric pressure, or the wind direction.

Looking at any one of these measures it is easy to find flaws, and short comings. – Should the temperature be recorded at ground level? or a top a

central tower? in the shade or in the sunlight.



9

Lines-of-code

What unit of measure should be used to measure software output?

The traditional and much maligned metric is called lines-of-code or LOC.

A summary of concerns with LOC:– Capers Jones notes:– 1) should the code count include non-executable code,

such as comments, or explanatory information. – 2) how are differences between high-level and low-level

languages represented. – 3) Whether non-delivered code should be represented in a

LOC count. – So, it appears that LOC counts may not be the best way to

measure software development output.



10

Function Points

If not LOC, then what?? Many other metrics have been developed. Most of

these metrics have major flaws. Albrecht developed Function Point Analysis (FPA)

in the late 70’s This method assumes that “the amount of function

to be provided by the application (program) can be estimated from an itemization of the major components of data to be used or provided by it”.

Albrecht believes that the complexity of a software project is determined by the functions of the software.



11

More on Function Points

FPA breaks the functionality of a software project into five areas.

Then for each area, the number of simple, average, and complex functions is determined, followed by a technical complexity factor calculated from 14 software system characteristics.

These 14 characteristics are tied to Halstead’s Software Science Metrics which are tied to Putnam’s cost estimation models, which are based on Norden’s Rayleigh Curve model first published in the late 50’s based on computer hardware development.



12

So LOC is not so bad after all A big problem with Rayleigh Curves is that for

early software development data, the curves appear to fit, but no one can explain why.

Beside that fact that function points have a shaky theoretical background, it is much harder to generate function points than LOC, therefore few use them.

Like the imperial measurement system, it is clearly inferior to the metric system, however, until people use the metric system, it will be of little relevance to most people.

Therefore, we will proceed with using line-of-code, being careful to minimize Jone’s issues



13

How long will the project take? Estimate of the size of a project

– Lines of code– Function points– Person-months

Based on requirements and experience or mathematical model


Software Development Life-cycle



15

Typical Life-cycle

Requirements Design Code Test Maintenance



16

Software Development Effort A team of programmers puts effort into

developing software Ideally measured in person-months, with

distinctions made for the type of effort– Design– Programming– Testing– Training

Often all that is available is the calendar time spend on developing software



17

Productivity

Team Productivity = Project Output/Project Effort

Programmer productivity = Programmer Output/Programmer Effort

Productivity typically measured in LOC/Person-month



18

Productivity Example

Need to produce 10,000 LOC, 10 KLOC.

Average programmer productivity = 200 LOC/Person-month (US average)

How many people do I need? How long will it take?



19




20


Time

EffortPeople

People

EffortTime

5months 10

monthsperson 50People



21

People vs Months

Effort

0

5

10

15

20

25

30

35

40

0 10 20 30 40 50 60

Calendar Months

Peo

ple

People Months50.0 125.0 216.7 312.5 410.0 58.3 67.1 76.3 85.6 95.0 104.5 114.2 123.8 133.6 143.3 153.1 162.9 172.8 182.6 192.5 20



22

Results

We can develop 10 KLOC in one month with 50 people, or

2 People in 25 months Assumes that the interaction

among people does not results in a productivity penalty

Total of 50 Person-months of effort needed



23

Productivity Loading Curve

Productivity Curve

0

0.5

1

1.5

2

2.5

0 5 10 15 20 25 30

Calendar Months

Pe

rso

n-M

on

ths

Assumes two people can start immediately and work full-time on the project



24

Software development life-cycle Early researchers found that labor

distribution of hardware and software development follows a Rayleigh distribution

2

2

2Dt

t

D

et

tpmPY

Where t = month, tD = month at peak effort



25

Rayleigh CurvesPeak effort at 7 months - Requiring 5 People50 total person-months of effort required

Rayleigh Curve

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

0 5 10 15 20 25 30

Calendar Months

Per

son

-mo

nth

s



26

Life-Cycle

Rayleigh Curve

0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

9.0

0 5 10 15 20 25 30

Calendar Months

Per

son

-mo

nth

sRequirements Design Code Test Maintenance



27

Putnam’s Slim Model

3

4

3

1

1 dks tKCdtyPRs Where S is the number of lines of codePR is the average productivityy is the Rayleigh loading curvet is timeC is the state of technologyK is the effort applied

4dt

CK



28

Effort ComparisonsEffort Models

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

40.0

0 5 10 15 20 25 30 35 40

Months

Eff

ort

Linear

SLIM


Productivity Studies



30

Background

Statistical Model– Little knowledge of the underlying

system– Given there is sufficient data, and

that the data is normally and independently distributed!

– Regression provides a linear model that provides a least squares fit to the data



31

Linear Regression

Where is an estimate of the mean of Y, and are numerical estimated of the parameters

Sample Regression Line

0

5

10

15

20

25

0 2 4 6 8 10 12

iii EY iY



32

Multiple Regression

ikki EY ...11

Similar processing to linear regression

Provides the ability to determine what factors are most significant



33

Many early studies applied regression Data gathered from multiple

software project Log-linear relationship found

between project size and effort

Where PM are person-months, KLOC is thousands of lines of code

ln(PM) = ln() + ln(KLOC)+ .



34

Typical Effort Vs Project Size Curve

Typical Log-linear Effort Curve

0

2000

4000

6000

8000

10000

12000

14000

0 100000 200000 300000 400000 500000 600000

Lines of code

Eff

ort



35

Some interesting results

Diseconomy of scale - larger projects need proportionately more effort

Many factors influencing productivity– Early studies show people are the major

factor in productivity– High productivity project have

experienced, well trained people



36

Summary

Project Size Estimates Software Development Life-Cycles Software Development

Productivity

Documents

CS 594 Software Engineering