DOCSLIB.ORG

Mobile Open Source Economic Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Mobile Open Source Economic Analysis Mobile Open Source Economic Analysis LiMo Foundation White Paper August 2009 ™ ™ White Paper 1 Executive Summary It is possible to use quantitative techniques to examine a number of the proposed economic benefits of open source software. The claimed benefits are a reduction in cost of acquisition, access to innovation and cost of ownership of software technology. The quantitative techniques we use to conduct our analysis are based on measuring source lines of code (SLOC) applied to publicly accessible open source project repositories. To aid our analysis, we have developed a command line tool to mine information on open source projects using the ohloh1 web service. Based on this analysis, Based on this analysis, there is a strong case for constructive engagement with there is a strong case for open source communities where the corresponding open source software constructive engagement components are used within a collaboratively developed, open mobile software with open source platform such as the LiMo Platform™. communities... There is additionally a case for mobile software platform providers to consider using certain strategic open source projects as the basis for development of new functionality on their roadmap. There is no proven case within this analysis for converting existing proprietary items already within a mobile software platform to open source. To conduct a cost-benefit analysis of that scenario would require examination of more factors than SLOC alone. 1http://www.ohloh.net ™ White Paper 1 1. Introduction The subject of open source is increasingly important in relation to mobile device platforms and in view of this, it is vital to understand the underlying economic factors driving the use of open source software in a mobile context. This paper seeks to move beyond opinion-based debate, by identifying the economic case for open mobile platforms to acknowledge and embrace their use of open source software and to actively contribute back changes to open source components modified or adapted within their platform. This white paper attempts to quantify and corroborate the benefits of using open Moving away from source software in mobile platforms in relation to key components which opinion-based lie below the mobile commodity line. This line, for our purposes, lies approximately conjecture towards around the UI framework level of a typical mobile software stack. Components data-based analysis below the line are considered for this analysis to be commodity software. Above the line lies the domain of differentiation. The approach we use involves applying economic cost-benefit analysis techniques where applicable in addition to citing relevant authoritative peer-reviewed material. The following areas of claimed benefit have been analysed in relation to open source mobile software components around or below the commodity line: • Reduced cost of software acquisition • Access to software innovation • Reduced cost of software ownership The analysis of this last area involves trying to quantify the cost to a mobile platform provider of failing to engage with upstream changes. ™ White Paper 2 2. Adopting open source to reduce the cost of software acquisition 2.1 The COCOMO model The claim that adopting existing open source technology reduces the cost of software acquisition can be measured using the COnstructive COst MOdel2 (COCOMO) developed in 19813 The COCOMO Model, by Dr Barry Boehm4, Emeritus Professor of Software Engineering at UCSC and developed at USC a leading software engineering academic. COCOMO has since evolved into an and based on industry standard5 with respect to software cost metrics. The model computes the measurement of SLOC, cost of software development as a function of the total source lines of code (SLOC) is widely used of the corresponding components. for estimating COCOMO has been significantly refined since its inception to reflect the software costs. intervening changes in software development methodology and techniques, in particular to acknowledge more iterative approaches which better reflect modern development. The latest version of the model, COCOMO II, contains a number of further adjusting factors and according to the UCSC Center for Systems and Software Engineering: “This new, improved COCOMO is now ready to assist professional software cost estimators for many years to come”6. The approach taken by COCOMO II is twofold. First, a hierarchy of three different cost models (organic, semi- detached and embedded) is introduced which is designed to take into account the overhead of development depending on the type of project being analysed. Secondly, COCOMO combines the cost model with suitable annualized engineer cost/productivity figure to yield the equivalent cost of development within a typical software engineering context. These elements combine in a single regression function as follows: Effort Applied = a(KLOC)b [man-months7] Development Time = c(Effort Applied)d [months] People required = Effort Applied / Development Time [count] 2http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html 3Barry Boehm. Software engineering economics. Englewood Cliffs, NJ: Prentice-Hall, 1981. 4http://sunset.usc.edu/Research_Group/barry.html 5See US Govt Dept of Defense SoftwareTech estimation site: https://www.thedacs.com/databases/url/key/4 6http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html 7http://www.amazon.com/Mythical-Month-Essays-Software-Engineering/dp/0201835959 ™ White Paper 3 The coefficients in this function vary according to the project type thus: Software project a b c d Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32 (source: Software Cost Estimation With Cocomo II) More detailed information on the COCOMO coefficients is available elsewhere8. For our purposes, COCOMO data can be viewed as a recognized and respectable starting point to begin an empirical examination of the potential benefits that open source offers for mobile platform providers in terms of the cost of software acquisition, access to innovation and cost of software ownership. 2.2 The application of COCOMO to open source software The applicability of COCOMO models to open source software was introduced in an influential and well-regarded economic analysis, “Why Open Source? Look At the Numbers!” written by D. Wheeler in 20029 (and updated regularly since), which remains a widely cited10 paper in relation to the economics We used a loaded cost of of Linux. The Linux Foundation commissioned some research11 in Oct 2008 $75,000 per engineer per updating Wheeler’s work. For the first calculation, they used the basic (i.e. “organic annum – the same figure used project”) COCOMO model applied to Fedora 9. Their choice of annualized salary by the Linux Foundation when figure was justified as follows: they updated Wheeler’s work. “To calculate the costs for these distributions, a base salary was found for computer programmers from the US Bureau of Labor Statistics. According to the BLS, the average salary for a US programmer in July, 2008 was $75,662.0810. This was the salary amount used in our SLOC Count run … the programmer making the average US salary figure of $75,662.08 is actually costing the employer $97,604.08 in compensation alone. This is just one piece of the total wrap pie.” 8http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922 9http://www.dwheeler.com/oss_fs_why.html 10For example: http://abstract.cs.washington.edu/wiki/index.php/Open_Source_and_Search, 11http://www.linuxfoundation.org/publications/estimatinglinux.php ™ White Paper 4 Combining these factors and applying them to the Fedora 9 source base, the research calculated an equivalent development cost of $10.78 billion for 204.5 million source lines of code (or SLOC) or in other words, $52/SLOC for its development up to the current state. Table 1 shows the COCOMO figures taken from this paper and how they were arrived at by using the coefficients for an organic project. Total Physical Source Lines of Code (SLOC) 204,500,946 Development Effort Estimate, Person-Years (Person-Months) 59389.53 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) (712674.36) Schedule Estimate, Years (Months) 24.64 (295.68) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Total Estimated Cost to Develop $10,784,484,309 (average salary = $75,662.08/year, overhead = 2.40). Table 1: SLOC and estimated production values for Fedora 9 (source: Linux Foundation) For the Fedora 9 Linux kernel itself, the paper acknowledges that the “organic project” COCOMO model is not appropriate since: “the Linux kernel code is typically more complex than an “average” application—among other things—it requires an analysis that goes beyond the basic COCOMO model. A user space application like Mozilla, for instance, is much easier to code line by line since it’s abstracted at a much higher level and has to handle far less tasks. A modern and enterprise-class operating system kernel is asked to do a great number of extremely complex things, all at once.” The paper moves on to indicate that an adjusted version of the organic project model is used which takes in the exponent value from the semi-detached project model instead. The result of this is an upwards revision of the equivalent cost of development of the 2.6.25 Linux kernel of $1.32 billion for 6.772 million SLOC or $202/SLOC for its development up to the current state. Table 2 shows the corresponding figures from the paper which details the use of adjusted COCOMO coefficients: Total Physical Source Lines of Code (SLOC) 6,772,902 Development Effort Estimate, Person-Years (Person-Months)\ 7557.4 (90688.77) (effort model Person-Months = 4.64607 * (KSLOC**1.12)) Schedule Estimate, Years (Months) 15.95 (191.34) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) 473.96 Total Estimated Cost to Develop $1,372,340,206 (average salary = $75,662.08/year, overhead = 2.40).
Load more

Recommended publications
  • 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]
  • Attachment A
    Board of Governors, State University System of Florida Request to Offer a New Degree Program (Please do not revise this proposal format without prior approval from Board staff) University of West Florida Fall 2018 University Submitting Proposal Proposed Implementation Term Hal Marcus College of Science and Engineering Computer Science Name of College(s) or School(s) Name of Department(s)/ Division(s) Bachelor of Science in Computer Computer Science Science Academic Specialty or Field Complete Name of Degree 11.0701 Proposed CIP Code The submission of this proposal constitutes a commitment by the university that, if the proposal is approved, the necessary financial resources and the criteria for establishing new programs have been met prior to the initiation of the program. Date Approved by the University Board of President Date Trustees Signature of Chair, Board of Date Provost and Senior Vice Date Trustees President Provide headcount (HC) and full-time equivalent (FTE) student estimates of majors for Years 1 through 5. HC and FTE estimates should be identical to those in Table 1 in Appendix A. Indicate the program costs for the first and the fifth years of implementation as shown in the appropriate columns in Table 2 in Appendix A. Calculate an Educational and General (E&G) cost per FTE for Years 1 and 5 (Total E&G divided by FTE). Projected Implementation Projected Program Costs Enrollment Timeframe (From Table 2) (From Table 1) E&G Contract E&G Auxiliary Total HC FTE Cost per & Grants Funds Funds Cost FTE Funds Year 1 150 96.87 3,241 313,960 0 0 313,960 Year 2 150 96.87 Year 3 160 103.33 Year 4 160 103.33 Year 5 170 109.79 3,426 376,087 0 0 376,087 1 Note: This outline and the questions pertaining to each section must be reproduced within the body of the proposal to ensure that all sections have been satisfactorily addressed.
    [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]
  • 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]
  • Problems and Alternative Approaches Expanding the Scope of Software
    Expanding the Scope of Software Product Families: Problems and Alternative Approaches Jan Bosch VP, Head of Software and Application Technologies Laboratory Nokia Research Center Helsinki, Finland [email protected] © 2006 Nokia QoSA/CBSE 2006/ June 2006 Some background • Nokia Research Center since fall 2004 • Professor and Head of Software Engineering group at University of Groningen, The Netherlands - earlier head of RISE research group @ Blekinge Institute of Technology, Sweden. • Collaboration through research and consulting with, among others, Philips, Bosch, Thales, Baan, Avaya, Ericsson, etc. • Working IEEE/IFIP Conference on Software Architecture series, programme chair (2002), general chair (2004), steering committee member • Software Product Line Conference series • EU and ITEA projects, e.g. SeCSE (Service Centric Software Engineering) © 2006 Nokia QoSA/CBSE 2006/ June 2006 Overview • Introduction • Nokia and Nokia Research Center • Trends in Software • Platforms for Nokia Mobile Devices • Problems and Challenges • Alternative approaches • Conclusions © 2006 Nokia QoSA/CBSE 2006/ June 2006 R&D in Nokia • Global network with R&D centers in 11 countries • Over 20,882 people in R&D at the end of 2005 • R&D personnel represents 36% of Nokia’s total workforce • Nokia’s R&D expenditure totaled EUR 3,825 million in 2005 (11.2% of net sales) All figures are from Dec, 2005 © 2006 Nokia QoSA/CBSE 2006/ June 2006 Nokia Research Center – world-class expertise • Founded in 1986 • 1,097 employees at the end of 2005, or 5% of Nokia’s R&D
    [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]
  • Pweb Peer-To-Peer Web Hosting Communication System and Dynamic Web Hosting
    pWeb Peer-to-Peer Web Hosting Communication System and Dynamic Web Hosting Alexander Pokluda1, Abdalla Aartail2, Md. Faizul Bari1, Reaz Ahmed1, and Raouf Boutaba1 1David R. Cheriton School of Computer Science University of Waterloo [apokluda | mfbari | r5ahmed | rboutaba]@uwaterloo.ca 2American University of Beirut [email protected] University of Waterloo Technical Report: CS-2013-15∗ ∗This report is a modified version of an internal technical report produced for Orange Labs, the project's sponsor. The original technical report was submitted to Orange Labs in August 2013. Abstract During the main phase of this project we identified and provided solution for the major challenges related to peer-to-peer (P2P) web hosting. More specifically, our solutions for naming, availability, ranking, indexing and dynamic web-hosting have been provided in previous reports. In this report we present a more concrete view of the pWeb infrastructure and address the issues related to a real-life deployment of the system. First we provide an overview of the light-weight P2P communication protocol between pWeb clients for signaling and media streaming in Part I. In Part II we provide an architectural overview of pWeb system and show the mapping of the abstract components in pWeb architec- ture to real life devices and technologies. In order to make pWeb compatible with the existing Web technology we have developed a DNS gateway. In Part II Section 3, we provide the design and implementation of this DNS gateway. For efficient indexing and fast discovery of end-user devices and multimedia content, we have developed a cloud-based solution for crawling, indexing and searching.
    [Show full text]
  • Empirical Software Engineering at Microsoft Research
    Software Productivity Decoded How Data Science helps to Achieve More Thomas Zimmermann, Microsoft Research, USA © Microsoft Corporation © Microsoft Corporation What makes software engineering research at Microsoft unique? Easy access to industrial problems and data Easy access to engineers Near term impact Collaborations with Microsoft researchers Collaborations with external researchers © Microsoft Corporation Product group engagement © Microsoft Corporation What metrics are the If I increase test coverage, will that best predictors of failures? actually increase software quality? What is the data quality level Are there any metrics that are indicators of used in empirical studies and failures in both Open Source and Commercial how much does it actually domains? matter? I just submitted a bug report. Will it be fixed? Should I be writing unit tests in my software How can I tell if a piece of software will have vulnerabilities? project? Is strong code ownership good or Do cross-cutting concerns bad for software quality? cause defects? Does Distributed/Global software Does Test Driven Development (TDD) development affect quality? produce better code in shorter time? © Microsoft Corporation Data Science Productivity © Microsoft Corporation Data Science © Microsoft Corporation Use of data, analysis, and systematic reasoning to [inform and] make decisions 17 © Microsoft Corporation Web analytics (Slide by Ray Buse) © Microsoft Corporation Game analytics Halo heat maps Free to play © Microsoft Corporation Usage analytics Improving the File Explorer for Windows 8 Explorer in Windows 7 Alex Simons: Improvements in Windows Explorer. http://blogs.msdn.com/b/b8/archive/2011/08/29 /improvements-in-windows-explorer.aspx © Microsoft Corporation Trinity of software analytics Dongmei Zhang, Shi Han, Yingnong Dang, Jian-Guang Lou, Haidong Zhang, Tao Xie: Software Analytics in Practice.
    [Show full text]
  • Final Report
    Team 4 - Rescue Drone Final Report Members Alexandra Borgesen [email protected] Peter Burchell [email protected] Cody Campbell [email protected] Shawn Cho [email protected] Sarah Hood [email protected] Halil Yonter [email protected] Sponsor Mr. David F. Merrick Faculty Advisor Dr. Rodney Roberts Instructor Dr. Jerris Hooker Reviewers Dr. Bruce Harvey Dr. Simon Foo 04/21/2017 Team 4 Final Report Rescue Drone Executive Summary UAVs used by Florida State University’s Emergency Management and Homeland Security Program can autonomously scan an area, but will provide no feedback regarding image contents, nor do they have a user-friendly interface for interprocess communication. The multidisciplinary ECE Senior Design Team #4 was tasked with creating a new, unique UAV capable of scanning disaster zones and identifying unique objects of interest. Careful research and planning has led to an innovative flight control architecture. The final product features a powerful onboard computer capable of live image processing for object detection, with distinct algorithms for color filtering and pedestrian tracking. A conversion algorithm was also implemented for converting the UAV’s latitude and longitude data, which is read from the flight control hardware, into USNG format. An IP network governs all communication between the ground station and the UAV. In the pursuit of increasing autonomy and implementing computer vision, a reliable and consistent object detection remains integral to accomplishing this task. By analyzing an image in search of HSV values that satisfy a predetermined range of color, any region of pixels that comply with the given range is highlighted using the color filtering algorithm.
    [Show full text]
  • Investigating the Applicability of Software Metrics and Technical Debt on X++ Abstract Syntax Tree in XML Format – Calculations Using Xquery Expressions
    Linköping University | Department of Computer and Information Science Master’s thesis, 30 ECTS | Datateknik 202019 | LIU-IDA/LITH-EX-A--2019/101--SE Investigating the applicability of Software Metrics and Technical Debt on X++ Abstract Syntax Tree in XML format – calculations using XQuery expressions Tillämpning av mjukvarumetri och tekniska skulder från en XML representation av abstrakta syntaxträd för X++ kodprogram David Tran Supervisor : Jonas Wallgren Examiner : Martin Sjölund External supervisor : Laurent Ricci Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt Detta dokument hålls tillgängligt på Internet ‐ eller dess framtida ersättare ‐ under 25 år frånpublicer‐ ingsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstakako‐ pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis‐ ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. Allannan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker‐ heten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman‐ nens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/. Copyright The publishers will keep this document online on the Internet ‐ or its possible replacement ‐ for a period of 25 years starting from the date of publication barring exceptional circumstances.
    [Show full text]