DOCSLIB.ORG

NASA Study on Flight Software Complexity

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
NASA Study on Flight Software Complexity Final Report NASA Study on Flight Software Complexity Commissioned by the NASA Office of Chief Engineer Technical Excellence Program Adam West, Program Manager “The demand for complex hardware/software systems has increased more rapidly than the ability to design, implement, test, and maintain them. … It is the integrating potential of software that has allowed designers to contemplate more ambitious systems encompassing a broader and more multidisciplinary scope, and it is the growth in utilization of software components that is largely responsible for the high overall complexity of many system designs.” Michael Lyu Handbook of Software Reliability Engineering, 1996 “While technology can change quickly, getting your people to change takes a great deal longer. That is why the people- intensive job of developing software has had essentially the same problems for over 40 years. It is also why, unless you do something, the situation won’t improve by itself. In fact, current trends suggest that your future products will use more software and be more complex than those of today. This means that more of your people will work on software and that their work will be harder to track and more difficult to manage. Unless you make some changes in the way your software work is done, your current problems will likely get much worse.” Watts Humphrey Winning with Software: An Executive Strategy, 2001 Editor: Daniel L. Dvorak Systems and Software Division Jet Propulsion Laboratory California Institute of Technology Flight Software Complexity Contents EXECUTIVE SUMMARY .............................................................................................................1 1 INTRODUCTION ....................................................................................................................4 1.1 Origins and Objectives ................................................................................................4 1.2 Work Description ........................................................................................................4 1.3 Organization of Report ...............................................................................................6 1.4 Participants ..................................................................................................................7 1.5 Acknowledgements ...................................................................................................11 2 FINDINGS AND RECOMMENDATIONS ..........................................................................13 2.1 Raise Awareness of Downstream Complexity .........................................................13 2.2 Emphasize Requirements Rationale .........................................................................14 2.3 Emphasize Trade Studies ..........................................................................................15 2.4 More Early Analysis and Architecting .....................................................................16 2.5 Establish Architecture Reviews ................................................................................17 2.6 Nurture Software Architects .....................................................................................18 2.7 Involve Operations Engineers Early and Often ........................................................19 2.8 COTS Software: A Mixed Blessing ..........................................................................20 2.9 Invest in Reference Architecture ..............................................................................21 2.10 Stimulate Technology Infusion .................................................................................21 2.11 Apply Static Analysis Tools and Code Compliance Checkers .................................22 2.12 Standardize Fault Protection Terminology ...............................................................22 2.13 Establish Fault Protection Proposal Review .............................................................23 2.14 Develop Fault Protection Education .........................................................................23 2.15 Research Fault Containment Techniques..................................................................24 2.16 Collect and Use Software Metrics ............................................................................24 3 FLIGHT SOFTWARE GROWTH .........................................................................................26 3.1 Flight Software Described ........................................................................................26 3.2 Growth of NASA Flight Software ............................................................................27 3.3 Growth of Embedded Systems Software ..................................................................30 3.4 Sources of Growth ....................................................................................................31 3.5 A Caution about Software Size Metrics....................................................................32 4 FLIGHT SOFTWARE COMPLEXITY ................................................................................33 4.1 Complexity Described ..............................................................................................33 4.2 Complexity through the Lifecycle ............................................................................36 4.3 Views on Complexity ...............................................................................................36 4.4 A Case Study: Laser Interferometer Space Antenna (LISA) ....................................40 3/5/09 i Flight Software Complexity 4.5 Software Complexity Metrics ...................................................................................42 5 FAULT MANAGEMENT .....................................................................................................43 5.1 NASA Planetary Spacecraft Fault Management Workshop .....................................43 5.2 Integrating Fault Protection with Nominal Control System .....................................44 6 THINKING OUTSIDE THE BOX ........................................................................................45 7 PREVENTION, DETECTION, AND CONTAINMENT .....................................................47 8 LITERATURE SURVEY ......................................................................................................49 9 TOPICS FOR FUTURE STUDY ...........................................................................................51 10 PAST AND FUTURE ............................................................................................................52 11 SUMMARY ...........................................................................................................................54 12 REFERENCES .......................................................................................................................55 3/5/09 ii Flight Software Complexity Executive Summary In 2007 the NASA Office of Chief Engineer (OCE) commissioned a multi-center study to bring forth technical and managerial strategies to address risks associated with the growth in size and complexity of flight software (FSW) in NASA’s space missions. The motivation for the study grew from problems attributed to flight software in a variety of missions—in both pre-launch and post-launch activities—and concerns that such problems were growing with the expanding role of flight software. The study was tasked to examine the growth in flight software size and complexity, recommend ways to reduce and better manage complexity, and identify methods of testing complex logic. The study gave special attention to fault protection software because of its complexity. Study participants consisted of engineers and managers at Applied Physics Laboratory, Goddard Space Flight Center, Jet Propulsion Laboratory, Johnson Space Center, and Marshall Space Flight Center. The study adopted a simple definition of “complexity”: how hard something is to understand or verify. This definition implies that the main consequence of complexity is risk, whether technical risk or schedule risk or mission risk. It also highlights the role of humans in the equation since understandability can be enhanced through education and training, as reflected in some recommendations. The study examined complexity not just in flight software development, but in upstream activities (requirements and design) and downstream activities (testing and operations). The study made a distinction between essential functionality, which comes from vetted requirements and is, therefore, unavoidable, and incidental complexity, which arises from decisions about architecture, design, and implementation. The latter can be reduced by making wise decisions and is, therefore, the target of most recommendations. Flight software is a kind of embedded real-time software, a field that has seen exponential growth since its inception. In some areas of NASA, flight software is growing by a factor of ten every ten years. Estimates for Orion’s primary flight software exceed one million lines of code. The growth trend is expected to continue because of increasingly ambitious requirements and because of the advantages of situating new functionality in software or firmware rather than hardware. Flight software has become a spacecraft’s “complexity sponge” because it readily accommodates evolving understanding, making it an enabler of progress. NASA is not alone in such growth. Over the forty years from
Load more

Recommended publications
  • U.S. National Aerobatic Championships
    November 2012 2012 U.S. National Aerobatic Championships OFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB OFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB OFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB Vol. 41 No. 11 November 2012 A PUBLICATION OF THE INTERNATIONAL AEROBATIC CLUB CONTENTSOFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB At the 2012 U.S. National Aerobatic Championships, 95 competitors descended upon the North Texas Regional Airport in hopes of pursuing the title of national champion and for some, the distinguished honor of qualifying for the U.S. Unlimited Aerobatic Team. –Aaron McCartan FEATURES 4 2012 U.S. National Aerobatic Championships by Aaron McCartan 26 The Best of the Best by Norm DeWitt COLUMNS 03 / President’s Page DEPARTMENTS 02 / Letter From the Editor 28 / Tech Tips THE COVER 29 / News/Contest Calendar This photo was taken at the 30 / Tech Tips 2012 U.S. National Aerobatic Championships competition as 31 / FlyMart & Classifieds a pilot readies to dance in the sky. Photo by Laurie Zaleski. OFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB REGGIE PAULK COMMENTARY / EDITOR’S LOG OFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB PUBLISHER: Doug Sowder IAC MANAGER: Trish Deimer-Steineke EDITOR: Reggie Paulk OFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB VICE PRESIDENT OF PUBLICATIONS: J. Mac McClellan Leading by example SENIOR ART DIRECTOR: Olivia P. Trabbold A source for inspiration CONTRIBUTING AUTHORS: Jim Batterman Aaron McCartan Sam Burgess Reggie Paulk Norm DeWittOFFICIAL MAGAZINE of the INTERNATIONAL AEROBATIC CLUB WHILE AT NATIONALS THIS YEAR, the last thing on his mind would IAC CORRESPONDENCE I was privileged to visit with pilots at be helping a competitor in a lower International Aerobatic Club, P.O.
    [Show full text]
  • Ff 89/6 Copy
    $3 vol libre • free flight 6/89 Dec - Jan POTPOURRI SAC was informed by Sport Canada on the 10th of July that we are not eligible for funding for 1989-90 and until further notice. Thus we are now totally on our own. The average yearly grant from 1979 to 1988 in 1989 dollars was $14,000, or $16 per person. Perhaps it’s a good thing as planning in an atmosphere of doubt is not conducive to good health and efficient use of funds. The cutback was not unexpected and steps were taken early on to ease the effects of this loss of revenue. Imaginative planning in our small store and a good response from our members through the use of the “Soaring Stuff” inserts resulted in in- creased sales. We will also receive higher than projected invest- ment income essentially due to careful cash management and short-term interest rates, which have remained higher for longer than generally expected. In addition, a small gain in projected receipts from an unexpected increase in membership – now at 1423 – which is the first time since 1982 that we have passed 1400. Total expenditures should come in well below budget projection, primarily as a result of scaling back meetings and travel expenditures. On balance it seems fair to say that a combination of some tight fistedness on the expenditure side and a bit of luck on the revenue side will leave SAC in a financially stronger position than was expected at the beginning of the season, despite the cutting off of govern- ment funding.
    [Show full text]
  • High Performance Computing Systems: Status and Outlook
    Acta Numerica (2012), pp. 001– c Cambridge University Press, 2012 doi:10.1017/S09624929 Printed in the United Kingdom High Performance Computing Systems: Status and Outlook J.J. Dongarra University of Tennessee and Oak Ridge National Laboratory and University of Manchester [email protected] A.J. van der Steen NCF/HPC Research L.J. Costerstraat 5 6827 AR Arnhem The Netherlands [email protected] CONTENTS 1 Introduction 1 2 The main architectural classes 2 3 Shared-memory SIMD machines 6 4 Distributed-memory SIMD machines 8 5 Shared-memory MIMD machines 10 6 Distributed-memory MIMD machines 13 7 ccNUMA machines 17 8 Clusters 18 9 Processors 20 10 Computational accelerators 38 11 Networks 53 12 Recent Trends in High Performance Computing 59 13 HPC Challenges 72 References 91 1. Introduction High Performance computer systems can be regarded as the most power- ful and flexible research instruments today. They are employed to model phenomena in fields so various as climatology, quantum chemistry, compu- tational medicine, High-Energy Physics and many, many other areas. In 2 J.J. Dongarra & A.J. van der Steen this article we present some of the architectural properties and computer components that make up the present HPC computers and also give an out- look on the systems to come. For even though the speed of computers has increased tremendously over the years (often a doubling in speed every 2 or 3 years), the need for ever faster computers is still there and will not disappear in the forseeable future. Before going on to the descriptions of the machines themselves, it is use- ful to consider some mechanisms that are or have been used to increase the performance.
    [Show full text]
  • Ii' C Aeronautical Engineering Aeron ^Al Engineering Aeronautical Er Lautical Engineering Aeronautic Aeronautical Engineering Ae
    ft • f^^m Jt Aeronautical NASA SP-7037(145) \\ I/%%i/\ Engineering February 1982 eg ^VV ^^•Pv % A Continuin9 Bibliography with Indexes National Aeronautics and Space Administration i' c Aeronautica• ^ l Engineerin•• ^^ • ^"— *g ^^ Aero* n (NASA-SP-7037 (1U5) ) AERONAUTICAL N82-21138 •^I ENGINEERING. A CONTINUING BIBLIOGRAPHY WITH _ ^NDEXFS (National Aeronautics and Space \ p^^^il Administration) 100 p HC $5.00 CSCL 01A ^al Engineering Aeronautical Er lautical Engineering Aeronautic Aeronautical Engineering Aeror sring Aeronautical Engineering ngineering Aeronautical Engine :al Engineering Aeronautical Er lautical Engineering Aeronauts Aeronautical Engineering Aeror 3ring Aeronautical Engineering NASASP-7037(145) AERONAUTICAL ENGINEERING A CONTINUING BIBLIOGRAPHY WITH INDEXES (Supplement 145) A selection of annotated references to unclassified reports and journal articles that were introduced into the NASA scientific and technical information sys- tem and announced in January 1982 in • Scientific and Technical Aerospace-Reports (STAR) • International Aerospace Abstracts (IAA). Scientific and Technical Information Branch 1982 National Aeronautics and Space Administration Washington, DC This supplement is available as NTISUB/141/093 from .the National Technical Information Service (NTIS), Springfield, Virginia 22161 at the price of $5.00 domestic; $10.00 foreign. INTRODUCTION Under the terms of an interagency agreement with the Federal Aviation Administration this publication has been prepared by the National Aeronautics and Space Administration for the joint use of both agencies and the scientific and technical community concerned with the field of aeronautical engineering. The first issue of this bibliography was published in September 1970 and the first supplement in January 1971. This supplement to Aeronautical Engineering -- A Continuing Bibliography (NASA SP- 7037) lists 326 reports, journal articles, and other documents originally announced in January 1982 in Scientific and Technical Aerospace Reports (STAR) or in International Aerospace Abstracts (IAA).
    [Show full text]
  • Soaring Magazine Index for 1990 to 1999/1990To1999 Organized by Subject
    Soaring Magazine Index for 1990 to 1999/1990to1999 organized by subject The contents have all been re-entered by hand, so thereare going to be typos and confusion between author and subject, etc... Please send along any corrections and suggestions for improvement. 1-26 Bob Dittert, 1-26s + Rain = Championship,December,1999, page 24 1-26 Association Bob Hurni, 1991 1-26 Championships (Caesar Creek),January,1992, pages 18-24 George Powell, The Stealth Glider,January,1992, pages 28-30 MikeGrogan, Hallelujah! I Am Flying Again,January,1992, pages 35-39 Harry Senn, Why 1-26’sDon’tFly Sports Class,February,1992, pages 39-41 Luan & John Walker, 1992 1-26 Championships (Midlothian, TX),January,1993, pages 40-44 Joe Walter, What a Contest (the 1-26 Championships),October,1993, page 3 Jim Hard, (1993) 1-26 Championships at Albert Lea, Minnesota,November,1993, pages 19-25 TomHolloran, GPS: The First Year-Almost,November,1993, pages 26, 28-30 1000 Kilometer Flights Robert Penn, Sixteen Contestants Fly 1000 KilometersinPossible World RecordContest Task,No- vember,1990, page 15 YanWhytlaw, The 1000 KM Club,March, 1992, pages 20-23 KenKochanski, The Joy of Soaring (1000KM from Blairstown by Bob Templin and Ken Kochanski)!, September,1992, page 6 Sterling V.Starr, 1000KM in the Sky! (Over the Sierraand White Mountains),March, 1993, pages 42-45 Advertising Mark Kennedy, Soaring in Action: Please Note! (No) July Classified Ads,June, 1997, page 14 Convenience and Savings (with Soaring Classifieds),October,1997, page 4 Aerobatics Wade Nelson, An Aerobatic Ride at Estrella,January,1990, page 3 Trish Durbin, Cat Among the Pigeons,February,1990, page 20 Bob Kupps, The ThirdWorld Glider Aerobatic Championships (Hockenheim),March, 1990, page 15 Trish Durbin, Author’sResponse (to "Cat Among the Pigeons" Complaints),July,1990, page 2 Thomas J.
    [Show full text]
  • The Flightline
    The Flightline The Flightline Volume 30,Issue 8 Newsletter of the Propstoppers RC Club AMA 1042 August 2000 scale models fly within sight for fifteen minutes and land Editorial - Park Flyers on their wheels. And I did see Class C gas ships auger to the heavens then float for seemingly hours within sight of Park flyers, they are everywhere, what are the launch point. Lost Hills is owned by the National Free Flight they and why are they so popular? Society and is six hundred acres of absolutely flat Most of us started in this hobby many years featureless land devoid of any vegetation. The nearest features are the Coastal Range of mountains twenty miles ago when the entry-level model was probably a rubber West ………………..But I digress.) powered free flight model from a kit. Enough of them flew just long enough to catch our imagination and In the Olde Days we never had it that good so we draw us into more complicated models. sought ways to fly our dreams in smaller fields. That Perhaps we were drawn to powered models but in the early days that meant either control line or meant the aforementioned control line models or Radio Control. While I flew control line team race and stunt in free flight. England the cry from my cohorts flying in the adjacent field Free flight has enormous charm as it melds our building and trimming skills with the broad was “is that radio controlled?” “No it is just naturally unstable”. capricious sweep of Mother Nature. There is nothing Of course the natural path was the desire for quite like a scale powered free flight model ROG, steady climb and gentle curving glide back to a perfect complete control over our models, so many have followed the path of RC developments, from the first heavy single landing.
    [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]
  • Development of F/A-18 Spin Departure Demonstration Procedure with Departure Resistant Flight Control Computer Version 10.7
    University of Tennessee, Knoxville TRACE: Tennessee Research and Creative Exchange Masters Theses Graduate School 12-2004 Development of F/A-18 Spin Departure Demonstration Procedure with Departure Resistant Flight Control Computer Version 10.7 David J. Park University of Tennessee - Knoxville Follow this and additional works at: https://trace.tennessee.edu/utk_gradthes Part of the Aerospace Engineering Commons Recommended Citation Park, David J., "Development of F/A-18 Spin Departure Demonstration Procedure with Departure Resistant Flight Control Computer Version 10.7. " Master's Thesis, University of Tennessee, 2004. https://trace.tennessee.edu/utk_gradthes/2312 This Thesis is brought to you for free and open access by the Graduate School at TRACE: Tennessee Research and Creative Exchange. It has been accepted for inclusion in Masters Theses by an authorized administrator of TRACE: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. To the Graduate Council: I am submitting herewith a thesis written by David J. Park entitled "Development of F/A-18 Spin Departure Demonstration Procedure with Departure Resistant Flight Control Computer Version 10.7." I have examined the final electronic copy of this thesis for form and content and recommend that it be accepted in partial fulfillment of the equirr ements for the degree of Master of Science, with a major in Aviation Systems. Robert. B. Richards, Major Professor We have read this thesis and recommend its acceptance: Charles T. N. Paludan, Richard J. Ranaudo Accepted for the Council: Carolyn R. Hodges Vice Provost and Dean of the Graduate School (Original signatures are on file with official studentecor r ds.) To the Graduate Council: I am submitting herewith a thesis written by David J.
    [Show full text]
  • Stearman Aerobatics
    ( SFA'OUIFI" OCIOBEF1990 3 AEROBATICS U.S.NAVY Fep ntedlbm: U.S.NAVY PRIMARY FLIGHT TFAINING MANUAL 1 Juy, I945 NAVALAIF TRAINING COMMAND CHIEFOF NAVALAIB PRIMAFYIFAINING o sFA 'OUrFrr'. @TOAEB1990 5 AEROBATICS Import it Regsrdl6 oI sherhd o! not . part.llar manelver lsdecrib€d in th€ lollowlngp!s.i you aE to prc. Youare now !e.dy lor rhar shse in yrlr tEinlnsas a Nav.l dc. only thosemaneuveB d€m6nst6i.d .nd p@scdbedby Aviarlor rowad {hlch you have been lookins loMad wlrh you LndrucrorIn rh2 oda preserr€dby ih€ syllabus keenanricLp,rion, p€rhars nor unmix€dwih 5omeI€€tinqs ot AII .ercb.ric d|l be comDl.r..l !r lad 2,0lr0 f€€r missrvlns.Uk€ manybclore you, 9ou are piobably wondelhg sherhff or nor you can \ak€ i1" ai dre same6me |rboilng Tl ! L nor h.nated .ldtud€ trt .cr!.I .ldtude uider rhedelusionrhanh?maitolasood pilor b hcsktllh aeob.hca $e aE,e'. ol .ou6e. is rhai you qtn be .bl. to "rake ",bu|h? querion$ltbe lnethsornoryouon "h-ue I Yourel€ry b€ll lr sh@ld b. lan.ned snugly.bur mr b Ll" T@ rony c.d?a helore ylo hde (fie ro Ei.t in C r.se, rsh& d ro inrerl€e s h yor les @€m€nis. Ah. simplybea u.e rheyrs'e tanied aky" birthdr entolnenr ol ch4* rh€ shouldq h.66 aerob.rt and r d6n€ ro bercm€ aerbaric expds Tiey 2 Be €@ nor akn in l@kjns lor dhq airEft in your nesleded rh€ prc.kion ert iirrodlc€d i.
    [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]