DOCSLIB.ORG

Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software 2011 OTD Lessons Learned Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software 2011-05-16 Sponsored by the Assistant Secretary of Defense (Networks & Information Integration) (NII) / DoD Chief Information Officer (CIO) and the Under Secretary of Defense for Acquisition, Technology, and Logistics (AT&L) This document is released under the Creative Commons Attribution ShareAlike 3.0 (CC- BY-SA) License. You are free to share (to copy, distribute and transmit the work) and to remix (to adapt the work), under the condition of attribution (you must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work)). For more information, see http://creativecommons.org/licenses/by/3.0/ . The U.S. government has unlimited rights to this document per DFARS 252.227-7013. Portions of this document were originally published in the Software Tech News, Vol.14, No.1, January 2011. See https://softwaretechnews.thedacs.com/ for more information. Version - 1.0 2 2011 OTD Lessons Learned Table of Contents Chapter 1. Introduction........................................................................................................................... 1 1.1 Software is a Renewable Military Resource ................................................................................ 1 1.2 What is Open Technology Development (OTD) ......................................................................... 3 1.3 Off-the-shelf (OTS) Software Development Approaches, including Open Government OTS (OGOTS) and Open Source Software (OSS).......................................................................................... 4 1.4 Key Prerequisites for OTD........................................................................................................... 6 1.4.1 Intellectual Rights ................................................................................................................. 6 1.4.2 Simplicity.............................................................................................................................. 7 Chapter 2. Running OTD Projects.......................................................................................................... 8 2.1 Establishing an OTD Program ..................................................................................................... 8 2.1.1 Step 1: Determine reuse options ........................................................................................... 8 2.1.2 Step 2: Identify the Projects to be Established...................................................................... 8 2.1.3 Step 3: Choose and Apply a Common License .................................................................... 9 2.1.4 Step 4: Establish Governance ............................................................................................. 10 2.1.4.1 Forkability ................................................................................................................... 10 2.1.4.2 Governance Models..................................................................................................... 10 2.1.5 Step 5: Establish Collaboration........................................................................................... 11 2.1.6 Step 6: Create Project Technical Direction......................................................................... 12 2.1.7 Step 7: Announcing............................................................................................................. 12 2.1.8 Continuously Review Steps 1-7.......................................................................................... 13 2.2 Technical Infrastructure for Collaboration................................................................................. 13 2.2.1 Key Functions ..................................................................................................................... 13 2.2.2 Public access, classification, and export control................................................................. 14 2.2.3 Hosting................................................................................................................................ 15 2.3 Communication .......................................................................................................................... 16 2.3.1 Be Inclusive ........................................................................................................................ 16 2.3.2 Avoid Private Discussions .................................................................................................. 17 2.3.3 Use Communication Mechanisms Effectively.................................................................... 17 2.3.4 Practice Conspicuous Code Review ................................................................................... 17 2.3.5 Nip Rudeness in the Bud..................................................................................................... 17 2.3.6 Counter Poisonous People .................................................................................................. 18 2.3.7 Be Aware of Roles.............................................................................................................. 18 2.4 Technical Management/Technical Criteria ................................................................................ 18 2.4.1 Goals ................................................................................................................................... 18 2.4.2 Reuse and Collaborate on OTD components...................................................................... 19 2.4.3 Don’t Fork OSS Solely for Government Use ..................................................................... 19 2.4.4 Open Standards ................................................................................................................... 20 2.4.5 Managing Contributions ..................................................................................................... 21 2.5 Continuous Delivery .................................................................................................................. 21 2.5.1 Managing Intellectual Rights.............................................................................................. 21 Chapter 3. OTD Programmatics: Tactics, Tools & Procedures ........................................................... 23 3.1 Initiation and/or Transition to OTD ........................................................................................... 23 3.1.1 Analysis of Alternatives (AoA) .......................................................................................... 23 3.1.2 Request for Information (RFI)............................................................................................ 24 4 2011 OTD Lessons Learned 3.2 Request for Proposal (RFP) ....................................................................................................... 25 3.2.1 Statement of Objectives (SOO) & Intent............................................................................ 26 3.2.2 Intellectual Rights ............................................................................................................... 26 3.2.3 Data Formats, Standards & Interfaces ................................................................................ 27 3.2.4 Off-the-Shelf (OTS) Technologies ..................................................................................... 27 3.2.5 Open Technology Development Practices.......................................................................... 27 3.2.6 Deliverables ........................................................................................................................ 28 3.3 Source Selection: Evaluating Proposals..................................................................................... 29 3.3.1 Evaluate how well proposal responds to RFP..................................................................... 29 3.3.2 Acceptance/Approval Criteria for Deliverables.................................................................. 29 3.3.3 Pitfalls to avoid ................................................................................................................... 30 Chapter 4. Continuous Development & Delivery ................................................................................ 31 4.1 Rapid Development Cycles........................................................................................................ 31 4.2 Testing, Certification and Accreditation .................................................................................... 31 4.3 Transition to Operations & Maintenance................................................................................... 32 4.4 Findability .................................................................................................................................. 32 4.5 Lessons Learned......................................................................................................................... 33 4.6 OTD Success Checklist.............................................................................................................. 33 Appendix A: U.S. Government Policy & Guidance on Openness ........................................................... 35 A.1 Open Standards and Interfaces (including open data formats) .................................................. 36 A.1.1
Load more

Recommended publications
  • Common Tools for Team Collaboration Problem: Working with a Team (Especially Remotely) Can Be Difficult
    Common Tools for Team Collaboration Problem: Working with a team (especially remotely) can be difficult. ▹ Team members might have a different idea for the project ▹ Two or more team members could end up doing the same work ▹ Or a few team members have nothing to do Solutions: A combination of few tools. ▹ Communication channels ▹ Wikis ▹ Task manager ▹ Version Control ￭ We’ll be going in depth with this one! Important! The tools are only as good as your team uses them. Make sure all of your team members agree on what tools to use, and train them thoroughly! Communication Channels Purpose: Communication channels provide a way to have team members remotely communicate with one another. Ideally, the channel will attempt to emulate, as closely as possible, what communication would be like if all of your team members were in the same office. Wait, why not email? ▹ No voice support ￭ Text alone is not a sufficient form of communication ▹ Too slow, no obvious support for notifications ▹ Lack of flexibility in grouping people Tools: ▹ Discord ￭ discordapp.com ▹ Slack ￭ slack.com ▹ Riot.im ￭ about.riot.im Discord: Originally used for voice-chat for gaming, Discord provides: ▹ Voice & video conferencing ▹ Text communication, separated by channels ▹ File-sharing ▹ Private communications ▹ A mobile, web, and desktop app Slack: A business-oriented text communication that also supports: ▹ Everything Discord does, plus... ▹ Threaded conversations Riot.im: A self-hosted, open-source alternative to Slack Wikis Purpose: Professionally used as a collaborative game design document, a wiki is a synchronized documentation tool that retains a thorough history of changes that occured on each page.
    [Show full text]
  • Going from Python to Guile Scheme a Natural Progression
    Going from Python to Guile Scheme A natural progression Arne Babenhauserheide February 28, 2015 Abstract After 6 years of intense Python-Programming, I am starting into Guile Scheme. And against all my expec- tations, I feel at home. 1 2 The title image is built on Green Tree Python from Michael Gil, licensed under the creativecommons attribution license, and Guile GNU Goatee from Martin Grabmüller, Licensed under GPLv3 or later. This book is licensed as copyleft free culture under the GPLv3 or later. Except for the title image, it is copyright (c) 2014 Arne Babenhauserheide. Contents Contents 3 I My story 7 II Python 11 1 The Strengths of Python 13 1.1 Pseudocode which runs . 13 1.2 One way to do it . 14 1.3 Hackable, but painfully . 15 1.4 Batteries and Bindings . 17 1.5 Scales up . 17 2 Limitations of Python 19 2.1 The warped mind . 19 2.2 Templates condemn a language . 20 3 4 CONTENTS 2.3 Python syntax reached its limits . 21 2.4 Time to free myself . 23 IIIGuile Scheme 25 3 But the (parens)! 29 4 Summary 33 5 Comparing Guile Scheme to the Strengths of Python 35 5.1 Pseudocode . 36 General Pseudocode . 36 Consistency . 37 Pseudocode with loops . 40 Summary . 44 5.2 One way to do it? . 44 5.3 Planned Hackablility, but hard to discover. 50 Accessing variables inside modules . 51 Runtime Self-Introspection . 51 freedom: changing the syntax is the same as reg- ular programming . 58 Discovering starting points for hacking . 60 5.4 Batteries and Bindings: FFI .
    [Show full text]
  • Návrh a Implementace Rozšíření Do Systému Phabricator
    Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Masarykova univerzita Fakulta informatiky Návrh a implementace rozšíření do systému Phabricator Diplomová práce Lukáš Jagoš Brno, podzim 2019 Na tomto místě se v tištěné práci nachází oficiální podepsané zadání práce a prohlášení autora školního díla. Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Lukáš Jagoš Vedoucí práce: Martin Komenda i Poděkování Srdečně chci na tomto místě poděkovat vedoucímu mé diplomové práce RNDr. Martinu Komendovi, Ph.D. za cenné náměty a odborné vedení. Dále chci poděkovat Mgr. Matěji Karolyi za všestrannou po- moc při implementaci praktické části práce a Ing. Mgr. Janu Krejčímu za zpřístupnění testovacího serveru a technickou podporu. iii Shrnutí Diplomová práce se zabývá nástroji pro projektové řízení. V teore- tické části jsou vymezeny pojmy projekt a projektové řízení. Poté jsou představeny vybrané softwarové nástroje pro projektové řízení a je provedeno jejich srovnání. Pozornost je zaměřena na systém Phabrica- tor, který je v práci detailně popsán. V praktické části je navrženo rozšíření Phabricatoru na základě analýzy potřeb a sběru požadavků. Výsledkem je rozšířující modul po- skytující přehledné informace o úkolech z pohledu času a náročnosti, čímž zefektivní jejich plánování a proces týmové spolupráce. iv Klíčová slova projektové řízení, Phabricator, PHP, reportovací modul, SCRUM v Obsah 1 Projektové řízení 3 1.1 Projekt a projektové řízení ..................3 1.2 SW nástroje pro projektové řízení ...............4 1.3 Přehled nástrojů z oblasti řízení projektů ...........6 1.3.1 Phabricator .
    [Show full text]
  • Accelerate Your Mobile Apps for Android On
    The Developer Summit at ARM® TechCon™ 2013 Accelerate your Mobile Apps and Games for Android™ on ARM Matthew Du Puy! Software Engineer, ARM The Developer Summit at ARM® TechCon™ 2013 Presenter Matthew Du Puy! Software Engineer, ARM! ! Matthew Du Puy is a software engineer at ARM and is currently working to ensuring mobile app performance on the latest ARM technologies. Previously a self employed embedded systems software contractor working primarily on the Linux Kernel and a mountain climber.! ! Contact Details: ! Email: [email protected] Title: Accelerate Your Mobile Apps and Games for Android on ARM Overview: Learn to perform Android application and systems level analysis on Android apps and platforms using tools from Google, ARM, AT&T and others. Find bottlenecks in both SDK and NDK activities and learn different approaches to fixing those bottlenecks and better utilize platform technologies and APIs. Problem: This is not a desktop ▪ Mobile apps require special design considerations that aren’t always clear and tools to solve increasingly complex systems are limited! ▪ Animations and games drop frames! ▪ Networking, display, real time audio and video processing eat battery! ▪ App won’t fit in memory constraints Analysis ▪ Fortunately Google, ARM and many others are developing analysis tools and solutions to these problems! ▪ Is my app … ?! ▪ CPU/GPGPU bound! ▪ I/O or memory constrained! ▪ Power efficient! ▪ What can I do to fix it?# (short of buying everyone who runs my app# a Quad-core ARM® Cortex™-A15 processor # & ARM Mali™-T604 processor or Octo phone) In emerging markets, not everyone has access to the latest and greatest devices but they still want to game, shop, socialize and learn with their mobiles.
    [Show full text]
  • Project Management Software March 2019
    PROJECT MANAGEMENT SOFTWARE MARCH 2019 Powered by Methodology CONTENTS 3 Introduction 5 Defining Project Management Software 6 FrontRunners (Small Vendors) 8 FrontRunners (Enterprise Vendors) 10 Runners Up 22 Methodology Basics 2 INTRODUCTION his FrontRunners analysis minimum qualifying score of 3.96 Tis a data-driven assessment for Usability and 3.91 for User identifying products in the Project Recommended, while the Small Management software market that Vendor graphic had a minimum offer the best capability and value qualifying score of 4.55 for Usability for small businesses. For a given and 4.38 for User Recommended. market, products are evaluated and given a score for Usability (x-axis) To be considered for the Project and User Recommended (y-axis). Management FrontRunners, a FrontRunners then plots 10-15 product needed a minimum of 20 products each on a Small Vendor user reviews published within 18 and an Enterprise Vendor graphic, months of the evaluation period. based on vendor business size, per Products needed a minimum user category. rating score of 3.0 for both Usability and User Recommended in both In the Project Management the Small and Enterprise graphics. FrontRunners infographic, the Enterprise Vendor graphic had a 3 INTRODUCTION The minimum score cutoff to be included in the FrontRunners graphic varies by category, depending on the range of scores in each category. No product with a score less than 3.0 in either dimension is included in any FrontRunners graphic. For products included, the Usability and User Recommended scores determine their positions on the FrontRunners graphic. 4 DEFINING PROJECT MANAGEMENT SOFTWARE roject management software and document management, as well Phelps organizations manage as at least one of the following: time and deliver projects on time, on tracking, budgeting, and resource budget and within scope.
    [Show full text]
  • A Wiki-Based Authoring Tool for Collaborative Development of Multimedial Documents
    MEDIA2MULT – A WIKI-BASED AUTHORING TOOL FOR COLLABORATIVE DEVELOPMENT OF MULTIMEDIAL DOCUMENTS Author Name * Affiliation * Address * Author Name * Affiliation * Address * * Only for Final Camera-Ready Submission ABSTRACT media2mult is an extension for PmWiki developed at our university. It provides functionality for embedding various media files and script languages in wiki pages. Furthermore media2mult comes with a cross media publishing component that allows to convert arbitrary wiki page sequences to print-oriented formats like PDF. This article gives an overview over the offered extensions, their functionality and implementation concepts. KEYWORDS wiki, multimedia, cross-media-publishing, authoring tool, XML 1. INTRODUCTION At least since the founding of the free web encyclopedia Wikipedia and its increasing popularity wiki web , wiki-wiki or just wiki are widely known terms in context of Web 2.0. However, their exact meaning often remains unclear. Sometimes wiki and Wikipedia are actually used synonymously. The crucial functionality of every wiki system is the possibility to edit wiki web pages directly inside a browser by entering an easy to learn markup language. Thus, manual uploads of previously edited HTML files are superfluous here. The user doesn't even have to know anything about HTML or external HTML editors. The browser- and server-based concept makes it possible that several authors can edit and revise common documents without the necessity of exchanging independently written and updated versions. Because most wiki systems offer an integrated version management system, authors can easily merge their changes and revert selected passages to former stages. Thus, accidentally or deliberately applied changes of protected or publicly accessible wiki pages can be taken back in a second.
    [Show full text]
  • The Opendaylight Open Source Project
    UNIVERSIDAD REY JUAN CARLOS Master´ Universitario en Software Libre Curso Academico´ 2014/2015 Proyecto Fin de Master´ The OpenDaylight Open Source Project Autor: Sergio Najib Arroutbi Braojos Tutor: Dr. Gregorio Robles 2 Agradecimientos A mi familia y a mi pareja, por su apoyo incondicional Al equipo de Libresoft de la Universidad Rey Juan Carlos, por su afan´ en ensenar˜ el que´ y el porque´ del Software Libre Dedicatoria Para todos aquellos´ que hacen posible el fenomeno´ del Software Libre 4 (C) 2014 Sergio Najib Arroutbi Braojos. Some rights reserved. This document is distributed under the Creative Commons Attribution-ShareAlike 3.0 license, available in http://creativecommons.org/licenses/by-sa/3.0/ Source files for this document are available at http://github.com/sarroutbi/MFP/opendaylight/ 6 Contents 1 Introduction 19 1.1 Terminology.................................... 19 1.1.1 Open Source Programmable Networking................ 19 1.2 About this document............................... 20 1.2.1 Document structure............................ 20 1.2.2 Scope................................... 21 1.2.3 Methodology............................... 21 2 Goals and Objectives 23 2.1 General Objectives................................ 23 2.2 Subobjectives................................... 23 2.2.1 Acquire competence on OpenDaylight project.............. 23 2.2.2 Analyze OpenDaylight project from an Open Source perspective.... 24 2.2.3 Statistics and measures of the OpenDaylight project.......... 24 3 OpenDaylight: A first view 25 3.1 OpenDaylight Project............................... 25 3.2 SDN........................................ 29 3.2.1 What is SDN?.............................. 29 3.2.2 SDN: Market share and expectations................... 31 3.3 NFV........................................ 34 3.3.1 What is NFV?.............................. 35 3.3.2 SDN/NFV relationship.......................... 36 3.3.3 NFV benefits..............................
    [Show full text]
  • Onapp Admin Guide
    2.0 Admin Guide 2.0 Admin Guide Contents 0. About This Guide ............................................................................................... 5 1. OnApp Overview ................................................................................................ 6 1.1 Servers ................................................................................................................... 6 1.2 Networks ................................................................................................................ 7 1.3 Templates .............................................................................................................. 8 1.4 Virtual Machines .................................................................................................... 8 1.5 Scalability .............................................................................................................. 8 1.6 Availability and Reliability .................................................................................... 8 1.7 Security .................................................................................................................. 9 1.8 API and Integration ............................................................................................... 9 2. OnApp Hardware & Software Requirements ................................................. 10 2.1 Hypervisor Servers ............................................................................................. 10 2.2 Control Panel Server ..........................................................................................
    [Show full text]
  • Encouragez Les Framabooks !
    Encouragez les Framabooks ! You can use Unglue.it to help to thank the creators for making Histoires et cultures du Libre. Des logiciels partagés aux licences échangées free. The amount is up to you. Click here to thank the creators Sous la direction de : Camille Paloque-Berges, Christophe Masutti Histoires et cultures du Libre Des logiciels partagés aux licences échangées II Framasoft a été créé en novembre 2001 par Alexis Kauffmann. En janvier 2004 une asso- ciation éponyme a vu le jour pour soutenir le développement du réseau. Pour plus d’infor- mation sur Framasoft, consulter http://www.framasoft.org. Se démarquant de l’édition classique, les Framabooks sont dits « livres libres » parce qu’ils sont placés sous une licence qui permet au lecteur de disposer des mêmes libertés qu’un utilisateur de logiciels libres. Les Framabooks s’inscrivent dans cette culture des biens communs qui, à l’instar de Wikipédia, favorise la création, le partage, la diffusion et l’ap- propriation collective de la connaissance. Le projet Framabook est coordonné par Christophe Masutti. Pour plus d’information, consultez http://framabook.org. Copyright 2013 : Camille Paloque-Berges, Christophe Masutti, Framasoft (coll. Framabook) Histoires et cultures du Libre. Des logiciels partagés aux licences échangées est placé sous licence Creative Commons -By (3.0). Édité avec le concours de l’INRIA et Inno3. ISBN : 978-2-9539187-9-3 Prix : 25 euros Dépôt légal : mai 2013, Framasoft (impr. lulu.com, Raleigh, USA) Pingouins : LL de Mars, Licence Art Libre Couverture : création par Nadège Dauvergne, Licence CC-By Mise en page avec LATEX Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution 2.0 France.
    [Show full text]
  • Guide to Open Source Solutions
    White paper ___________________________ Guide to open source solutions “Guide to open source by Smile ” Page 2 PREAMBLE SMILE Smile is a company of engineers specialising in the implementing of open source solutions OM and the integrating of systems relying on open source. Smile is member of APRIL, the C . association for the promotion and defence of free software, Alliance Libre, PLOSS, and PLOSS RA, which are regional cluster associations of free software companies. OSS Smile has 600 throughout the World which makes it the largest company in Europe - specialising in open source. Since approximately 2000, Smile has been actively supervising developments in technology which enables it to discover the most promising open source products, to qualify and assess them so as to offer its clients the most accomplished, robust and sustainable products. SMILE . This approach has led to a range of white papers covering various fields of application: Content management (2004), portals (2005), business intelligence (2006), PHP frameworks (2007), virtualisation (2007), and electronic document management (2008), as well as PGIs/ERPs (2008). Among the works published in 2009, we would also cite “open source VPN’s”, “Firewall open source flow control”, and “Middleware”, within the framework of the WWW “System and Infrastructure” collection. Each of these works presents a selection of best open source solutions for the domain in question, their respective qualities as well as operational feedback. As open source solutions continue to acquire new domains, Smile will be there to help its clients benefit from these in a risk-free way. Smile is present in the European IT landscape as the integration architect of choice to support the largest companies in the adoption of the best open source solutions.
    [Show full text]
  • GNU Stow Manual
    Stow 2.3.1 Managing the installation of software packages Bob Glickstein, Zanshin Software, Inc. Kahlil Hodgson, RMIT University, Australia. Guillaume Morin Adam Spiers This manual describes GNU Stow version 2.3.1 (28 July 2019), a program for managing farms of symbolic links. Software and documentation is copyrighted by the following: c 1993, 1994, 1995, 1996 Bob Glickstein <[email protected]> c 2000, 2001 Guillaume Morin <[email protected]> c 2007 Kahlil (Kal) Hodgson <[email protected]> c 2011 Adam Spiers <[email protected]> Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section enti- tled \GNU General Public License" is included with the modified manual, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. i Table of Contents 1 Introduction::::::::::::::::::::::::::::::::::::: 1 2 Terminology ::::::::::::::::::::::::::::::::::::: 3 3 Invoking Stow ::::::::::::::::::::::::::::::::::: 4 4 Ignore Lists ::::::::::::::::::::::::::::::::::::: 7 4.1 Motivation
    [Show full text]
  • Operating RISC: UNIX Standards in the 1990S
    Operating RISC: UNIX Standards in the 1990s This case was written by Will Mitchell and Paul Kritikos at the University of Michigan. The case is based on public sources. Some figures are based on case-writers' estimates. We appreciate comments from David Girouard, Robert E. Thomas and Michael Wolff. The note "Product Standards and Competitive Advantage" (Mitchell 1992) supplements this case. The latest International Computerquest Corporation analysis of the market for UNIX- based computers landed on three desks on the same morning. Noel Sharp, founder, chief executive officer, chief engineer and chief bottle washer for the Superbly Quick Architecture Workstation Company (SQAWC) in Mountain View, California hoped to see strong growth predicted for the market for systems designed to help architects improve their designs. In New York, Bo Thomas, senior strategist for the UNIX systems division of A Big Computer Company (ABCC), hoped that general commercial markets for UNIX-based computer systems would show strong growth, but feared that the company's traditional mainframe and mini-computer sales would suffer as a result. Airborne in the middle of the Atlantic, Jean-Helmut Morini-Stokes, senior engineer for the UNIX division of European Electronic National Industry (EENI), immediately looked to see if European companies would finally have an impact on the American market for UNIX-based systems. After looking for analysis concerning their own companies, all three managers checked the outlook for the alliances competing to establish a UNIX operating system standard. Although their companies were alike only in being fictional, the three managers faced the same product standards issues. How could they hasten the adoption of a UNIX standard? The market simply would not grow until computer buyers and application software developers could count on operating system stability.
    [Show full text]