Software Project Management begins with a set of activities that are collectively called Project Planning. Software Project Planning encompasses Five major activities: 1. Project Estimation 2. Project Scheduling 3. Risk Analysis 4. Quality management Planning 5. Change Management Planning ESTIMATION Software Project Management begins with a set of activities that are collectively called Project Planning.

Before a Project begins Project Manager must Estimate
The Work to be done The Resources that will be required. The Time that will be ³elapsed´ from start to finish.

‡ The Software Team must establish a Project Schedule that defines :a) Software Engineering tasks b) Milestones, c) Responsible for conducting each task, d) Inter-task dependencies. . Estimation lays a foundation for all other Project Planning activities and that Project Planning provides the ³ROAD MAP´ for successful Software Engineering.



‡ Estimation is as much µ¶Art¶¶ as it is Science. However this important activity need not be conducted in a haphazard manner. Software Estimation begins with a description of the ³SCOPE OF SOFTWARE PRODUCT´.
Until the Scope is ³Bounded´ it is not possible to develop a meaningful Project Estimate.



The µ¶PROBLEM¶¶ is then decomposed into a set of smaller Problems and each of these is Estimated using historical data (Metrics) and/or previous experience as a guide. The Problem Complexity and Risk are then considered before final Estimate is made.


Estimation of Recourses, Cost and Schedule for a Software Engineering Effort requires:- Experience, - Access to good historical information (Project Metrics) - Courage to commit to Quantitative predictions (when Quantitative information is all that exists). Estimation carries inherent ³RISK´, and this Risk leads to uncertainty. The availability of Historical Information (Project Metrics) has a strong influence on Estimation Risk. Estimation Risk is measured by the degree of uncertainty in the Quantitative Estimates establish for Recourses, Cost and Project Schedule. Estimation Risk becomes dangerously high when Project Scope is poorly understood or Project Requirements are subject to changes.

. Software Scope is defined using one of the following techniques: .SOFTWARE ESTIMATION SOFTWARE SCOPE AND FEASIBILITY Software Scope Describes: . .The ³Content´ that is presented to user as a consequence of using the software. . .A set of Use-Cases are developed by end-users. constraints.The function and features that are to be delivered to end-users.A narrative description of software scope is developed after communication with all stakeholders. reliability and interfaces that bounds the system.Performance.The data that are input and output. .

SOFTWARE ESTIMATION SCOPE CONSIDERATION Functions described in the ³Statement of Scope´ or within the Use-Cases are evaluated and in some cases refined to provide more detail point to the beginning of Estimation. ‡ ‡ . available memory size on other existing system. ‡ Because both Cost and Schedule Estimates are functionally oriented. Constraints identify limits placed on the software by hardware. Performance considerations encompass Processing and Response Time requirements. some degree of functional decomposition is useful.

Since not everything in real life is feasible.SOFTWARE ESTIMATION SCOPE CONSIDERATION Once the Project Scope has been identified it is reasonable to ask yourself:. the Software Feasibility is emphasized in Estimation.Is the Project feasible? Often Software Engineers rush past these questions only to become mired (become stuck) in a Project that is doomed from the onset.Can we build the Software to meet this scope? . Software Feasibility has four solid dimensions: Technology Finance Time Resources .

NOTE: The last two characteristics can be viewed as a ³Time Window´. Time when resources will be required.SOFTWARE ESTIMATION SOFTWARE SCOPE AND FEASIBILITY Once the Software Scope and Feasibility have been identified the second task is Estimation of the ³RESOURCES´ required to accomplish the Software Development Effort. Availability of the Resource for a specified window must be established at the earliest practical time.People . . S/W Tools) Each Resources is specified with four Characteristics: Description of the resource. RESOURCES The three major categories of Software Engineering Resources: .Reusable software components. . A statement of availability.Development environment (H/W. Duration of the time that resource will be applied.

. Person-months) is made. Manager. Senior Software Engineer etc and the specialty (e.g.The Number of People required for a Software Project can be determined only after an Estimate of Development Effort (e. Both Organizational position (e.g Database Telecommunication.g. client/server etc) and the Location of each human resource is specified.SOFTWARE ESTIMATION 1. . HUMAN RESOURCES .The Project Planner begins by evaluating Software Scope and selecting the µ¶skills¶¶ required to complete development.

. If Partial-Experience Components are available. If full-experience components are available.SOFTWARE ESTIMATION 2. PARTIAL-EXPERINECE COMPONENTS 4. REUSABLE SOFTWARE RESOURCES The Reusable Software Resource categories:1. NEW COMPONENTS: Guidelines for Planning Reusable Resource Components :1. 2. If Off-the-Shelf Components meet Project requirement acquire them.If extensive modification is required proceed carefully since the cost to modification can sometimes be greater than the cost to develop new components also Risk is high. The cost of the off-the-shelf components will almost always be less than the cost to develop equivalent software. OFF-THE-SHELF COMPONENTS 2. . the use of them for current Project must be carefully analyzed. the risk associated with modification and integration are generally acceptable. FULL-EXPERIENCE COMPONENTS 3. 3. Also risk is low.

ENVIRONMENTAL RESOURCES The Software Engineering Environment (SEE) corporate Hardware and Software / NetWare.SOFTWARE ESTIMATION 3. When a System is to be engineered the Software team may require access to H/W elements being developed by other Engineering teams. . H/W provides a platform that support the tools required to produce Work Products that are outcome of good Software Engineering practice. Software Project Planner must specify each Hardware element and the Time window for HW / SW and verify that these resources will be available.

Environmental Factors .Political Factors . custom System.Technical Variable Factors . Cost overrun can be disastrous.Human Factor .SOFTWARE ESTIMATION SOFTWARE PROJECT ESTIMATION Software is the most expensive element of virtually all Computer-Based System. Software Cost and Effort Estimation will never be an exact science. Variable Project Factors: . For complex. a large Cost Estimation error can make the difference between profit and loss. Because too many Variables Factors can affect the ultimate Cost of Software and Effort applied to develop it.

costing rest on a very shaky foundations. .SOFTWARE ESTIMATION OPTIONS FOR RELIABLE ESTIMATES a) Delay Estimation until late in the Project (obviously we can achieve 100% accurate Estimates after the Project is complete!) b) Base Estimates on similar Projects that have already been completed. c) Use one or more Empirical Models for Software cost and Effort Estimation. If no Historical data (metrics) exist. Each of the viable Software Cost Estimation options are only as good as the Historical data used to seed the estimation. d) Use relatively simple Decomposition Techniques to generate Project Cost and Effort Estimates.

re-characterizing it as a set of smaller problems. we Decompose the problem. the Problem to be solved is too complex in one piece. and in most cases. the Project Planner must understand the Scope of the Software to be built and generate an Estimate according to the µ¶Size of Software¶¶.Decomposition of the Process Before an Estimate can be made . .Decomposition of the Problem .SOFTWARE ESTIMATION DECOMPOSITION TECHNIQUES Software Project Estimation is a form of Problem solving. For this reason. Estimation uses one or both form of the two different partitioning point of views:.

4. .If a Direct approach to Sizing is taken size can be measured in (LOC) . ‡ Sizing represents the Project Planner¶s first major challenge since a Project Estimate is only as good as the Estimate of the Size of the work to be accomplished Size refers to a Quantifiable outcome of the Software Project.SOFTWARE ESTIMATION SOFTWARE PROJECT SIZING: Accuracy of a Software Project Estimate is predicted on a number of things: 1.If an Indirect approach is taken that the sizing approach is represented as FP ‡ . The ability to translate the Size Estimate into Human-effort (Calendar Time and Money) 3. 2. The stability of Product requirement s and the environment that supports the Software Engineering effort. The degree to which the Planner has properly Estimated the Size of the Product to be built. The degree to which the Project Plan reflects the abilities of Software team.

Function Point Sizing 3. Change Sizing ‡ The result of each Sizing approaches must be combined statistically to create Expected-Value Estimate.Once the Expected Value for the Estimation variable has been determined.´ This is accomplished by determining the following values for. Fuzzy Logic Sizing 2. . Historical (LOC) or (FP) Productivity data are applied.Most Likely (Sm) (Moderate estimation value) . Standard Component Sizing 4.SOFTWARE PROJECT SIZING: SOFTWARE ESTIMATION There are Four Different Sizing Approaches: 1.Pessimistic (Spess) (High estimation value) ‡ Combine the Value Sizes using the following Equation to determine the Expected Value Estimation S =[(Sopt + (4 * Sm) + Spess)] / 6 .Optimistic (Sopt) (Lowest estimation value) .

Yet both have number of characteristics in common.SOFTWARE ESTIMATION PROBLEM ± BASED ESTIMATION TECHNIQUES ‡ LOC and FP data are used in two ways during Software Estimation. ‡ As an Estimation variable to ³Size´ each element of Software. ‡ As a Baseline Metrics collected from past project and used in conjunction with estimation variable to develop cost and effort projections. . ‡ LOC and FP Estimations are different Estimation techniques.

Baseline Productively Metrics are then applied to the appropriate Estimation Variable and Cost or Effort for the Function is derived.SOFTWARE ESTIMATION PROBLEM ± BASED ESTIMATION TECHNIQUES ‡ The Project Planner begins with a bounded Statement of Software Scope and from this Statement attempts to Decompose Software problem Functions that can be Estimated individually. .(LOC) or (FP) is then estimated for each Function. . . Function Estimates are combined to produce an overall Estimate for the entire Project.

When (LOC) is used as the Estimation variable Decomposition is absolutely essential and often taken to considerable levels of detail. For (FP) Estimation. Decomposition works differently. Besides focusing on each Function¶s Information Domain characteristics it also takes into consideration the Complexity Adjustment Factor values. - .SOFTWARE ESTIMATION PROBLEM ± BASED ESTIMATION TECHNIQUES The (LOC) and (FP) Estimation Techniques differ in the level of detail required for Decomposition and the target of partitioning.

.SOFTWARE ESTIMATION PROBLEM ± BASED ESTIMATION TECHNIQUES Regardless of Estimation variable that is used the Project Planner begins by Estimating a range of Values for each Function or Information domain value. Most Likely Value Pessimistic Value S = [Opt value + (4 * Most Likely) + Pess value] / 6 Once the Expected Value has been determined. Using Historical data or intuition. Historical (LOC) and (FP) Productivity data are applied. the Planner Estimates µ¶Expected Value¶¶ considering the following variables: Optimistic Value.

Computer Graphic Display facility (CGDF) 4.Two Dimensional Analysis (2DGA) 5.SOFTWARE ESTIMATION PROBLEM ± BASED ESTIMATION TECHNIQUES AN EXAMPLE OF (LOC) BASED ESTIMATION FUNCTIONS ESTIMATED LOC .800 *** .300 .Using the Expected Value Equation we can calculate the Estimated Value for (3DGA) Function as follows:Optimistic Estimation = 5.700) + 9.Database Management (DBM) 3.000 LOC Most Likely Estimation = 6.000 LOC S = [Opt value + (4 * Most Likely) + Pess value] / 6 S = [5000 + ( 4 * 6.User Interface and Control Facilities (UICF) 2.350 .700 LOC Pessimistic Estimation = 9.000] / 6 6.300 .3D Geometric Analysis Function (3DGA) 6.950 .200 ========================================================== For Example:.Peripheral Control Function (PCF) 2.800 .Design Analysis Modules DAM) 8.100 .400 __________________________________________________________________ TOTAL ESTIMATED LOC ( ™ LOC ) 33.

600  Total Estimated Project Effort = (33200 / 620) = ~ 54 Man Months .000 Per month.SOFTWARE ESTIMATION AN EXAMPLE OF (LOC) BASED ESTIMATION Historical data obtained from the Metrics indicates the following Organizational Averages:  Average Productivity is 620 LOC / Pm (Lines of Code Per Month)  Average Labor Cost is $8.200 : Total Estimated Project Cost = (33200 * 13 ) = $431. Cost for a Line of Code can be calculated as follows (COST / LOC) COST / LOC = (8000 / 620) = $13 Total Estimated Project Cost and Project Effort can be calculated as: follows Considering that the Total LOC ( ™ LOC) for the System is 33.

of External Enquiries No. of External Inputs No. 320 ‡ Each of the Complexity Weighting Factor is estimated and the Complexity Adjustment Factor is computed using the Complexity Factor Table as shown on the next page ‡ Expected Value is calculated for each Information Domain using :- S = [Opt value + (4 * Most Likely) + Pess value] / 6 . Count (Expected Value ) 24 16 22 4 2 Weighting Factor FP Count 4 5 5 10 7 97 78 88 42 15 No. of External Interface Files 20 12 16 4 2 24 15 22 4 2 30 22 28 5 3 COUNT TOTAL (™ FP) ‡ For this example we assume Average Complexity Weighting Factor.SOFTWARE ESTIMATION AN EXAMPLE OF FUNCTION POINT (FP-BASED) ESTIMATION INFORMATION DOMAIN VALUE Opt Most Likely Pess. Est. of Internal Logical Files No. of External Outputs No.

Internal Processing Complex? 5 11 Code Designed for reuse? 4 12.17) = 375 . Back-up and Recovery ? 4 2.01*™(Fi))] Complexity Adjustment Factor is  Complexity Adjustment Factor = [0. Online Updates ? 3 9. Information Domain Values Complex ? 5 10.01 * 52)] = 1. Application Designed for change ? 5 =========================================== FACTOR ™ (Fi) 52 Estimated Number of Adjusted FP is derived using the following Formula:FP ESTIMATED = (FP COUNT TOTAL * [COMPLEXITY ADJUSTMENT FACTOR] [0. Performance Critical ? 4 5. Multiple Installations? 5 14. On-line Data Entry ? 4 7. Conversion / installation in Design? 3 13.SOFTWARE ESTIMATION AN EXAMPLE OF FUNCTION POINT (FP-BASED) ESTIMATION COMPLEXITY FACTOR ASSUMPTIONS (Based on the Answers for 14 Questions) VALUE (Fi) -----------------------------------------------------------------1. Input transactions over multiple Screens? 5 8. Distributed Processing ? 0 4.65 + (0.17 ESTIMATED FP COUNT = (320 * 1. Data Communication ? 2 3. Existing Operational Environment ? 3 6.65+ (0.

Average Productivity for this type of Application is 6.000  Total Estimated Project Effort = (375 / 6.SOFTWARE ESTIMATION AN EXAMPLE OF (FP) BASED ESTIMATION Historical data obtained from the Metrics indicates the following Organizational Averages:.5) = ~ 58 Man Months .000 Per Month.5) = $1230 (Cost for 1 FP) Total Estimated Project Cost and Project Effort can be calculated as:Considering that the Total Adjusted FP ( ™ FP) is 375 FP : Total Estimated Project Cost = (375 * 1230) = $461.Average Labor Cost is $8. Cost for a Function Point (COST / FP ) is calculated as follows Cost / FP = (8000 / 6.5 FP / Per Month .

50 4.50 1.60 1.00 0.50 4.00 1.00 3.25 0.50 0.00 1.00 4.50 2.50 1.50 0.00 16.000 Per month .25 0.25 0.00 3.25 5.75 4.00 2.35 8.00 2.50 5.00 20.40 7.50 0.50 3.000 * 46) = $368.000 .00 5.40 0.75 0.50 0.50 0.SOFTWARE ESTIMATION ACTIVITY RISK ENGINEERING CONSTRUCTION CC ANPEXAMPLE OF PROCESS-BASED ESTIMATION CE ANALYSIS RELEASE L A N Analysis Design Code Test TOTALS (Man Months) TASK FUNCTIONS UICF 2DGA 3DGA CGDF DBM PCF DAM TOTALS 0.50 n/a n/a n/a n/a n/a n/a n/a 8.5 2.Month .Total Estimated Project Cost = (8.75 0.00 2.50 0.Total Estimated Project Effort = 46 Person .00 46.25 0.00 3.00 (™ Months) % EFFORT 1% 1% 1% 8% 45% 10% 36% Notes: ‡ CC = Customer Communication CE = Customer Evaluation Based on Average Labor cost of $8.50 6.

Use-cases can be used for Estimation. .  Use-cases do not describe complex behavior (e.SOFTWARE ESTIMATION ESTIMATION WITH USE-CASES Developing an Estimation approach with Use-Cases is problematic for the following reasons: Use-cases are described using many different formats and styles. However. but only if they are considered within the context of the µ¶Structured Hierarch¶¶ that the Usecases are described.g interactions) that involves many functions and features.  Use-cases do not address the complexity of the functions and features that are described. there is no standard form.  Use-cases represent an external view (User¶s view) of the Software and are written at different levels of abstracttion.

(obviously more Scenarios require considerably more development efforts. Engineering / Scientific. . etc) d) Rough architecture for the System is considered Once these characteristics are established. c) Type of Software is defined (eg. Emperical Data may be used to establish the Estimated number of LOC or FP per Use-case (for each level of hierarchy). b) Each Use-case would contain no more than 30 distinct Scenarios. Business. Real time. b) The Average Length (in pages) of each Use-case is determined. The Structured Hierarchical data then used to compute the Effort required to develop the System.SOFTWARE ESTIMATION ESTIMATION WITH USE-CASES It is argued that any level of Use-case Structural Hierarchy :a) Can be described by no more than 10 Use-cases.) Before Use-cases can be used for Estimation:a) The Level within the Structural Hierarchy is established.

based on the Actual number of Use-cases Adjusted by the number of Scenarios and Page length of the Use-cases.1)] * LOCadjust Where: N = Actual number of Use-cases LOC avg = Historical Average LOC / Use-case for this type Subsystem LOC adjust = Adjustment based on µn %¶ of LOC avg n = Defined locally and represents the difference between this Project and the µAverage¶ Project Sa = Actual Scenarios per Use-case Sh = Average Scenarios per Use-case for this type Subsystem Pa = Actual Pages per Use-case Ph = Average Pages per Use-case for this type of Subsystem The above expression is used to develop a rough Estimation of the Number of LOC. The Adjustment represents up to µn %¶ of the Historical Average LOC per Use-case. .1) + (Pa / Ph .SOFTWARE ESTIMATION ESTIMATION WITH USE-CASES LOC estimates = N * LOCavg + [(Sa / Sh .

CAD Software is composed of three Subsystem groups:1. User Interface Subsystem includes (UICF) 2. Infrastructure Subsystem group includes (CGDF) and PCF Subsystems) .SOFTWARE ESTIMATION AN EXAMPLE OF USE-CASE BASED ESTIMATION Consider the CAD Software example again for Use-case Estimation purpose. 3. Engineering Subsystem group includes the (2DGA) (3DGA) and (DAM) Subsystems.

Each Use-case has no more than 20 Scenarios .Each use case has an average of 8 Pages 3.Each use-case has an average of 6 Scenarios . User Interface Subsystem (UICF). 3DG.Each Use-case has an average of 5 Pages .Described with 6 Use-cases . PCF) . .SOFTWARE ESTIMATION AN EXAMPLE OF USE-CASE BASED ESTIMATION 1.Each Use-case is described by no more than 10 Scenarios . DAM) . Infrastructure Subsystem group (CGDF. Engineering Subsystem (2DG.Each Use-case has an average of 6 Pages 2.Described with 5 Use-cases .Described with 10 Use-cases .

970 TOTAL LOC ESTIMATES 42.568 .366 31.233 5 6 5 10 6 1650 7.SOFTWARE ESTIMATION Based on n = 30% Difference the following tabe is created for USE-CASE Based Estimation UseCases (N) 6 10 Scenarios (Sa) 10 20 Pages (Pa) 6 8 Scenarios Pages (Ph) 5 8 LOC LOC Estimates SUBSYSTEMS (Sh) 12 16 USER INTERFACE ENGINEERING GROUP INFRASTRUCTURE GROUP 560 3100 3.

Months .30) = 560 Using the formulae below we can calculate LOC Estimates for each Subsystem group LOC Estimates = N * LOC avg + [(Sa / Sh . Total Project Cost and Total Development Effort can be calculated as follows: .568 * 13) = $552.Total Project Estimates = (42.Cost / LOC = (8000 / 620) = $13 (Cost for 1 LOC) .000 .Average Salary of $8000 Per month. .Total Development effort = (42.1) + (Pa / Ph .Average Productivity rate 620 LOC / Month .SOFTWARE ESTIMATION USE CASE BASED ESTIMATION Let us consider the calculations for User Interface Subsystem based on 30% difference between this project and Actual Project (n = 30%) Historical data obtained from Metrics indicates that User Interface Software requires: An Average (LOC avg) of 800 LOC per Use-case when the Use-case has no more than 12 Scenarios and described in less than 5 Pages.568 / 620 ) = 68 Person.LOC avg = 800  When considering 30% Differences between this Project and Average Projects  LOC Adj = (800 * 0.1)] * LOC adjust Historical data from Metrics indicates the following Averages .

SOFTWARE ESTIMATION RECONCILING ESTIMATES The Problem Based Estimation Techniques dicussed so far each gave different Cost and Effort Estimate results which must be reconciled to produce a single Estimate of Effort. .  The variation from Average estimate is approximately 18% on the low side and 21% on the high side. Project Duration or Cost. Examination of the four different Problem-Based Estimation techniques indicate different Total Estimated Efforts for the CAD Software range from :  46 Person-months to a high of 68 Person-months  The Average Estimate Of Efforts is 56 Person-months.

. Wedely divergent Estimate can often be traced to one of the two causes. 1. The Scope of the Project is not adequately understood or has been misinterpreted by the Project planner.SOFTWARE ESTIMATION RECONCILING ESTIMATES What Happens When Agreement Between Estimates is poor? The answer to this question requires a re-evoluation of information used to make the Estimates. Productivity Data is either obsolute (no longer accurately reflects the Software Engineering Organization) . Productivity data used for Problem-Base Estimation Techniques is inappropriate for the Application. or has been misapplied. The Project Planner must determine the cause of divergence and then reconcile the Estimates. 2.

The Estimation Model should be tested by applying data collected from completed projects.  If aggrement is poor the Estimation Model must be tuned and reflected before it can be used. and then comparing Actual to Predicted results. no Estimation Model is appropriate for all Classes of Software and in all Development Environments.  Therefore. Values for LOC and FP are estimated using LOC based Estimations and FP Based Estimations.SOFTWARE ESTIMATION EMPIRICAL ESTIMATION MODELS An Estimation model for Computer Software uses Empirically derived formulas to predict Effort as a Function of LOC or FP. the results obtained from such Models must be used judiciously. The Empirical data that support most Estimation Models are derived from a limited sample of Projects. An Estimation Model should be calibrated to reflect local conditions. . plugging the data into model.  The resultant Values out of these Estimation are plugged into the Estimation Model. For this reason.

E is Effort in Person-Months (ev) is the Estimation Variable either LOC or FP) In addition the relationship noted in the above equation . the majority of Estimation Models have some from of Project Adjustment Components that enables Effort in Person Months (E) to be Adjusted by other Projects Characteristic such as Problem Complexity. Staff experience. and Development environment). The overall structure of such Model takes the from of : c E = A + B * (ev) Where: A.SOFTWARE ESTIMATION THE STRUCTURE OF ESTIMATION MODEL A typical Estimation Model is derived using Regression Analysis on data collected from past Software Projects. . B and c are Emperically derived constant.

2 * (KLOC) 1. .047 DOTY MODEL FOR E = 5.73 (KLOC) 1.288 * (KLOC) ---------------------------------------------------------------------------------------------------------- PROPOSED FP MODELS ALBRECHT AND GAFFNEY Model KEMERER MODEL SMALL PROJECT REGRESSION MODEL E = -91.SOFTWARE ESTIMATION PROPOSED LOC-ORIENTED ESTIMATION MODELS 0. The implication is clear.96 FP E= -12.91 WALSTON-FELIX MODEL E = 5.0355 FP E = -37 + 0.05 BOEHM SIMPLE MODEL E = 3.4 + 0.405 FP Each of these Models indicates that each will yield a different result for the same value of LOC or FP.2* (KLOC) 1.Estimation Models must be calibrated for local needs.5 + 0.16 BAILEY-BASILI MODEL E = 5.88 + 0.

.Consideration of Software and System Intraction. . APPLICATION COMPOSITION MODEL Used during the early stages of Software Engineering when: . 2. 3. POST-ARCHITECTURAL STAGE MODEL Used during the Construction of the Software. EARLY DESIGN STAGE MODEL Used once Requirement have been stabilized and basic Software Arcchitecture has been established. The latest COCOMO Model II is a H erarch of Est mat on Models that address the following areas:. 1.Assesment of Performance and Evaluating of Technology maturity are paramount.SOFTWARE ESTIMATION THE COCOMO II MODEL (COnstructive COst MOdel) COCOMO is most widely used and discussed Software Cost Estimation Model in the Software Industry.Prototyping of User Interfaces. .

Three different Sizing Options are audilable as part of the COCOMO Model Hierarchy:  LINES OF SOURCE CODES (LOC)  FUNCTION POINT (FP)  OBJECT POINTS (OP)  The COCOMO II Application Composition Model uses Object Points (OP) .an Indirect Software measure that is computed using Counts of of : 1. of Reports 3. No. No. NOTE : COCOMO II is also available in FP and LOC as sophisticated Estimation Model. of Reusable Components to be required to build the Application Each Object instance is classified into one of threee complexity levels (Simple . Medium and Difficult) using criteria suggested by Boehm. . No. of User Interface Screen 2.SOFTWARE ESTIMATION THE COCOMO II MODEL (Constructive Cost Model) Like all other Estimation Model COCOMO II Model requires Sizing Information.

Once Complexity is determined.COMPLEXITY WEIGHTING FOR OBJECT TYPES TABLE OBJECT TYPE Screen Report 3GL Components Simple 1 2 Medium 2 5 Difficult 3 8 10 In essece Complexity is a Function of the Number of Source of the Client and Server Data tables that are required to generate the Screen or Report and the number of Views or Sections presented as part of the Screen or Report. Reports and Reusable Components are weighted according to Boehm¶s Complexity weighly of object table (as above). . The Object Point Count is them determined by multiplying the Original number of Objects instances by the Weighting Factor in the figure and then summing to obtain a Total Object Point Count. the number of Screens.

SOFTWARE ESTIMATION When Component-based development or General Software Reuse is to be applied the percent of Reuse (%Reuse) is estimated and Object Point Count is adjusted: NOP = (OBJECT POINTS) * [(100 . ³Productivity Rate´ must be derived by considering the different Levels of Developer Experiences and Development Environment Maturity as shown on the Productivity Rate for Object Points table below DEVELOPERS EXPERIENCE / CAPABILITY ENVIRONMENT MATURITY CAPABILITY PROD RATE VERY LOW VERY LOW 4 LOW NORMAL HIGH VERY HIGH VERY HIGH 50 LOW NORMAL HIGH 7 13 25 Once the Productivity Rate has been determine an Estimate of Project Effort can be derived as: ESTIMATED EFFORT = (NOP / PROD) .% REUSE)/100] *** Where: NOP is defined as New Object Points  To derive and Estimate of Effort on the computed NOP value.

The Complexity of the Application.16 ) B = 0. The Model has been derived from Productivity Data collected for over 400 contemporary Software Projects. . Based on this data an Estimation Model of the form:0.The Skills and Exprience of team .333 3 4 E = [LOC * B Where / P ] * (1 / t ) E = Effort in Person Month or Year t = Project Duration Month/Year B = Special Skills Factor (For Small Programs (KLOC = 5 to 15) (For Programs where (KLOC > 70) B = 0.39) P = Productivity Parameters that reflects .SOFTWARE ESTIMATION THE SOFTWARE EQUATION The Software Equation is a multivariable Model that assumes a specific distribution of Effort over the life of a Software Development Project.The level of Programming Languages used .Overall Process Maturity and manupulate practices to the extent to which good SE practices are used .The State of Software Environmen .

An Estimate of Size in LOC 2. The Productivity Parameters can be derived for local conditions using Historical Data collected from past Development Efforts.000 for Business System Applications.SOFTWARE ESTIMATION THE SOFTWARE EQUATION Typicalal values of P (Productivity Parameter) might be:P = 2. It is important to note that the Software Equation has two independent Parameters: 1.000 for Telecominication and System Software P = 12.000 for Scientific Software P = 28.000 for the development of Real-time embeded Software P = 10. An Indication of Project Duration in Calendar Months or Years .

14 (LOC / P) in Calendar months for tmin > 6 Calendar months 3 = 180 Bt in Person-month for E > or equal to 20 Person-months Using Equation with P = 12.14 (33200 / 12000) = 12.6 Calendar Months 3 E = 180 * 0.05) = 58 Person-months The results of Software Equation corresponds favourable with the Estimates developed with COCOMOS Model .000 tmin = 8. Minimum Development Time is defined as: 0.28 * (1.43 tmin E = 8.SOFTWARE ESTIMATION THE SOFTWARE EQUATION To simplify the Estimation process Putnam and Myers suggested a set of equations derived from the Software Equation.

2. Using O-O Analysis modeling.00 ‡ TEXT BASED USER INTERFACE 2. From the Analysis model. FP Analysis and any other Method that is applicable for conventional applications. Develop Estimates using effort decomposition. develop Use-case and determine a count Recognize that the number of Use-cases may change as the project progresses.00 ============================================================= Multiply No. of Key Classes with Multiplier to obtain an Estimation for No. 4. . determine the number of Key Classes.50 ‡ COMPLEX GUI 3. LORENY AND KIDD SUGGEST THE FOLLOWING APPROACH: 1.25 ‡ GUI 2. INTERFACE TYPE MULTIPLIER (FOR SUPPORT CLASS) ‡ NO GUI (Without Graphical User interface) 2. of Support Class.SOFTWARE ESTIMATION ESTIMATION FOR OBJECT-ORIENTED PROJECTS It is worth to supplement Conventional Software Cost Estimation Methods with an approach that has been designed explicity for O-O Software. Catagorize the type of Interface for the application and develop a Multiplier for Support Class. 3.

. when a Software Team encounters an extremly Short Project Duration (weeks rather than months) that is likely to have a continuing stream of changes.SOFTWARE ESTIMATION ESTIMATION FOR OBJECT-ORIENTED PROJECTS (Cont¶d) 5. Multiply the Total Number of Classes (Key + Support) by the AverageN number of Work-Unit per Class (Suggestion 15-20 Person-day per Class). 6. Project Planning in General and Estimation in particular should be abbreviated. However. Cross-check the Class-Based Estimate by Multiplying the Average Number of Work-Unit Per Use-case . =============================================================== The previously mentioned Estimation Techniques can be used for any Software Projects.

4 a) Estimation for eachTask are summed to create an Estimate for the Scenario.Based on Historical data and Emperical Model. 3a) Each Tasks is estimated Seperatly ( Note:. Each User Scenario is considered seperatly for Estimation purpose:- 2. yet reasonably disciplined and meaningfull within the context of Project Planning for each Software Increment. 4 b) Alternatively the Volume Estimate for Scenario is translated into Effort using historical data 5. The Effort Estimation for all Scenarios that are to be implemented for a given Software Increment are summed to develop the Effort Estimate for thr Increment. Agile Projects Estimation uses a Decomposition Approach that encompasses following Steps 1. . The Scenario is decomposed into the set of Functions and the Software Engineering Tasks that will be required to develop them. or experience) 3b) Alternatively the Volume (Size) of the Scenarious can be Estimated in LOC. FP on Object Points.ESTIMATION FOR AGILE DEVELOPMENT Bcause the Requirements for an Agile Project are defined as a Set of User Scenarios it is Possible to develop an Estimation approach that is informal.

1. conforms to the available Resources.ESTIMATION FOR AGILE DEVELOPMENT Since the Project Development Duration required for the development of a Software Increment is quite short (typically 3 to 6 weeks for each version).The Estimation for Agile Development Approach serves two purposes:. . To ensure that the Number of scenarious to be included in the Increment. 2. To establish a basis for allocating Effort as the Increment is developed. .

each Dynamic Web Page Script (e.g. TABLES: Each Logical Table in the Database plus (If you are using XML to store data in a file). ASP.ESTIMATION FOR WEB ENGINEERING PROJECTS A Modified Function Point Measure. coupled with the Steps mentioned in Estimation for Agile Development (Since Web Engineering Projects often adopt the Agile Process Model) can be used to develop an Estimate for the Web Applications. DCOM. QUERIES: Are each external Published on use a Message-oriented Interface (e. THE FOLLOWING INFORMATION DOMAINS ARE SUGGESTED FOR WEB APPLICATION ESTIMATION INPUTS: Are each Input Screen or Form. each XML objects. DHTML script) and each report.each Maintenance Screen and each Tab ( If you use a Tab not a book methaphore any where). INTERFACES: Retain their Definition as Logical files units or out-of the System boundaries. COM external references) .g . OUTPUTS: Are each Static Web page.

Linking Complexity. Page Authoring Effort.ESTIMATION FOR WEB ENGINEERING PROJECTS The Volume of Web Applictaions is best determined by collecting measures called Preditor Variables´ associated with the Applications such as:. Reused Code length). However. These measures can be used to develop Empirical Estimation Models for:Total Project Effort. Code length. Function Count). further work remains to be done. Medium Authoring Effort Script Effort. Medium Count.Media Characterstic (Media duration) . before such Estimation Model can be used with confidence.Functional Characteristic (eg. . .Page Count.Web Page Characteristics (eg: Page Complexity. Graphic Complexity) .

. 3. Software may be Purchased (or licensed) Off the Shelf Software 2. Software may be Custom built by an outside Contractor to meet the Purchaser¶s specifications. it is often more Cost effective to acquire rather than develop Computer Software. Software Engineering Managers are faced with a Make or Buy Decision that can be further complicated by a number of acquisation options such as:1. Full-experience or Partial-experience Software components may be acquired and then modified and integrated to meet specific needs. .THE MAKE / BUY DECISION In many Software Applications areas. The steps involved in Acquisation of Software are defined by the criticality of the Software to be Purchased and the end-cost.

FINAL ANALYSIS OF MAKE / BUY DECISION IS BASED ON THE FOLLOWING CONDITIONS 1. Will the Software Product be no available sooner than that for internally developed Software? 2.THE MAKE / BUY DECISION In small PC based software. Cost is not a great concern but for more expensive Software Products the following Guidliness can be applied. Will the Cost of Outside Support (e. Maintenance Contract) be less than the Cost of internal support? These Conditions apply for each of the three Acquisation Options.g. . Will the Cost of Acqusation plus the Cost of Custimazation be less than that of Cost of the developing Software Internally? 3.

.DECISION TREE FOR MAKE / BUY OPTION SOFTWARE ESTIMATION A Decision Tree can be created by using a Statistical Tecnique to help the Management to make a Make or Buy Decision.

000) + 0.30 ($380. d) Contract out the development work to an Outside Vendor.80 * (490.000) + 0.70 (450.000) = $429.000 Based on the Probability and Projected Costs the Lowest Expected Cost is BUY option.60 [0. .40 (275.Shelf Software and modify it.000  Cost for Reuse = 0.DECISION TREE FOR MAKE / BUY OPTION .Based on the above Decision Tree The Software Engineerting Organization can a) Build System ³X´ from Scratch. b) Reuse Components (Use Existing Partial-experienced Components´) c) Buy off.the.20 (310000) + 0. The Expected Cost Value will be computed for each branch of Decision Tree as: EXPECTED COST = ™ (Path Probability) * (Estimated Path Cost) i Where (i) is Decision Tree path  Cost for Build Path = 0.000)] = $328.

However it is important to note that besides the Expected Cost several other Criteria must be considered during the Decision Modeling Process.Conformance to requirements .Experience of Developer / Vvendor /Contractor .DECISION TREE FOR MAKE / BUY OPTION . Some of the few criteria to be considered are:.Likely hood of change .Based on the Probability and Projected Costs the Lowest Expected Cost is ³BUY´ option.Availability .Local Politics (Internal Politics) .

a Company runs the risk of putting the fate of its competiveness into the hands of a third party. .  On the negative side a Company loses some control over the Software that it needs. Business Managers consider whether a significsnt portion of all software work can be contracted to other. The PROS (Advantages) and CONS (Disadvantages) of Outsourcing are:  One positive side of Outsourcing is Cost saving.g Computers. Since Software is one of the technology that differentiates the Systems. Project Manager determine whether part or all of a Project can be best accomplished by subcontracting the Software work. Services and Products.  At the Tactical level. Infrastructure) that support them. Software Engineering activities are contracted to a third party who does the work at Lower cost and hopefully Hihg quality. The decision to Outsource can be either Strategic or Tactical.OUTSOURCING Outsourcing concept is very simple.  At the Strategic level. which can usually be achieved by reducing the number of Software People and the facilities (e.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.