DOCSLIB.ORG

The Evolution of Software Size: a Search for Value©

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Evolution of Software Size: a Search for Value© Software Engineering Technology The Evolution of Software Size: A Search for Value© Arlene F. Minkiewicz PRICE Systems, LLC Software size measurement continues to be a contentious issue in the software engineering community. This article reviews soft- ware sizing methodologies employed through the years, focusing on their uses and misuses. It covers the journey the software community has traversed in the quest for finding the right way to assign value to software solutions, highlighting the detours and missteps along the way. Readers will gain a fresh perspective on software size, what it really means, and what they can and cannot learn from history. hen I first started programming, it evolved throughout the last 25 years. It In the ’70s, the LOC measure never occurred to me to think focuses on reasons why these approaches seemed like a pretty good device. aboutW the size of the software I was were attempted, the technological or Programming languages were simple developing. This was true for several rea- human factors that were in play, and the and a fairly compelling argument could sons. First of all, when I first learned to degree of success achieved in the use of be made about the equivalence among program, software had a tactile quality each approach. Finally, it addresses some LOC. Besides, it was the only measure in through the deck of punched cards of the reasons why the software engineer- town. required to run a program. If I wanted to ing community is still searching for the In the late ’70s, RCA introduced the size the software, there was something I right way to measure software size. first commercially available software could touch, feel, or eyeball to get a sense cost estimation tool, which used SLOC of how much there was. Secondly, I had Lines of Code converted to machine instructions as the no real reason to care how much code I As software development moved out of size measure for software items being was writing; I just kept writing until I got the lab and into the real world, it quickly estimated. In the ’80s, Barry Boehm’s the desired results and then moved on to became obvious that the ability to mea- COCOMO was introduced, also using the next challenge. Finally, as an engi- SLOC as the size measure of choice. As neering student, I was expected to learn other cost models followed, they too how to program but was never taught to “Now, 25 years later, used LOC measures to quantify the appreciate the fact that developing soft- amount of functionality being delivered. ware was an engineering discipline. The if you Google the It is important to note that while all of idea of size being a characteristic of soft- phrase software size you these models used SLOC as a primary ware was foreign to me—what did it real- cost driver, there are many other factors ly mean and what was the context? And will get more than that influence the cost of software why would anyone care? development as well. These software Now, 25 years later, if you Google the 100,000 hits. cost estimation models also need to phrase software size you will get more than gather information about factors such as 100,000 hits. Clearly, there is a reason to Clearly, there is a the complexity of the software being care about software size and there are lots estimated, the experience and capability of people out there worrying about it. reason to care about of the software development team, And still, I am left to wonder: What does expected reuse, the overall productivity it really mean and what is the context? software size and of the development organization, con- And why does anyone care? straints, and so forth. The quantification It turns out that there are several very there are lots of people of these factors is applied to the soft- good reasons for wanting to measure soft- ware size to determine estimates of cost ware size. Software size can be an impor- out there worrying and effort. tant component of a productivity compu- I believe that SLOC will go down in tation, a cost or effort estimate, or a qual- about it.” the annals of engineering history as the ity analysis. More importantly, a good soft- most maligned measure of all time. ware size measure could conceivably lead There are many areas where criticism of sure productivity and quality would be SLOC as a software size measure is jus- to a better understanding of the value useful and necessary. The lines of code being delivered by a software application. tified. SLOC counts are, by their nature, (LOC) measure—including source LOC very dependent on programming lan- The problem is that there is no agreement (SLOC), thousands of LOC, and thou- among professionals as to the right units guage. You can get more functionality sands of SLOC—is a count of the num- with a line of Visual C++ than you can for measuring software size or the right ber of machine instructions developed. with a line of FORTRAN, which is way to measure within selected units. It was the first measure applied to soft- more than you get with a line of This article examines the various ware, with its first documented use by Assembly Language. This does make approaches used to measure software size R.W. Wolverton in his attempt to formal- using SLOC as a basis for a productivity as the discipline of software engineering ly measure software development pro- or quality comparison among different © Copyright PRICE Systems, 2009. ductivity [1]. programming languages a bad idea. March/April 2009 www.stsc .hill.af.mil 23 Software Engineering Technology Capers Jones has gone so far as to label method for estimation and measurement assessing the productivity of their such comparisons “professional mal- within the context of their projects and processes. practice” [2]. practices. Another important considera- While I would be remiss not to Concerns also surround the consis- tion is the fact that once an organization acknowledge the great contribution that tency of SLOC counts, even within the has agreed on measurement rules for Albrecht made to the software engineer- same programming language. There are SLOC, counting can be automated so ing community with the introduction of several distinct methods for counting that completed projects can be mea- function points, I would be equally LOC. Counting physical LOC involves sured with minimal time and effort and remiss to stop the story here. Function counting each line of code written while without subjectivity. points are not the answer to all software logical lines involve counting the lines measurement woes, as they come with that represent a single complete thought Function Points their own set of limitations. to the compiler. In many programming In 1979, Allan J. Albrecht introduced Albrecht developed function points languages, spaces are inconsequential; function points, which are used to quan- to address a specific problem within his because of this, the differences between tify the amount of business functionali- organization, IBM. They, like many busi- physical and logical lines can be signifi- ty an information system delivers to its nesses that developed software, were cant. Add to this the fact that even with- users [3]. Where SLOC represents some- concerned with the problem of runaway in each of these methods, there are ques- thing tangible that may or may not relate software projects and wanted to get a tions as to how to deal with blanks, com- directly to value, function points attempt better handle on their software develop- ments, and non-executable statements to measure the intangible of end user ment processes. According to Tom (such as data declarations). Programmer value. Function point counts look at the DeMarco, “you can’t manage what you style also influences the number of LOC can’t measure” [4]. Function points written as there are multiple ways a pro- related very closely to the types of busi- grammer may decide to solve a problem Where SLOC ness applications that IBM was develop- with the same language. “ ing at the time, proving to be a far supe- Additionally, if SLOC is the only represents something rior measure of business value than characteristic of a software program that SLOC; function points can be much bet- is measured, productivity and quality tangible that ter for an organization that develops studies will overlook many important these types of systems to use for pro- factors. Other important characteristics may or may not ductivity comparison studies. include the amount of reuse, the inher- It’s fair to say that function points ent difficulty of solving a particular relate directly to value, caught on like wildfire in the software problem, and environmental factors that engineering community. Many new and model the approaches and practices of function points attempt successful businesses grew around help- an organization. All of these things ing software development organizations influence the productivity of a project. to measure the use function points to improve their mea- In general, it is fair to say that SLOC surement and quality programs, especial- measurement, considered in a vacuum, intangible of ly for commercial IT software develop- is a poor way to measure the value that ments. Two problems grew out of the is delivered to the end user of the soft- end user value.” introduction of function points. The first ware. It does continue to be a popular was that the fervor to jettison the much- measure for software cost and effort maligned SLOC measures caused many estimation. Even as other metrics have five basic things that are required for a to embrace function points for all types emerged that are considered better by user to get value out of software: Input, of systems, many not well-suited to func- much of the software engineering com- Outputs, Enquiries, Internal Data tion points.
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]
  • 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]
  • 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]
  • Automating Software Quality Measurement with Standards
    Automating Software Quality Measurement with Standards Paul C. Bentz Amsterdam June 18, 2019 Why Automate? ©2019 CISQ 2 Complexity 1 Unit Level • Code style & layout • Expression complexity • Code documentation • Class or program design • Basic coding standards J • Developer level APIs JSP ASP.NET Java Java Java a 2 Technology Level Web v Services • Single language/technology layer • layer Architecture layer a Intra-technology architecture - • Intra-layer dependencies Hibernate Messaging • Inter-program invocation Struts .NET • Security vulnerabilities Spring • Development team level COBOL PL/SQL T/SQL EJB language, multi - 3 System Level SQL Server . Integration quality . Data access control Oracle Multi . Architectural compliance . SDK versioning DB2 . Risk propagation . Calibration across Sybase IMS . Application security technologies . Resiliency checks . IT organization level . Transaction integrity . Function point, . Effort estimation Technology Stack ©2019 CISQ 3 Velocity ©2019 CISQ 4 Automated Complex Toolchains • Production metrics, objects and feedback • Requirements • Design of the software and • Business metrics configuration • Update release metrics • Coding including code quality • Release plan, timing and business case and performance • Security policy and requirement • Software build and build performance • Infrastructure storage, • Release candidate database and network provisioning and configuring • Application provision and configuration • Acceptance testing • Regression testing • Security and vulnerability analysis
    [Show full text]
  • Language-Independent Volume Measurement
    Language-independent volume measurement Edwin Ouwehand [email protected] Summer 2018, 52 pages Supervisor: Ana Oprescu Organisation supervisor: Lodewijk Bergmans Second reader: Ana Varbanescu Host organisation: Software Improvement Group, http://ww.sig.eu Universiteit van Amsterdam Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering http://www.software-engineering-amsterdam.nl Contents Abstract 3 1 Introduction 4 1.1 Problem statement...................................... 5 1.2 Research Questions...................................... 5 1.3 Software Improvement Group................................ 6 1.4 Outline ............................................ 6 2 Background 7 2.1 Software Sizing........................................ 7 2.1.1 Function Points.................................... 7 2.1.2 Effort estimation................................... 8 2.2 Expressiveness of programming languages......................... 8 2.3 Kolmogorov Complexity................................... 8 2.3.1 Incomputability and Estimation .......................... 9 2.3.2 Applications ..................................... 9 2.4 Data compression....................................... 9 2.4.1 Compression Ratio.................................. 10 2.4.2 Lossless & Lossy................................... 10 2.4.3 Archives........................................ 10 3 Research Method 12 3.1 Methodology ......................................... 12 3.2 Data.............................................. 12 3.3 Counting
    [Show full text]
  • Quality Characteristics and Metrics for Reusable Software (Preliminary Report)
    Quality Characteristics and Metrics for Reusable Software (Preliminary Report) W. J. Salamon D. R. Wallace Prepared by the U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Gaithersburg, MD 20899 for the Department of Defense Ballistic Missile Defense Organization —Qe 100 .U56 NIST NO. 5459 1994 4 NISTIR 5459 Quality Characteristics and Metrics for Reusable Software (Preliminary Report) W. J. Salamon D. R. Wallace Prepared by the U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards and Technology Gaithersburg, MD 20899 for the Department of Defense Ballistic Missile Defense Organization May 1994 U.S. DEPARTMENT OF COMMERCE Ronald H. Brown, Secretary TECHNOLOGY ADMINISTRATION Mary L Good, Under Secretary for Technology NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Arad Prabhakar, Director ABSTRACT This report identifies a set of quality characteristics of software and provides a summary of software metrics that are useful in measuring these quality characteristics for software products. The metrics are useful in assessing the reusability of software products. This report is preliminary. Additional research is needed to ensure the completeness of the quality characteristics and supporting metrics, and to provide guidance on using the metrics. KEYWORDS Reusable Software; Quality Characteristics; Software Reliability; Completeness; Correctness; Software Metrics ,fi> i^fi.'4»^lw(ti>bi ncwp>t «frfT' '^^m'^ki^'m m tBtis ir^m^t »mw^g ' ^ .. ^ W : IBIOL EXECUTIVE SUMMARY The Software Producibility Manufacturing Operations Development and Integration Laboratory (Software Producibility MODIL) was established at the National Institute of Standards and Technology (NIST) in 1992. The Software Producibility MODIL was one of four MODILs instituted at national laboratories by the U.S.
    [Show full text]
  • Software Development Cost Estimation Approaches – a Survey1
    Software Development Cost Estimation Approaches – A Survey1 Barry Boehm, Chris Abts University of Southern California Los Angeles, CA 90089-0781 Sunita Chulani IBM Research 650 Harry Road, San Jose, CA 95120 1 This paper is an extension of the work done by Sunita Chulani as part of her Qualifying Exam report in partial fulfillment of requirements of the Ph.D. program of the Computer Science department at USC [Chulani 1998]. Abstract This paper summarizes several classes of software cost estimation models and techniques: parametric models, expertise-based techniques, learning-oriented techniques, dynamics-based models, regression-based models, and composite-Bayesian techniques for integrating expertise- based and regression-based models. Experience to date indicates that neural-net and dynamics-based techniques are less mature than the other classes of techniques, but that all classes of techniques are challenged by the rapid pace of change in software technology. The primary conclusion is that no single technique is best for all situations, and that a careful comparison of the results of several approaches is most likely to produce realistic estimates. 1. Introduction Software engineering cost (and schedule) models and estimation techniques are used for a number of purposes. These include: § Budgeting: the primary but not the only important use. Accuracy of the overall estimate is the most desired capability. § Tradeoff and risk analysis: an important additional capability is to illuminate the cost and schedule sensitivities of software project decisions (scoping, staffing, tools, reuse, etc.). § Project planning and control: an important additional capability is to provide cost and schedule breakdowns by component, stage and activity.
    [Show full text]
  • Enhancement in Function Point Analysis
    International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.6, November 2012 ENHANCEMENT IN FUNCTION POINT ANALYSIS Archana Srivastava1 , Dr. Syed Qamar Abbas2 , Dr.S.K.Singh3 1 Amity University, Lucknow, India [email protected], [email protected], 2Director, Ambalika Institute of Management & Technology , Lucknow, India 3Professor, Amity University, Lucknow, India ABSTRACT Early and accurate estimation of software size plays an important role in facilitating effort and cost estimation of software systems. One of the commonly used methodologies for software size estimation is Function Point Analysis (FPA). The purpose of Software size estimation and effort estimation techniques is to provide a useful measure of the software complexities, efforts, and costs involved in software development. Despite almost three decades of research on software estimation, the research community has yet not able to provide a reliable estimation model for End-User Development (EUD) environments. EUD essentially out-sources development effort to the end user. Hence one element of the size and effort is the additional design time expended in end-user programming. This paper discusses the concept end-user programming and enhancement of FPA by adding end-user programming as an additional General System Characteristic (GSC). KEYWORDS size estimation, end user programming, function point analysis, end user development 1. INTRODUCTION End-User Programming system aims to give some programmable system functionality to people who are not professional programmers. One of the most successful computer programs of all times is the spreadsheet applications. The primary reason for its success is that end users can program it without going into the background details of logic and programming.
    [Show full text]
  • COSMIC FFP Measurement Manual V2.2
    The COSMIC Functional Size Measurement Method Version 4.0.1 Guideline on Non-Functional & Project Requirements How to consider non-functional and project requirements in software project performance measurement, benchmarking and estimating Version 1. November 2015 Version control Date Reviewer(s) Modifications / Additions March 2014 v0.1 followed by 15 iterations November See Acknowledgements First version 1.0 published 2015 Copyright 2015. All Rights Reserved. The Common Software Measurement International Consortium (COSMIC). Permission to copy all or part of this material is granted provided that the copies are not made or distributed for commercial advantage and that the title of the publication, its version number, and its date are cited and notice is given that copying is by permission of the Common Software Measurement International Consortium (COSMIC). To copy otherwise requires specific permission. Acknowledgements Authors and reviewers who have contributed to the development of v1.0 (alphabetical order) Alain Abran, Diana Baklizky Carol Buttle École de Technologie Supérieure, TI Metricas Safety and Security Engineering Université du Québec Council Brazil Canada United Kingdom Jean-Marc Desharnais Peter Fagg Cigdem Gencel École de Technologie Supérieure, Pentad Ltd DEISER Université du Québec United Kingdom Spain Canada Barbara Kitchenham, Arlan Lesterhuis Roberto Meli Keele University Data Processing Organization United Kingdom The Netherlands Italy Dylan Ren Luca Santillo Hassan Soubra Measures Agile Metrics Ecole Supérieure
    [Show full text]
  • Software Estimation, Measurement, and Metrics Chapter 13: Software Estimation, Measurement & Metrics GSAM Version 3.0
    Part 3: Management GSAM Version 3.0 Chapter 13 Software Estimation, Measurement, and Metrics Chapter 13: Software Estimation, Measurement & Metrics GSAM Version 3.0 Contents 13.1 Chapter Overview .................................................................................. 13-4 13.2 Software Estimation ............................................................................... 13-4 13.2.1 Measuring Software Size................................................................... 13-6 13.2.2 Source Lines-of-Code Estimates ....................................................... 13-7 13.2.3 Function Point Size Estimates........................................................... 13-7 13.2.4 Feature Point Size Estimates.............................................................. 13-9 13.2.5 Cost and Schedule Estimation Methodologies/Techniques ............. 13-10 13.2.6 Ada-Specific Cost Estimation ......................................................... 13-12 13.3 Software Measurement ......................................................................... 13-13 13.3.1 Measures and Metrics, and Indicators ............................................. 13-13 13.3.2 Software Measurement Life Cycle................................................... 13-15 13.3.3 Software Measurement Life Cycle at Loral...................................... 13-16 13.4 Software Measurement Process........................................................... 13-18 13.4.1 Metrics Plan ..................................................................................
    [Show full text]
  • Software Cost Estimation and Sizing Methods: Issues and Guidelines
    THE ARTS This PDF document was made available CHILD POLICY from www.rand.org as a public service of CIVIL JUSTICE the RAND Corporation. EDUCATION ENERGY AND ENVIRONMENT Jump down to document6 HEALTH AND HEALTH CARE INTERNATIONAL AFFAIRS The RAND Corporation is a nonprofit NATIONAL SECURITY research organization providing POPULATION AND AGING PUBLIC SAFETY objective analysis and effective SCIENCE AND TECHNOLOGY solutions that address the challenges SUBSTANCE ABUSE facing the public and private sectors TERRORISM AND HOMELAND SECURITY around the world. TRANSPORTATION AND INFRASTRUCTURE WORKFORCE AND WORKPLACE Support RAND Purchase this document Browse Books & Publications Make a charitable contribution For More Information Visit RAND at www.rand.org Explore RAND Project AIR FORCE View document details Limited Electronic Distribution Rights This document and trademark(s) contained herein are protected by law as indicated in a notice appearing later in this work. This electronic representation of RAND intellectual property is provided for non- commercial use only. Permission is required from RAND to reproduce, or reuse in another form, any of our research documents. This product is part of the RAND Corporation monograph series. RAND monographs present major research findings that address the challenges facing the public and private sectors. All RAND mono- graphs undergo rigorous peer review to ensure high standards for research quality and objectivity. 4PGUXBSF $PTU&TUJNBUJPO BOE4J[JOH.FUIPET *TTVFTBOE(VJEFMJOFT 4IBSJ-BXSFODF1GMFFHFS 'FMJDJB8V 3PTBMJOE-FXJT 1SFQBSFEGPSUIF6OJUFE4UBUFT"JS'PSDF "QQSPWFEGPSQVCMJDSFMFBTFEJTUSJCVUJPOVOMJNJUFE 4HERESEARCHDESCRIBEDINTHISREPORTWASSPONSOREDBYTHE5NITED3TATES !IR&ORCEUNDER#ONTRACT& # &URTHERINFORMATIONMAY BEOBTAINEDFROMTHE3TRATEGIC0LANNING$IVISION $IRECTORATEOF0LANS (Q53!& ,IBRARYOF#ONGRESS#ATALOGING IN 0UBLICATION$ATA 0FLEEGER 3HARI,AWRENCE 3OFTWARECOSTESTIMATIONANDSIZINGMETHODSISSUESANDGUIDELINES 3HARI,AWRENCE0FLEEGER &ELICIA7U 2OSALIND,EWIS PCM h-' v )NCLUDESBIBLIOGRAPHICALREFERENCES )3".
    [Show full text]