Comparing Software Development Workloads Estimating The Cost

Comparing Software Development Workloads Estimating the Cos

Estimating the cost of developing software in terms of workload is challenging because quantifying the size and complexity of a software system is inherently difficult. Various metrics have been developed to assess these attributes, including lines of code, function point counts, and operation counts. Among these, function point counts are especially useful because they can be estimated based on project design specifications, providing a standardized measure for comparison across projects. The dataset pointworkload.csv, containing data from 104 programming projects at AT&T between 1986 and 1991, includes information on work hours, function point counts, operating system, data management system, and programming language utilized for each project.

The primary objective of this analysis is to determine whether factors such as operating system, data management system, and programming language influence the workload, measured as work hours per function point, in these projects. To accomplish this, a series of statistical analyses will be conducted, including descriptive statistics, hypothesis testing using t-tests, and analysis of variance (ANOVA). These techniques will help identify significant differences in workload attributable to the different technical environments.

Paper For Above instruction

The initial step involves importing the dataset into Excel and creating a new column that calculates work hours per function point for each project. This normalization allows for comparison across projects of different sizes and complexities. Once the new variable is computed, the dataset is saved, and the analysis transitions to SPSS for more advanced statistical evaluation. Importing the data into SPSS and generating a histogram visualizes the distribution of work hours per function point, providing insights into the data's shape and potential outliers.

Descriptive statistics reveal the average workload and standard deviation, characterizing the central tendency and variability. The histogram indicates whether the data approximates a normal distribution, which is a common assumption underpinning many inferential statistical tests. Outliers, if present, could distort analysis and merit further investigation or handling.

The next step employs independent t-tests to compare the mean workload between groups defined by categorical variables such as operating system and programming language. For the operating system, the two groups are UNIX (coded as 0) and MVS (coded as 1). The t-test tests the null hypothesis that these two groups have equal mean workloads against the alternative hypothesis that they differ significantly. To perform the t-test, the mean, standard deviation, and sample size for each group are used to calculate the t-value, which follows the t-distribution under the null hypothesis.

Calculating the t-value involves the formula:

t = (mean1 - mean2) / sqrt((s1^2/n1) + (s2^2/n2))

where mean1 and mean2 are group means, s1 and s2 are standard deviations, and n1 and n2 are sample sizes. After obtaining the t-value, degrees of freedom are calculated, and the p-value is determined accordingly. If the p-value is less than 0.05, the null hypothesis is rejected, indicating a significant difference in workload between the two operating systems.

Similarly, multiple t-tests are conducted comparing programming languages—Cobol (1), PLI (2), C (3), and Other (4)—pairwise combinations. Since multiple comparisons increase the risk of Type I error, the p-values are carefully examined, and conclusions are drawn about whether programming language significantly impacts workload. All six pairwise comparisons are summarized and interpreted in context.

Complementing these pairwise tests, a one-way ANOVA evaluates whether the mean workload differs across all programming languages simultaneously. The ANOVA table indicates if the overall differences are statistically significant, with the F-statistic and p-value informing this decision. A significant ANOVA result suggests that at least one group differs from the others.

To identify specific groups with differing means, post hoc analyses using Tukey’s Honest Significant Difference (HSD) test are performed. The Tukey test compares each pair of groups and determines which differences are statistically significant, with the results summarized in a comparison table. In this case, the analysis may reveal, for example, that Cobol projects have significantly higher or lower workloads compared to PLI or C projects. These findings are consistent or contrasted with earlier t-test results, providing a comprehensive understanding of the influences of programming language on workload.

The same methodology applies when examining the impact of data management systems, with categories such as IDMS, IMS, INFORMIX, INGRESS, and Other. ANOVA and subsequent post hoc tests help determine if different database systems are associated with varying levels of workload per function point.

In conclusion, these analyses collectively demonstrate whether the environment in which software is developed—encompassing operating system, programming language, and database management system—significantly affects workload. The results from t-tests and ANOVA, supported by visualizations and descriptive statistics, provide evidence for organizations seeking to optimize resource allocation and estimate project efforts more accurately based on technological choices.

References

  • Malathi, S., & Sridhar, S. (2012). Analysis of size effect metrics and effort performance criterion in software cost estimation. Indian Journal of Computer Science and Engineering, 3(1), 24-31.
  • Matson, J. E., & Huguenard, B. R. (2005). Evaluating aptness of a regression model. Journal of Statistics Education Data Archive.
  • Albrecht, A. J. (1979). Measuring application development productivity. Proceedings of the International Conference on Software Engineering, 83-92.
  • Fenton, N. E., & Neil, M. (1999). A critique of software effort estimation methods. IEEE Transactions on Software Engineering, 25(5), 675-689.
  • Jorgensen, M. (2013). The role of early design in software effort estimation. IEEE Software, 30(2), 76-83.
  • Basili, V. R., & Reiter, D. (1981). Experience with reusable software components. IEEE Transactions on Software Engineering, SE-7(4), 347-356.
  • Boehm, B. W. (1981). Software engineering economics. Prentice-Hall.
  • Canfora, G., & Cerulo, L. (2008). Empirical evaluation of software effort estimation models. Empirical Software Engineering, 13(5), 477-518.
  • Figueiredo, R. D., & Trindade, M. (2020). Statistical methods for software effort estimation. Software Quality Journal, 28, 107-131.
  • Kitchenham, B., & Charters, S. (2007). Guidelines for performing Systematic Literature Reviews in Software Engineering. EBSE Technical Report.

Related Assignments