 Rule: Determine the minimum payoff for each alternative. Choose the alternative which maximizes the minimum payoff. Maximax Rule: Determine the maximum payoff for each alternative. Choose the alternative which maximizes the maximum payoff. Laplace or Equal-Probability Rule: Assume all of the states of nature are equally likely. Determine the expected value for each alternative, and choose the alternative with the maximum expected value.”[6] How to quantify uncertainties? There are two quantitative techniques that can help with it: simulation and event analysis. The simulation methods such as Monte Carlo and Bayesian Network can help to find the probability of completing a certain task. The event analysis method can identify the risky events that could cause loss of the project, thus people can prepare the plan to deal with the expected loss.
9 3.3 Value of Estimation in Project Management Planning is one the most important processes in project management: good planning will lead to a successful project. However, good planning requires accurate estimation on the size of the project, the effort of staff power, cost and schedule. The goal of a good estimation is to provide the cost and schedule to the manager. If the actual cost of a project is out of budget, no matter how complete the product is, the project is regarded as failure because there is no profit. Similarly if the promised deliverables are late to meet its delivering date, it is still regarded as failure because the contract is not fulfilled and the stakeholder may sustain loss. In addition, monitoring and controlling processes are iterative and estimation is required between the processes to find the deviations from the plan. For the same example in 3.1, how to know a solution can fix the problem and make Team B catch up with the schedule? A re-estimation would be preferred in this case. Therefore, estimation is needed throughout the entire project management process.
Source: Barry W. Boehm, Software Engineering Economics, p75, Prentice-Hall, INC., 1981[7].
B)”[8] A = 2.94 B = 0.91 C = 3.67 D = 0.28 EM = Effort Multipliers SF = Scale Factors Effort Multipliers are inherited from the cost drivers from COCOMO 81 and Scale Factors are new introduced in COCOMO II. The five Scale Factors are Precedentedness (PREC), Development flexibility (FLEX), Architecture/risk resolution (RESL), Team cohesion (TEAM), and Process maturity (PMAT).
4.2 Sizing Sizing is the most significant factor that affects COCOMO. There are many sizing methods such as Source Lines of Code (SLOC), Function Point, Use Case Point, Object Point, UML Metrics, etc. No matter what sizing method is used, it involves uncertainty.
Unadjusted Function Points can be converted to Adjusted Function Points but it is not required in COCOMO. In COCOMO, it is preferred to relate UFPs to SLOC in the implementation language such as Java, C++, PHP, etc. According to the data from QSM, it will result in significant variation in the number of source statements per function point which refers to uncertainty or risks. (See Table 4.3).
Source: DCG, Software Sizing with Function Points, http://www.davidconsultinggroup.com[12].
Source: Hao Wang, Software Productivity Analysis with CSBSG Data Set, 2008[13].
16 effective productivity based on the new functionality and the work involved in redesign, reimplementation, and retest, forming an effective productivity. Some studies leave out such detail.” [15] If the projects are not of ultra-size or they are enhancement projects that mainly involve in reuse work, the result will make sense. And there is another reason productivity may increase when project gets bigger: the learning curve effect. The developing team often improves during the project to get more maturity in their working process.
Secondly, productivity is more likely impacted by the staff size. As Brooks Law stated, the staff gets bigger the productivity gets lower in Figure 4.2.
Furthermore, productivity is influenced by Project Type and Programming Language. (See Figure 4.3 and 4.4).
In Figure 4.3, New Development projects have larger range of productivity which means New Development projects have more uncertainties in productivity.
4.4 Reliability “A software product possesses reliability to the extent that it can be expected to perform its intended functions satisfactorily. Quantitatively, we can define software reliability as a probability: the software performs its intended functions satisfactorily over its next run or its next quantum of execution time.”[16] Normally, reliability can be calculated with following steps: Choose N inputs or input sequences randomly from the probability distribution over the space of possible inputs or input sequences to the software. Execute the software N runs or a certain execution time with the inputs. Based on the success criterion to determine the M number of runs resulted in the satisfactory outputs. Meanwhile, collect the elapsed time between failures to calculate Mean Time to Failure. Calculate the estimator R = M/N.
As a result, a product requires very high reliability may cost 50% more effort than a product requires very low reliability. The effort may include the work on code inspection, unit test and program proving.
4.6 Other Cost Drivers. COCOMO II involves five Scale Factors and seventeen Effort Multipliers. The five Scale Factors account for the relative economies or diseconomies of scale encountered for software projects of different sizes [Banker et al. 1994a]. The Effort Multipliers can be classified to Product Attributes, Computer Attributes, Staff Attributes, and Project Attributes.
There are several factors that result in uncertainties in COCOMO. The first reason is sizing. Table 4.4 shows the accuracy of different methods of Function Point counting. The accuracy may range from +/-100% to +/-5%. Even if the number of Function Point is correct, it still needs to be converted to SLOC in COCOMO. Table 4.3 shows a huge distribution of source lines of statement per function point. Thus the SLOC used in COCOMO may be overestimated or underestimated. Due to the exponential increasing of effort by size, the larger the size of the project, the bigger risks it takes. The second reason is productivity. In COCOMO, productivity is determined by a nominal value and a group of effort multipliers. The effort multipliers have both positive and negative effects on productivity. The effects are based on the rating of effort multipliers which is shown in Table 4.7. Then the productivity ranges of these effort multipliers can be calculated from the data. Here is an example in Figure 5.1.
These productivity ranges show the relationships between all effort multipliers and productivity which reflects one effort multiplier’s ability to increase or reduce effort required to develop a software product. However, the numbers in Table 4.8 are gathered by statistical method based on historical data. The number of each rating is possibly an average value that cannot be always accurate.
5.2 Uncertainties in Effort Multipliers To find out the uncertainties in productivity, it is necessary to know the accuracy of COCOMO effort multipliers. The point is how to know the variance of each Effort Multiplier. In Boehm’s book “Software Engineering Economics”, he provides the data that COCOMO effort multiplier versus ideal effort multiplier. Because the ideal effort multipliers are the real project data, they can be considered as the range of the accuracy.
25 If the ideal effort multipliers are close to the COCOMO effort multiplier, the accuracy is relatively high. If not, the accuracy is relatively low. Because there are more than 60 projects which are included in the data, it is possible to find a statistical distribution for Effort Multipliers. The procedure of selecting a statistical distribution that best fits to a data set generated by some random process is called Distribution Fitting. The purpose here is to find the best distribution for the Effort Multipliers because statistical distribution is a perfect way to express uncertainty. There are several basic characteristics in distribution, which are shown below.
Normally, the distributions of Effort Multipliers are right-skewed but sometimes they can be symmetric.
26 tool to calculate the triangular distribution of Effort Multipliers. EasyFit[23] is such software that can do the calculation to save our time. Here is an example of how to find a distribution for an effort multiplier.
Step 1: Collect the ideal effort multipliers from Figure 5.2 as shown below.
Step 3: Import the result to EasyFit in one column. Step 4: Press F9 to run the distribution.
Figure 5.3 Distribution of Required Software Reliability. Burr is a default statistics model in EasyFit and it can be ignored in this figure. X axle represents the percentage.
Figure 5.5 Triangular Distribution of Use of Software Tools. In Figure 5.5, the range of Use of Software Tools values is from 75% to 140% When it applies the same steps to Schedule Constraint, the data from COCOMO 81 shows distributions in Table 5.5.
34 Delete the outliers which are smaller than 80% or greater than 140%, then import the data to EasyFit. In Figure 5.6, the range of Schedule Constraint value is from 84% to 130%.
Figure 5.6 Triangular Distribution of Schedule Constraint 5.3 Uncertainty in Scale Factors Scale Factors are very different from Effort Multipliers because their influence on estimation is affected by the size of the project. In COCOMO II, the productivity range of Effort Multipliers does not involve the size of the project. However, the productivity range of Scale Factors is based on a 100 KLOC project