classmate

Date
Page

treget panning proceSs:

tiS eSsentia decide owch tasr

to be bo t0 wana9,

s an
a Orqaniced
froject plaonng
prcess from requreuet atheriog
to test & SoppoBt .
focoses oo au atfoitto reaqwred
Roccespul
elps în bever GHSZatice. sh
fesooree cpsinal Usage
QUodme

sOfAUOare projectpople
wanag
Act ao ojccA l ades
Cotac ofy al statebaldes
wasaqig bomoan resouCce

atining
wanage Sesing
Cp projectSCOpe
proje
pogress
gisk andtysis at G Peyorang
 Date

Page

froiectplaooiOg DrOress
docotetahion)
Stareboldes (Spei
oeeds
project
Objectes
(3slps)
TdentiY
Projecr e date
CorsytosuoiCaton plammg produc

project
Schedte
deacns
latttt
(ost. (Desicnes, Develope
Sppet eOGinees
Pocj ect
enc

Kesource (Osed is psojec Developwe

Reosoble sw
Cbaponet
 Page

"Hoan Pesovrce
sjw ldeuelopes
posiiOS are decided acc to sIl
Spe ciality

Qeosablc (ompone:
bodgat for precc is most
fmp task tha au pieect wanages dene
poytm +

educe the (ost.

HOt0Ols ire Sensor, LED

procesSor:
progiamoig tool

oect SCope
SCOPe managuent olo
’thechance s oPDrHonity to do
Goohing
SCopei - S t OF featureo
psocess,OPs
deadtn
 Date
Paqe

SOpe Mgmii
Greateo bouodies
psaject by cleely
ah the
Oht
wbat wOUId be dore
pict bat uoud ot be done

Aajcct sope wgmli

°s to
Jhe paipase
ensre tht thé proje oco
des ubork reguird
uatk txclude

Steps psoject wgti

plas scope ugut
Collect reqwreuet

ioecd scope (worK

Validate scopeCvStoes
 Date
Page
alas mate
Approx' Voe
SOrtware projeot simatiou

devel opwens projed

t s a piocedwre that predíis
budgdsthad (equited
for Compleing a project
pioied estiaasfon 'requires tbe.
Wse df
watbewatical'o weU as
about plangig
wein recusc sluo proqsa fais
fae
due to Poabiity tÏ dceUrate
estute slu
C'ses iequieuet
scheau
Constrait slo project
Ciganizutic9a es tiwaton ¬tects
puides Cest

x factor a
psoject
Cost
oneysseguuret
psoje
Csiute both
Podividle!Project
tiue
 clasSMate
Date
Page

sop ordes t0 delives Compite

produc on
tfme
Risk. Create

ResoUrce ens0re c resCärces ar

aVculab le

Steps

eS+fnat e project sice

safmase ort s (person per meotb t)
- Cfu at e prõjRct Schedule
-cstiate piock Cost.
Esiuate project sizef LOc efP)
LOC- Loes (ode
Fp- foncio0al pof.
to wate

etiwasion o the
SRS. dcU went E
eent.
(9sed fo Y
System docomet

eaHwating
 muchte)
evalute bou
rered,Gor ce
Manages money
( pieject

35 Generad SDL
for C(alulaing, project

touoles
nHA, eso, cading desig
Revieusiogdcod't
Tmplemensing plototype t decide
cuesau praser eports
s to Cal awe eStimat

oltpending og Qw) bisto rical data

SA deuelbomeut pioce sS.
pitiet sire, deuelopuet we ue thdole ay
4cbIS, ss sed for CaledigCacdg
O2US projets.
3h dèrferent natore of
there, theo ditecaTationproectneed
to adopt for
Cas. stiuate corts
porpase we Use
Stratey7
CocoMo
for that
uocel.
 ciASSMAe.
Date
Page

fstiuate projet schedue Qeeplc

peoplee wbo
worK00 the proje+ L oba
they uof| worK-90
AlSO LONRN they uoiu S4oct voc?g
when they uot eFsh.
dlecided clate actia date,
Start date end dae prGjet
Estuate proj<ct Cast:
Jbe Cost of pioject
prOjEC+ is. denfued got
Only froM the estioatey Of erson
orts 2 sice.
0ther parameter Soch os purchase b{w
S|W , tete (o mmonicatio) (est, ofÉice

Ohe ooplest labor (ost Cao be

the
6bBaied
Project.
b
90thipc.
eoortc te Cin hoor)
by Geneas (abor mte

depend the po
 estiuasion is form
Slw project
slprobjes sc0vio4 (do estiua¯e co

Secompositiog dechoquea fs diue,

codes pproac
ploject estfuatoo

SOFware
sicing
problcm base e uasion
process based estiuaton.
froblem Aeompos+foo*
AlSe Caled ao putihoning
he ioitfd stage picject
planofog

the otjal OF

pieqieueu quhen
fo [equireiet Gonesog
Problem's are.
u thu
 olassate
Dnte

Parye

pioble's are de lornposed. i 4hs

where
ahen
wWho
bow.
nhat

*Potess Delompositioo:
Oue is the krood step atteryor
peblem deeompositiog
yo0r poblede Cogpocico
COCe Start
s done tbeyyou
prorecs ale loposion
You
wuode your
decide ohich
are
ehect the process
paoitet wahorop riat
odeI
eguest the pralt
rot
CUs1Omer oho reqveAt
wbo ofl do the, 0ork
peopie
hich
project
tears WoK.
Obseivatio) o9 Cstíutatio:

tis st mayos chaseng

pieiect plama
wodel 40 be but
Ploduct
arage sHwate tota
estfwase
fto huMon eort S, Hme
money
As pe the 3ire cha C
Mandgo decdes thee
peduct Ycquireuet piduct
eONrOnen wAanage Sboot
iequienet
Oc based estiuasoo
ibe Code

pactage to be dive o
ed for Coroputhaded
pp Por Wechaical Compok

YesojION
vwoUse, digfti el, biqb
laser
pe
OOr dusplo
 elassmate
Date
Page

Bounded Statyet

A we chaNCa CAD Su o acept

tu0o b 3D geoMerNG data. fsom

ereu sysks 1utesact

fooctio ¬shuated Loc

2300
EOwebic anaysis S300
(2be4)
335O
Databaoe 4q50
Compues Gropuicdisplo fociines (CGOE ) 2100.
penphesal cowrol Funcioo (PCE) G400
sio Analsis wadwes (DAM) 3200
delormposijo) dec hoiques for Loc
S= Spt t xSmcst tSpe ssi
SepioiG 600 Smost litey 6q00 Spessinishc=
4600+4x64CO tSGGO
By form)
 clAssMate
Date
Page

NOw
bíetonca dota,
Revieo'
tht
620 LOc/perperSon is ucor,
Calary = GOO0
per person Salay
Z000
620

Poce |S

So
we bave B3200 So
tote project 43), 00
(0st 43000

S4
 Bstimated L0
Punction
B,400
Design Analysis Modules (DAM)
33,200
Bstimated lines of code
For our purposes, we assume that further refnement has oceurred and that the major software
bis,
TabBe 4.Ñl are identiñed. The decomposition technique for L0, an estimation table, shown in Tabie Ar funetions
developrd. Arange of LOC estimates is developed for each funetton
For example : The range of L.OC estimates for the 3D geometric analysis function is optimistic 4600 L
ikety 6900 LOC, and pessimistic B600 LOC. Appying Bquation (4.6.1), the expected value for the 3D ge
anatysis function is 6800 L.0C.
4.6.4 FP-based Estimation

University Questions
a. Explatin the FP based estimation technique. SPPU- May 18,6 #aris
a. Compare Lines of oode (LOC) and Function Point (FP) based estimation of software. SPPU-May 19,8 Marts
Q. How do you calculate FP and how it is used in estimation of a software project. SPPU Dec. 19, 51Mars
Table 4.6.2:Estimating information domain values
Information domain value Opt. Likely Pess. Est. count Weight FP count

Number of external inputs 20 24 30 24 4 97

Number of external outputs 12 15 22 16 5 78

Number of external inquíries 16 22 28 22 5 88

Number of internal logical files 4 5 4 10 42

Number of external interface files 2 2 3 2 7 15

Count total 320

Decomposition for FP-based estimation focuses on information domain values rather than software functions.
Referring to the table presented in Table 4.6.2, the project planner estimates external inputs, external outpe
external inquiries, internal logical files, and external interface files for the CAD software.
FP are conputed using the technique discussed. For the purposes of this estimate, the complexity weigt:
factor is assumed to be average. Table 4.6.2 presents the resulis of this estimate.
Each of the complexity weighting factors is estinmated and the value adjustment factor is computed.
Table 4.6.3

Factor Value
Backup and recovery 4

Data communications

Distributed processing
Performance critical 4
 Factor Value

5. Existing operating environment 3

6 On-line data entry 4

7. input transaction over multiple screens 5

ILFs updated onlin

9. Information domain values complex 5

10. Internal processing complex 5

11. Code designed for reuse 4

12. Conversion/installation in design 3

13. Multiple installations

14. Application designed for change 5

Value adjustment factor 1.17

Finally, the estimated number of FPis derived:

FPestimated =count-total x[0.65 + 0.01 (F)1
FPestimated = 375

The organizational average productivity for systems of this type is 6.5 FP/pm.
4.6.5 Process-based Estimation

Ihe most common technique for estimating a project is to.base the estimate on the process that will be used. That
is, the process is decomposed into a relatively smallset of tasks and the effort required to accomplish each task is
estimated.
Table 4.6.4 : Process-based estimation table
Activity - CC Planning Risk analysis Engineering Construction release CE Totals
Task ’ Analysis Design Code Test

Function

UICF 0.50 2.50 0.40 5.00 n fa 8.40

2 DGA
0,75 4.00 0.60 2.00 na 7.35
3DGA 0.50 4.00 1.00 3.00 n fa 8.50
CGDF
0.50 3.00 1.00 1.50 n /a 6.00
DBM
0.50 3.00 0.75 1.50 n/a 5.75
 Construction release CE
Activity’ Planning Risk analysis Engineering
1.50
Totals
0.50 n fa
PCF 0.25 2.00 4.25
2.00 0.50 2.00 n fa 5.00
DAM 0.50
16.50
Totais 0.25 0.25 0.25 3.50 20.50 4.50 46.00
45% 10% 36%
effort 1% 1% 1% 8%

CC = Customer Communication,

CE = Customer Evaluation

function. Functions and related framee

A series of framework activities must be performed for each
presented in Table 4.6.4.
activities may be represented as part of a table similar to the one
After the probiem functions and development process activities are declared, the planner may begin estimatine:
process actiyih
the effort like person-months This estimation is necessary to accomplish each of the software
for each of software function. Ali these data constructs the central matrix of the table as shown in TabBe 4h4
The average labou rates like cost/unit effort are applied to the effort estimated for each of the process activity

4.6.6 An Exampie of Process-based Estimation

To explain the use of process-based estimation, we again consider the CAD software. Refer the compieted
process-based tabie shown in Table 4.6.4, estimates of effort (in person-months) for each software engineering
activity are provided for each CAD software function. The engineering and construction release activities ar
subdivided into the major software engineering tasks.
Generalty the gross estimatés of effort are prepared for communication with the customers, planning and risk
analysis. it must be noted that nearty 53 percent of the efforts is spent on front-end engineering tasks like
requirements analysis and design. It actually indicates the significance and importance of this work.
For example: Let the average burdened labour rate of $8,000 per
month, then the total estimated project cost 3
computed as $368,000, and the estimated effort is approximately 46
rates couid be associated with each framework activity, if person-months. In this case, the labou
desired. It can also be associated with each of the
software engineering task and calculated separately.
4.6.7 Estimation with Use-Cases
Use-cases give software team members to see into insight of
estimation approach can be probiematic due to following the software scope and requirements. But use-caseo
reasons:
Use-cases snay be written by using variousformats and
styles.So far, there is no standard
They represent the external view of the format.
software and may be described at various
They do not look at the Bevels of abstraction.
complexity of the functions and features.
And use-cases do not explain
in
complex behaviour also.
contrast to a LOC or a FP
Some other person's computations, the efforts required to
"use-case"
person may require a day or "may vary drastically. That is, one implement one person's "use-case" and
two. person mnay require months and
anou
 Toillustrate how this computation might be made, consider the following relationship:
LOCestimate Nx LOCavg +[(Sa/Sh - 1)+ (Pa/Ph - 1)] x LOCadjust ...(4.6.2)

where, N= Actuai number of use-cases

LOCg = Historical average LOCper use-case for this type of subsystem.
Represents an adjustment based on of LOCavg
LOCadjust
Actual scenarios per use-case
Sh = Average scenarios per use-case for this type of subsystem
Pa = Actual pages per use-case
Ph = Average pages per use-case for this type of subsystem
The Equation (4.6.2) is useful in developing the rough estimate of the number based on LOC and the actual
number of use-cases used by several scenarios along with the page length of the use-cases. Thus the adjustment
shows the historical average LOC per use case.
4.6.8 An Example of Use-Case based Estimation

The CAD software is composed of three subsystem groups :

1. User interface subsystem
2. Engineering subsystem group
3. Infrastructure subsystem group

Consider an example in that six use-cases describe the user interface subsystem. Each of the use case is written
by approximately 10 scenarios and it has an average length of six pages.
The engineering subsystem group is illustrated by approximately 10 use-cases. And each of these use-cases
may have 20 scenarios associated with it and it has an average length of nearly eight pages.
Finaliy, the infrastructure subsystem group is covered by five use-cases with an average of only six scenarios
and an average length of five pages.
Table 4.6.5 : Use-case estimation

Use-cases Scenarios Pages Scenarios Pages LOC LOC estimate

User interface subsystem 10 6 12 5 560 3,366

Engineering subsystem groupP 10 20 16 3100 31,233

|Infrastructure subsystem grOup 5 10 1650 7,970

|Total L0C estimate 42,568

OSing the relationship noted in Equation (4.6.2). the table shown in Table 4.6.4 is developed, Hence the LOC
Estimate for the user interface subsystem is computed using Equation (4.6.2). Using the same approach,
aumates are made for both the engineering and infrastructure subsystem groups. Table 4.6.5 summarizes the
estimates and indicates that the overall size of the CAD software is estimated at 42,500 LOC.
 An estimation model must be calibrated in such a way that reflects its local conditions. The estimation model
must be thoroughly tested by appiying the data gathered from the past completed projects.
A8.1 The Structure of Estimation Models
The estimation model is generally derived from regression analysis on the data that are collected from
previously collected software projects. The structure of estimation models take the following form:
E = A+Bx (e)e .(4.8.1)
Where A. B, and Care nothing but the empiricaly derived constants. The constant E is an effort in person
months, and the estimation variable is ev.
In addition to the relationship described by Equation (4.8.1), most of estimation models use project adjustment
component that enables the effort E. Generally the effort Eis adjusted by the following project characteristics :
Problem complexity,
Staff experience,
Development environment etc.
Various LOC-oriented estimation models that have been proposed in the literature are as followS:
1) E =5.288 x(KLOCj147 (Doty model for KLOC >9)
2) E =3.2 x(KLOC)1.05(Boehmsimple model)
3) E =5.2 ×(KLOCJ91 (Walston-Felix model)
4) E=5.5 +0.73 x(KLOCJL16 (Bailey-Basili model)
Foliowingare some FP-oriented models proposed :

1) E =-37+ 0.96 FP (Kemerer model)

2) E = -91.4 + 0.355 FP (Albrecht and Gaffney model)
3) E =- 12.88 +0.405 FP (small project regression model)
After observing ali these models, we come to conclusion that different results are possible for the same values of
LOC or FP.

4.8.2 The CocOMOI Model

University Question
t. txpiain CocoMO model for project estimation with suitable example.
SPPU. Dec. 13, Dec. 15, May 16, Dec. 16, Dec. 18, 8 Marks
al

Barry Boekm has devised a software estimation models hierarchy having the name as CoCOMO Le.
COnstrucive COst M0del. The COCOMO aodeB has been evolved into more comprehensive model called
COCOMO H. t is actually having ahierarchy of estimation models that focus the following areas :
Application composition modei : it is used in the early stages of development, when user interfaces,
system interactio, performance assesSnentaRd technokogy evaluation are prine important.
Earty design stage model: Once the requirernents are stabilized and basic architecture is constructed,
then eariy design stage model is used.
 Post-architecture stage model: lt is used during development of the software.
COCOMOl models also require sizing information ike other estimation models for the software.
sizing options are available:
Object points
Folowing thre,
Function points and
Lìnes of source code

The CoCOMO II model uses obiect points that are an indirect software measure. They are computed ..
the counts of :
Screenshots taken at user interface
Reports and
Components required in developing the application.
The screenshots or the reports are classified into any of the following three complexity levels :
Simple
Medium
Difficult

The client and server data tables are required tocreate the screenshots and reports. The complexity is defined as
the functionof these reports.
Table 4.8.1 :Complexity weighting for object types
Complexity weight
Object type
Simple Medium Difficult
Screen 1 2 3

Report 2 5

3GL Component 10

After the determination of complexity, the number of sereenshots, reports, and components object point are
weighted as per the Table 4.8.1. In component-based development when software reuse is implemented, then
the percent of reuse (% reuse) is estimated and the object point count is adjusted according to the following
equation:

NOP = (object points) x [(100 - % reuse)/100]

where NOP -’ New Object Points.
Table 4.8.2: Productivity rate for object points
Deveioper'sexperience/capability Very low Low Nominal High Very high
Environment maturity / capability Very low Low Nominal High Very high
PROD 7 13 25 50
In order to derive theestimate of etfort, a "productivity rate" shoukd be derived first. They are based On
computed NOP vaiue. The Tabie 4.8.2 shown above presents the
productivity rate.
These productivity rates are illustrated for various levels of developer's experience as well as various levels
environment maturity.
 PROD NOP/person-month
After determining the productivity rate, an estimate of project effort can be derived as follows :
Estimated effort NOP/PROD
4.8.3 The Software Equation
The software equation is a model that considers a specific distribution of effort over the project development
ife. The software equation model is a multivariable model. This model is deríved from productivity data
collected from nearly 4000 contemporary software projects. Depending on all these data, the estimation model
takes the following form:
E = [LOCx BO.33a/Pj3 x(1/t) ..(4.8.2)
Where, E = Person-months effort or person-yearsefforts
t = Duration of the project in months or years
B = The special skills factor

P = Productivity parameter
The productivity parameter reflects the following characteristics:
Process maturity
Managerment practices
Good software engineering practices
Programming languages used
Software environment
The skill set of team members

The experience of team members, and

The conplexity of the software
Typical values might be P = 2000 for development of real-time embedded software;
P= 10,000 for telecommunication and systems software; P= 28,000 for
business systems applications. The
efforts.
productivity parameter is derived using historical data collected from previous development
The software equation has following two independent parameters :
An estimate of size and

An indication of project duration.

4.9 Requirements Management :Preparing Requirement Traceability Matrix

University Question|
Draw and explain the traceabiity tabie for requirement maiagement. SPPUMay 14, 6 Marks
Requirement management is a software engineering task that helps the project team members to identify the
requirements, control the requiremnents, track the requirements and changes to requirements at any time as the
project exceeds.
 identification and each of the requirerments is
The requirement management task starts with assigried a
identifier.
developed. Traceability tabje
After the requirements finalízation, the traceability table is
is environment, The traceability tables
requirements tO one or more aspects of the system or it
one particular requirernent
requirements database and are useful in understanding how change in
other parts or aspects of thesystem.
Following are some examples of traceability table :
how it is closely r
Features traceability table observes product features and rmake sure that
customer requirement.
Source traceability table is used to identify the source of each of the requirement
Dependency traceability table observes the relationships among requirements.
Subsystem traceability table classifies the requírements as per the subsystem they govern.
interface traceability table indicates the internal and external system interface relate as per the g
requirenment.
Table 4.9.1 :Generic traceability table
Specific aspect of the system or its ervironment

Requirement A01 A02A03 A04 A05

ROT

R02

R03

RO4

RO5

Rnn
 lassmate

Hioect Schedislig
Sehedg respos'slee
by psojed uasag
Projct anag epíot ore
tast îo actfiuiea i-e

PM Prouide
psoUide eCsuate tíne s resour
(e requred do omplete
Cqives
for actiuity
4eciue prject scheduewg leado
Ho projet, reduced eost
ocess ef
îocKeasec cUctoue Qatisacricn

dettY ¬stiwarC People ro

POscib|e
dependenies RecoUrES

deterine

(onduc din? acti

 alassAte

dtes for
tiyeie *notoiies
Cbat

Toccplco?
tokwaratièos

Cutan
c(Cei) pace
lccativ)

dat. Cqiveg

PM al0 Cate ople for

perrormnA
Irsponilwisey:
the su)
 Gate
Page

DXfoed aulomy : Cach 4ask, ha)

Cuttowl.
deinct
oteslons: aHt (oroplet
Stcps lhey tate a fe
back 6om OOtom ? chec
LOhetes the picuct
Cstes

Prciect scheduliag technqRAi -

ccau weiboA:
t helps you determie both lcngesr
shotest pessible imetare to

2. 4

Ctast

E
3 1.

Reuie techoqls
PICqIan Evaluatioo
(tERT)
Coroplete it.
+irne 4ate) to
 classmate
Date
Page

Laptimistfe tme (o):

Qoictest fiae to Compiete pro,
(P):
Pcssin)ctic to)c
Longest re. to (ompiet. proir
Hue
Longest
R°reLy time Cm):
west itll take to oich
How
theVe.are no probkms.
yOUr projetoh
Lot4M+P)6
+ask 1
Hasr

<slar
>haskots
tase+
(tasts