Matin-Ao & Delacruz (Cost Estimation Techniques)

7/31/2019 Matin-Ao & Delacruz (Cost Estimation Techniques)

http://slidepdf.com/reader/full/matin-ao-delacruz-cost-estimation-techniques 1/21



Techniques, methods, and tools for planning,estimating, and monitoring the cost, budget,or schedule of a software project. Included inthis discussion are Function Point and Lines-of-Code cost estimation techniques.



Based From Wikipedia:

The ability to accurately estimate the timeand/or cost taken for a project to come in toits successful conclusion is a serious problemfor software engineers. The use of arepeatable, clearly defined and well

understood software development process has, in recent years, shown itself to be themost effective method of gaining usefulhistorical data that can be used for statistical

estimation. In particular, the act of samplingmore frequently, coupled with the looseningof constraints between parts of a project, hasallowed more accurate estimation and morerapid development times.

http://en.wikipedia.org/wiki/Project


http://en.wikipedia.org/wiki/Software_engineering


http://en.wikipedia.org/wiki/Software_development_process


http://en.wikipedia.org/w/index.php?title=Historical_data&action=edit&redlink=1
















◦ The development of the IBM OS/360

operating system over 30 years ago was amonumental undertaking. That effortspawned many technical innovations, nowwidely copied. In spite of technicalsuccesses, the OS/360 was a managementfailure. "The product was late, it tookmore memory than planned, the costs

were several times the estimate, and it didnot perform well until several releasesafter the first".



Dr. Brooks published many of his lessons

learned from managing this project in thebook "The Mythical Man-Month: Essays onSoftware Engineering". The book remainsone of the best-regarded texts on software

project management. Today, situationssimilar to the OS/360 remain all toofamiliar.



There are several techniques for cost estimation,

but the 2 basic approaches are top-down andbottom-up. In the top-down approach, cost isderived from a business analysis of the majorproject components. In the bottom-up approach,cost is derived by accumulating estimates fromthe people responsible for various components.

The primary techniques for cost estimation are:

Ask an expert in the domain of interest

Analogy to other projects "Price-to-Win" strategy

Resource availability

Parametric models



Expert judgmentDelphi cost estimation

Work breakdown structure

Algorithmic cost modelsConstructive cost model (cocomo)



A software project typically starts with a smallgroup of capable people to do planning andanalysis, a larger, but still small group to doarchitectural design. The size of required

personnel increases in each successive phase,peaks at the implementation and system testingphase, and decreases in the maintenance phase.

The personnel level of effort required throughout

the life cycle of a software product can beapproximated by the following equation, whichdescribes a Rayleigh curve:



Express oneself clearly in English • Develop and validate software requirements

and

specifications • Work within applications area

• Perform software maintenance

• Perform economic analyses

• Work with project management techniques • Work in group



“Changes that have to be made to computer programs after they have beendelivered to the customer or user.

Corrective maintenanceAdaptive maintenancePerfective maintenance

Enhancements (Although technically they are not apart of software maintenance but, being a post-releaseactivity, are often considered a part of it)



Software maintenance costs around 50%of total software life-cycle cost.

But relatively little is known about thesoftware maintenance process and the factorsthat influence its cost.



Defect repairs keep software in operational condition costs absorbed by software supplier low pre-release defect removal efficiency (~85%) productivity = 8 defect repairs per month (can be higher with experienced personnel and defect-

tracking tools etc.)

Abeyant defects (10%) - based on unique combinationof

events Invalid defects (15%) - misdiagnosed errors Bad fix injection (7%) - derivative errors Duplicate defects - multiple complaints about the

same error



concentration of errors in particular modules common among large poorly-structured systems expensive to maintain, due to high bad fix

injection rate 500% more expensive than normal modules

interface between clients and defect repairteams effort depends on number of users • with phone contact, 1 customer support person

for 150 users

• with electronic contact, 1 customer supportperson for 1000 users



Code restructuring

done by automated tools to lower complexity

levels lowering complexity eases maintenance

precursor to other maintenance activities

Migration across platforms

from one OS or hardware to another

with well-documented specifications,

migration speed = 50 FP per month

with missing or obsolete specifications, migration speed = 5 FP per month



Conversion to new architectures

l changes to interface or file structure of apps.

l quality of specifications affects productivity

l reverse engineering may need to be

performed to extract missing design info.

Mandatory changes

l in response to changes in law or policy

l involve high costs and tight schedules

l difficult to predict in advance



Performance optimization

to minimize delays in transactions

improving performance at trouble spots Enhancements

adding new features as per user request

funded by user

annual rate = 7% increase in FP total of anapp.

high integration and testing costs for poorly

structured apps.



del for software maintenance effort estimation (MM)AM = (ACT)(MM)DEV (MM)AM : annual maintenance effort in man-

month (MM)DEV : development effort in man-month ACT : annual change traffic (fraction of

software that undergoes change during a year) For intermediate and detailed COCOMO, (MM)AM = (EAF)M(ACT)(MM)NOM (EAF)M : maintenance effort adjustment factor



(MM)M = (M/D)(MM)DEV

(MM)M : overall life-cycle maintenance effortin man-month

(MM)DEV : development effort in man-month

M/D : maintenance/development cost ratio Value of M/D ranges from 0.67 to 4.5,

depending on

application type.



origin: number of cards each software person can

maintain (KDSI/FSP)M : KDSI maintained per full-time software

person(KDSI)DEV

(FSP)M = ------------------

(KDSI/FSP)M

(FSP)M : number of software maintenance personnelrequired

(KDSI)DEV : size of software in KDSI

Value of (KDSI/FSP)M ranges from 3 to 132,depending on application type. The annual maintenance effort (MM)AM is then simply (MM)AM = 12 (FSP)M



“Software processes must produce softwarethat can be gracefully evolved at reasonable costs. The choice of software architecture

significantly influences modifiability and hence

maintainability.Estimating maintenance is complex because of

the relationship between base application and changes being made. Moreover predicting adaptive maintenance and enhancements in advance is very difficult.

Matin-Ao & Delacruz (Cost Estimation Techniques)

Documents

Transcript of Matin-Ao & Delacruz (Cost Estimation Techniques)