Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Guide to Computer Forensics and Investigations, 2e CC20O7N Software

Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1

Software Project Management

Introduction to

Estimating Development Effort

(courtesy of “Software Project management –

Hughes & Cotterell” 4th Edition)

Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1

What Makes a Successful Project?

Delivering: agreed functionality on time at the agreed cost with the required

quality

Stages: set targets attempt to achieve

targets

BUT what if the targets are not achievable?


Over and Under-estimating

Parkinson’s Law: ‘Work expands to fill the time available’

An over-estimate is likely to cause project to take longer than it would otherwise

(http://www.heretical.com/

miscella/parkinsl.html)

Weinberg’s Zeroth Law of reliability: ‘a software project that does not have to meet a reliability requirement can meet any other requirement’

(http://eppsnet.com/tag/

jerry-weinberg)


A Taxonomy of Estimating Methods

Expert opinion - just guessing? Bottom-up - activity based Parametric e.g. function points Analogy Parkinson and ‘price to win’


Estimation Techniques


Heemstra and Kusters Survey

Expert judgement 25.5% Analogy 60.8% ‘Capacity problem’ 20.8% Price-to-win 8.9% Parametric models 13.7%


Pricing to Win The project costs whatever the customer

has to spend on it. Advantages:

– You get the contract. Disadvantages:

– The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required.


Heemstra and Kusters (cont.)

Only 50% kept project data on past projects - but 60.8% used analogy!

35% did not produce estimates 62% used methods based on intuition -

only 16% used formalized methods Function point users produced worse

estimates!


Top-down versus Bottom-up

Top-down– produce overall estimate based on project cost

drivers– based on past project data

Bottom-up– use when no past project data


Top-down Estimates

Produce overall estimate using effort driver(s)

distribute proportions of overall estimate to components

design code

overall project

test

Estimate100 days

30%i.e.30 days

30%i.e.30 days

40%i.e. 40 days


Bottom-up Estimating

1. Break project into smaller and smaller components

2. Stop when you get to what one person can do in one/two weeks

3. Estimate costs for the lowest level activities

4. At each higher level calculate estimate by adding estimates for lower levels


Parametric Models

COCOMO (lines of code) and function points examples of these problem with COCOMO etc:

guess algorithm estimate

but what is desired issystem

characteristicalgorithm estimate


Parametric Models (cont.)

Examples of system characteristics– no of screens x 4 hours– no of reports x 2 days– no of entity types x 2 days

the quantitative relationship between the input and output products of a process can be used as the basis of a parametric model


Conventional Methods:LOC/FP Approach

Compute LOC/FP using estimates of information domain values

• Line of Code (LOC)• Function Point (FP)

Use historical effort for the project


Example: LOC Approach

Functions

UICF

2DGA

3DGA

DSM

CGDF

PCF

DAM

Totals

estimated LOC $/LOC Cost Effort (months)LOC/pm

2340

5380

6800

3350

4950

2140

8400

33,360

14

20

20

18

22

28

18

315

220

220

240

200

140

300

32,000

107,000

136,000

60,000

109,000

60,000

151,000

655,000

7.4

24.4

30.9

13.9

24.7

15.2

28.0

145.0


Example: FP Approach

number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces algorithms

measurement parameter

4 5 4 7 7 3

count

x x x x x x

count-total

= = = = = =

weight

complexity multiplier

feature points

0.25 p-m / FP = 120 p-m

40 25 12 4 4 60

160 125 48 28 28 180

569

.84

478


Parametric Models – the Need for Historical Data

simplistic model for an estimate

estimated effort = (system size) / productivity e.g.

system size = lines of code

productivity = lines of code per day productivity = (system size) / effort

– based on past projects


Parametric models Some models focus on task or system size

e.g. Function Points FPs originally used to estimate Lines of

Code, rather than effortNumber

of file types

model

Numbers of input and output transaction types

‘systemsize’


Parametric Models Other models focus on productivity: e.g.

COCOMO Lines of code (or FPs etc.) an input

SystemSize

Productivity Factors

Estimated Effort


System Size: Function Points

Based on work at IBM 1979 onwards– Albrecht and Gaffney wanted to measure the

productivity independently of lines of code.– has now been developed by the International FP

User Group (which is US based).– Mark II FPs developed by Simons mainly used

in UK.


Function points Mark II Developed by Charles R. Symons ‘Software sizing and estimating - Mk II FPA’,

Wiley & Sons, 1991. Builds on work by Albrecht Work originally for CCTA(

Consumer Credit Trade Association): – should be compatible with SSADM; mainly

used in UK has developed in parallel to IFPUG FPs IFPUG (International Function Point Users Group)


Function Points Mk II (Cont.) For each

transaction, count– data items input

(Ni)

– data items output (No)

– entity types accessed (Ne)

#entities accessed

#inputitems

#outputitems

FP count = Ni * 0.58 + Ne * 1.66 + No * 0.26


Using Mark II Function Points Calculate FPs for each transaction in a

system Total transaction counts to get a count for

the system Recall that

estimated effort = size (FPs) x productivity rate (effort per FP)

Productivity rate obtained from past projects


Estimating by Analogy

source cases

attribute values

effort

attribute values ?????

target case

attribute values

attribute values

attribute values

attribute values

attribute values

effort

effort

effort

effort

effortSelect case with closet attributevalues

Use effortfrom source as estimate


Estimating by Analogy

Identify significant attributes (‘drivers’) Locate closest match amongst source cases

for target Adjust for differences between source and

target


Stages: Identify

Significant features of the current project Previous project(s) with similar features Differences between the current and

previous projects Possible reasons for error (risk) Measures to reduce uncertainty


Some Conclusions: how to review estimates

Ask the following questions about an estimate What are the task size drivers? What productivity rates have been used? Is there an example of a previous project of

about the same size? Are there examples of where the productivity

rates used have actually been found?


Estimating the size of the measure (e.g. how many function points).

Estimating the total number of programmer months that have elapsed.

Estimating contractor productivity (e.g. documentation team) and incorporating this estimate in overall estimate.

Measurement Problems


System Development Times


Real-time embedded systems, 40-160 LOC/P-month.

Systems programs , 150-400 LOC/P-month. Commercial applications, 200-900

LOC/P-month. In object points, productivity has been

measured between 4 and 50 object points/month depending on tool support and developer capability.

Productivity Estimates


Changing Technologies Changing technologies may mean that previous

estimating experience does not carry over to new systems– Distributed object systems rather than mainframe

systems;– Use of web services;– Use of Enterprise Resource Planning (ERP) or

database-centred systems;– Use of off-the-shelf software;– Development for and with reuse;– Development using scripting languages;– The use of CASE tools and program generators.


Estimate uncertainty

x

2x

4x

0.5x

0.25x

Feasibility Requirements Design Code Delivery


The COCOMO Model An empirical model based on project experience. Well-documented, ‘independent’ model which is

not tied to a specific software vendor. Long history from initial version published in 1981

(COCOMO-81) through various instantiations to COCOMO 2.

COCOMO 2 takes into account different approaches to software development, reuse, etc.


COCOMO 81


COCOMO 2 COCOMO 81 was developed with the

assumption that a waterfall process would be used and that all software would be developed from scratch.

Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development.


COCOMO 2 models COCOMO 2 incorporates a range of sub-models

that produce increasingly detailed software estimates.

The sub-models in COCOMO 2 are:– Application composition model. Used when software is

composed from existing parts.– Early design model. Used when requirements are

available but design has not yet started.– Reuse model. Used to compute the effort of

integrating reusable components.– Post-architecture model. Used once the system

architecture has been designed and more information about the system is available.


Use of COCOMO 2 ModelsNumber of

application points

Number of functionpoints

Based on Used for

Used for

Used for

Used for

Based on

Based on

Based on

Number of lines ofcode reused or

generated

Number of lines ofsource code

Applicationcomposition model

Early design model

Reuse model

Post-architecturemodel

Prototype systemsdeveloped using

scripting, DBprogramming etc.

Initial effortestimation based onsystem requirementsand design options

Effort to integratereusable components

or automaticallygenerated code

Development effortbased on system

design specification


Application Composition Model Supports prototyping projects and projects where

there is extensive reuse. Based on standard estimates of developer

productivity in application (object) points/month. Takes CASE tool use into account. Formula is

– PM = ( NAP (1 - %reuse/100 ) ) / PROD

– PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.

Documents

Guide to Computer Forensics and Investigations, 2e CC20O7N Software Engineering 1 Guide to Computer Forensics and Investigations, 2e CC20O7N Software