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
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
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
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
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
\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
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
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
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:
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
Now bringing you back...
Does that email address look wrong? Try again with a different email.