Unit Ii

MCA-209, Software Engineering
SOFTWARE
ENGINEERING
Software Project Planning &
Software Design
UNIT II
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Anukiran Jian
U2.
1
Learning Objectives
Software Project Planning
Size Estimation
lines of Code
Function Count
Cost Estimation Models
COCOMO
COCOMO-II
Putnam resource allocation model
Risk Management.
Software Design
Cohesion & Coupling
Classification of Cohesiveness & Coupling
Function Oriented Design
Object Oriented Design
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Anukiran Jain
U2.
2
U2.
3
U2.1
Learning Objectives
Characteristics of project manager

The Steps
Activities during SPP
Size Estimation
Lines of code (LOC)
Function count
Cost Estimation
Estimation Techniques
Empirical Estimation Models
The Constructive Cost Model (COCOMO)
COCOMO II
Putnam Resource Allocation Model
U2.
4
Characteristics of Project Manager

A person with the ability to know what will go wrong
before it actually does and the courage to estimate
when the future is cloudy
U2.
5

The overall goal of project planning is to
establish a pragmatic strategy for controlling,
tracking, and monitoring a complex technical
project.
Why?
So the end result gets done on time, within
budget and with quality!
U2.
6
U2.2
The Steps
Scopingunderstand the problem and the work that
must be done
Estimationhow much effort? how much time?
Riskwhat can go wrong? how can we avoid it?
what can we do about it?
Schedulehow do we allocate resources along the
timeline? what are the milestones?
Control strategyhow do we control quality? how
do we control change?
U2.
7
Write it Down!
Project Scope
Estimates
Software
Software
Project
Project
Plan
Plan
Risks
Schedule
Control
strategy
U2.
8
Activities During SPP

Size Estimation
Development Time
Cost Estimation
Resources
Requirements
Project Scheduling
U2.
9
U2.3
Size Estimation
Critical & Difficult area of the project planning
Conventional Methods (LOC/FP Approach)
compute LOC/FP using estimates of information
domain values
use historical effort for the project
U2.
10
Lines of Code (LOC)

First measurement attempted
Easily recognizable uses different approaches
Dont include data declarations, comments or
any other lines that did not result in object code
Include declaration and any other unexecutable
statement but exclude blank lines and
comments
01
Int sort (int x[], int n)
02
03
Int I, j, save, im1;
04
/* This function sorts array x in ascending order */
05
If (n <2) return 1;
06
For ( I=2; I<= n; I++)
07
U2.
11
08
IM1 = I-1
09
for(j=1; j<= im; j++)
10
IF (X[I] < x[j])
11
12
Save = x[I];
13
x[I] = x[j];
14
x[j] = Save;
15
16
17
Return 0
18
U2.
12
U2.4
LOC cont..
Include all lines
18 LOC
When comments and blank lines are ignored
17 LOC
Executable statements
13 (5-17)
U2.
13
LOC cont..
Language dependent
Reflect what the system is rather than what it does
Useful in estimating programming time for a program during
the build phase of a project
Usefulness is limited for functionality, complexity, efficiency
etc.
U2.
14
Productivity Comparisons
The
lower
level
the
productive the programmer
the
more
The same functionality takes more code to implement in a

lower-level language than in a high-level language
The more verbose

the productivity
language,
the
programmer,
the
higher
Measures of productivity based on lines of code suggest that

programmers who write verbose code are more productive
than programmers who write compact code
U2.
15
U2.5
High and Low Level Languages
Low-level language
Analysis
Design
Coding
Validation
High-level language
Analysis
Design
Coding
Validation
U2.
16
System Development Times
Analysis Design Coding Testing Documentation

Assembly code
3 weeks 5 weeks 8 weeks 10 weeks
2 weeks
High-level language 3 weeks 5 weeks 8 weeks 6 weeks
2 weeks
Size
Effort
Productivity
Assembly code
5000 lines
28 weeks 714 lines/month
High-level language 1500 lines
20 weeks 300 lines/month
U2.
17
Example: LOC Approach in SPP

Functions estimated LOC LOC/pm
$/LOC
Cost
Effort (months)
UICF
2300
315
14
32,000
7.4
2DGA
5300
220
20
107,000
24.4
3DGA
6800
220
20
136,000
30.9
DBM
3350
240
18
60,000
13.9
CGDF
4950
200
22
109,000
24.7
PCF
2100
140
28
60,000
15.2
300
18
151,000
28.0
655,000
145.0
DAM
Totals
8400
33,200
U2.
18
U2.6
Function Count
Introduce by Alan Albrecht while working for IBM in
the 1970s
Measures functionality from the user point of view
Deals with the functionality being delivered
U2.
19
Albrecht's Function Point Analysis Principle

Decomposed into functional units
Transactional Function Types
Inputs :
Information entering the system
Outputs:
Information leaving the system
Enquiries
Requests for instant access to information
Data Function Types
Internal logical files
Information held within the system
External interface files
Information held by other systems that is used by the
system being analyzed
U2.
20
FPA Functional Units

User
Inquiries
Inputs
ILF
User
Outputs
System
Other
applications
EIF
ILF: Internal Logical Files

EIF : External Interfaces
U2.
21
U2.7
Special Features
Independent of the language, tools or methodologies used

for implementation
Can be estimated from requirement specifications or design
specifications, so possible to estimate development effort in
early phases of development
Directly linked to the statement of requirements; any
change in requirements can easily be followed by a reestimate
Based on the system users external view of the system,
easy to understand by non-technical users
FPs are very subjective. They depend on the estimator.
Automatic function-point counting is impossible
U2.
22
Counting Function Points cont..

Counted by considering a linear combination of five basic
software components, each at one of three levels
Simple
Average
Complex
5 3
UFP = Wij Zij ;

I=1j=1
Zij is the count for components i at level j

Wij Fixed weight (language-dependent factor varying
from 200-300 for assemble language to 2-40 for a
4GL)
Also known as unadjusted function points (UFP).
U2.
23
Counting Function Points

Software Components
Weighting Factors
Simple
Average Complex
user inputs
user outputs
user inquiries
Internal logical files
10
15
external interfaces
10
U2.
24
U2.8
Counting Function Points cont..

Final number is arrived by multiplying the UFP by an
adjustment factor; determine by considering 14 aspects
of processing complexity
FP = UFP * CAF
CAF; complexity adjustment factor, equal to [0.65+0.01* Fi]
Fi (i = 1 to 14) ; degree of influence
No
:0
Incidental : 1
Moderate : 2
Average
:3
Significant : 4
Essential
:5
U2.
25
Factors Considered
1.
2.
3.
4.
5.
Does the system require reliable backup and recovery

Is data communication required
Are there distributed processing functions
Is performance critical
Will the system run in an existing heavily utilized operational
environment
6. Does the require on line data entry
7. Does the the on line data entry requires the input transaction
to be built over multiple screens or operations
8. Are the master files updated on line
U2.
26
Factors Considered Cont..

9.
10.
11.
12.
13.
Is the inputs, outputs, files or inquiries complex

Is the internal processing complex
Is the code designed to be reusable
Are conversion and installation included in the design
Is the system designed for multiple installation in different
organizations
14. Is the application designed to facilitate change and ease of
use by the user
U2.
27
U2.9
Typical Function-Oriented Metrics

defects per FP; Quality
$ per FP; Cost
pages of documentation per FP; Documentation
FP per person-month; Productivity
U2.
28
Function Count Example

Compute the function point value for a
project with the following information
Number of user inputs
Number of user outputs
Number of user inquiries
Number of files
Number of external interfaces
= 32
= 60
= 24
= 08
=2
4
5
4
10
7
Assume that all complexity adjustment

values and weighting factors are
average. Assume that 14 algorithms
have been counted
5 3
UFP = Wij Zij ;

I=1j=1
CAF= (0.65+ 0.01 Fi)

FP = UFP* CAF
U2.
29
Function Count Example cont..

5
UFP
= Wij Zij ; J = 2
I=1
CAF
FP
= 32*4+60*5+24*4+8*10+2*7
= 618
= (0.65+ 0.01 Fi)
= 0.65+0.01(14*3)
= 1.07
= UFP* CAF
= 661.26
U2.
30
U2.10
Cost Estimation
Common attributes for any cost

estimation technique
project scope must be explicitly
defined
task and/or functional decomposition
is necessary
historical measures (metrics) are
very helpful
at least two different techniques
should be used
remember that uncertainty is inherent
U2.
31
To achieve reliable cost & schedule estimates , a number of
options arise:
Delay estimation until late in project
past (similar) project experience
conventional estimation techniques
task breakdown and effort estimates
Develop empirical models for estimation
Acquire one or more automated estimation tools
U2.
32
Empirical Estimation Models

Model is concerned with the representation of the process to be
estimated
Two types of model
Static
A unique variable (say, size) is taken as a key element for
calculating all others (say, cost, time etc.)
The form of equation used is the same for all calculations.
Dynamic
All variables are interdependent and there is no basic
variable as in the static model
U2.
33
U2.11
Empirical Estimation Models cont..
Single variable model :

Use single basic variable to calculates all others
Multivariable model:
Several variables are needed to describe the
software development process, and selected
equations combine these variables to give the
estimate of time and cost
Predicator
The variables, that are input to the model to predict
the behavior of a software development are called
predictors
U2.
34
Empirical Estimation Models cont..
General form:
effort = tuning coefficient * size
exponent
usually derived
as person-months
either a constant or
a number derived based
on complexity of project
empirically
derived
usually LOC but
may also be
function point
U2.
35
Static, Single Variable Models

Use an equation to estimate the desired values such as cost,
time, effort etc
Depend on the same variable used as predictor ( say, size)
C= aLb
C
: cost
L
: size
a&b
: constants derived from the historical data of the
organization
A & b depend on the local development environment, these
models are not transportable to different organizations
U2.
36
U2.12
Static, Single Variable Models cont..

The software Engineering Laboratory of the university of
Maryland has established a model, the SEL model, for
estimating its own software production
E = 1.4 L 0.93
Effort (person-month)
DOC = 30.4 L 0.90
Documentation (number of pages)
D = 4.6 L 0.26
Duration ( month)
L : number of lines of code ( thousands of lines) used as
predictor
U2.
37
Static, Multi Variable Models

Depends on several variables representing various aspects
of the software development environment, for example,
method used, user participation, customer oriented
changes, memory constraints etc.
Develop by Walston and Felix at IBM
E = 5.2 L 0.91
D = 4.1 L0.36
L ; source code in thousands of lines
E ; effort in person-month
D ; development in month
U2.
38
Static, Multi Variable Models..

Productivity index uses 29 variables
29
I = Wi Xi ;
I=1
Wi weight factor for ith variable and Xi one of the

values 1,0 or +1 depending on whether the
variable decreases, has no effect, or increases the
productivity respectively
U2.
39
U2.13
Example
Compare the Walston-Felix model with SEL model on a
software development expected to involve 8 personyears of effort
Calculate the number of lines of source code that can
be produced
Calculate the duration of the development
Calculate the productivity in LOC/PY
Calculate the average manning
SEL
Walston-Felix
E = 1.4 L 0.93
E = 5.2 L 0.91
DOC = 30.4 L 0.90
D = 4.1 L0.36
D = 4.6 L 0.26
U2.
40
Example cont..
The amount of man power involved = 8 PY = 96 person-month
a) L = (E/a)1/b
L (SEL) = (96/1.4)1/0.93 = 94264 LOC
L (W-F) = (96/5.2)1/0.91 = 24632 LOC
b) D (SEL) = 4.6(94.264)0.26 = 15 months
D (W-F) = 4.1(24.632)0.36 = 13 months
c) P (SEL) = LOC/PY = 94264/8 = 11783 LOC/ PY
P (W-F) = LOC/PY = 24632 /8 = 3079 LOC/ PY
d)
Average manning is the average number of persons required per
month in the project.
M (SEL) = 96pM/15M = 6.4 persons
M (W-F) = 96pM/13M = 7.4 persons
U2.
41
The Constructive Cost Model (COCOMO)
one of the most widely used software estimation model in

the world.
Introduced by Barry Boehm in 1981 in his classic book
Software Engineering Economics
predicts the effort and schedule for a software product
development based on inputs relating to the size of the
software and a number of cost drivers that affect
productivity.
has three different models according to the complexity of
the model:
the Basic Model,
the Intermediate Model,
the Detailed Model
U2.
42
U2.14
Basic Model
Applicable to small to medium sized software projects
Use for a quick and rough estimates
Three modes of software development are
considered
Organic
Semi-detached
Embedded
Organic Mode
A small team of experienced programmers develop

software in a very familiar environment
Require little Innovation
Size range ( 0-50 KLOC)
U2.
43
Basic Model cont..

Embedded mode
Project has tight constraints
Problem to be solved is unique
Hard to find experienced persons
Require significant Innovation
Development environment is complex
Size range ( over 300 KLOC)
U2.
44
Basic Model cont..

Semi-detached mode
An intermediate mode between the organic mode and
embedded mode
Depending on the problem at hand, the team include the
mixture of experienced and less experienced people
Require medium Innovation
Development environment is medium
Size range ( 50 - 300 KLOC)
U2.
45
U2.15
COCOMO - Model
Project Characteristics
Develo
pment
Model
Size
Organic
Small
Medium
Semidetache
d
Embed
ded
Innovati Deadline/ Developm

Constrain
ent
on
ts
Large
Little
Not Tight
Mediu
m
Medium
Greater
Tight
Environme
nt
Stable
Medium
Complex
hardware/
Customer
Interface
U2.
46
Basic Model cont..

The basic COCOMO equation
E = ab(KLOC)bb
D = Cb(E)db
E; effort applied in Person-Months
D; development time in months
ab, bb , cb, db ; the coefficients
U2.
47
Basic COCOMO Coefficients

Project
ab
bb
cb
db
Organic
2.4
1.05
2.5
0.38
Semi detected
3.0
1.12
2.5
0.35
Embedded
3.6
1.20
2.5
0.32
E = ab(KLOC)bb
D = Cb(E)db
U2.
48
U2.16
Basic COCOMO Model Example

Suppose that a project was estimated to be 400 KLOC.
Calculate the effort and development time for each of the
three modes I.e., organic, semidetached and embedded
The basic COCOMO equation take the form:
E = ab(KLOC)bb
D = Cb(E)db
Project
ab
bb
cb
db
Organic
2.4
1.05
2.5
0.38
Semi detected
3.0
1.12
2.5
0.35
Embedded
3.6
1.20
2.5
0.32
U2.
49
Basic COCOMO Model Example cont..

E = ab(KLOC)bb
D = Cb(E)db
Organic Mode
E = 2.4(400)1.05
= 1285.31 PM
D = 2.5(1285.31)0.38 = 38.07 M
Semidetached ModeE = 3.0(400)1.12
= 2462.79 PM
Embedded Mode
D = 2.5(2462.79)0.38 = 38.45 M
E = 3.6(400)1.20
= 4772.81 PM
D = 2.5(2462.79)0.32 = 38 M
U2.
50
Intermediate Model
Boehm introduces set of 15 predictors called cost
drivers in the intermediate model to take account
of the software development environment
Cost drivers are used to adjust the nominal cost of a
project to the actual project environment
U2.
51
U2.17
Intermediate Model cont..

The multiplying factors for all 15 cost drivers are multiplied to
get the effort adjustment factor (EAF).
Typical values fro EAF range from 0.9 to 1.4
The intermediate COCOMO equation
E = ai (KLOC)bi * EAF
D = ci (E) di
very tedious to use on a product with many components
U2.
52
Cost drivers
Grouped into four categories:
Product attributes
Required software reliability (RELY)

Database Size (DATA)
Product Complexity (CPLX)
Computer attributes
Execution time constraint (TIME)

Main storage constraint (STORE)
Virtual machine volatility (VIRT)
Computer turnaround time (TURN)
U2.
53
Cost drivers cont..

Personnel attributes
Analyst capability (ACAP)
Application experience (AEXP)
Programmer capability (PCAP)
Virtual machine experience (VEXP)
Programming language experience (LEXP)
Project attributes
Modern programming practices (MODP)
Use of software tools (TOOL)
Required development schedule (SCED)
Each cost driver is rated for a given project environment
using a scale very low, low, nominal, high, very high, extra
high
U2.
54
U2.18
Cost drivers Product attributes

Cost Driver
Very
Low
Lo
w
Nominal
High
Very
High
.75
.88
1.00
1.15
1.4
.94
1.00
1.08
1.16
.85
1.00
1.15
1.30
Extra
High
Product Attributes
RELY Required software reliability
DATA Data base size
CPLX Product Complexity
.70
1.65
U2.
55
Cost Drivers Computer Attributes

Cost Driver
Very
Low
Nominal
High
Very
High
Extra
High
TIME Execution time

constraint
1.00
1.11
1.3
1.66
STOR Main storage constraint
1.00
1.06
1.21
1.56
Lo
w
Computer Attributes
VIRT Virtual machine

volatility
.87
1.00
1.07
1.15
TURN Computer turnaround

time
.87
1.00
1.07
1.15
U2.
56
Cost drivers Personnel Attributes

Cost Driver
Very
Low
Lo
w
ACAP Analyst capability
1.46
1.19
AEXP Application experience
1.29
PCAP Programmer capability
Nominal
High
Very
High
1.00
.86
.71
1.13
1.00
.91
.82
1.42
1.17
1.00
.86
.70
VEXP Virtual machine experience
1.21
1.10
1.00
.90
LEXP Programming lang.

experiences.
1.14
1.07
1.00
.95
Extra
High
Personnel Attributes
U2.
57
U2.19
Cost Drivers Project Attributes

Cost Driver
Very
Low
Lo
w
Nominal
High
Very
High
MODP Use of modern prog.

practices
1.24
1.10
1.00
.91
.82
TOOL Use of software tools
1.24
1.10
1.00
.91
.83
SCED Required development

schedule
1.23
1.08
1.00
1.04
1.10
Extra
High
Project Attributes
U2.
58
Intermediate Model cont..

The multiplying factors for all 15 cost drivers are
multiplied to get the effort adjustment factor (EAF).
Typical values fro EAF range from 0.9 to 1.4
The intermediate COCOMO equation
D = ci (E) di
very tedious to use on a product with many

components
U2.
59
Coefficient for Intermediate COCOMO

Project
ai
bi
ci
di
Organic
3.2
1.05
2.5
0.38
Semidetached 3.0
1.12
2.5
0.35
Embedded
1.20
2.5
0.32
2.8
D = ci (E) di
U2.
60
U2.20
Example
Project A is to be a 32,000 LOC semi-detached
software. It is only a feasibility demonstration
model (RELY=very low=0.75). Then we can
estimate:
; 3.0; 1.12
0.35
D = ci (E)di
; 2.5;
Effort
= 3.0*(32)1.12 * 0.75 = 109 PM
Productivity
= 32,000 LOC/109 PM = 291 LOC /PM
Schedule
= 2.5*(109)0.35 = 13 months
Average Staffing
= 109 PM/13 months = 8.4 Persons
U2.
61
Detailed COCOMO Model

The Detailed model differs from the intermediate
model in two aspects:
Phase-sensitive Effort Multipliers

The effort multipliers for every cost drivers are different
during the software development phases.
These multipliers are used to determine the amount of
effort required to complete each phase.
The Module-Subsytem-System Hierarchy

The software product is estimated in the three level
hierarchical decomposition.
The 15 cost drivers are related to module or subsystem
level.
U2.
62
Detailed COCOMO Model cont..

Module level cost drivers
CPLX, PCAP, VEXP, LEXP
Subsystem level cost drivers
RELY, DATA, TIME, STOR,

The subsystem level cost drivers vary from subsystem
to subsystem, but tend to be the same for all the
modules within a subsystem
System Level
overall project relations such as nominal effort and

schedule equations
U2.
63
U2.21

Development phases
Plan/ requirement
6% to 8% of the effort
10% to 40% of the development time
Product design
Programming
Integration/ Test
U2.
64

uses the same equations for estimations as the
Intermediate Model
uses a complex procedure to calculate estimation.
procedure uses the LOCs for subsystems and
modules, and module level and subsystem level
effort multipliers as inputs
U2.
65

Assume five distinct life cycle phases
Plan & Requirement

System Design
Detail Design
Module Code & Test
Integration & Test
Adjusted Factor in case of Reuse
A=0.4DD + 0.3C+0.3I
S(equivalent) = (S*A)/100
Efforts and schedule for each phase are assumed

to be given
Ep = p E ;
Dp =p D
U2.
66
U2.22

Ignores software safety & security issues
Ignores many hardware and customer related
issues
Silent about the involvement and responsiveness
of the customer
doesnt give proper importance to software
requirements and specification phase
U2.
67
COCOMO II
Revised version of the original COCOMO
Developed at University of Southern California under the

leadership of Dr. Barry Boehm
Categories of application/project identified by COCOMO II

End User Programming
Infrastructure Sector
Intermediate Sectors
Application Generators and composition aids
Application composition sector
System Integration
U2.
68
Objective of COCOMO 2
To develop a software cost and schedule estimation model

tuned to the life cycle practices of the 1990's and 2000's.
To develop software cost database and tool support

capabilities for continuous model improvement.
To provide a quantitative analytic framework, and set of

tools and techniques for evaluating the effects of software
technology improvements on software life cycle costs and
schedules.
U2.
69
U2.23
Levels of COCOMO II
3 level model that allows increasingly detailed estimates to

be prepared as development progresses
Early prototyping level/ Application composition
Early design level
Use for Application composition projects

Estimates based on object points and a simple formula is used for
effort estimation
Use for Application generators, infrastructure & system integration
projects
Estimates based on function points that are then translated to LOC
Post-architecture level
Use for Application generators, infrastructure & system integration

projects
Estimates based on lines of source code
U2.
70
Early prototyping/ Application Composition

Estimation Model
Supports prototyping projects and projects where there is

extensive reuse
Size is first estimated using object points
Based on standard estimates of developer productivity in

object points/month
Takes CASE tool use into account
Suitable for projects built with modern GUI-builder tools.

Based on new Object Points
U2.
71
Steps for the Estimation of Efforts in Person Month

Assess Object
Count
Classify Complexity
Level of each Object
Assign Complexity
weights to each Object
Determine Object
points
Compute new
Object points
Calculate
Productive rate
Compute the estimated
Effort in person month
U2.
72
U2.24
1. Access Object Counts

estimate the number of screens, reports, and 3GL
components that will comprise this application.
U2.
73
2. Classification of Complexity Levels

Classify each object instance into simple, medium and difficult
complexity levels depending on values of characteristic
dimensions. Use the following scheme:
U2.
74
3. Assign Complexity weights to each Object
Weigh the number in each cell using the following scheme.

The weights reflect the relative effort required to implement
an instance of that complexity level.:
U2.
75
U2.25
Steps 4-6
Step 4 :Determine Object-Points: add all the weighted
object instances to get one number, the ObjectPoint count.
Step 5 : Compute new object points
NOP = (object points) * (100 -%reuse)/100
Step 6 : Calculation of productivity rate
Productivity rate(PROD) = NOP/Person month

(Table given)
U2.
76
Step 7
Step 7 : Compute the effort in Person-Months
using following scheme
Effort in PM = NOP/PROD
U2.
77
Example
Consider a database application project with the
following characteristics:
The application has 4 screens with 4 views each and 7

data tables for 3 servers and 4 clients
The application may generate two report of 6 sections
each from 07 data tables for two server and 3 clients.
There is 10% reuse of object points
The developers experience and capability in the
similar environment is low. The maturity of organization
in terms of capability is also low. Calculate the object
point count, new object points and effort to develop
such a project
U2.
78
U2.26
Example cont..
Number of screens
(medium)
Number of reports
(difficult)
Object point count
NOP
Efforts in PM
Effort
with
views
each
= 2 with 6 section each

= 4*2+2*8 =24
= 24 *(100-10)/100 = 21.6
= NOP/PROD
= 21.6/7 = 3.086 PM
U2.
79
The Early Design Model

can use this model to get rough estimates of a
project's cost and duration before you've
determined it's entire architecture.
uses a small set of new Cost Drivers, and new
estimating equations. Based on Unadjusted
Function Points or KSLOC
Uses Unadjusted Function Points
U2.
80
The Early Design Model cont..

Base equation used
Effort is expressed as Person Months PM

A = a constant to capture the multiplicative effects on
effort with projects of increasing size , provisionally
set to 2.5
B = Scale factor; accounts for the relative economies or

diseconomies of scale encountered for software
projects of different sizes
Value of B is computed on the basis of scaling factors
(or drivers) that may cause drop in productivity with
increase in size
U2.
81
U2.27
COCOMO II Scale Drivers

(The Early Design & Post Architecture Models)
Precedentedness (PREC)
Development Flexibility (FLEX)
Architecture/Risk Resolution (RESL)
Team Cohesion (TEAM)
Process Maturity (PMAT)
U2.
82
Exponent Scaling Factor to calculate B

Scaling factors
Very low
low
6.20 4.96
Nomi High
nal
3.72 2.48
Very
High
1.24
Extra
High
0.0
Development
flexibility
5.07
4.05
3.04
2.03
1.01
0.0
Architecture/
Risk resolution
Team cohesion
7.07
5.65
4.24
2.83
1.41
0.0
5.48
4.38
3.29
2.19
1.10
0.0
Process Maturity 7.80
6.24
4.68
3.12
1.56
0.0
Precedentness
U2.
84
Exponent Scaling Factor to calculate B

B = 0.91+0.01 * (Sum of rating on scaling factor for
the project)
Range from 0.91(Extra High) to 1.23(Very Low)
U2.
85
U2.28
Effort-Multiplier Cost Drivers

COCOMO 2.0 uses a set of effort multipliers to adjust
the nominal person-month estimate obtained from
the projects size and exponent drivers:
U2.
86
Early Design Cost drivers

1.
2.
3.
4.
5.
6.
7.
FCIL Facilities
PDIF Platform Difficulty
PERS Personnel Capability
PREX Personnel Experience
RCPX Product Reliability and Complexity
RUSE Required Reusability
SCED Required Development Schedule
U2.
87
Early Design Parameters

EDCD
Extra
Low
Very
Low
Low
Nominal
High
Very
High
Extra
High
RCPX
.73
.81
.98
1.0
1.30
1.74
2.38
RUSE
0.95
1.0
1.07
1.15
1.24
PDIF
0.87
1.0
1.29
1.81
2.61
PERS
2.12
1.62
1.26
1.0
0.83
0.63
0.50
PREX
1.59
1.33
1.12
1.0
0.87
0.71
0.62
FCIL
1.43
1.30
1.10
1.0
0.87
0.73
0.62
SCED
1.43
1.14
1.0
1.0
1.0
U2.
88
U2.29
Example
A software project of application generator category with
estimated 50 KLOC has to b developed. The scale factor (B) has
low precedentece [4.96]; high development flexibility [2.03]; low
tem cohesion [4.38] . Other factors are nominal Architeture/ Risk
resolution [4.24]; Process maturity[4.68].
The early design cost drivers like platform difficult [1.29] and
personal capability [0.83] are high . and others are nominal.
Calculate the effort in person months for the development of the
project.
B = 0.91 +0.01 * (sum of rating on scaling factors for the project)
PM nominal = A *(size) B
PM adjusted = PM nominal *( EMi)
U2.
89
Example cont..
B = 0.91 +0.01 * (sum of rating on scaling factors
for the project)
= 0.91+0.01 *(4.96+2.03+4.24+4.38+4.68)
= 0.91 +0.01(20.29)
= 1.1129
= 2.5 *(50) 1.1129 = 194.41 Person month
PM adjusted = PM nominal *( EMi)
= 194.41 * [1.29* 0.83] = 194.41 *1.07
= 208.155 Person-month
U2.
90
Post Architecture Cost drivers

1.
2.
3.
4.
5.
6.
7.
8.
9.
ACAP Analyst Capability

AEXP Applications Experience
CPLX Product Complexity
DATA Database Size
DOCU Documentation to match lifecycle needs
LTEX Language and Tool Experience
PCAP Programmer Capability
PCON Personnel Continuity
PDIF Platform Difficulty
U2.
91
U2.30
Post Architecture Cost drivers cont..

10. PEXP Platform Experience
11. PREX Personnel Experience
12. PVOL Platform Volatility
13. RELY Required Software Reliability
14. SCED Required Development Schedule
15. STOR Main Storage Constraint
16. TIME Execution Time Constraint
17. TOOL Use of Software Tools
U2.
92
Mapping of Early Design and Post Architecture Cost

Drivers
U2.
93
Cost Driver Rating
U2.
94
U2.31
Cost Driver Rating cont..
U2.
95
U2.
96
U2.
97
U2.32
Post Architecture Cost Driver

CD
RELY
DATA
CPLX
RUSE
DOCU
TIME
STOR
PVOL
ACAP
PCAP
PCON
AEXP
PEXP
LTEX
TOOL
SITE
SCED
VL
Low
Nominal
High
0.75
0.88
1.00
1.15
0.89
0.93
0.88
0.91
0.95
1.50
1.37
1.24
1.22
1.25
1.22
1.24
1.25
1.29
0.87
1.22
1.16
1.10
1.10
1.12
.10
1.12
1.10
1.10
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.09
1.15
1.14
1.06
1.11
1.06
1.15
0.83
0.87
0.92
0.89
0.88
0.91
0.86
0.92
1.00
0.75
VH
EH
1.39
1.19
1.30
1.29
1.13
1.31
1.21
1.30
0.67
0.74
0.84
0.81
0.81
0.84
0.72
0.84
1.00
1.66
1.49
1.67
1.57
0.78
U2.
98
Schedule Estimation
B = 0.91 +0.01 * (sum of rating on scaling factors for the
project)
PM adjusted = PM nominal * ( EMi)
TDEV nominal = [ * PM adjusted ) (0.28+0.2(B-0.091) *
SCED%/100
= constant, provisionally set to 3.67
TDEV nominal =Calendar Time in months
Language
SLOC per FP
Assembler
320
Macro Assembler
213
150
Algol
106
Chill
106
Cobol
106
Fortran
106
Jovial
106
Pascal
91
RPG
80
PL/I
80
Modula-2
71
U2.
99
U2.
100
U2.33
Ada
71
Prolog
64
Lisp
64
Forth
64
Basic
64
Logo
53
4th Generation Database
40
Strategem
35
APL
32
Objective - C
26
Smalltalk
21
Query Languages
16
Spreadsheet Languages
U2.
101
Putnam Resource Allocation Model

based on an equation of staffing profiles for
research and development projects (Putnam,
1978), (Londeix, 1987), (Putnam and Myers,
1992).
Its major assumption is that the Rayleigh curve can
be used to model staff levels on large (>70,000
KDSI) software projects.
KDSI : Kilo delivered source instructions
U2.
102
Putnam Resource Allocation Model cont..
Plotting the number of people working on a project is a

function of time and a project starts with relatively few
people.
The manpower reaches a peak and falls off and the
decrease in manpower during testing is slower than the
earlier build up.
Putnam assumes that the point in time when the staff level
is at its peak should correspond to the project development
time.
Development effort is assumed to be 40% of the total life
cycle cost.
Putnam explicitly excludes requirements analysis and
feasibility studies from the life cycle.
U2.
103
U2.34
U2.
104

The basic Rayleigh form is characterized through a
differential equation
M(t) = dy/dt= 2Kat exp(-at 2)
dy/dt : manpower utilization rate per unit time;

staff build-up rate,
t: elapsed time
a : parameter, affects the shape of the curve
K : area under the curve in the interval [0,inf..]
U2.
105

Y(t) :Cummulative man power used up to time t
Y ( t) = k[1- exp(-at 2) ]
Y(0) = 0
Y(inf..) = K
a can be obtained from peak time

d2y/dt2 =2Ka exp(-at2)[ 1 2 at2]=0
td2 =1/2a
a = 1/ (2*td2)
td2 = 1/2a
a = 1/2 td2
Larger the value of a earlier the peak time; steeper the
person profile
U2.
106
U2.35

td is nearly equal to project development time
E = y(t) = k[1- exp(- td 2/2 td 2)]
= 0.39535K
Cumulative man power required at td

Y ( t) = k[1- exp(-at 2) ]
d2y/dt2 =2Ka exp(-at2)[ 1 2 at2]
a = 1/2 td2
U2.
107

Number of people involved at peak time
m(t) = 2Kat exp(-at 2)

m(t) = (2K/2 td2 )t exp ( - t2 / 2td2 )
m(t) = (K/ td2 )t exp ( - t2 / 2td2 )
At t = td,the peak manning, m(td) is obtained
mo = K / (td * sqrt(e))
K : total project cost (or effort) in person year
td : the delivery time in years
mo : number of persons employed at the peak
Y ( t) = k[1- exp(-at 2) ]
a = 1/2 td2
U2.
108
Difficulty Metric
The slope of the manpower distribution at start time (t
=0) used to represent the difficulty denoted by D
m(t)=d2y/dt2 =2Ka exp(-at2)[ 1 2 at2]

For t = 0
m(0) = 2 Ka = 2K/ 2td2=k /td2
Shows that a project is more difficult to develop when

manpower demand is high or when the time
schedule is short
Y ( t) = k[1- exp(-at 2) ]
a = 1/2 td2
U2.
109
U2.36
Difficulty Metric cont..

Peak manning is defined as
mo = K / (td * sqrt(e))
D is also related to peak manning mo and the

development time td by
D = K / td2 = mo sqrt(e)/td
Difficult projects tend to have a higher peak manning

for a given development time
Y ( t) = k[1- exp(-at 2) ]
a = 1/2 td2
U2.
110
Manpower Buildup
D is dependent upon K and td.
D(td)= -2K/ td3 person/year2
D(K) = I/ td2 year-2
Putnam observed that the difficulty derivative relative to time
played an important role in explaining the behaviour of
software development.
PA: Cost = 20PY & td = 1Year
PB: Cost = 120PY & td = 2.5Year
PA : D(td)= -40
& D(K) = 1
PB : D(td)= -15.36 & D(K) = 0.16
Y ( t) = k[1- exp(-at 2) ]
a = 1/2 td2
U2.
111
Manpower Buildup cont..

If project scale is increased the development time
also increases to such an extent that the quantity
K/ td3 remains constant around a value, which
could be 8, 15 or 27; represented by D0
D0 = K/ td3 person/year2
D0 is related to the nature of s/w developed in the
following way
Y ( t) = k[1- exp(-at 2) ]
a = 1/2 td2
U2.
112
U2.37
Manpower Buildup cont..

D0
is related to the nature of s/w developed in the

following way
D0 = 8 refers to entirely new s/w with many interfaces and
interactions with other systems
D0 = 15 refers to new stand alone system
D0 = 27 refers to the s/w that is rebuilt from existing s/w
D0 has a strong influence on the shape of the manpower
distribution.
The larger D0 is, the steeper manpower distribution is and
the faster the necessary manpower build up will be
So quantity D0 is called manpower buid up
U2.
113
Productivity Versus Difficulty

Productivity is proportional to difficulty
P Db
P = lines of code produced/ cumulative manpower

used to produce code
P = S/E
S : lines of code produced
E : cumulative manpower used from t =0 to t = td
(inception of the project to the delivery time)
U2.
114
Productivity Versus Difficulty cont..

According to Putnam
p = D-2/3
S = D-2/3 E
= D-2/3 (0.3935 K)
S = [K/td2]-2/3 K(0.3935)
= 0.3935 K1/3td4/3
=C K1/3td4/3
C =S K-1/3td - 4/3
Easy to use size, cost and development time of past
projects to determine the value of C
U2.
115
U2.38
Productivity Versus Difficulty cont..

Putnum proposed 20 values of C ranging from
610 to 57314 reflecting the effect of various
factors effect on productivity
h/w
constraint,
PCPLX,
programing environment
PEXP,
U2.
116
The Trade off Between Time versus Cost

K1/3td 4/3 = S/C
Raise power by 3
Ktd4 = [S/C]3
Ktd4 is constant for a constant size software
Compression in development time will produce an
increase in manpower cost
According to Boehm time scale should never be
reduced to less than 75% of its initial calculated
value
U2.
117
Development Sub-Cycle
Let md(t) and yd (t) be the design manning & the cumulative design
manpower cost and can be represented as
md(t) = Kdbt exp(-bt2)
yd (t) = Kd[1-exp(-bt2)]
md(t) is non zero value for md at td
So design and coding still completing this activity after td
By assumption development will be completed 95% by the time td
U2.
118
U2.39
Development Sub-Cycle cont..

yd (t) / Kd = 1-exp(-bt2) = 0.95
b = 1/2 tod2
tod is the time at which the development exhibits a peak
manning
the relationship between td and tod
tod = td /sqrt(6)
Consider the relationship between K and Kd
Kd = K /6
Difficulty : D = K/ td2 = Kd/ tod2
Manpower build up; D0 = K/td3 = Kd/sqrt(6) tod3
U2.
119
What we Learnt
Characteristics of project manager

The Steps
Activities during SPP
Size Estimation
Cost Estimation
U2.
120
Software Design
U2.
121
U2.40
Learning Objectives
Software Design
Design Framework
Design Principle
Modularity
Cohesion & Coupling
U2.
122
Software Design
Designer plans HOW
Transformation of ideas into detailed implementation

descriptions, with the goal of satisfying the software
requirements
Designer must satisfy both customers and system builders
U2.
123
Where Do We Begin?
modeling
Prototype
Spec
Design
U2.
124
U2.41
Design Framework
Initial requirements
Gather data on user requirement
Analyze the requirements data
Obtain answers to
Requirement Question
Validate the design against

The requirements
Conceive of a high level design
Refine & document the design
U2.
125
Design Principles
should be traceable to the analysis model.
should minimize the intellectual distance [DAV95] between

the software and the problem as it exists in the real world.
should exhibit uniformity and integration.
should be structured to accommodate change.
Design is not coding, coding is not design.
should be reviewed to minimize conceptual (semantic) errors.
U2.
126
Objective of Design
Correct & Complete
Understandable
At the right level
Maintainable & to facilitate maintenance of the
produced
U2.
127
U2.42
Transformation of an Informal Design to a Detailed

Design
Informal
Design
outline
More
formal
design
Informal
design
Finished
design
U2.
128
If not Design
Fail when small changes are made
Difficult to maintain
Quality cannot be assessed until late in the
software process
U2.
129
What Features Must Be Designed
Elements of the Design

Data flows, Data Stores, Processes (Activities),
Procedures, Controls (Standards and guidelines
for determining whether are occurring in the
anticipated or accepted manner i.e. under
control), Roles
Design of output
Design of files
Design of database interactions, example
Data needed from the database
Actions that will affect database
Design of Input
U2.
130
U2.43
What Features Must Be Designed cont..

Design of Control, for example input control provides the way to
Ensures only authorized user access
Guarantee that transactions are acceptable
Validate the data for accuracy
Determine whether any necessary data have been
omitted
Design of procedures
Data entry procedures
Run time procedures
Error handling procedures
Security and backup procedures
Design of program specifications
U2.
131
Design Methodologies
Requirements for design techniques & methodologies.

Improve productivity of analyst and programmer
Improve, documentation, maintenance and enhancements
Cut down cost overruns and delays
Improve communication among the user, analyst, designer
and programmer
Standardize approach to analysis and design
Simplify design by segmentation
U2.
132
Module
What is a module?
lexically contiguous sequence of program
statements, bounded by boundary elements,
with aggregate identifier
Examples
procedures & functions in classical PLs
objects & methods within objects in OO PLs
U2.
133
U2.44
Good vs. Bad Modules

Modules in themselves are not good
Must design them to have good properties
i) CPU using 3 chips (modules)
Chip 1
ii) CPU using 3 chips (modules)

Chip 2
Chip 1
Chip 2
AND gates
OR gates
Registers
ALU
ALU
Chip 3
Shifter
SHIFTER
Chip 3
NOT gates
What is the problem here?

U2.
134
Good vs. Bad Modules

Two designs functionally equivalent, but the 2nd is
hard to understand
hard to locate faults
difficult to extend or enhance
cannot be reused in another product. Implication?
-> expensive to perform maintenance
Good modules must be like the 1st design

maximal relationships within modules (cohesion)
minimal relationships between modules (coupling)
this is the main contribution of structured design
U2.
135
Modular System
consists of discrete components
each component can be implemented separately
change to one component has minimal impact on
other components
Under modularity and over modularity should be
avoided
U2.
136
U2.45
Modularity Cont..
U2.
137
Module Independence
COHESION - the degree to which

module performs one and only one
function.
COUPLING - the degree to which
module is "connected" to other
modules in the system.
U2.
138
Cohesion & Coupling

Cohesion
Extent to which module

has
a
single
responsibility
Informal
(Defined
in
terms of purpose)
High cohesion is good
coupling
between
modules
Coupling
Extent to which modules

depend on each other
Can be defined formally
Loose coupling is good
cohesion within
module
U2.
139
U2.46
Coupling
Refers strength of the relationship between modules in a

system
Loose coupling minimizes the interdependence between
modules
can be control in the following ways
Control the number of parameters passed between
modules
Avoid passing unnecessary data to called module
Pass data only when needed
Maintain superior/subordinate relationship between
calling and called modules
U2.
140
Levels of coupling
5.Data Coupling
4.Stamp Coupling
3.Control Coupling
2.Common Coupling
1.Content Coupling
U2.
141
1. Content Coupling
Def.
one module directly references contents of the
other
Example
module a modifies statements of module b
module a refers to local data of module b in
terms of some numerical displacement within b
module a branches into local label of module b
Why is this bad?
almost any change to b requires changes to a
U2.
142
U2.47
2. Common Coupling
Def.
two modules have write access to the same global data
Example
two modules have access to same database, and can
both read and write same record
while (global variable == 0)
Why is this bad?
if (argument xyz > 25)
module 3 ();
resulting code is unreadable
else
modules can have side-effects module 4 ();
ccb
must read entire module to understand
cca
difficult to reuse
module exposed to more data than necessary
global variable
U2.
143
3. Control Coupling
Def.
one module passes an element of control to the
other
Example
control-switch passed as an argument
Why is this bad?
modules are not independent
module b must know the internal

structure of module a
affects reusability
U2.
144
4. Stamp Coupling
Def.
data structure is passed as parameter, but called module
operates on only some of individual components
Example
calculate withholding (employee record)
Why is this bad?
affects understanding
not clear, without reading entire module, which fields of
record are accessed or changed
unlikely to be reusable
other products have to use the same higher level data
structures
passes more data than necessary
e.g., uncontrolled data access can lead to computer
crime
U2.
145
U2.48
5. Data Coupling
Def.
every argument is either a simple argument or a data
structure in which all elements are used by the called
module
Example
display time of arrival (flight number)
get job with highest priority (job queue)
Slippery slope between stamp & data (see queue)
Why is this good?
maintenance is easier
good design has high cohesion & weak coupling
U2.
146
Levels of cohesion
1.Coincidental cohesion
2.Logical cohesion
3.Temporal cohesion
4.Procedural Cohesion
5.Communicational Cohesion
6.Sequential Cohesion
7.Functional Cohesion
U2.
147
7. Functional Cohesion
Def.
module performs exactly one action
Examples
get temperature of furnace
compute orbital of electron
calculate sales commission
Why is this good?
more reusable
corrective maintenance easier
fault isolation
reduced regression faults
easier to extend product
U2.
148
U2.49
Examples
COMPUTE COSINE OF ANGLE
VERIFY ALPHABETIC SYNTAX
READ TRANSACTION RECORD
DETERMINE CUSTOMER MORTGAGE REPAYMENT
COMPUTE POINT OF IMPACT OF MISSILE
CALCULATE NET EMPLOYEE SALARY
ASSIGN SEAT TO AIRLINE CUSTOMER
U2.
149
6. Informational Cohesion
Def.
one whose elements are involved in activities
such that output data from one activity serves
as input data to the next
Repaint Car Body
CLEAN CAR BODY
FILL IN HOLES IN CAR
SAND CAR BODY
APPLY PRIMER
If add Put on final Coat
U2.
150
Example
module format and cross-validate record
uses raw record
format raw record
cross-validate fields in raw record
returns formatted cross-validated record
endmodule
U2.
151
U2.50
5. Communicational Cohesion
Def.
module performs series of actions related by
procedure to be followed by product, but in
addition all the actions operate on same data
Why is this bad?
still leads to less reusability -> break it up
U2.
152
Example
use the same input or output data.
find out some facts about a book: For instance, we may
wish to
1.FIND TITLE OF BOOK
2.FIND PRICE OF BOOK
3.FIND PUBLISHER OF BOOK
4.FIND AUTHOR OF BOOK
U2.
153
Example
module determine customer details
use customer account no
find customer name
find customer loan balance
return customer name, customer loan balance
endmodule
U2.
154
U2.51
4. Procedural Cohesion
Def. ?
module performs series of actions related by
procedure to be followed by product
Example
update part number and update repair record in master
db
Why is this bad?
actions are still weakly related to one another
not reusable
Solution
break up!
U2.
155
Example
module write read and edit somewhat
uses out record
write out record
read in record
pad numeric fields of in record with zeros
return in record
endmodule
U2.
156
Example
procedurally cohesive module that averages two completely unrelated
tables, TABLE-A and TABLE-B, which both just happen to have 100
elements each.
module compute table-A-avg and table-B-avg
uses table-A, table-B
returns table-A-avg, table-B-avg
table-A-total : = 0
table-B-total : = 0
for i = i to 100
add table-A (i) to table-A-total
add table-B (i) to table-B-total
endfor
table-A-avg : = table-A-total/100
table-B-avg : = table-B-total/100
endmodule
U2.
157
U2.52
3. Temporal Cohesion
Def. ?
module performs series of actions related in time
Initialization example
open old db, new db, transaction db, print db,
initialize sales district table, read first transaction
record, read first old db record
Why is this bad?
actions weakly related to one another, but strongly
related to actions in other modules
code spread out -> not maintainable or reusable
Initialization example fix
define these intializers in the proper modules & then
have an initialization module call each
U2.
158
Example
module initialize
updates a-counter, b-counter, items table,
totals table, switch-a, switch-b
rewind tape-a
set a-counter to 0
rewind tape-b
set b-counter to 0
clear items table
clear totals table
set switch-a to off
set switch-b to on
endmodule
U2.
159
Example
PUT OUT MILK BOTTLES
PUT OUT CAT
TURN OFF TV
BRUSH TEETH
U2.
160
U2.53
2. Logical Cohesion
Def.
module performs series of related actions, one of which is
selected by calling module
Example
function code = 7;
new operation (op code, dummy 1, dummy 2, dummy 3);
// dummy 1, dummy 2, and dummy 3 are dummy variables,
// not used if function code is equal to 7
Why is this bad?
interface difficult to understand
code for more than one action may be intertwined
difficult to reuse
U2.
161
Example
GO BY CAR
GO BY TRAIN
GO BY BOAT
GO BY PLANE
U2.
162
1. Coincidental Cohesion
Def. ?
module performs multiple, completely unrelated actions
Example
module prints next line, reverses the characters of the
2nd argument, adds 7 to 3rd argument
How could this happen?
hard organizational rules about module size
Why is this bad?
degrades maintainability & modules are not reusable
Easy to fix. How?
break into separate modules each performing one task
U2.
163
U2.54
Example
FIX CAR
BAKE CAKE
WALK DOG
FILL OUT ASTRONAUT-APPLICATION FORM
HAVE A BEER
GET OUT OF BED
GO TO THE MOVIES
U2.
164
Strategy of Design
Bottom up design
Need to use lot of intution

Chances Recoding is High
Testing is easy
Top-Down Design
Stepwise refinement
Suitable of specifications are clear
Testing is typical
Hybrid Design
U2.
165
Function-oriented Design
Design with functional units which transform inputs to
outputs
U2.
166
U2.55
Functional Design Process

Data flow design
Model the data processing in the system using data

flow diagrams
Structural decomposition
Model how functions are decomposed into subfunctions using graphical structure charts
Detailed design
The entities in the design and their interfaces are

described in detail. These may be recorded in a data
dictionary and represented as Pseudode
U2.
167
Structural Decomposition
Structural decomposition is concerned with
developing a model of the design which shows the
dynamic structure; i.e., function calls.
The aim of the designer should be to derive
design units which are highly cohesive and
loosely coupled.
In essence, a data flow diagram is converted to a
structure chart
U2.
168
Design Notations
Data flow Diagrams

Data Dictionaries
Structure Charts
Pseudocode
U2.
169
U2.56
Structure Chart
A design tool that visually displays the relationships

between modules
Not intended to express procedural logic done by flow

charts or pseudocode
Identify the data passes existing between individual

modules that interact with one another
Assist the analyst in developing a S/W that meets the

objectives of good S/W design
U2.
170
Structure Chart Cont..

Notation use in Structure Chart
Program modules identified by rectangles, with the
module name inside the rectangle
Arrows indicates calls
Annotations indicate the parameters that are passed
and the direction of the data movement
Two types of data are transmitted
Parameter data -> items of data needed in the

called module
Control Information (flag data)-> to assist in
the control of processing by indicating the
occurrence of, say, errors or end of file
conditions
U2.
171
Notations
Data
Module
Physical Storage
Control
Diamond
symbol for
conditional call
or module
Library
Module
Repetitive
call of
Module
U2.
172
U2.57
Functional Procedure Layers

Level0
Function or procedure name

Relationship to other system components
Brief description of the function purpose
Author date
Level 1
Function parameters
Global variables
Routines called by the function
Side effects
Input/Output Assertions
U2.
173
Functional Procedure Layers contd..

Level2
Local data structure

Timing constraints
Exception handling
Any other limitation
Level 3
Body
U2.
174
Object Oriented Design steps
Create Use case model

Draw activity diagram
Draw the interaction diagram
Draw the class diagram
Design of state chart diagrams
Draw component and development diagram
U2.
175
U2.58
What we Learnt
Software Design
Design Framework
Design Principle
Modularity
Cohesion & Coupling
U2.
176
UNIT II Learning's
Size Estimation
Cost Estimation Models
Putnam resource allocation model
Risk Management.
Software Design
Cohesion & Coupling
U2.
177
Objective Questions
Q1. How technology factor C is defined in Putnam Resource allocation model?
What is its significance?
Q2. Differentiate between flow chart and structure chart.
Q3. Give at least one example for each of cohesion .The example should be either
from O.S or from any of widely used software.
Q4. Discuss the categorization Empirical Estimation Models.
Q5. What are the activities during Software Project Planning?
Q6. What are the FPA functional units?
Q7. Compare DFD with ER Diagram.
Q8. What are the Risk management activities?
Q9. Define variable span with example.
Q10. Which one is not an infrastructure software?
(a) Operating system
(b) Database management system
(c) Compilers
(d) Result management system
Q11. How many stages are in COCOMO-II?
(a) 2
(b) 3
(c) 4
(d) 5
U2.
178
U2.59
Short Questions
Q1. Discuss difference between object oriented and function oriented design.
Q2. What problems are likely to arise if module has high complexity?
Q3. Define module cohesion. List different types of cohesion.
Q4. Can we have inheritance without polymorphism? Explain.
Q5. List points of a simplified design process.
Q6.You are the manager of a new project charged with developing a 100000 lines
embedded system. You have a choice of hiring from two pools of developers;
highly capable with very little experience in the programming language being
used; or developers of low quality but a lot of experience with the
programming language. What is the impact of hiring all the developers from
one or the other group in terms of efforts and duration?
Q7. Consider a large-scale project for which the manpower requirement is K=
600PY and the development time is 3 years and 6 months.
Calculate the peak manning and peak time
What is the manpower cost after 1 year and two months?
Calculate the difficulty and manpower build up
U2.
179
Long Questions
Q1. Define coupling and explain various types of coupling? Which one is best and
why?
Q2. Describe the Albrechts function count method with suitable example.
Q3. What are risk management activities? Is it possible to prioritize the risks?
Q4. What is risk exposure? What techniques can be used to control each risk?
Q5. If a module has logical cohesion, what kind of coupling is the module likely to
have with others? Justify..
Q6. Explain Walston-Felix model and compare it with SEL model.
Q7.Assuming Putnam model with S=100, 000, C=5000, D0=15, compute
development time td and manpower development kd.
Q8. Suppose that a project was estimated to be 600 KLOC. Calculate the effort and
development time for each of the three models i.e., organic, semidetached and
embedded.
Q9. software development requires 90 PM during total development subcycle. The
development time is planned for duration of 3 yrs and 5 months.
Calculate the manpower cost expanded until development time.
Determine development peak time.
Calculate the difficulty and manpower build-up.
U2.
180
Long Questions
Q10. Discuss the Categories of application/project identified by COCOMO II. Write
an example and applicable level of COCOMO II estimation model for each
application/project identified.
Q11. Discuss the steps for efforts estimation using COCOMOII Application
Composition estimation model.
Q12. What are software metrics? Discuss Halistead software sciences metrics along
with its limitations.
Q13. Discuss Putnam resource allocation model to derive the cumulative effort, a
parameter at peak time, difficulty metric and man power build up.
Q14. The size of a software product to be developed has been estimated to be
22000 LOC. Predict the manpower cost by Waltson-Felix Model and SEL
Model.
Q15. Describe various stages of COCOMO-II.
Q16. Explain with example different type of functional independence of the
individual modules.
Q17. Discuss information flow metrics with its limitation. How a more sophisticated
Information Flow model can overcome them?
U2.
181
U2.60
Research Problems
Q1. You want to monitor the effort spent on different phases in the project and
the time spent on different components. Design a time sheet or form to be
filled in by the programmers that can be used to get this data. The design
should be such that automated processing is possible.
Q2. For a student project being done in a semester course, list the major risks
and risk mitigation strategy for them.
Q3. For a group student project in the software engineering course, device a
suitable monitoring plan, and plans for data collection for this monitoring
Q4. For a project to manage enrollment and activities in a hobby club, design a
suitable quality plan.
U2.
182
References..
1. K. K. Aggarwal & Yogesh Singh, Software Engineering, 2nd Ed., New Age
International, 2005.
2. R. S. Pressman, Software Engineering A practitioners approach, 5th Ed.,
McGraw Hill Int. Ed., 2001.
3. Pankaj Jalote, An Integrated Approach to Software Engineering, Narosa, 3rd
Ed., 2005.
4. Stephen R. Schach, Classical & Object Oriented Software Engineering, IRWIN,
1996.
5. James Peter, W. Pedrycz, Software Engineering: An Engineering Approach,
John Wiley & Sons.
6. Sommerville, Software Engineering, Addison Wesley,8th Ed., 2009.
7. Frank Tsui and Orlando Karan, Essentials of Software Engineering, Joes and
Bartlett, 2nd Ed., 2010.
8. Kassem A. Saleh, Software Engineering, Cengage Learning, 2009.
9. Rajib Mall, Fundamrntal of Software Engineering, PHI, 3rd Ed., 2009.
10. Carlo Ghizzi , Mehdi Jazayeri and Dino Mandrioli, Fundamental of Software
Engineering, PHI, 2nd Ed.,2003.
U2.
183
References
11. Carol L. Hoover, Mel Rosso-Llopart and Gil Taran, Evaluating Project Decision
Case Studies in Software Engineering, Pearson, 2010.
12.
Sommerville,
Software
Engineering,
Addison Wesley,
2002
http://www.cse.iitk.ac.in/JaloteSEbook/
13.http://www.csse.monash.edu.au/~jonmc/CSE2305/Topics/07.14.SWEng2/html/te
xt.html
14.http://www.softpanorama.org/SE/software_life_cycle_models.shtml
15.http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
16. http://www.levela.com/software_home.htm
U2.
184
U2.61

Unit Ii

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Unit Ii

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit Ii

Uploaded by

Copyright:

Available Formats

MCA-209, Software Engineering

Software Project Planning

MCA-209, Software Engineering

Characteristics of project manager

Characteristics of Project Manager

Software Project Planning

MCA-209, Software Engineering

Activities During SPP

MCA-209, Software Engineering

Lines of Code (LOC)

Int sort (int x[], int n)

Int I, j, save, im1;

/* This function sorts array x in ascending order */

For ( I=2; I<= n; I++)

for(j=1; j<= im; j++)

IF (X[I] < x[j])

MCA-209, Software Engineering

When comments and blank lines are ignored

The same functionality takes more code to implement in a

The more verbose

Measures of productivity based on lines of code suggest that

MCA-209, Software Engineering

High and Low Level Languages

System Development Times

Analysis Design Coding Testing Documentation

Example: LOC Approach in SPP

MCA-209, Software Engineering

Albrecht's Function Point Analysis Principle

FPA Functional Units

ILF: Internal Logical Files

MCA-209, Software Engineering

Independent of the language, tools or methodologies used

Counting Function Points cont..

UFP = Wij Zij ;

Zij is the count for components i at level j

Counting Function Points

Internal logical files

MCA-209, Software Engineering

Counting Function Points cont..

Does the system require reliable backup and recovery

Factors Considered Cont..

Is the inputs, outputs, files or inquiries complex

MCA-209, Software Engineering

Typical Function-Oriented Metrics

Function Count Example

Assume that all complexity adjustment

UFP = Wij Zij ;

CAF= (0.65+ 0.01 Fi)

Function Count Example cont..

MCA-209, Software Engineering

Common attributes for any cost

Empirical Estimation Models

MCA-209, Software Engineering

Empirical Estimation Models cont..

Single variable model :

Empirical Estimation Models cont..

Static, Single Variable Models

= 3.0(32)1.12 0.75 = 109 PM