SPM unit-2m
-
Upload
aishwarya-thamizharasi -
Category
Documents
-
view
241 -
download
0
description
Transcript of SPM unit-2m
-
Software Project Management
Size and Cost Estimation
*
-
Overview
Different level of estimationProject EvaluationIntroduction to EstimationSize EstimationCost Estimation*
*
The emphasis is on the last two items.
However, project managers need to understand there are various level of estimation based on the purposes.
Spend 30-40 minutes on first 34 slides. Can skip some because they are rather obvious.
-
Different level of estimation
Before decision to do a project The estimation is coarseThe estimation is in high level termsProfit? Good to the organization? etc.After decision to go aheadMore detailed size and cost estimations are required*
-
Project Evaluation
A high level assessment of the projectto see whether it is worthwhile to proceed with the projectto see whether the project will fit in the strategic planning of the whole organization*
-
Project Evaluation - Why
Want to decide whether a project can proceed before it is too lateWant to decide which of the several alternative projects has a better success rate, a higher turnover, a higher ...Is it desirable to carry out the development and operation of the software system?*
-
Project Evaluation - Who
Senior managementProject manager/coordinatorTeam leader*
-
Project Evaluation - When
Usually at the beginning of the projecte.g. Step 0 of Step Wise Framework*
-
Project Evaluation - What
Strategic assessmentTechnical assessmentEconomic assessment*
-
Project Evaluation - How
Cost-benefit analysisCash flow forecastingCost-benefit evaluation techniquesRisk analysis*
-
Technical Assessment
Functionality against hardware and softwareThe strategic IS plan of the organizationany constraints imposed by the IS plan*
*
Functionality: evaluate the functionality of the product against available hardware and software
Constraints: constraints imposed by the companys IS plan will affect the development cost
-
Economic Assessment
Why?
Consider whether the project is the best among other optionsPrioritise the projects so that the resources can be allocated effectively if several projects are underway*
*
A common way is to compare the expected costs of development and operation of the system with the benefits of having it in production
-
Economic Assessment (contd)
How?
Cost-benefit analysisCash flow forecastingVarious cost-benefit evaluation techniquesNPV and IRR*
*
Cost-benefit analysis is to compare the estimated costs of development and operation of a system with the estimated benefits of putting the system in place.
Cash flow forecasting is
Why need Cash flow forecasting? It is because the excess of benefits over costs is not sufficient to justify the implementation of a proposed project.
-
EA Cost-benefit Analysis
A standard way to assess the economic benefitsProject will be prioritized so that resources are allocated effectively.Two stepsIdentify and estimate all the costs and benefits of carrying out the projectThese includes development cost , operating & expected cost.Express the costs and benefits in a common unit for easy comparison (e.g. $)Evaluate Net benefit (i.e) total benefit & total cost of creating operating cost*
-
EA Cost-benefit Analysis (contd)
CostsDevelopment costsIncludes salaries & other employment cost of staff involved in development project & all associated cost Setup costs Includes costs of putting system into place but also includes cost of file conversion, recruitment & staff trainingOperational costsConsist of cost of operating system once it has been installed.*
*
Development costs:
Salaries and employment costs of staff
Hardware and software for development platform
Setup cost: cost for putting system in place
New hardware and ancillary equipments
Database conversion
Recruitment of staff
Staff training
-
EA Cost-benefit Analysis (contd)
BenefitsDirect benefitsAssessable indirect benefitsIntangible benefits*
*
Benefits are quite difficult to quantify in monetary terms even if they are identified.
Direct benefits are those accrue directly from the operation of the system.
Examples:
Reduction of staff employment
Re-organization of staff
Assessable indirect benefits are the secondary benefits.
Example:
Increase of accuracy through a more user-friendly screen
Intangible benefits relate to those benefits that are longer term in nature or those benefits that are considered very difficult to quantify.
Example:
Enhanced job interest lower recruitment costs
-
EA Cash Flow Forecasting
What?Estimation of the cash flow over timeWhy?An excess of estimated benefits over the estimated costs is not sufficientNeed detailed estimation of benefits and costs versus time*
*
Cash flow: income and expenditure
-
EA Cash Flow Forecasting (Contd)
*
Expenditure
Income
*
Need to spend money at first (e.g. staff salary, employment cost, hardware and software costs) no matter where the money comes from
e.g. resources from company, or money from the bank
If the money is from bank, you need to calculate the interest as well.
-
EA Cash Flow Forecasting (Contd)
Need to forecast the expenditure and the incomeAccurate forecast is not easyNeed to revise the forecast from time to time*
*
Expenditure:
Staff salary, recrutment costs, bank interest
We only calculate the bank interest, if any. Alternatively, we can calculate the bank repayment as one of the expense and the bank loan (principle) as one of the incomes.
Income:
Payment on completion and Payment by phases
Payment by phases is more likely to occur in outsourcing projects.
Forecast is not easy:
Not much information at the early phases of the project
The project may span several years
Revise the cash flow forecast quarterly, or even monthly.
-
Cost-benefit Evaluation Techniques Example
*
YearProject 1Project 2Project 3Project 40-100,000-1,000,000-100,000-120,000110,000200,00030,00030,000210,000200,00030,00030,000320,000200,00030,00030,000420,000200,00020,00025,0005100,000350,00020,00050,000Net Profit60,000150,00030,00045,000Payback5544ROI12%4%10%11%*
Simple example: (where negative values represent net expenses, positive values represent net incomes)
Assumptions:
1. Cash flow take place at the end of each year.
2. The year 0 figure represents the initial investment made at the start of the project.
Let the student to do the calculation themselves during the lecture.
-
Cost-benefit Evaluation Techniques
Net profit= Total income Total costs
Payback period= Time taken to break even or pay back the initial initial investment. Normally shortest pay back period be chosen to minimize time in debit .( eg:In project3 : during the fouth year initial investment cost will be taken.)
Return on Investment (ROI)*
*
Net profit
Advantage: simple to use
Disadvantage: ignores the timing of the cash flow
Payback period
Advantage: simple to calculate, not particular sensitive to small forecasting errors
Disadvantage: ignores any income (or expenditure) after the payback period
Return on Investment (ROI)
Advantage: simple and easy to calculate, quite popular
Disadvantage:
1. ignores the timing of the cash flow
2. Potentially very misleading because it is very tempting to compare the rate of return with the current interest rates
-
Cost-benefit Evaluation Techniques NPV
Net present value (NPV)
It is the sum of the present values of all future amounts.Present value is the value which a future amount is worth at presentIt takes into account the profitability of a project and the timing of the cash flows*
*
NPV
Advantage: takes into account the profitability of a project and the timing of the cash flows that are produced.
Disadvantage:
1. hard to select an appropriate discount rate
2. NPV might not be directly comparable with earnings from other investments or the costs of borrowing capital.
-
Cost-benefit Evaluation Techniques NPV (contd)
Discount rate is the annual rate by which we discount future earninge.g. If discount rate is 10% and the return of an investment in a year is $110, the present value of the investment is $100.*
*
-
Cost-benefit Evaluation Techniques NPV (contd)
Let n be the number of year and r be the discount rate, the present value (PV) is given byr-Discount rate & t-number of years into the future that flow occurs*
-
Cost-benefit Evaluation Techniques NPV (contd)
Issues in NPVSelecting an appropriate discount rate is difficultEnsuring that the rankings of projects are not sensitive to small changes in discount rateNormally any initial investment takes place immediately an is not discounted- later cash flows are normally assumed to place at the en of each year and are discounted approx.(Note : Refer Sums in text book)*
*
-
Cost-benefit Evaluation Techniques NPV (contd)
Guidelines:Use the standard rate prescribed by the organizationUse interest rate + premium rateUse a target rate of returnRank the projects using various discount rates*
-
Cost-benefit Evaluation Techniques NPV (contd)
DisadvantageNPV measure of profitability although it may be use to compare projects, it might not be directly comparable with earnings from other investments or the costs of borrowing capital*
-
Cost-benefit Evaluation Techniques IRR
Internal Rate of Return (IRR)It attempt to provide a profitability measure as a percentage return that is direct comparable with interest rateThe percentage discount rate that would produce a NPV of zeroA relative measureEg: IRR of 10% is worth while if capital could be borrowed for less than 10% or if capital could not be invested else where for a return greater than 10% (note : refer books for sum)*
*
Use Excel to demonstrate the calculation of NPV and IRR. See file lect03-npv.xls.
The IRR being a relative measure does not indicate the absolute size of the return.
-
Cost-benefit Evaluation Techniques IRR (contd)
*
11
9
8
-3000
3000
6000
9000
12
10
Discount rate (%)
Net Present Value($)
0
-
Cost-benefit Evaluation Techniques IRR (contd)
AdvantagesConvenientDirectly comparable with rate of return on other projects and with interest ratesUsefulDismiss a project due to its small IRR value Indicate further precise evaluation of a projectSupported by MS Excel and Lotus 1-2-3*
*
It is convenient in the sense that further calculation are not required.
It is useful in the sense that, in many cases, it is sufficient to dismiss a project or indicate further investigation of a project even though it is an approximation.
-
Estimation
Why? to define the project budget and to refine the product to realize the budgetWho? the managerWhat? size and costWhen? alwaysHow? techniques and models*
-
Issues related to Estimation
Difficult to make accurate estimationBetter to have previous data and analyze the actual values against their estimates so that you know how accurate you areEven better to have previous data of the whole organization so that you know how accurate the estimation method, if any, used within the organization is*
*
Even you have your own personal historic data and those of the organization, there is still no guarantee that your next estimation is an accurate one.
-
Positive Attitude Towards Estimation
Use your estimation as a guide to manage your projectFrom time to time, you need to revise your estimation based on the current status of the project*
-
Estimation Approaches
Expert judgementAsk the knowledgeable expertsEstimation by analogyUse the data of a similar and completed projectPricing to winUse the price that is low enough to win the contract*
-
Estimation Approaches (contd)
Top-downAn overall estimate is determined and then broken down into each component taskBottom-upThe estimates of each component task are aggregated to form the overall estimateAlgorithmic modelEstimation is based on the characteristics of the product and the development environment.*
*
Top-down: An 14-month project would have broken down into 4 months on plans and requirements specification; 4 months on months on product design; 2 months on detailed design; 2 months on coding and unit testing; 3 months on integration testing and user-acceptance testing; and 1 month on training.
Bottom-up: The reverse of top-down.
Most models in estimation are algorithmic models.
-
Size Estimation
Problems related to size estimationSize Estimation ModelFunction Point Analysis (FPA)*
-
Problems related to size estimation
Nature of softwareNovel application of softwareFast changing technologyLack of homogeneity of project experienceSubjective nature of estimationPolitical implications within the organization*
*
Nature of software is about its complexity and invisibility
Novel application of software: each time the software to be developed has some unique features.
Fast changing technology: technology changes very fast, how well the personnel can manage the new technology is still not known yet.
Lack of homogeneity of project experience: past data is not available for present estimation
Political implications: The marking director tends to push the product to be on the market at an early stage. Project manager may then have a tighter schedule as planned.
-
Function Point Analysis (FPA)
Developed by A. Albrecht in IBMAim: To estimate the LOC of a systemLOC of system
= FP of system LOC-per-FP of the language
*
*
FPA is a top-down approach.
Developed by Albrecht (1979) and later refined by Albrecht and Gaffney (1983)
Used in development with 3GL (3rd Generation Language)
LOC means Line of Code (programming statement)
For COBOL, the LOC per FP is 91.
For C, the LOC per FP is 128.
-
Function Point Analysis (contd)
Idea: Software system consists of five major components (or, external user types)External input typesExternal output typesLogical internal file typesExternal interface file typesExternal inquiry types*
*
External input types
Input transactions that update internal computer files
External output types
Transactions that output data to user such as report printing.
Logical internal file types
The standing file used by the system.
File: a group of data that is usually accessed together. It may have one or more record types. Example: A PurchaseOrder may contain one or more PurchaseItems.
External interface file types
Input and output that may pass from and to other computer applications.
Files shared among applications would also be counted.
Example: the transmission of accounting data from an order processing system to the main ledger system.
External inquiry types
Transactions initiated by the user that provide information but do not update the internal files.
-
Function Point Analysis - Steps
Identify each instance of each external user type in the proposed systemClassify each instance as having high, medium or low complexityAssign the FP of each instanceFP of the system = sum of FP of individual components*
*
To obtain the LOC, multiply FP of the system by the LOC per FP value for the programming language used.
For COBOL, the LOC per FP is 91.
For C, the LOC per FP is 128.
-
Function Point Analysis
*
Number of FPsComplexityExternal user typeLowAverageHighExternal input type346External output type457Logical internal file type71015External interface file type5710External inquiry type346 -
Function Point Analysis - Example
A component of an inventory system consisting of Add a record, Delete a record, Display a record, Edit a record, and Print a record will have3 external input types1 external output type1 external inquiry typeThen, assign FPs based on the complexity of each type
*
*
3 external input types: add, delete, and edit (all of low complexity)
1 external output type: print (average complexity)
1 external inquiry type: display (high complexity)
Result: 3*3 + 1*5 + 1*6 = 20.
-
Function Point Analysis (contd)
Other issuesThe assignment of level of complexity is rather subjectiveInternational FP User Group (IFPUG) imposes rules on assigning the level of complexity to individual external user types*
*
For further rules imposed by IFPUG, see Tables 5.3 to 5.5, Hughes book.
-
Object Point Analysis
Similar to function point analysisUsed on 4GL development projectsTakes account of features that may be more readily identifiable if the system is built on high-level application building tools*
*
The word object in object points has nothing to do with object oriented techniques.
Procedure suggested by Kauffman and Kumar (1993)
Productivity data reported by Banker, Kauffman and Kumar (1994)
-
Object Point Analysis Steps
Identify the number of screens, reports and 3GL componentsClassify each object as Simple, Medium and DifficultAssign the weight accordinglyCalculate the total object pointsTotal OP = sum of individual OP weighting
*
*
3GL: 3rd Generation Language
Objects:- screens, reports and 3GL components
It is assumed that these objects are defined in a standard way as part of an integrated CASE environment.
The 3GL components are used to supplement the 4GL code.
Classifying the level of objects and assigning the complexity weightings is done according to some guidelines (see tables below)
-
Object Point Analysis Steps (contd)
Deduct the reused objects (r% reused)NOP = OP (1 r%)
Identify the productivity rate of both developer and CASEProductivity rate = average of the two PRsCalculate the effortEffort = NOP / Productivity Rate
*
*
NOP: New Object Point
The productivity rate of developers experience and capability and CASE maturity and capability is the average of the two values from the table.
-
Object Point Analysis Screens
*
Number and source of data tablesNumber of views containedTotal < 4(5 client)< 3SimpleSimpleMedium3 7SimpleMediumDifficult8+MediumDifficultDifficult*
-
Object Point Analysis Reports
*
Number and source of data tablesNumber of sections containedTotal < 4(5 client)< 2SimpleSimpleMedium2 or 3SimpleMediumDifficult> 3MediumDifficultDifficult*
-
Object Point Analysis Complexity Weightings
*
ComplexityType of objectSimpleMediumDifficultScreen123Report2583GL componentN/AN/A10*
Note that: All 3GL components may be of different size. But, according to OBA, they are the same.
-
Object Point Analysis Productivity Rate
*
Very lowLowNominalHighVery HighDevelopers experience and capability47132550CASE maturity and capability47132550*
-
Object Point Analysis Issues
Adopted in Boehms COCOMO II in the application composition stage*
*
-
Object Point Analysis Example
See separate handout*
*
Description is too complicated to contain in any slides.
See Word document lect03-COCOMOII.doc.
-
Cost Estimation
Cost Estimation ModelCOCOMO II*
*
-
Constructive Cost Model II (COCOMO II)
A parametric cost modelImportant aspects of software projects are characterized by variables (or parameters)Once the value of the parameters are determined, the cost can be computed from an equation*
*
COCOMO is a parametric model
-
COCOMO II (contd)
Recognizes different approaches to software developmentPrototyping, Incremental development etc.Software Project Management
*
*
-
A history of COCOMOs
COCOMO originally proposed by Boehm in 1981, now called COCOMO 81Later evolved to Ada COCOMO in 1989In 1995, Boehm proposed COCOMO IISoftware Project Management
*
*
-
COCOMO II
A family of modelsUses different models in 3 different stages of the project3 stages: application composition, early design and post architectureSupports estimation early in the processAllows further detailed estimation after the system architecture has been definedSoftware Project Management
*
*
-
COCOMO II (contd)
The basic model equationEffort = Constant (Size)scale factor
Effort Multiplier
Effort in terms of person-monthsConstant: 2.45 in 1998Size: Estimated Size in KSLOCScale Factor: combined process factors Effort Multiplier (EM): combined effort factorsSoftware Project Management
*
*
KSLOC is Kilo Source Line of Code
Scale Factor is also called Process Exponent in Royce (1998).
Effort Multiplier is also called Effort Adjustment Factor in Royce (1998).
-
The Application Composition Stage
Estimation at the early stageCorresponding to exploratory work such as prototypingUses object points to estimate the size of the productSoftware Project Management
*
*
-
The Early Design Stage
Estimate after the requirements specification is completed and possibly with some designUse the basic model equationEstimate the size by FPs (preferred) or KSLOCEstimate scale factor and effort multiplierSoftware Project Management
*
*
The value of the Constant is 2.45 in 1998 (also suggested by Royce).
Although size estimation is done in FP, the value has to be converted to KSLOC for the calculation.
-
The Early Design Stage Scale Factor
Estimation of the scale factorA combined effect of 5 parametersApplication precedentednessProcess flexibilityArchitecture risk resolutionTeam cohesionProcess maturitySoftware Project Management
*
*
Application precedentedness: the degree of domain experience of the development organization
Process flexibility: the degree of contractual rigor, ceremony, and change freedom inherent in the project contract, life-cycle activities, and stake-holder communications
Architecture risk resolution: the degree of technical feasibility demonstrated before commitment to full-scale production
Team cohesion: the degree of cooperation and shared vision among stake-holders (buyers, developers, users, and maintainers, among others)
Process maturity: the maturity level of the development organization, as defined by SEIs CMM
-
The Early Design Stage Scale Factor (contd)
Software Project Management
*
ParameterVery Low(0.05)Low(0.04)Nominal(0.03)High(0.02)Very High(0.01)Extra High(0.00)PrecedentednessThoroughly unprecedentedLargely unprecedentedSomewhat unprecedentedGenerally familiarLargely familiarThoroughly familiarDevelopment flexibilityRigorousOccasional relaxationSome relaxationGeneral conformitySome conformityGeneral goalsArchitecture risk resolutionLittle20%Some40%Often60%Generally 75%Mostly90%Full100%Team cohesionVery difficult interactionsSome difficult interactionsBasically cooperativeLargely cooperativeHighlyCooperativeSeamless interactionsProcess maturityLevel 1Level 2Level 2+Level 3Level 4Level 5*
Beware that Table B-7 of Royce (1998) gives 0.00 to Very Low, 0.01 to Low, etc which is a bit confusing. There might be some printing errors.
This is confirmed in COCOMO II Model Definition Manual (Very Low 0.05 Very High 0.01).
The manual is download from USCs COCOMO site (http://sunset.usc.edu)
-
The Early Design Stage Scale Factor (Contd)
Calculate the scale factor based on the equationScale factor = 1.01 + sum of the values
Software Project Management
*
*
The range of process exponent is from 1.01 to 1.26.
The smaller is the number, the less extra effort is needed.
Thus, an ideal team will have the ideal process exponent value (1.01).
-
The Early Design Stage Effort Multiplier
7 factors in Effort Multiplierproduct Reliability and ComPleXity (RCPX)required reusability (RUSE)Platform DIFficulty (PDIF)PERSonnel capability (PERS)PeRsonnel EXperience (PREX)FaCILities available (FCIL)SChEDule pressure (SCED)Software Project Management
*
*
-
The Early Design Stage Effort Multiplier (contd)
Assess each factor byVery low, low, nominal, high, very high, and extra highAssign each factor using a value between 0.5 and 1.5 (inclusive)EM is the product of all these valuesSoftware Project Management
*
*
The typical range of each factor is from 0.5 to 1.5.
Beware that
For some factors such as PDIF: 0.5 (very low) 1.5 (extra high)
For other factors such as PREX: 0.5 (extra high) 1.5 (very low)
Sometimes, the value may exceed 1.5. However, if the difference is too much, the validity of the model is rendered.
Your organization can have your own values. For example,
CPLX may have 0.70 1.65 (from very low to extra high);
PERS may have 1.42 0.70 (from very low to extra high).
If no idea, start with nominal value (for example 1.0). However, there are situations that the nominal value may not be 1.0. It is up to you and your organization.
-
The Early Design Stage Effort Multiplier (contd)
Software Project Management
*
Early DesignVery Low Extra HighRCPX0.5 1.5RUSE0.5 1.5PDIF0.5 1.5PERS1.5 0.5PREX1.5 0.5FCIL1.5 0.5SCED1.5 0.5 -
The Early Design Stage Example
See separate handoutSoftware Project Management
*
*
Description is too complicated to contain in any slides.
See Word document lect03-COCOMOII.doc.
-
The Post-architecture Stage
Estimation after the software architecture has been definedThe same basic model equationSize estimation by KSLOC (preferred) or FPsSame scale factor estimation17 factors in EM (7 in early design stage)Software Project Management
*
-
The Post-architecture Stage Effort Multiplier
17 factors in 4 different categoriesProduct attributesPlatform attributesPersonnel attributesProject attributesSoftware Project Management
*
*
Factors with ** is the same as that in early design stage.
Factors with * or ^ is a part of some factor in the early design stage.
Other factors are new to the post-architecture stage.
-
The Post-architecture Stage Effort Multiplier
Product attributesRequired reliability (RELY)*Database size (DATA)Product complexity (CPLX)*Required reuse (RUSE)**Documentation (DOCU)*Relate to RCPX in early design stage
Software Project Management
*
-
The Post-architecture Stage EAF (Contd)
Platform attributesexecution TIME constraint (TIME)*main STORage constraint (STOR)*Platform VOLatility (PVOL)**Related to Platform DIFficulty (PDIF) in early design stage
Software Project Management
*
-
The Post-architecture Stage EAF (Contd)
Personnel attributesAnalyst CAPabilities (ACAP)^Application EXPerience (AEXP)*Programmer CAPabilities (PCAP)^Personnel EXPerience (PEXP)*programming Language/Tool EXperience (LTEX)*Personnel CONtinuity (PCON)^Software Project Management
*
*
*Relate to personnel experience (PEXP)
^Related to personnel capability (PCAP)
-
The Post-architecture Stage EAF (Contd)
Project attributesuse of software TOOLs (TOOL)*multiSITE development team communications (SITE)**Relate to FCIL in early design model
Software Project Management
*
-
EAF Relations
Software Project Management
*
Early DesignPost-ArchitectureRCPXRELY, DATA, CPLX, DOCURUSERUSEPDIFTIME, STOR, PVOLPERSACAP, PCAP, PCONPREXAEXP, PEXP, LTEXFCILTOOL, SITESCEDSCED -
The Post-architecture Stage Example
See separate handoutSoftware Project Management
*
*
Description is too complicated to contain in any slides.
See Word document lect03-COCOMOII.doc.
-
COCOMO II (contd)
AdvantagesGood improvement over COCOMOGood match for iterative development, modern technology, and management processDisadvantagesStill immature, diverse projects in databaseHard to believe that it will be any more reliable than the original COCOMO modelSoftware Project Management
*
*
There are 83 projects in the project database according to Royce (1998).
-
References
Hughes, B., and Cotterell, M. (1999) Software project management, 2nd ed., McGraw HillPfleeger, S.L. (1998) Software Engineering: Theory and Practice, Prentice HallRoyce, W. (1998) Software Project Management: A Unified Framework, Addison WesleyCenter for Software Engineering, USC (1999) COCOMO II Model Definition Manual.Software Project Management
*
%
100
investment
total
profit
annual
average
=
%
12
100
100,000
60,000/5
:
=
eg
60000
000
,
100
000
,
160
:
=
-
eg
n
r
n
)
(1
year
in
value
(PV)
lue
Present va
+
=
9091
.
0
)
10
(1
000
,
10
Year
first
in
A
Project
for
PV
:
Eg
1
=
+
=