DOCSLIB.ORG

Software Development Cost Estimating Handbook Volume I

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Development Cost Estimating Handbook Volume I Naval Center for Cost Analysis Air Force Cost Analysis Agency Software Development Cost Estimating Handbook Volume I Developed by the Software Technology Support Center September 2008 Resource manual for education and support in developing credible software development cost estimates Executive Summary The purpose of the Software Development Estimating Handbook is to provide the cost analyst with a resource manual to use in developing credible software development cost estimates. A realistic estimate is based upon a solid understanding of the software development process and the historical data that forms a framework for the expected values. An estimating methodology that follows a proven process consistent with best practices and Department of Defense (DoD) policies further contributes to estimate validity. The information is presented at two levels. One level will help the experienced analyst immediately focus on the material necessary to develop an estimate. The second level of information is for the novice, or infrequent user, to use as educational information regarding the software development and estimating processes. The estimating process starts with a determination of the purpose of the estimate. Next, the cost (or effort) and schedule for the software development project are determined using three factors: effective size, development environment, and product complexity. The key, and most important, element in the software estimate is the effective size of the software product. Determining size can be approached from several directions depending upon the software size measure (lines of code, function points, use cases, etc.) used by the development organization. A system developed by writing lines of code requires a different estimating approach than a previously developed or off-the- shelf application. The acquisition phase also influences the analyst’s approach because of the amount and type of software development data available from the program or developers. The development environment is the next most important effort and schedule driver. The environment can be factored into five categories: (1) developer capability or efficiency, (2) personnel experience, (3) development system characteristics, (4) management characteristics, and (5) product characteristics. The last four categories are largely driven by the product requirements. These factors take into consideration the development environment itself, the capabilities and experience of the developers, the developing organization’s management style, security requirements, and so on. These factors, along with software size and complexity, combine to determine the productivity or efficiency with which a developer can ―build‖ and test the software. Ultimately, these environment characteristics drive the cost and schedule of the software development and implementation of the system. It is uncertain who first coined the phrase, ―A fool with a tool is still a fool.‖ Plugging numbers into a parametric model without knowing if the results are realistic fits this adage. This handbook addresses estimate realism using historical data, industry best practices, and authoritative insight. The insight comes from experts in the fields of software development and cost estimating. This information helps the analyst conduct a ―sanity check‖ of their estimate results. A well-understood and validated estimate offers a defensible position for program office analysts, component cost agency analysts, and independent evaluators. A reasonable estimate is useful in budgeting, milestone decision reviews, and determining the life cycle or other costs of the program. The contents of this volume, ten sections and nine appendices, are grouped into four major parts. An introduction and the basics of the software development process lead off the tutorial. The next two parts cover the estimating process and related details. Concepts and examples presented in the sections are covered in greater detail in the appendices. The idea behind this structure is to present principles for instruction and reference in the core sections and, then, examine details and related examples. This handbook was written for use by the Naval Center for Cost Analysis (NCCA) and the Air Force Cost Analysis Agency (AFCAA). The information herein is not intended to dictate policy or supplant guidance given in official documents. However, the authors hope that everyone within the software cost estimating community will find it useful. The extent of information on software development and cost estimating presented within these pages is not intended to be all-inclusive. Yet, the handbook is meant to be comprehensive and complete, providing a single-resource document for use in creating estimates. Table of Contents Executive Summary ............................................................................................................. i Acknowledgements ............................................................................................................ xi List of Figures ................................................................................................................... xii List of Tables ................................................................................................................... xiii List of Equations .............................................................................................................. xvi Section 1 Introduction ...................................................................................................... 1-1 1.1 Development constraints ............................................................................................ 1-4 1.2 Major cost factors ...................................................................................................... 1-4 1.2.1 Effective size ....................................................................................................... 1-5 1.2.2 Product complexity ............................................................................................. 1-5 1.2.3 Development environment .................................................................................. 1-6 1.2.4 Product characteristics ........................................................................................ 1-6 1.3 Software support estimation ...................................................................................... 1-6 1.4 Handbook overview ................................................................................................... 1-7 Section 2 Software Development Process ....................................................................... 2-1 2.1 The Defense Acquisition System ............................................................................... 2-1 2.1.1 Framework Elements .......................................................................................... 2-1 2.1.2 User Needs and Technology Opportunities ........................................................ 2-2 2.1.3 Pre-Systems Acquisition ..................................................................................... 2-2 2.1.3.1 Concept Refinement Phase .......................................................................... 2-2 2.1.3.2 Milestone A .................................................................................................. 2-3 2.1.3.3 Technology Development Phase.................................................................. 2-3 2.1.3.4 Milestone B .................................................................................................. 2-3 2.1.4 Systems Acquisition............................................................................................ 2-3 2.1.4.1 System Development & Demonstration ...................................................... 2-3 2.1.4.2 Milestone C .................................................................................................. 2-3 2.1.4.3 Production & Deployment ........................................................................... 2-4 2.1.5 Sustainment ......................................................................................................... 2-4 2.2 Waterfall Model ......................................................................................................... 2-4 2.2.1 Requirements Analysis and Specification .......................................................... 2-6 2.2.2 Full-Scale Development...................................................................................... 2-6 ii 2.2.3 System Integration and Test................................................................................ 2-7 2.3 Software Development Products................................................................................ 2-7 2.3.1 Software Development Plan ............................................................................... 2-8 2.3.1.1 Project Organization .................................................................................... 2-8 2.3.1.2 Schedule ....................................................................................................... 2-8 2.3.1.3 Software Design Document ......................................................................... 2-8 2.3.1.4 Quality Plan ................................................................................................. 2-9 2.3.2 Software Requirements Specification ................................................................. 2-9 2.3.3 Interface Control Document ..............................................................................
Load more

Recommended publications
  • 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]
  • 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.
    [Show full text]
  • Understanding the Syntactic Rule Usage in Java
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by UCL Discovery Understanding the Syntactic Rule Usage in Java Dong Qiua, Bixin Lia,∗, Earl T. Barrb, Zhendong Suc aSchool of Computer Science and Engineering, Southeast University, China bDepartment of Computer Science, University College London, UK cDepartment of Computer Science, University of California Davis, USA Abstract Context: Syntax is fundamental to any programming language: syntax defines valid programs. In the 1970s, computer scientists rigorously and empirically studied programming languages to guide and inform language design. Since then, language design has been artistic, driven by the aesthetic concerns and intuitions of language architects. Despite recent studies on small sets of selected language features, we lack a comprehensive, quantitative, empirical analysis of how modern, real-world source code exercises the syntax of its programming language. Objective: This study aims to understand how programming language syntax is employed in actual development and explore their potential applications based on the results of syntax usage analysis. Method: We present our results on the first such study on Java, a modern, mature, and widely-used programming language. Our corpus contains over 5,000 open-source Java projects, totalling 150 million source lines of code (SLoC). We study both independent (i.e. applications of a single syntax rule) and dependent (i.e. applications of multiple syntax rules) rule usage, and quantify their impact over time and project size. Results: Our study provides detailed quantitative information and yields insight, particularly (i) confirming the conventional wisdom that the usage of syntax rules is Zipfian; (ii) showing that the adoption of new rules and their impact on the usage of pre-existing rules vary significantly over time; and (iii) showing that rule usage is highly contextual.
    [Show full text]
  • Development of an Enhanced Automated Software Complexity Measurement System
    Journal of Advances in Computational Intelligence Theory Volume 1 Issue 3 Development of an Enhanced Automated Software Complexity Measurement System Sanusi B.A.1, Olabiyisi S.O.2, Afolabi A.O.3, Olowoye, A.O.4 1,2,4Department of Computer Science, 3Department of Cyber Security, Ladoke Akintola University of Technology, Ogbomoso, Nigeria. Corresponding Author E-mail Id:- [email protected] [email protected] [email protected] 4 [email protected] ABSTRACT Code Complexity measures can simply be used to predict critical information about reliability, testability, and maintainability of software systems from the automatic measurement of the source code. The existing automated code complexity measurement is performed using a commercially available code analysis tool called QA-C for the code complexity of C-programming language which runs on Solaris and does not measure the defect-rate of the source code. Therefore, this paper aimed at developing an enhanced automated system that evaluates the code complexity of C-family programming languages and computes the defect rate. The existing code-based complexity metrics: Source Lines of Code metric, McCabe Cyclomatic Complexity metrics and Halstead Complexity Metrics were studied and implemented so as to extend the existing schemes. The developed system was built following the procedure of waterfall model that involves: Gathering requirements, System design, Development coding, Testing, and Maintenance. The developed system was developed in the Visual Studio Integrated Development Environment (2019) using C-Sharp (C#) programming language, .NET framework and MYSQL Server for database design. The performance of the system was tested efficiently using a software testing technique known as Black-box testing to examine the functionality and quality of the system.
    [Show full text]
  • Data Sanity Check for Deep Learning Systems Via Learnt Assertions
    Data Sanity Check for Deep Learning Systems via Learnt Assertions Haochuan Lu∗y, Huanlin Xu∗y, Nana Liu∗y, Yangfan Zhou∗y, Xin Wang∗y ∗School of Computer Science, Fudan University, Shanghai, China yShanghai Key Laboratory of Intelligent Information Processing, Shanghai, China Abstract—Reliability is a critical consideration to DL- based deviations in a data flow perspective. Invalid input cases are systems. But the statistical nature of DL makes it quite vulnerable thus identified effectively. to invalid inputs, i.e., those cases that are not considered in We summarize the contributions of this paper as follows. the training phase of a DL model. This paper proposes to perform data sanity check to identify invalid inputs, so as to • We approach reliability enhancement of DL systems via enhance the reliability of DL-based systems. We design and data sanity check. We proposed a tool, namely SaneDL, implement a tool to detect behavior deviation of a DL model to perform data sanity check for DL-based systems. when processing an input case. This tool extracts the data flow SaneDL provides assertion mechanism to detect behavior footprints and conducts an assertion-based validation mechanism. The assertions are built automatically, which are specifically- deviation of DL model. To our knowledge, SaneDL is the tailored for DL model data flow analysis. Our experiments first assertion-based tool that can automatically detects conducted with real-world scenarios demonstrate that such an invalid input cases for DL systems. Our work can shed assertion-based data sanity check mechanism is effective in light to other practices in improving DL reliability.
    [Show full text]
  • The Commenting Practice of Open Source
    The Commenting Practice of Open Source Oliver Arafat Dirk Riehle Siemens AG, Corporate Technology SAP Research, SAP Labs LLC Otto-Hahn-Ring 6, 81739 München 3410 Hillview Ave, Palo Alto, CA 94304, USA [email protected] [email protected] Abstract lem domain is well understood [15]. Agile software devel- opment methods can cope with changing requirements and The development processes of open source software are poorly understood problem domains, but typically require different from traditional closed source development proc- co-location of developers and fail to scale to large project esses. Still, open source software is frequently of high sizes [16]. quality. This raises the question of how and why open A host of successful open source projects in both well source software creates high quality and whether it can and poorly understood problem domains and of small to maintain this quality for ever larger project sizes. In this large sizes suggests that open source can cope both with paper, we look at one particular quality indicator, the den- changing requirements and large project sizes. In this pa- sity of comments in open source software code. We find per we focus on one particular code metric, the comment that successful open source projects follow a consistent density, and assess it across 5,229 active open source pro- practice of documenting their source code, and we find jects, representing about 30% of all active open source that the comment density is independent of team and pro- projects. We show that commenting source code is an on- ject size. going and integrated practice of open source software de- velopment that is consistently found across all these pro- Categories and Subject Descriptors D.2.8 [Metrics]: jects.
    [Show full text]
  • Differences in the Definition and Calculation of the LOC Metric In
    Differences in the Definition and Calculation of the LOC Metric in Free Tools∗ István Siket Árpád Beszédes Department of Software Engineering Department of Software Engineering University of Szeged, Hungary University of Szeged, Hungary [email protected] [email protected] John Taylor FrontEndART Software Ltd. Szeged, Hungary [email protected] Abstract The software metric LOC (Lines of Code) is probably one of the most controversial metrics in software engineering practice. It is relatively easy to calculate, understand and use by the different stakeholders for a variety of purposes; LOC is the most frequently applied measure in software estimation, quality assurance and many other fields. Yet, there is a high level of variability in the definition and calculation methods of the metric which makes it difficult to use it as a base for important decisions. Furthermore, there are cases when its usage is highly questionable – such as programmer productivity assessment. In this paper, we investigate how LOC is usually defined and calculated by today’s free LOC calculator tools. We used a set of tools to compute LOC metrics on a variety of open source systems in order to measure the actual differences between results and investigate the possible causes of the deviation. 1 Introduction Lines of Code (LOC) is supposed to be the easiest software metric to understand, compute and in- terpret. The issue with counting code is determining which rules to use for the comparisons to be valid [5]. LOC is generally seen as a measure of system size expressed using the number of lines of its source code as it would appear in a text editor, but the situation is not that simple as we will see shortly.
    [Show full text]
  • Projectcodemeter Users Manual
    ProjectCodeMeter ProjectCodeMeter Pro Software Development Cost Estimation Tool Users Manual Document version 202000501 Home Page: www.ProjectCodeMeter.com ProjectCodeMeter Is a professional software tool for project managers to measure and estimate the Time, Cost, Complexity, Quality and Maintainability of software projects as well as Development Team Productivity by analyzing their source code. By using a modern software sizing algorithm called Weighted Micro Function Points (WMFP) a successor to solid ancestor scientific methods as COCOMO, COSYSMO, Maintainability Index, Cyclomatic Complexity, and Halstead Complexity, It produces more accurate results than traditional software sizing tools, while being faster and simpler to configure. Tip: You can click the icon on the bottom right corner of each area of ProjectCodeMeter to get help specific for that area. General Introduction Quick Getting Started Guide Introduction to ProjectCodeMeter Quick Function Overview Measuring project cost and development time Measuring additional cost and time invested in a project revision Producing a price quote for an Existing project Monitoring an Ongoing project development team productivity Evaluating development team past productivity Evaluating the attractiveness of an outsourcing price quote Predicting a Future project schedule and cost for internal budget planning Predicting a price quote and schedule for a Future project Evaluating the quality of a project source code Software Screen Interface Project Folder Selection Settings File List Charts Summary Reports Extended Information System Requirements Supported File Types Command Line Parameters Frequently Asked Questions ProjectCodeMeter Introduction to the ProjectCodeMeter software ProjectCodeMeter is a professional software tool for project managers to measure and estimate the Time, Cost, Complexity, Quality and Maintainability of software projects as well as Development Team Productivity by analyzing their source code.
    [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]
  • Counting Software Size: Is It As Easy As Buying a Gallon of Gas?
    Counting Software Size: Is It as Easy as Buying A Gallon of Gas? October 22, 2008 NDIA – 11th Annual Systems Engineering Conference Lori Vaughan and Dean Caccavo Northrop Grumman Mission Systems Office of Cost Estimation and Risk Analysis Agenda •Introduction • Standards and Definitions •Sample • Implications •Summary 2 NORTHOP GRUMMAN CORPORTION© Introduction • In what ways is software like gasoline? • In what ways is software not like gasoline? 3 NORTHOP GRUMMAN CORPORTION© Industry Data Suggests… • A greater percentage of the functions of the DoD Weapon Systems are performed by software System Functionality Requiring Software • Increased amount of software in Space Systems and DoD Weapon Systems – Ground, Sea and Space/Missile • Increased amount of software in our daily lives: – Cars, Cell Phones, iPod, Appliances, PDAs… Code Size/Complexity Growth The amount of software used in DoD weapon systems has grown exponentially 4 NORTHOP GRUMMAN CORPORTION© Is There a Standard for Counting Software? • Since, increasing percent of our DoD systems are reliant on software we need to be able to quantify the software size – Historical data collection – Estimation and planning – Tracking and monitoring during program performance • Software effort is proportional to the size of the software being developed – SW Engineering Economics 1981 by Dr. Barry Boehm • “Counting” infers there is a standard • Experience as a prime integrator – Do not see a standard being followed There are software counting standards but the message isn’t out or it is not being followed consistently 5 NORTHOP GRUMMAN CORPORTION© Source Line of Code definition From Wikipedia, the free encyclopedia ”Source lines of code (SLOC) is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code.
    [Show full text]
  • Appendix A: Measuring Software Size
    Appendix A: Measuring Software Size Software size matters and you should measure it. —Mary Gerush and Dave West Software size is the major determinant of software project effort. Effectively measuring software size is thus a key element of successful effort estimation. Failed software sizing is often the main contributor to failed effort estimates and, in consequence, failed projects. Measuring software size is a challenging task. A number of methods for mea- suring software size have been proposed over the years. Yet, none of them seems to be the “silver bullet” that solves all problems and serves all purposes. Depending on the particular situation different size metrics should typically be used. In this appendix we provide a brief overview of the common software sizing approaches: functional and structural. These approaches represent two, often- confused, perspectives on software size: customer perspective and developer per- spective. The first perspective represents value of software, whereas the second perspective represents the cost (work) of creating this value. We summarize the most relevant strengths and weaknesses of the two most popular sizing methods that represent these perspectives: function point analysis (FPA) and lines of code (LOC). In technical terms, FPA represents “what” whereas LOC represent “how” in software development. Finally, we provide guidelines for selecting appropriate sizing methods for the purpose of effort estimation. A.1 Introduction There are two aspects to sizing a system: what is the count, and what is the meaning or definition of the unit being counted? —Phillip G. Armour A. Trendowicz and R. Jeffery, Software Project Effort Estimation, 433 DOI 10.1007/978-3-319-03629-8, # Springer International Publishing Switzerland 2014 434 Appendix A: Measuring Software Size A.1.1 What Is Software Size? One of the key questions project managers need to answer is “how big is my development project going to be?” The key to answering this question is software size.
    [Show full text]
  • Caradoc of the North Wind Free
    FREE CARADOC OF THE NORTH WIND PDF Allan Frewin Jones | 368 pages | 05 Apr 2012 | Hachette Children's Group | 9780340999417 | English | London, United Kingdom CARADOC OF THE NORTH WIND PDF As the war. Disaster strikes, and a valued friend suffers Caradoc of the North Wind devastating injury. Branwen sets off on a heroic journey towards destiny in an epic adventure of lovewar and revenge. Join Charlotte and Mia in this brilliant adventure full of princess sparkle and Christmas excitement! Chi ama i libri sceglie Kobo e inMondadori. The description is beautiful, but at times a bit too much, and sometimes at its worst the writing is hard to comprehend completely clearly. I find myself hoping vehemently for another book. It definitely allows the I read this in Caradoc of the North Wind sitting and could not put it down. Fair Wind to Widdershins. This author has published under several versions of his name, including Allan Jones, Frewin Jones, and A. Write a product review. Now he has stolen the feathers Caradoc of the North Wind Doodle, the weather-vane cockerel in charge of the weather. Jun 29, Katie rated it really liked it. Is the other warrior child, Arthur?? More than I thought I would, even. I really cafadoc want to know more, and off author is one that can really take you places. Join us by creating an account and start getting the best experience from our website! Jules Ember was raised hearing legends of wjnd ancient magic of the wicked Alchemist and the good Sorceress. Delivery and Returns see our delivery rates and policies thinking of returning an item? Mar 24, Valentina rated it really liked it.
    [Show full text]