SPM unit-2m

76
Software Project Management Size and Cost Estimation

description

Unit 2 two marks

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 system

    LOC 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 type

    Then, 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 points

    Total 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 effort

    Effort = 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 II

    Software 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 defined

    Software Project Management

    *

    *

  • COCOMO II (contd)

    The basic model equation

    Effort = 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 factors

    Software 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 product

    Software 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 multiplier

    Software 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 maturity

    Software 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 equation

    Scale 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 values

    Software 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 handout

    Software 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 attributes

    Software 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 handout

    Software 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 model

    Software 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

    =

    +

    =