Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Metrics more

Metrics more

Ratings: (0)|Views: 111 |Likes:
Published by api-3756170

More info:

Published by: api-3756170 on Oct 16, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





inspection/testing will not improve or will not guarantee the quality of the
product/service. the product quality can only be guaranteed/improved through
constantly improving the underlying processes followed to produce the product or
deliver the service

fundamental metrics \u2013rule: size is either measured as lines of code (loc), the

number of function points or change complexity
for measuring loc
\u2022count statements that are executed or interpreted
\u2022count only once for any statement
\u2022do not count blank lines and comments
for measuring function points:
\u2022use the ifpug guide
for estimating and measuring complexity of change in maintenance requests:
\u2022define program complexity and change complexity. (for example the complexity can
be estimated as simple =1, medium=3 or complex=5.)


1. for development projects size is estimated at initiation, analysis and design
stages. the size is measured after the code is constructed.
2. for conversion projects the size of source code is measured and converted code is
estimated in the initiation and design phase. after the code is converted to target
platform, the size is measured.
3. tcs-qms-103, software estimation guidelines provides details on size estimation
4. size estimation and measurement need to be done at functionality level and
aggregated to get the application level
5. for individual maintenance requests use complexity as the measure of size

fundamental metrics - effort: effort is measured as number of person days spent
to estimate
effort = size/productivity

where productivity is calculated as
a. number of loc or fp/day in development and conversion projects
b. number of simple requests/day in maintenance requests
c. the productivity is normally for the complete life cycle.


1. effort is estimated at the initiation of project and recalculated at every phase.
2. in case of development projects effort estimation is done at functionality level and
aggregated up for the application level.
3. in case of conversion projects effort estimation is done at module level and
aggregated up for the application level.
4. the effort for sdlc phases is calculated by apportioning the total effort. example
the apportion is (refer the estimation guidelines for details)
analysis = 25%; design = 20%; construction = 38%; system testing = 17%
5. in case of maintenance projects, the effort estimation is done at maintenance
request level


1. productivity is derived for a given technology from the projects done earlier. adjust
the productivity figures in case if the phases or life cycle has differences from the
original project.

2. in case productivity figures are not available for estimation purpose, estimate
effort using cocomo model.
3. measure actual effort spent for each phase either by functionality or module as
done in the estimation. effort spent on testing, reviews and rework is also recorded

fundamental metrics - defect:

\u2022 defect is any deviation from the user expectation or the standards. defects are
identified through inspections, reviews and testing.
\u2022 defect is classified on the basis of severity.
\u2022severity 1: fatal errors that cause the program to abort
\u2022severity 2: fatal errors that result in erroneous outputs
\u2022severity 3: errors which are not fatal
\u2022severity 4: suggestions towards improvement

1. do not count duplicate errors
a library routine may be used by many application programs. an error in the library
routine may manifest as many errors across the application. if the error in the library
routine is removed then all the errors manifested due to it will disappear. count such
errors only once.
2. assign first level cause to the defect
the developer has to assign the first level cause to the defect.
3. identify the source of defect
the developer has to find the source of defect. the source may be the same phase
where the defect is detected or one of the earlier phases

improve planning & estimation - size deviation
size deviation is calculated as
actual size \u2013 estimated size
---------------------------------* 100

estimated size
in a development project the size was estimated to be 85 kloc for the application to
be developed. at the end of construction the application had 100 kloc. calculate the
size deviation for the project

the size deviation for the project = (100 -85)*100 /85 = 17.6%

1.in the above example, if the change in size estimation at the design stage was due
to a change request from the customer, then the size deviation will be calculated as
(100-105)*100/105 = - 4.7%.
2. size deviation is calculated for
a. development projects
b. conversion projects where the conversion involves rewriting of code
3. size deviation is calculated at each phase end. in case of spiral/iterative model
based development projects it is calculated at each delivery. the estimated size is
taken from at requirement phase or when the last change in requirement was base

improve planning & estimation - effort slippage
effort slippage is calculated as actual effort \u2013 estimated effort
---------------------------------- * 100
estimated effort
in a development project the life cycle effort was estimated for a delivery module as
100 person days.

the effort spent at analysis phase was 40 days. the effort spent at design stage was 22 days. the construction effort was 48 days. the testing effort was 15 days. on the basis of standard apportioning of effort to life cycle phases, calculate the effort slip and infer the data:

effort slippage for the delivery module
= (120 \u2013 100)*100/100

= 25%
1. as a project planning activity the slippage in the effort need to be monitored
continuously during the project course. effort slippage may lead to cost over run.
2. effort slippage is formally computed as a metric for phase ends in case of
development projects and conversion projects. in spiral and iterative model of
development, if the cycle time for each delivery is low (less than 2 months) then it is
calculated for each delivery
3. in case of maintenance projects, effort slippage can be computed at cr/sr level
metric or for medium and complex maintenance requests.
4. in case of implementation projects, the effort slippage is calculated at phase end

improve planning & estimation - schedule slippage
schedule slippage is calculated as
actual elapsed time \u2013 planned elapsed time
--------------------------------------------------------* 100
planned elapsed time

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->