DOCSLIB.ORG

A Metrics-Based Software Maintenance Effort Model

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Metrics-Based Software Maintenance Effort Model A Metrics-Based Software Maintenance Effort Model Jane Huffman Hayes Sandip C. Patel Liming Zhao Computer Science Department Computer Science Department Computer Science Department Lab for Advanced Networking University of Louisville University of Kentucky University of Kentucky [email protected] [email protected] [email protected] (corresponding author) Abstract planning a new software development project. Albrecht introduced the notion of function points (FP) to estimate We derive a model for estimating adaptive software effort [1]. Mukhopadhyay [19] proposes early software maintenance effort in person hours, the Adaptive cost estimation based on requirements alone. Software Maintenance Effort Model (AMEffMo). A number of Life Cycle Management (SLIM) [23] is based on the metrics such as lines of code changed and number of Norden/Rayleigh function and is suitable for large operators changed were found to be strongly correlated projects. Shepperd et al. [27] argued that algorithmic cost to maintenance effort. The regression models performed models such as COCOMO and those based on function well in predicting adaptive maintenance effort as well as points suggested an approach based on using analogous provide useful information for managers and maintainers. projects to estimate the effort for a new project. In addition to the traditional off-the-self models such as 1. Introduction COCOMO, machine-learning methods have surfaced recently. In [17], Mair et al. compared machine-learning Software maintenance typically accounts for at least 50 methods in building software effort prediction systems. percent of the total lifetime cost of a software system [16]. There has also been some work toward applying fuzzy Schach et al. found that 0 – 13.8% of changes made fall logic to building software metrics models for estimating under the category of adaptive maintenance [25]. It is software development effort [10]. Recent attempts have wise to design software that is maintainable since 18.2% also been made to evaluate the potential of genetic of project time is devoted to adaptive maintenance [25]. programming in software effort estimation [6]. Putnam et Software maintainability is defined as “the ease with al. [24] argue that the relationship between the metrics which a software system or component can be modified to size, effort, and time is nonlinear. Mendes et al. [18] correct faults, improve performance, or other attributes, or suggest that stepwise regression provides better adapt to a changed environment” [15]. Unfortunately, predictions than linear regression. developers and managers underestimate the time and effort required to change software. A lack of validated, widely accepted, and adopted tools for planning, 2.2 Maintenance Effort Estimation Models estimating, and performing maintenance also contributes to this problem. Basili et al. [2] attempted to develop a model to estimate This paper addresses the aforementioned problem of the cost of software releases that includes large planning and estimating when change is required. A enhancements. Gefen et al. [9] present a case study to metrics-based method is introduced that uses a model for estimate total lifecycle cost of a software system. The estimating adaptive maintenance effort. A study was estimation techniques for large information systems use performed to determine metrics that correlated closely lines of code or function points to calculate project effort with maintenance effort as measured in time (hours). in person-months [3, 4, 23]. These metrics were then used to build a model for The Albrecht Function Point model assumes that effort estimating adaptive maintenance effort. Two simple is primarily related to the size of a change [20]. In [20], regression models were built. The result, the Adaptive Niessink et al state that the size of the component to be Maintenance Effort Model (AMEffMo), appears changed (as opposed to the size of changes) is crucial. In promising from initial results. [21], they state that the size of the change and the size of the component to be changed are equally important. 2. Related Work Niessink et al. [20, 21] also emphasize the consistency of 2.1 Effort Estimation Models the process in maintenance effort data collection. Henry et al. found that the number of requirements changes that The Constructive Cost Model (COCOMO) [3,5,7,28] occur during maintenance can be used to improve effort supports the estimation of cost, effort, and schedule when estimates [14]. 3. Metrics Identification Table 2. Metric description. Metrics Description We hypothesize that the maintenance effort for a 1 Percent difference in total software application depends on measurable metrics that %Operators number of operators in the can be derived from the software development process. Changed application after maintenance We first identified the metrics that could affect the effort 2 LOC Difference Lines of code edited, added or required for maintaining an application to help managers (DLOC) deleted during maintenance 3 % Mod % Code modules changed during use the right metrics. Next, we worked on establishing change/add maintenance correlation between maintenance effort and the identified 4 metrics. Noprtr Total number of operators 5 Our first set of metrics was primarily taken from the CF Coupling factor results of two previous studies: [12] and [13]. The data 6 CR Comment ratio was taken from four sources: CS 499 and CS 616 courses 7 Hdiff Halstead’s difficulty (taught at the University of Kentucky), the research 8 LCOM Lack of cohesion in methods performed in [13] using Together® [29] and the industry 9 AC Attribute complexity research data from [12]. 10 CC Cyclomatic complexity Table 1 displays the results of correlation analysis: the 11 TCR True comment ratio higher the value of the coefficient, the stronger the 12 PM Perceived maintainability relationship between effort and the metric. The results 13 suggest that percentage of operators changed and the MP Maintainability product number of lines of codes changed edited, added or 14 Classes Changed Number of classes modified deleted (DLOC) were the most effective for predicting 15 Welker’s[30] Maintainability adaptive maintenance effort. Note that these will have to MI Index 16 be estimated. Table 2 describes the metrics in Table 1. HPVol Halstead program volume 17 Classes Added Number of classes added Table 1. Correlation between metrics and effort. 18 Heff Halstead’s effort Significance 19 LOC Total lines of code Coefficient of level Determination from ANOVA Metrics (R²) Regression 4. Development and Validation of AMEffMo 1 %Operators Changed 0.978 0.0002 We built an analytical model called Adaptive 2 LOC Delta -DLOC 0.779 0.00003 Maintenance Effort Model (AMEffMo) to predict 3 % Mod adaptive maintenance effort in terms of person-hours. We change/add 0.192 0.117 took the top two metrics from Table 1 to build AMEffMo. 4 Noprtr 0.152 0.444 “A typical estimation model is derived using regression 5 CF 0.108 0.525 analysis on data collected from past software projects” 6 CR 0.071 0.358 [22]. We used 70% of our data to build the model and the 7 Hdiff 0.046 0.683 remaining 30% to validate it. Table 3 lists the data 8 LCOM 0.034 0.725 availability and the average size of the applications 9 AC 0.033 0.518 constituting each dataset. 10 CC 0.032 0.581 11 TCR 0.011 0.741 4.1 Our Approach 12 PM 0.008 0.77 13 MP 0.006 0.79 In addition to a variation of the “leave one out” approach 14 Classes Changed 0.006 0.8 to evaluate the model, we performed standard checks such 15 MI 0.003 0.874 as examining residues, coefficient of determination, 16 HPVol 0.0008 0.929 significance level, performing a bias reduction technique 17 Classes Added 0.0006 0.946 [8], etc. 18 Heff 0.0004 0.969 19 LOC 0.00001 0.991 . Table 3. Number of data points per data source. where E is maintenance effort in person-hours. This Data Total Data points Data Avg size of model shows a significant linear relationship between Source data with DLOC points apps (lines DLOC and effort spent on changes (Figure 1.a and 1.b) in points information with of code), which the R square value and significance are 0.78 and DNoprtr min, max 0.000029 respectively. info Then, by using the course data to build the model and 1 CS 499 9 81 02 2688.2, 101, 6201 the rest of the data to validate, we obtained the following 2 CS 616 10 10 83 1934, model: 1192, 3425 E = 78 + .01DLOC (2) 3 Previous In- 8 8 02 58.6, 35, house 79 Research 1500 Data [12] Effort 4 Industry 6 6 6 2725.4, 238, 1000 Changing Research 18952 Data [11] 500 Predicted Effort 4.2 Multiple Regression Changing 0 First, we treated the percentage of operators changed and 0 50 100 150 the change in the total lines of code (DLOC) as multiple -500 variables for the data from CS 616. The multiple Predicting by DLOC(E=-40+6.56DLOC) regression output showed that none of the independent variables related to effort. But the simple regression (a) performed showed that the independent variable was 300 strongly related to effort. Next, we performed simple 200 regression using the LOC difference (DLOC). 100 4.3 Simple Regression 0 0 50 100 150 First, we used the data from the sources numbered 3 -100 and 4 in Table 3. Table 4 indicates that our models were -200 built based on small- to medium-sized maintenance tasks. -300 Table 4. Descriptive statistics data of DLOC and -400 Effort Spent on Changes (in person hours). Residues VS DLOC (of E=-40+6.56DLOC) DLOC Effort Spent on Changes (b) Mean 502.19 Mean 112.75 0 Standard 194.87 Standard 34.34 -1000 0 2000 4000 6000 8000 Deviation Deviation -2000 Minimum 0 Minimum 10 -3000 Maximum 6026 Maximum 1121 -4000 Sum 16070 Sum 3608 -5000 Using the least square method, we produced the -6000 following model: E = -40 + 6.56 DLOC (1) -7000 Residues vs DLOC- validating using course data 1 Did not have enough information from one student team.
Load more

Recommended publications
  • The Use of Summation to Aggregate Software Metrics Hinders the Performance of Defect Prediction Models
    IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. XX, NO. XX, XXX 2016 1 The Use of Summation to Aggregate Software Metrics Hinders the Performance of Defect Prediction Models Feng Zhang, Ahmed E. Hassan, Member, IEEE, Shane McIntosh, Member, IEEE, and Ying Zou, Member, IEEE Abstract—Defect prediction models help software organizations to anticipate where defects will appear in the future. When training a defect prediction model, historical defect data is often mined from a Version Control System (VCS, e.g., Subversion), which records software changes at the file-level. Software metrics, on the other hand, are often calculated at the class- or method-level (e.g., McCabe’s Cyclomatic Complexity). To address the disagreement in granularity, the class- and method-level software metrics are aggregated to file-level, often using summation (i.e., McCabe of a file is the sum of the McCabe of all methods within the file). A recent study shows that summation significantly inflates the correlation between lines of code (Sloc) and cyclomatic complexity (Cc) in Java projects. While there are many other aggregation schemes (e.g., central tendency, dispersion), they have remained unexplored in the scope of defect prediction. In this study, we set out to investigate how different aggregation schemes impact defect prediction models. Through an analysis of 11 aggregation schemes using data collected from 255 open source projects, we find that: (1) aggregation schemes can significantly alter correlations among metrics, as well as the correlations between metrics and
    [Show full text]
  • The Principles of Sizing and Estimating Projects Using
    Principles of Sizing… www.davidconsultinggroup.com The Principles of Sizing and Estimating Projects Using International Function Point User Group (IFPUG) Function Points By David Garmus, David Consulting Group Introduction Software practitioners are frequently challenged to provide early and accurate software project estimates. It speaks poorly of the software community that the issue of accurate estimating, early in the lifecycle, has not been adequately addressed and standardized. The CHAOS Report by The Standish Group’s study on software development projects revealed: 60% of projects were behind schedule 50% were over cost, and 45% of delivered projects were unusable. At the heart of the estimating challenge are two issues: 1) the need to understand and express (as early as possible) the software problem domain and 2) the need to understand our capability to deliver the required software solution within a specified environment. Then, and only then, can we accurately predict the effort required to deliver the product. The software problem domain can be defined simply as the scope of the required software. The problem domain must be accurately assessed for its size and complexity. To complicate the situation, experience tells us that at the point in time that we need an initial estimate (early in the systems lifecycle), we cannot presume to have all the necessary information at our disposal. Therefore, we must have a rigorous process that permits a further clarification of the problem domain. Various risk factors relating to environment, technology, tools, methodologies, and people skills and motivation influence our capability to deliver. An effective estimating model, as contained in Figure 1, considers three elements: size, complexity and risk factors, to determine an estimate.
    [Show full text]
  • Software Maintainability a Brief Overview & Application to the LFEV 2015
    Software Maintainability A Brief Overview & Application to the LFEV 2015 Adam I. Cornwell Lafayette College Department of Electrical & Computer Engineering Easton, Pennsylvania [email protected] Abstract — This paper gives a brief introduction on For “lexical level” approaches which base what software maintainability is, the various methods complexity on program code, the following which have been devised to quantify and measure software maintainability, its relevance to the ECE 492 measurands are typical: individual and average Senior Design course, and some practical lines of code; number of commented lines, implementation guidelines. executable statements, blank lines, tokens, and data declarations; source code readability, or the Keywords — Software Maintainability; Halstead ratio of LOC to commented LOC; Halstead Metrics; McCabe’s Cyclomatic complexity; radon Metrics, including Halstead Length, Volume, and Effort; McCabe’s Cyclomatic Complexity; the I. INTRODUCTION control structure nesting level; and the number of Software Maintainability is an important knots, or the number of times the control flow concept in the upkeep of long-term software crosses. The final measurand is not as useful with systems. According to the IEEE, software object oriented programming but can still be of maintainability is defined as “the ease with which some use. a software system or component can be modified to correct faults, improve performance or other “Psychological complexity” approaches measure attributes, or adapt to a changed environment difficulty and are based on understandability and [1].” Software Maintainability can be measured the user [3]. The nature of the file and the using various devised methods, although none difficulty experienced by those working with the have been conclusively shown to work in a large file are what contribute to these kinds of variety of software systems [6].
    [Show full text]
  • DRE) for Software
    Exceeding 99% in Defect Removal Efficiency (DRE) for Software Draft 11.0 September 6, 2016 Capers Jones, VP and CTO, Namcook Analytics LLC Abstract Software quality depends upon two important variables. The first variable is that of “defect potentials” or the sum total of bugs likely to occur in requirements, architecture, design, code, documents, and “bad fixes” or new bugs in bug repairs. Defect potentials are measured using function point metrics, since “lines of code” cannot deal with requirements and design defects. (This paper uses IFPUG function points version 4.3. The newer SNAP metrics are only shown experimentally due to insufficient empirical quality data with SNAP as of 2016. However an experimental tool is included for calculating SNAP defects.) The second important measure is “defect removal efficiency (DRE)” or the percentage of bugs found and eliminated before release of software to clients. The metrics of Defect Potentials and Defect Removal Efficiency (DRE) were developed by IBM circa 1973 and are widely used by technology companies and also by insurance companies, banks, and other companies with large software organizations. The author’s Software Risk Master (SRM) estimating tool predicts defect potentials and defect removal efficiency (DRE) as standard quality outputs for all software projects. Web: www.Namcook.com Email: [email protected] Copyright © 2016 by Capers Jones. All rights reserved. 1 Introduction Defect potentials and defect removal efficiency (DRE) are useful quality metrics developed by IBM circa 1973 and widely used by technology companies as well as by banks, insurance companies, and other organizations with large software staffs. This combination of defect potentials using function points and defect removal efficiency (DRE) are the only accurate and effective measures for software quality.
    [Show full text]
  • Empirical Evaluation of the Effectiveness and Reliability of Software Testing Adequacy Criteria and Reference Test Systems
    Empirical Evaluation of the Effectiveness and Reliability of Software Testing Adequacy Criteria and Reference Test Systems Mark Jason Hadley PhD University of York Department of Computer Science September 2013 2 Abstract This PhD Thesis reports the results of experiments conducted to investigate the effectiveness and reliability of ‘adequacy criteria’ - criteria used by testers to determine when to stop testing. The research reported here is concerned with the empirical determination of the effectiveness and reliability of both tests sets that satisfy major general structural code coverage criteria and test sets crafted by experts for testing specific applications. We use automated test data generation and subset extraction techniques to generate multiple tests sets satisfying widely used coverage criteria (statement, branch and MC/DC coverage). The results show that confidence in the reliability of such criteria is misplaced. We also consider the fault-finding capabilities of three test suites created by the international community to serve to assure implementations of the Data Encryption Standard (a block cipher). We do this by means of mutation analysis. The results show that not all sets are mutation adequate but the test suites are generally highly effective. The block cipher implementations are also seen to be highly ‘testable’ (i.e. they do not mask faults). 3 Contents Abstract ............................................................................................................................ 3 Table of Tables ...............................................................................................................
    [Show full text]
  • SOFTWARE TESTING Aarti Singh
    © November 2015 | IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002 SOFTWARE TESTING Aarti Singh ABSTRACT:- Software testing is an investigation can be installed and run in its conducted to provide stakeholders with intended environments, and information about the quality of the product or achieves the general result its stakeholders service under test Software testing can also desire. provide an objective, independent view of Software testing can be conducted as soon as thesoftware to allow the business to appreciate executable software (even if partially complete) and understand the risks of software exists. The overall approach to software implementation.In this paper we will discuss development often determines when and how testing about testing levels suct as alpha testing , beta is conducted. For example, in a phased process, most testing, unit testing , integrity testing, testing testing occurs after system requirements have been cycle and their requirement n comparison defined and then implemented in testable programs. between varius testing such as static and dynamic HISTORY: testing. The separation of debugging from testing was initially introduced by Glenford J. Myers in INTRODUCTION: 1979.[] Although his attention was on breakage Software testing involves the execution of a testing ("a successful test is one that finds a bug) it software component or system component to illustrated the desire of the software engineering evaluate one or more properties of interest. In community to separate fundamental development general, these
    [Show full text]
  • Lightweight Requirements Engineering Metrics Designing And
    Universiteit Leiden ICT in Business and the Public Sector Lightweight Requirements Engineering Metrics Designing and evaluating requirements engineering metrics for software development in complex IT environments – Case study Name: Jenny Yung Student-no: s0952249 Date: 18/04/2019 1st supervisor: Werner Heijstek 2nd supervisor: Guus Ramackers Pagina 1 van 83 Abstract The software development industry is relatively young and has matured considerably in the past 15 years. With several major transformations, the industry continues to seek ways to improve their delivery. A while ago, the waterfall method was the standard option for software development projects. Today, agile methodology is used more frequently. New development engineering practices are developed like standardization, continuous integration or continuous delivery. However, the consensus of being predictable and repeatable is not yet there. Agile software development and delivery are still not sufficiently reliable, resulting in expensive and unpredictable projects. In this thesis, measurements in requirements engineering are introduced. This paper presents a maturity model to assess the requirements engineering in complex IT environments. Companies strive to improve their software production and delivery, and the study aims to find a lightweight requirements metric method. The method is compared with a library of abstract metric models. The case study is performed at three different companies, and experts evaluated the conceptual metric system. As a result, a Requirements Engineering Maturity scan (REMS) is created. The tool suggests appropriate generic requirements metrics to deal with the encountered project. The paper concludes a review with related work and a discussion of the prospects for REMS. Keywords: Requirements Engineering • Quality Measurements • Metrics • ISO/IEC 9126 • Agile Methodology • Requirements Engineering Maturity Scan • Complex IT Infrastructure • Pagina 2 van 83 Acknowledgement Anyone writing a thesis will tell you it is a lot of work, and they are right.
    [Show full text]
  • Understanding ROI Metrics for Software Test Automation
    University of South Florida Scholar Commons Graduate Theses and Dissertations Graduate School 2005 Understanding ROI Metrics for Software Test Automation Naveen Jayachandran University of South Florida Follow this and additional works at: https://scholarcommons.usf.edu/etd Part of the American Studies Commons Scholar Commons Citation Jayachandran, Naveen, "Understanding ROI Metrics for Software Test Automation" (2005). Graduate Theses and Dissertations. https://scholarcommons.usf.edu/etd/2938 This Thesis is brought to you for free and open access by the Graduate School at Scholar Commons. It has been accepted for inclusion in Graduate Theses and Dissertations by an authorized administrator of Scholar Commons. For more information, please contact [email protected]. Understanding ROI Metrics for Software Test Automation by Naveen Jayachandran A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science Department of Computer Science and Engineering College of Engineering University of South Florida Co-Major Professor: Dewey Rundus, Ph.D. Co-Major Professor: Alan Hevner, Ph.D. Member: Rafael Perez, Ph.D. Date of Approval: June 2, 2005 Keywords: Return on investment metrics, automated testing feasibility, manual vs. automated testing, software quality assurance, regression testing, repetitive testing © Copyright 2005, Naveen Jayachandran Dedication To my Parents, Suja, Rocky and Reemo. Acknowledgements I would like to thank my major professors Dr. Alan Hevner and Dr. Dewey Rundus for recognizing and encouraging my interest, giving me this opportunity and providing constant support for my research. I have gained immensely from this experience enabling me to truly appreciate the saying – ‘The journey is more important than the destination’.
    [Show full text]
  • 12 Steps to Useful Software Metrics
    12 Steps to Useful Software Metrics Linda Westfall The Westfall Team [email protected] PMB 101, 3000 Custer Road, Suite 270 Plano, TX 75075 972-867-1172 (voice) 972-943-1484 (fax) Abstract: 12 Steps to Useful Software Metrics introduces the reader to a practical process for establishing and tailoring a software metrics program that focuses on goals and information needs. The process provides a practical, systematic, start-to-finish method of selecting, designing and implementing software metrics. It outlines a cookbook method that the reader can use to simplify the journey from software metrics in concept to delivered information. Bio: Linda Westfall is the President of The Westfall Team, which provides Software Metrics and Software Quality Engineering training and consulting services. Prior to starting her own business, Linda was the Senior Manager of the Quality Metrics and Analysis at DSC Communications where her team designed and implemented a corporate wide metric program. Linda has more than twenty-five years of experience in real-time software engineering, quality and metrics. She has worked as a Software Engineer, Systems Analyst, Software Process Engineer and Manager of Production Software. Very active professionally, Linda Westfall is a past chair of the American Society for Quality (ASQ) Software Division. She has also served as the Software Division’s Program Chair and Certification Chair and on the ASQ National Certification Board. Linda is a past-chair of the Association for Software Engineering Excellence (ASEE) and has chaired several conference program committees. Linda Westfall has an MBA from the University of Texas at Dallas and BS in Mathematics from Carnegie- Mellon University.
    [Show full text]
  • Software Metrics: Investigating Success Factors, Challenges, Solutions and New Research Directions
    INTERNATIONAL JOURNAL OF SCIENTIFIC & TECHNOLOGY RESEARCH VOLUME 9, ISSUE 08, AUGUST 2020 ISSN 2277-8616 Software Metrics: Investigating Success Factors, Challenges, Solutions And New Research Directions Hina Noor, Dr. Babur Hayat, AbuBakar Hamid, Tamoor Wakeel, Rashida Nasim Abstract: Software metrics is becoming important every day. A measure of software characteristics which are countable or measurable is known as software metrics. Software metrics are very important because they are used for many purposes for example, estimating efficiency, arranging work things and estimating execution of software etc. Software product and software development process specific attributes are measured by software metrics. Many metrics related to coupling, cohesion etc. have been defined. This paper investigates success factors and challenges in the implementation of software metrics and also tries to investigate solutions to those challenges. The paper explains new research directions to software metrics as well which really a need of today. Index Terms: Software metrics, Measurements, Types of metrics, Success factors of software metrics, Challenges in implementation of software metrics, New research directions in software metrics. —————————— —————————— 1. INTRODUCTION IN software, measurements are done using software metrics. A software metric is a measurement measure of the degree to which a software program or procedure has certain capital. Even if a metric is not a measure (metrics are functions, while measurements are the numbers obtained through metric application) [1]. Accurate measurement for all engineering fields is a requirement and software engineering is no different. For decades engineers and academics are persuading to communicate numerical software functionality to enable quality assurance of software. A broad variety of quality software measures have been created and there are various methods to obtain measures from system representations [2], [20].
    [Show full text]
  • Cyclomatic Complexity 6 Code Churn 8 Churn Vs
    www.codacy.com Index Why software metrics are important 3 Scope of this e-book 4 I. The Good 6 Cyclomatic complexity 6 Code churn 8 Churn vs. Complexity 9 Code coverage 10 Code duplication 12 Lack of Cohesion Of Methods (LCOM) 13 Relational cohesion 14 II. The Bad 15 Afferent & efferent coupling 15 Instability 17 Abstractness 18 Distance from main sequence (DMS) 19 III. The Ugly 21 Density of comments 21 Source line of code (SLOC) 22 Number of parameters 24 Number of variables 24 Number of overloads 24 Bonus: The best metric of all 25 Conclusion 25 About Codacy 26 Cheat sheet 27 Further reading 29 3 Why software metrics are important “If debugging is the process of removing software bugs, then programming must be the process of putting them in.” - Edsger Dijkstra Is the code tested? Is it readable? How easy is it to add or modify code without introducing bugs? Is it more complex than it needs to be? How maintainable is it going to be? Is it resource efficient? Is it easily extensible? Is technical debt creeping up? Software metrics are important because they help answer these questions. They provide objective, quantifiable measurements that support the myriad of decisions that developers make daily. Yet software metrics are not without their flaws, far from it. First, no single software metric can claim to provide a complete and accurate picture. Second, most metrics fail as universal yardsticks: sensitivity to factors such as programming language or even the lack of consensus on the algorithms that underpin them, lead to confusion and frustrations.
    [Show full text]
  • Application of Sizing Estimation Techniques for Business Critical Software Project Management
    International Journal of Soft Computing And Software Engineering (JSCSE) e-ISSN: 2251-7545 Vol.3,No.6, 2013 DOI: 10.7321/jscse.v3.n6.2 Published online: Jun 25, 2013 Application of Sizing Estimation Techniques for Business Critical Software Project Management *1 Parvez Mahmood Khan, 2 M.M. Sufyan Beg Department of Computer Engineering, J.M.I. New Delhi, India 1 [email protected] , 2 [email protected] Abstract Estimation is one of the most critical areas in software project management life cycle, which is still evolving and less matured as compared to many other industries like construction, manufacturing etc. Originally the word estimation, in the context of software projects use to refer to cost and duration estimates only with software-size almost always assumed to be a fixed input. Continued legacy of bad estimates has compelled researchers, practitioners and business organizations to draw their attention towards another dimension of the problem and seriously validate an additional component – size estimation. Recent studies have shown that size is the principal determinant of cost, and therefore an accurate size estimate is crucial to good cost estimation[10]. Improving the accuracy of size estimates is, therefore, instrumental in improving the accuracy of cost and schedule estimates. Moreover, software size and cost estimates have the highest utility at the time of project inception - when most important decisions (e.g. budget allocation, personnel allocation, etc). are taken. The dilemma, however, is that only high- level requirements for a project are available at this stage. Leveraging this high-level information to produce an accurate estimate of software size is an extremely challenging and high risk task.
    [Show full text]