DOCSLIB.ORG

Gems of Software Engineering Wisdom 34 Years of IEEE Software History in 1000 Quotes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

  1260
Copy Link
Gems of Software Engineering Wisdom 34 years of IEEE Software history in 1000 quotes Željko Obrenović This book is for sale at http://leanpub.com/se-wisdom This version was published on 2018-03-09 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2018 Željko Obrenović Contents Foreword .................................. 1 1984 .................................... 2 1985 .................................... 16 1986 .................................... 32 1987 .................................... 52 1988 .................................... 78 1989 .................................... 98 1990 .................................... 117 1991 .................................... 140 1992 .................................... 160 1993 .................................... 189 1994 .................................... 214 1995 .................................... 242 1996 .................................... 275 CONTENTS 1997 .................................... 306 1998 .................................... 337 1999 .................................... 378 2000 .................................... 412 2001 .................................... 444 2002 .................................... 477 2003 .................................... 517 2004 .................................... 560 2005 .................................... 608 2006 .................................... 655 2007 .................................... 707 2008 .................................... 762 2009 .................................... 819 2010 .................................... 871 2011 .................................... 925 2012 .................................... 971 2013 ....................................1011 2014 ....................................1072 2015 ....................................1123 2016 ....................................1166 CONTENTS 2017 .................................... 1238 2018 .................................... 1253 Foreword This book contains a selection of 1000 quotes from IEEE Software1. IEEE Software is a leading software engineering magazine with a very rich his- tory. Since 1984, many of the leading software engineering professionals have contributed to IEEE Software. The content is based on the material from the IEEE Software history website2. Visit this site to find more details about IEEE Software and its history. Selected quotes are not intended to serve as a comprehensive overview of the history of software engineering. Rather, the book is designed as a “coffee table book”. It is intended for casual reading, offering interesting, educative, thought-provoking, and sometimes controversial quotes. Zeljko Obrenovic 1https://publications.computer.org/software-magazine/ 2https://obren.info/ieeesw 1984 1984 3 1984 4 “Many of the challenges facing the software industry today are a direct result of our insatiable appetite for new computer-based systems applications. Others confront us simply because we have not managed to successfully solve a large number of problems that we ourselves created many years ago.” Bruce D. Shriver, From the Editor-in-Chief, IEEE Software, January 1984.3 3DOI: 10.1109/MS.1984.233385 1984 5 “There probably isn’t a best way to build the system or even a major part of it. Much more important is to avoid choosing a terrible way and to have a clear division of responsibilities among the parts.” Butler W. Lampson, Hints for Computer System Design, IEEE Software, January 1984.4 4DOI: 10.1109/MS.1984.233391 1984 6 “Designing a computer system is very different from designing an algorithm: … the requirement - is less precisely defined more complex, and more subject to change; the system has much more internal structure - hence, many internal interfaces; and the measure of success is much less clear. The designer usually finds himself flondering in a sea of possibilities, unclear about how one choice will limit his freedom to take other choices or affect the size and performance of the entire-system.” Butler W. Lampson, Hints for Computer System Design, IEEE Software, January 1984.5 5DOI: 10.1109/MS.1984.233391 1984 7 “Booch offers a software design methodology, which he calls ‘object-oriented design’ in contrast to earlier popular methods he designates as either functional or data-oriented. In contrast to suggestions that we either identify a program’s principal function and describe it in the top box in a hierarchy chart or carefully identify the patterns of data and their flows, Booch suggests, ‘Define the problem, develop an informal strategy; formalize the strategy.’” Peter G. Anderson, Review of Grady Booch’s book ‘Software Engineering with Ada’, IEEE Software, January 1984.6 6DOI: 10.1109/MS.1984.233391 1984 8 1984 9 “One does not use structural engineering analysis to build a sandcastle. But neither does one choose the prize-winning builder of sandcastles as architect for a tower block of offices in a city.” Sir Charles Antony Richard Hoare, Programming: Sorcery or Science?, IEEE Software, April 1984.7 7DOI: 10.1109/MS.1984.234042 1984 10 “I believe that in our branch of engineering, above all others, the academic ideals of rigor and elegance will pay the highest dividends in practical terms of reducing costs, increasing performance, and in directing the great sources of computational power on the surface of a silicon chip to the use and convenience of man.” Sir Charles Antony Richard Hoare, Programming: Sorcery or Science?, IEEE Software, April 1984.8 8DOI: 10.1109/MS.1984.234042 1984 11 1984 12 “The greater speed of technical change means that capital investment must be recovered more quickly and that enhancement and evolution consume proportionately more resources than in a slowly changing technology. This contributes to the fact that maintenance and enhancement are the dominant costs in the software life cycle today.” Peter Wegner, Capital-Intensive Software Technology, IEEE Software, July 1984.9 9DOI: 10.1109/MS.1984.234384 1984 13 “Periods of rapid technological change require more innovation and greater risks than periods of stability.” Peter Wegner, Capital-Intensive Software Technology Conclusion, IEEE Software, July 1984.10 10DOI: 10.1109/MS.1984.234706 1984 14 1984 15 “An abstraction is a simplified description, or specification, of a system that emphasizes some of the system’s details or properties while suppressing others. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details that are, at least for the moment immaterial or diversionary.” Mary Shaw, Abstraction Techniques in Modern Programming Languages, IEEE Software, October 1984.11 11DOI: 10.1109/MS.1984.234384 1985 1985 17 1985 18 “The use of formal notation does not, however, preclude that of natural language. In fact, mathematical specification of a problem usually leads to a better natural-language description. This is because formal notations naturally lead the specifier to raise some questions that might have remained unasked, and thus unanswered, in an informal approach.” Bertrand Meyer, On Formalism in Specifications, IEEE Software, January 1985.12 12DOI: 10.1109/MS.1985.229776 1985 19 1985 20 “In essence, programming-in-the large involves the two complementary activities of modularization and interface control. Modularization is the identification of the major system modules and the entities those modules contain, where entities are language elements that are given names, such as subprograms, data objects, and types. Interface control is the specification and control of the interactions among entities in different modules.” Alexander L. Wolf, Lori A. Clarke, Jack C. Wileden, Ada-Based support for programming-in-the-Large, IEEE Software, March 1985.13 13DOI: 10.1109/MS.1985.230352 1985 21 “Engineers may be able to design a better interface if they take into account the control structures underlying the interface syntax.The syntactic, semantic, and protocol aspects of the interface each have their own ‘complexity.’.” T.E. Lindquist, Assessing the Usability of Human-Computer Interfaces, IEEE Software, March 1985.14 14DOI: 10.1109/MS.1985.230052 1985 22 1985 23 “The lack of a complete theoretical basis for distributed computing systems need not inhibit the development of useful systems. Even without such a basis, many technical advances have been made by individuals, who then share them with others, who in turn accept useful concepts and add further innovations.” Stephen F. Lundstrom, Duncan H. Lawrie, Experiences with Distributed Systems, IEEE Software, May 1985.15 15DOI: 10.1109/MS.1985.230692 1985 24 1985 25 “System designers should provide for such practical issues as deadlock avoidance, scheduling, necessary and sufficient primitives to allow for synchronization, and the combination of multiprogramming (a single system dividing its time and resources among many jobs) and multiprocessing (multiple processing units operating on a single job).” Joanne L. Martin, Operating Systems and Environments for Large-Scale Parallel Processors, IEEE Software, July 1985.16 16DOI: 10.1109/MS.1985.231051 1985 26 1985 27 “Program testing consists of scattered collection of rules of thumb, coverage measures, and testing philosophies.” William E. Howden, The Theory and Practice of Foundation Testing, IEEE Software, September 1985.17 17DOI:
Recommended publications
  • Ewsolutions Enterprise Architecture, Data Architecture, Data

    Ewsolutions Enterprise Architecture, Data Architecture, Data

    EWSolutions Enterprise Architecture, Data Architecture, Data Governance, Metadata Management Case Study Leveraging Existing Investments in Systems, Data and Personnel to Improve Logistics and Supply Chain Management for Defense Operations Enterprise architecture planning and development, data architecture, metadata management, data governance, and enterprise data integration combined to ensure the success of the world's largest defense logistics and supply chain. EWSolutions, Inc. 1/25/2017 Developing and Implementing a New Defense Logistics Supply Chain: A Case Study in How EWSolutions Enabled Success for the US Department of Defense The Department of Defense (DoD) is America's oldest and largest government agency. It employs a civilian force of 742,000, along with over 1.3 million men and women on active duty; it is the United State's largest employer. Another 826,000 people serve in the National Guard and Reserve forces. The national security depends on defense installations, people, and facilities being in the right place, at the right time, with the right qualities and capacities to protect the security of the United States and allies. These military service members and civilians operate in every time zone and in every climate. More than 450,000 employees are overseas, both afloat and ashore. This complexity extends to the logistics, communication, and supply chain needed to connect and furnish these employees and dependents with all the required resources (food, clothing, weapons, etc.) The mission of the US Department of Defense is to provide the military forces needed to deter war and to protect the security of the United States. Fulfilling this mission requires a large variety of resources; securing and delivering those resources to the right place at the right time in the right quantities requires accurate information that comes from complete and valid data.
  • Enterprise Architecture

    Enterprise Architecture

    Enterprise Architecture Dr. Adnan Albar Faculty of Computing & Information Technology King AbdulAziz University - Jeddah 1 Enterprise Architecture Methods Lecture 5 Week 5 Slides King AbdulAziz University - FCIT 2 Overview . Description Languages for Business & IT Domains . IDEF . BPMN . Testbed . ARIS . Unified Modeling Language . Service-Oriented Architecture (SOA) Slide 3 Description Languages . In domains such as business process design and software development, we find established description languages for modeling these domains. For software modeling, UML is of course, the single dominant language. In organization and process modeling, on the other hand, a multitude of languages are in use: there is no standard for models in this domain. We will focus on languages that either find widespread use or have properties that are interesting from the perspective of our goals in developing an enterprise architecture language. Slide 4 IDEF – Integrated DEFinition Methods .IDEF is a family of languages .Used to perform enterprise modeling and analysis .Currently, there are 16 IDEF methods. Of these methods, IDEF0, IDEF3, and IDEF1X (‘the core’) are the most commonly used. Slide 5 IDEF – The Scope it Covers .Functional modeling, IDEF0: The idea behind IDEF0 is to model the elements controlling the execution of a function, the actors performing the function, the objects or data consumed and produced by the function, and the relationships between business functions (shared resources and dependencies). .Process modeling, IDEF3: IDEF3 captures the workflow of a business process via process flow diagrams. These show the task sequence for processes performed by the organization, the decision logic, describe different scenarios for performing the same business functions, and enable the analysis and improvement of the workflow.
  • Integrating IT Portfolio Management with Enterprise Architecture Management 79

    Integrating IT Portfolio Management with Enterprise Architecture Management 79

    Enterprise Modelling and Information Systems Architectures Vol. 8, No. 2, December 2013 Integrating IT Portfolio Management with Enterprise Architecture Management 79 Daniel Simon, Kai Fischbach, Detlef Schoder Integrating IT Portfolio Management with Enterprise Architecture Management The management of information technology (IT) as a business has become a crucial factor in today’s complex and dynamic environments. Many firms thus have implemented IT portfolio and enterprise architecture (EA) management practices, and academic research has paid increasing attention to these concepts. However, their integration seems poorly substantiated; this article therefore seeks to answer two main questions: (1) What are differences and common characteristics of IT portfolio and EA management, and in what way can they be integrated? and (2) what factors and types might describe an integrated process design of EA management and project portfolio management in particular? To answer these questions, this study synthesises previous research and surveys EA practitioners to propose an EA management process map, as well as three descriptive factors and four clusters, which provide an integrated process design with project portfolio management. The interrelations with organisational aspects and software tool support are also explored. This article thereby clarifies and systematises the subject area while also offering advice for researchers and practitioners. 1 Introduction structured, business-like approach to IT manage- ment that comprises application, infrastructure, The notion of managing information technology service, and project portfolio management (Ben- (IT) as a business (Lientz and Larssen 2004) has son et al. 2004; Kaplan 2005). attracted significant attention, particularly as IT environments grow steadily more complex and Integration is equally critical to EA management, thus more difficult to manage.
  • Schon Mal Dran Gedacht,Linux Auszuprobieren? Von G. Schmidt

    Schon Mal Dran Gedacht,Linux Auszuprobieren? Von G. Schmidt

    Schon mal dran gedacht, Linux auszuprobieren? Eine Einführung in das Betriebssystem Linux und seine Distributionen von Günther Schmidt-Falck Das Magazin AUSWEGE wird nun schon seit 2010 mit Hilfe des Computer-Betriebs- system Linux erstellt: Texte layouten, Grafiken und Fotos bearbeiten, Webseiten ge- stalten, Audio schneiden - alles mit freier, unabhängiger Software einer weltweiten Entwicklergemeinde. Aufgrund der guten eigenen Erfahrungen möchte der folgende Aufsatz ins Betriebssystem Linux einführen - mit einem Schwerpunkt auf der Distri- bution LinuxMint. Was ist Linux? „... ein hochstabiles, besonders schnelles und vor allem funktionsfähiges Betriebssystem, das dem Unix-System ähnelt, … . Eine Gemeinschaft Tausender programmierte es und verteilt es nun unter der GNU General Public Li- cense. Somit ist es frei zugänglich für jeden und kos- tenlos! Mehrere Millionen Leute, viele Organisatio- nen und besonders Firmen nutzen es weltweit. Die meisten nutzen es aus folgenden Gründen: • besonders schnell, stabil und leistungs- stark • gratis Support aus vielen Internet- Newsgruppen Tux, der Pinguin, ist das Linux-Maskottchen • übersichtliche Mailing-Listen • massenweise www-Seiten • direkter Mailkontakt mit dem Programmierer sind möglich • Bildung von Gruppen • kommerzieller Support“1 Linux ist heute weit verbreitet im Serverbereich: „Im Oktober 2012 wurden mindes- tens 32% aller Webseiten auf einem Linux-Server gehostet. Da nicht alle Linux-Ser- ver sich auch als solche zu erkennen geben, könnte der tatsächliche Anteil um bis zu 24% höher liegen. Damit wäre ein tatsächlicher Marktanteil von bis zu 55% nicht 1 http://www.linuxnetworx.com/linux-richtig-nutzen magazin-auswege.de – 2.11.2015 Schon mal dran gedacht, Linux auszuprobieren? 1 auszuschliessen. (…) Linux gilt innerhalb von Netzwerken als ausgesprochen sicher und an die jeweiligen Gegebenheiten anpassbar.
  • What Every Engineer Should Know About Software Engineering

    What Every Engineer Should Know About Software Engineering

    7228_C000.fm Page v Tuesday, March 20, 2007 6:04 PM WHAT EVERY ENGINEER SHOULD KNOW ABOUT SOFTWARE ENGINEERING Phillip A. Laplante Boca Raton London New York CRC Press is an imprint of the Taylor & Francis Group, an informa business © 2007 by Taylor & Francis Group, LLC 7228_C000.fm Page vi Tuesday, March 20, 2007 6:04 PM CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2007 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Printed in the United States of America on acid-free paper 10 9 8 7 6 5 4 3 2 1 International Standard Book Number-10: 0-8493-7228-3 (Softcover) International Standard Book Number-13: 978-0-8493-7228-5 (Softcover) This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the conse- quences of their use. No part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.
  • Enterprise Architecture for Project Managers

    Enterprise Architecture for Project Managers

    Enterprise Architecture for Project Managers JK Corporate Services (JKCS) Authored by: Stan Ketchum, PMP Enterprise Architecture for Project Managers by Stan Ketchum is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License Enterprise Architecture for Project Managers Table of Contents Introduction .................................................................................................................................... 1 Purpose ........................................................................................................................................... 2 What Is Enterprise Architecture? ................................................................................................... 2 Why Is EA Needed? ..................................................................................................................... 2 What are the benefits of EA? ...................................................................................................... 3 EA vs Projects .............................................................................................................................. 3 What Does EA Consist of? ............................................................................................................... 4 EA Domains ................................................................................................................................. 4 Business Architecture ............................................................................................................
  • Architecting Software the SEI Way Twitter #Seiarchitecture © 2012 Carnegie Mellon University Outline Essential Problems for Architects

    Architecting Software the SEI Way Twitter #Seiarchitecture © 2012 Carnegie Mellon University Outline Essential Problems for Architects

    Analyzing and Evaluating Enterprise Architectures John Klein Senior Technical Staff John has over 20 years experience developing systems and software. He joined SEI in 2008. Before joining SEI, John was a chief architect at Avaya, Inc. There his responsibilities included development of multimodal agents, architectures for communication analytics, and the creation and enhancement of the Customer Interaction Software Product Line architecture. Prior to that, John was a software architect at Quintus, where he designed the first commercially successful multi- channel integrated contact center product and led the technology integration of the product portfolio as Quintus acquired several other companies. See his full bio at: www.sei.cmu.edu/go/architecting-software-the-sei-way Architecting Software the SEI Way Twitter #SEIArchitecture © 2012 Carnegie Mellon University Outline Essential problems for architects - • How do we efficiently translate business goals into quality attribute requirements? • How do we ensure that these quality attribute requirements are reflected in the tradeoffs and decisions that shaped the architecture? Agenda • Review of the SEI perspective on architecture-centric engineering • Scaling from software context to systems of systems and enterprise architectures • An approach to developing quality attribute requirements for enterprise architectures • An approach to first-pass evaluation of enterprise architectures • Tying together EA and system/software analysis and evaluation Architecting Software the SEI Way 1 Twitter #SEIArchitecture © 2012 Carnegie Mellon University Architecture-centric Engineering – Software and Systems IMPLEMENT AND EVOLVE DESIGN IMPLEMENT BUSINESS AND MISSION GOALS ARCHITECTURE SYSTEM SATISFY CONFORM SATISFY Architecting Software the SEI Way Twitter #SEIArchitecture © 2012 Carnegie Mellon University Principles of Architecture-Centric Engineering Every system has an architecture, regardless of scale.
  • 4.3 NWS ENTERPRISE ARCHITECTURE Bobby Jones

    4.3 NWS ENTERPRISE ARCHITECTURE Bobby Jones

    4.3 NWS ENTERPRISE ARCHITECTURE Bobby Jones*, Chief IT Architect Barry West, Chief Information Officer NOAA’s National Weather Service 1 INTRODUCTION An Enterprise Architecture (EA) is a comprehensive blueprint that aligns an organization’s business In 1996, Congress required Federal Agency Chief processes with its Information Technology (IT) Information Officers (CIO) to develop, maintain, and strategy. It is documented using multiple facilitate integrated systems architectures with the architectural models or views that show how the passage of the Clinger-Cohen Act. Additionally, current and future needs of an organization will be Office of Management and Budget (OMB) issued met. The key components of the EA are: guidance that requires agency information systems investments to be consistent with Federal, Agency, • Accurate representation of the and bureau architectures. Enterprise Architectures business environment, strategy and (EA) are “blueprints” for systematically and critical success factors completely defining an organization’s current • Comprehensive documentation of (baseline) or desired (target) environment. EAs are business units and key processes essential for evolving information systems and • Views of the systems and data that developing new systems that optimize their mission support these processes value. This is accomplished in logical or business • A set of technology standards that terms (e.g., mission, business functions, information define what technologies and flows, and systems environments) and technical products are approved to be used terms (e.g., software, hardware, communications), within an organization, and includes a sequencing plan for transitioning complemented by prescriptive from the baseline environment to the target enterprise-wide guidelines on how environment. to best apply these technology standards in creating business If defined, maintained, and implemented effectively, applications.
  • Software Development Process for Teams with Low Expertise, High-Rotation and No- Architect: a Systematic Mapping Study

    Software Development Process for Teams with Low Expertise, High-Rotation and No- Architect: a Systematic Mapping Study

    Software Development Process for Teams with Low Expertise, High-Rotation and No- Architect: A Systematic Mapping Study Paulina Valencia Franco Angelina Espinoza, Humberto Cervantes Maceda Electrical Engineering Department, Electrical Engineering Department, Universidad Autónoma Metropolitana Universidad Autónoma Metropolitana Iztapalapa, México Iztapalapa, México Email: paulatina63 –at- gmail.com Email: aespinoza, hcm -at- xanum.uam.mx Abstract —To have a well-organized software team is Process) [1], TSP (Team Software Process) [2], PSP (Personal fundamental to achieve the business goals in a software Software Process) [3], XP (Extreme Programming) [4] or development project, such as: functionality and quality in the SCRUM [5]. planned times. However, the teams present a particular problematic that are common in both industrial and academic These methodologies, for their nature, are more or less settings, this paper focuses on three: a) Teams with members prepared to face the team features previously mentioned, but with low expertise on methodologies, b) Teams with high member the real big challenge is to combine these models, to get an rotations, or c) Teams lacking a software architect. One adapted process model for overcoming all the three previous approach to address this situation is to define a software features in development teams. Particularly, these kinds of development process, adapted from the adaptability teams are commonly found in academic environments where characteristics and benefits offered by several methodologies there are not resources to hire a technical leader, nor currently used, in order that the development team obtains the experienced staff, so that development teams are mainly expected results in terms of productivity, time and quality of the comprised of students who are in constant rotation.
  • Adapting the Harris Matrix for Software Stratigraphy

    Adapting the Harris Matrix for Software Stratigraphy

    Adapting the Harris Matrix for Software Stratigraphy Andrew Reinhard Edward Harris’s (1979) landmark work, Principles of preservation of these born-digital archaeological Archaeological Stratigraphy, from which sprouted sites. the idea and practice of the Harris matrix, became This is not a new concern for people who work within the broad my windmill (or albatross) in 2017 as I attempted to umbrella of “digital humanities.” “Software archaeology”—the leverage its data visualization technique onto a digital attempt to reverse-engineer poorly documented (or undocu- mented) software in order to restore and preserve functionality— archaeological site. This visualization would not only has existed formally for over 15 years.1 Digital preservation is allow archaeologists to understand the composition also not a new idea and forms a border of software archaeology; namely, what to do with software post-use or post-“excavation.”2 and history of a digital built environment—something None of the software archaeology approaches, however, treat important to the emerging field of digital heritage— software as archaeological sites in the traditional sense, and I wanted to see what would happen if I conducted a truly archaeo- but also would contribute to the conservation and logical investigation of a software application using a tool known ABSTRACT In 1979, Edward C. Harris invented and published his eponymous matrix for visualizing stratigraphy, creating an indispensable tool for generations of archaeologists. When presenting his matrix, Harris also detailed his four laws of archaeological stratigraphy: superposition, original horizontal, original continuity, and stratigraphic succession. In 2017, I created the first stratigraphic matrix for software, using as a test the 2016 video game No Man’s Sky (Hello Games).
  • The Importance of Data Models in Enterprise Metadata Management

    The Importance of Data Models in Enterprise Metadata Management

    THE IMPORTANCE OF DATA MODELS IN ENTERPRISE METADATA MANAGEMENT October 19, 2017 © 2016 ASG Technologies Group, Inc. All rights reserved HAPPINESS IS… SOURCE: 10/18/2017 TODAY SHOW – “THE BLUE ZONE OF HAPPINESS” – DAN BUETTNER • 3 Close Friends • Get a Dog • Good Light • Get Religion • Get Married…. Stay Married • Volunteer • “Money will buy you Happiness… well, it’s more about Financial Security” • “Our Data Models are now incorporated within our corporate metadata repository” © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable 2. Data Models can in be incorporated into your corporate metadata repository © 2016 ASG Technologies Group, Inc. All rights reserved 3 POINTS TO REMEMBER SOURCE: 10/19/2017 DAMA NYC – NOONTIME SPEAKER SLOT – MIKE WANYO – ASG TECHNOLOGIES 1. Happiness is individually sought and achievable 2. Data Models can in be incorporated into your corporate metadata repository 3. ASG Technologies can provide an overall solution with services to accomplish #2 above and more for your company. © 2016 ASG Technologies Group, Inc. All rights reserved AGENDA Data model imports to the metadata collection View and search capabilities Traceability of physical and logical
  • Distro Notes This Document Was Revised on March 9, 2011

    Distro Notes This Document Was Revised on March 9, 2011

    Distro Notes This document was revised on March 9, 2011. Older versions can be discarded. 1. Overview. This document discusses a Linux distro that's under construction. Comments are welcome. The distro is portable; most versions run directly from pocket-size media (thumbdrives, 3" Mini-DVDs, etc.). It's useful for multimedia tasks, software development, Internet file or site downloads, office work, and system maintenance. Some versions also provide a large collection of games (including lightweight that even people who "don't play games" may find diverting). Target: This distro is aimed at UNIX and MS-Windows CLI developers, system administrators, multimedia hobbyists, and people with an interest in chess (there's 11 chess engines) and lightweight games in general. Desktop: There's a lightweight desktop. The desktop doesn't include GNOME or KDE eye candy (dancing icons, 3D workspaces, etc.) but it gets the job done and does support a few special features, including remote access and single-instance support. Windows clones: This distro resembles old versions of MS-Windows visually, it includes some MS-Windows work-alike programs, and it runs MS-Windows programs. However, it's not aimed at MS-Windows people. Former MS-Windows users should try PCLinuxOS and Ubuntu instead (these are polished Windows-style distros). That said, this distro offers somes advantages over Windows-style distros: it's faster, in some cases; it requires less memory (*); it includes tools, collections, and databases that are generally unavailable or poorly maintained elsewhere; and you can run it from a Flash device that fits on a keychain.