DOCSLIB.ORG

The 1968 NATO Software Engineering Conference

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The 1968 NATO Software Engineering Conference SOFTWARE ENGINEERING Report on a conference sponsored by the NATO SCIENCE COMMITTEE Garmisch, Germany, 7th to 11th October 1968 Chairman: Professor Dr. F. L. Bauer Co-chairmen: Professor L. Bolliet, Dr. H. J. Helms Editors: Peter Naur and Brian Randell January 1969 2 2 The present report is available from: Scientific Affairs Division NATO Brussels 39 Belgium Note for the current edition: The version of this report that you are reading was prepared by scan- ning the original edition, conversion to text through OCR, and then reformatting. Every effort has been made to do this as accurately as possible. However, it is almost certain that some errors have crept in despite best efforts. One of the problems was that the OCR software used kept trying to convert the original British spellings of words like ‘realise’ to the American spelling ‘realize’ and made other stupid mistakes. Whenever the OCR program was unsure of a reading, it called it to the attention of the operator, but there were a number of occasions in which it was sure, but wrong. Not all of these instances are guaranteed to have been caught. Although the editor tried to conform to the original presentation, certain changes were necessary, such as pagination. In order that the original Table of Contents and Indices would not have to be recalculated, an artifice was used. That is the original page breaks are indicated in the text thusly: 49 indicates that this is the point at which page 49 began in the original edition. If two such indicators appear together, this shows that there was a blank page in the original. The figures have been redrawn to improve legibility. The original size and scale was not changed. In order to accommodate the new pagination, the figures may have been shifted slightly from their position in the original document. Finally, it should be noted that the effort required to produce the current edition was a tiny fraction of the effort required for the original. The current editor therefore wants to express his apprecia- tion to the original editors, Peter Naur and Brian Randell, for producing what was clearly a land- mark effort in the Software Engineering field. Robert M. McClure Arizona 2001 NATO SOFTWARE ENGINEERING CONFERENCE 1968 3 3 HIGHLIGHTS The present report is concerned with a problem crucial to the use of computers, viz. the so-called software, or pro- grams, developed to control their action. The report summarises the discussions at a Working Conference on Software Engineering, sponsored by the NATO Science Committee. The Conference was attended by more than fifty people, from eleven different countries, all concerned professionally with software, either as users, manufacturers, or teachers at universities. The discussions cover all aspects of software including • relation of software to the hardware of computers • design of software • production, or implementation of software • distribution of software • service on software. By including many direct quotations and exchanges of opinion, the report reflects the lively controversies of the original discussion. Although much of the discussions were of a detailed technical nature, the report also contains sections reporting on discussions which will be of interest to a much wider audience. This holds for subjects like • the problems of achieving sufficient reliability in the data systems which are becoming increasingly integrated into the central activities of modern society • the difficulties of meeting schedules and specifications on large software projects • the education of software (or data systems) engineers • the highly controversial question of whether software should be priced separately from hardware. Thus, while the report is of particular concern to the immediate users of computers and to computer manufacturers, many points may serve to enlighten and warn policy makers at all levels. Readers from the wider audience should note, however, that the conference was concentrating on the basic issues and key problems in the critical areas of software engineering. It therefore did not attempt to provide a balanced review of the total state of software, and tends to understress the achievements of the field. NATO SOFTWARE ENGINEERING CONFERENCE 1968 4 4 5 CONTENTS HIGHLIGHTS . 3 CONTENTS . 5 PREFACE . .9 1. BACKGROUND OF CONFERENCE . 13 2. SOFTWARE ENGINEERING AND SOCIETY . 19 3.1. THE NATURE OF SOFTWARE ENGINEERING . 19 3.2. SOFTWARE ENGINEERING MANAGEMENT AND METHODOLOGY . 24 3.3. DESIGN AND PRODUCTION IN SOFTWARE ENGINEERING . 32 4. DESIGN . 35 4.1. INTRODUCTION . 35 4.1.1. Sources of techniques . 35 4.1.2. Need for hardware based on program structure . 35 4.1.3. Relation to mathematics . 37 4.2. DESIGN CRITERIA . 38 4.2.1. Genera design criteria . 38 4.2.2. User requirements . 40 4.2.3. Reliability and design . 44 4.2.4. Logical completeness . 44 4.3. DESIGN STRATEGIES AND TECHNIQUES . 45 4.3.1. Sequencing the design process . 45 4.3.2. Structuring the design . 50 4.3.3. Feedback through monitoring and simulation . 53 4.3.4. High-level languages . 55 4.4. COMMUNICATION AND MANAGEMENT IN DESIGN . 59 5. PRODUCTION . 65 5.1. INTRODUCTION . 65 5.1.1. The problems of scale . 65 5.1.2. The problems of reliability . 70 5.2 PRODUCTION — MANAGEMENT ASPECTS . 72 5.2.1. Production planning . 72 5.2.2. Personnel factors . 83 5.2.3. Production control . 86 5.2.4. Internal communication . 89 6 5.3. PRODUCTION — TECHNICAL ASPECTS . 93 5.3.1. Tools . .93 5.3.2. Concepts . 96 5.3.3. Performance monitoring . 99 6. SERVICE . 103 6.1. INTRODUCTION . 103 6.1.1. The virtue of realistic goals . 103 6.1.2. Initial system release . 103 6.1.3. Frequency of releases . 104 6.1.4. Responsibility for modified systems . 106 6.2. REPLICATION, DISTRIBUTION AND MAINTENANCE . 107 6.2.1. Replication . 107 NATO SOFTWARE ENGINEERING CONFERENCE 1968 5 6.2.2. Distribution . 109 6.2.3. Maintenance . 110 6.3. SYSTEM EVALUATION . 112 6.3.1. Acceptance testing . 113 6.3.2. Performance monitoring . 114 6.4. FEEDBACK TO MANUFACTURERS FROM USERS . 115 6.5. DOCUMENTATION . 116 6.6. REPROGRAMMING . 117 7. SPECIAL TOPICS . 119 7.1. SOFTWARE: THE STATE OF THE ART . 119 7.1.1. Introduction . 119 7.1.2. Problem areas . ..
Load more

Recommended publications
  • 1 Oral History Interview with Brian Randell January 7, 2021 Via Zoom
    Oral History Interview with Brian Randell January 7, 2021 Via Zoom Conducted by William Aspray Charles Babbage Institute 1 Abstract Brian Randell tells about his upbringing and his work at English Electric, IBM, and Newcastle University. The primary topic of the interview is his work in the history of computing. He discusses his discovery of the Irish computer pioneer Percy Ludgate, the preparation of his edited volume The Origins of Digital Computers, various lectures he has given on the history of computing, his PhD supervision of Martin Campbell-Kelly, the Computer History Museum, his contribution to the second edition of A Computer Perspective, and his involvement in making public the World War 2 Bletchley Park Colossus code- breaking machines, among other topics. This interview is part of a series of interviews on the early history of the history of computing. Keywords: English Electric, IBM, Newcastle University, Bletchley Park, Martin Campbell-Kelly, Computer History Museum, Jim Horning, Gwen Bell, Gordon Bell, Enigma machine, Curta (calculating device), Charles and Ray Eames, I. Bernard Cohen, Charles Babbage, Percy Ludgate. 2 Aspray: This is an interview on the 7th of January 2021 with Brian Randell. The interviewer is William Aspray. We’re doing this interview via Zoom. Brian, could you briefly talk about when and where you were born, a little bit about your growing up and your interests during that time, all the way through your formal education? Randell: Ok. I was born in 1936 in Cardiff, Wales. Went to school, high school, there. In retrospect, one of the things I missed out then was learning or being taught Welsh.
    [Show full text]
  • ASSESSING the MAINTAINABILITY of C++ SOURCE CODE by MARIUS SUNDBAKKEN a Thesis Submitted in Partial Fulfillment of the Requireme
    ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE By MARIUS SUNDBAKKEN A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science WASHINGTON STATE UNIVERSITY School of Electrical Engineering and Computer Science DECEMBER 2001 To the Faculty of Washington State University: The members of the Committee appointed to examine the thesis of MARIUS SUNDBAKKEN find it satisfactory and recommend that it be accepted. Chair ii ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE Abstract by Marius Sundbakken, M.S. Washington State University December 2001 Chair: David Bakken Maintenance refers to the modifications made to software systems after their first release. It is not possible to develop a significant software system that does not need maintenance because change, and hence maintenance, is an inherent characteristic of software systems. It has been estimated that it costs 80% more to maintain software than to develop it. Clearly, maintenance is the major expense in the lifetime of a software product. Predicting the maintenance effort is therefore vital for cost-effective design and development. Automated techniques that can quantify the maintainability of object- oriented designs would be very useful. Models based on metrics for object-oriented source code are necessary to assess software quality and predict engineering effort. This thesis will look at C++, one of the most widely used object-oriented programming languages in academia and industry today. Metrics based models that assess the maintainability of the source code using object-oriented software metrics are developed. iii Table of Contents 1. Introduction .................................................................................................................1 1.1. Maintenance and Maintainability.......................................................................
    [Show full text]
  • Computing Versus Human Thinking
    By Peter Naur, recipient of ACM’s 2005 A.M. Turing Award Computing Versus Human Thinking n this presentation I shall give you an overview of efforts. Indeed, I have found that a large part of what Imy works from the past fifty years concerning the is currently said about human thinking and about sci- issue given in the title. Concerning this title I entific and scholarly activity is false and harmful to invite you to note particularly the middle word, ‘ver- our understanding. I realize that my presentation of sus’. This word points to the tendency of my efforts some of these issues may be offensive to you. This I around this theme, to wit, to clarify the contrast regret, but it cannot be avoided. between the two items, computing and human thinking. This tendency of my work has found its DESCRIPTION AS THE CORE ISSUE OF SCIENCE AND ultimate fulfilment in my latest result, which is a SCHOLARSHIP description of the nervous system showing that this The tone of critique and rejection of established system has no similarity whatever to a computer. ideas has its roots in my earliest activity, from its very It is ironic that my present award lecture is given beginning more than fifty years ago. Already in my under the title of Turing. As a matter of fact, one part work in astronomy, around 1955, a decisive item in of my work concerning computing and human think- my awareness came from Bertrand Russell’s explicit ing has been an explicit critique, or rejection, of the rejection of any notion of cause as a central issue of ideas of one prominent contribution from Alan Tur- scientific work.
    [Show full text]
  • A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book)
    A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book) R. w. BEMER Introduction This is an admittedly fragmentary chronicle of events in the develop­ ment of the algorithmic language ALGOL. Nevertheless, it seems perti­ nent, while we await the advent of a technical and conceptual history, to outline the matrix of forces which shaped that history in a political and social sense. Perhaps the author's role is only that of recorder of visible events, rather than the complex interplay of ideas which have made ALGOL the force it is in the computational world. It is true, as Professor Ershov stated in his review of a draft of the present work, that "the reading of this history, rich in curious details, nevertheless does not enable the beginner to understand why ALGOL, with a history that would seem more disappointing than triumphant, changed the face of current programming". I can only state that the time scale and my own lesser competence do not allow the tracing of conceptual development in requisite detail. Books are sure to follow in this area, particularly one by Knuth. A further defect in the present work is the relatively lesser availability of European input to the log, although I could claim better access than many in the U.S.A. This is regrettable in view of the relatively stronger support given to ALGOL in Europe. Perhaps this calmer acceptance had the effect of reducing the number of significant entries for a log such as this. Following a brief view of the pattern of events come the entries of the chronology, or log, numbered for reference in the text.
    [Show full text]
  • Software Maintenance Maintenance Is Inevitable Types of Maintenance
    SoftWindows 8/18/2003 Software Maintenance • Managing the processes of system change Reverse Engineering (Software Maintenance & Reengineering) © SERG Maintenance is Inevitable • The system requirements are likely to change while the system is being developed because the environment is changing. • When a system is installed in an environment it changes that environment and therefore changes the system requirements. Reverse Engineering (Software Maintenance & Reengineering) © SERG Types of Maintenance • Perfective maintenance – Changing a system to make it meet its requirements more effectively. • Adaptive maintenance – Changing a system to meet new requirements. • Corrective maintenance – Changing a system to correct deficiencies in the way meets its requirements. Reverse Engineering (Software Maintenance & Reengineering) © SERG Distributed Objects 1 SoftWindows 8/18/2003 Distribution of Maintenance Effort Corrective maintenance (17%) Adaptive maintenance Perfective (18%) maintenance (65%) Reverse Engineering (Software Maintenance & Reengineering) © SERG Evolving Systems • It is usually more expensive to add functionality after a system has been developed rather than design this into the system: – Maintenance staff are often inexperienced and unfamiliar with the application domain. – Programs may be poorly structured and hard to understand. – Changes may introduce new faults as the complexity of the system makes impact assessment difficult. – The structure may be degraded due to continual change. – There may be no documentation available to describe the program. Reverse Engineering (Software Maintenance & Reengineering) © SERG The Maintenance Process • Maintenance is triggered by change requests from customers or marketing requirements. • Changes are normally batched and implemented in a new release of the system. • Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step.
    [Show full text]
  • System Software Maintenance and Support 24X7
    SYSTEM SOFTWARE MAINTENANCE AND SUPPORT SERVICES - PREMIUM These Premium System Software Maintenance and Support Service terms and conditions (“Terms and Conditions”) apply to any quote, order, order acknowledgment, and invoice, and any sale or provision of Premium System Software Maintenance and Support Services as defined herein provided to Customer by Viavi Solutions Inc. (“Viavi”), in addition to Viavi’s General Terms (“General Terms”) and/or Software License Terms, which are incorporated by reference herein and are either attached hereto, available at www.viavisolutions.com/terms or available upon request. k) Severity Level means classification of a problem determined by Viavi personnel 1. PURPOSE AND SCOPE based upon the Customer’s assessment of business impact. The three (3) Severity Levels that apply to the Services are as follows: These Terms and Conditions describe the Services that Viavi will provide to, and perform for, Customer. These Terms and Conditions apply to Services for standard Software, as 1) Problem Report – Critical means conditions that severely affect the defined herein, and are limited to the System configuration specified in a Statement of primary functionality of the System and because of the business impact to the Work (“SOW”) or other ordering document (i.e., a quote, order, order acknowledgment customer requires non-stop immediate corrective action, regardless of time of day or invoice) which contains a description of the System. All Services and Documentation or day of the week as viewed by a customer
    [Show full text]
  • An Early Program Proof by Alan Turing F
    An Early Program Proof by Alan Turing F. L. MORRIS AND C. B. JONES The paper reproduces, with typographical corrections and comments, a 7 949 paper by Alan Turing that foreshadows much subsequent work in program proving. Categories and Subject Descriptors: 0.2.4 [Software Engineeringj- correctness proofs; F.3.1 [Logics and Meanings of Programs]-assertions; K.2 [History of Computing]-software General Terms: Verification Additional Key Words and Phrases: A. M. Turing Introduction The standard references for work on program proofs b) have been omitted in the commentary, and ten attribute the early statement of direction to John other identifiers are written incorrectly. It would ap- McCarthy (e.g., McCarthy 1963); the first workable pear to be worth correcting these errors and com- methods to Peter Naur (1966) and Robert Floyd menting on the proof from the viewpoint of subse- (1967); and the provision of more formal systems to quent work on program proofs. C. A. R. Hoare (1969) and Edsger Dijkstra (1976). The Turing delivered this paper in June 1949, at the early papers of some of the computing pioneers, how- inaugural conference of the EDSAC, the computer at ever, show an awareness of the need for proofs of Cambridge University built under the direction of program correctness and even present workable meth- Maurice V. Wilkes. Turing had been writing programs ods (e.g., Goldstine and von Neumann 1947; Turing for an electronic computer since the end of 1945-at 1949). first for the proposed ACE, the computer project at the The 1949 paper by Alan M.
    [Show full text]
  • Internet Engineering Jan Nikodem, Ph.D. Software Engineering
    Internet Engineering Jan Nikodem, Ph.D. Software Engineering Theengineering paradigm Software Engineering Lecture 3 The term "software crisis" was coined at the first NATO Software Engineering Conference in 1968 by: Friedrich. L. Bauer Nationality;German, mathematician, theoretical physicist, Technical University of Munich Friedrich L. Bauer 1924 3/24 The term "software crisis" was coined at the first NATO Software Engineering Conference in 1968 by: Peter Naur Nationality;Dutch, astronomer, Regnecentralen, Niels Bohr Institute, Technical University of Denmark, University of Copenhagen. Peter Naur 1928 4/24 Whatshouldbe ourresponse to software crisis which provided with too little quality, too late deliver and over budget? Nationality;Dutch, astronomer, Regnecentralen, Niels Bohr Institute, Technical University of Denmark, University of Copenhagen. Peter Naur 1928 5/24 Software should following an engineering paradigm NATO conference in Garmisch-Partenkirchen, 1968 Peter Naur 1928 6/24 The hope is that the progress in hardware will cure all software ills. The Oberon System User Guide and Programmer's Manual. ACM Press Nationality;Swiss, electrical engineer, computer scientist ETH Zürich, IBM Zürich Research Laboratory, Institute for Media Communications Martin Reiser 7/24 However, a critical observer may notethat software manages to outgrow hardware in size and sluggishness. The Oberon System User Guide and Programmer's Manual. ACM Press Nationality;Swiss, electrical engineer, computer scientist ETH Zürich, IBM Zürich Research Laboratory, Institute for Media Communications Martin Reiser 8/24 Wirth's computing adage Software is getting slower more rapidly than hardware becomes faster. Nationality;Swiss, electronic engineer, computer scientist ETH Zürich, University of California, Berkeley, Stanford University University of Zurich. Xerox PARC.
    [Show full text]
  • The Roots of Software Engineering*
    THE ROOTS OF SOFTWARE ENGINEERING* Michael S. Mahoney Princeton University (CWI Quarterly 3,4(1990), 325-334) At the International Conference on the History of Computing held in Los Alamos in 1976, R.W. Hamming placed his proposed agenda in the title of his paper: "We Would Know What They Thought When They Did It."1 He pleaded for a history of computing that pursued the contextual development of ideas, rather than merely listing names, dates, and places of "firsts". Moreover, he exhorted historians to go beyond the documents to "informed speculation" about the results of undocumented practice. What people actually did and what they thought they were doing may well not be accurately reflected in what they wrote and what they said they were thinking. His own experience had taught him that. Historians of science recognize in Hamming's point what they learned from Thomas Kuhn's Structure of Scientific Revolutions some time ago, namely that the practice of science and the literature of science do not necessarily coincide. Paradigms (or, if you prefer with Kuhn, disciplinary matrices) direct not so much what scientists say as what they do. Hence, to determine the paradigms of past science historians must watch scientists at work practicing their science. We have to reconstruct what they thought from the evidence of what they did, and that work of reconstruction in the history of science has often involved a certain amount of speculation informed by historians' own experience of science. That is all the more the case in the history of technology, where up to the present century the inventor and engineer have \*-as Derek Price once put it\*- "thought with their fingertips", leaving the record of their thinking in the artefacts they have designed rather than in texts they have written.
    [Show full text]
  • Software Engineering Software Maintenance
    SOFTWARE ENGINEERING SOFTWARE MAINTENANCE Software maintenance is the process of modification or making changes in the system after delivery to overcome errors and faults in the system that were not uncovered during the early stages of the development cycle. LEARNING OBJECTIVES • To study on why maintenance is an issue. • To study on reverse engineering and limitations. • To organize data. • To check what the system does. SOFTWARE MAINTENANCE The IEEE Standard for Software Maintenance (IEEE 1219) gave the definition for software maintenance as “The process of modifying a software system or component after delivery to correct faults, improves performance or other attributes, or adapt to a changed environment.” Maintenance Principles 100 Hardware Development 60 Software 20 Maintenance Percent of total cost total of Percent 1995 2000 2010 The IEEE/EIA 12207 Standard defines maintenance as modification to code and associated documentation due to a problem or the need for improvement. Nature of Maintenance Modification requests are logged and tracked, the impact of proposed changes are determined, code and other software artifacts are modified, testing is conducted, and a new version of the software product is released. Maintainers can learn from the developer´s knowledge of the software. Need for Maintenance Maintenance must be performed in order to: • Correct faults. • Improve the design. • Implement enhancements. • Interface with other systems. • Adapt programs so that different hardware, software, system features, and telecommunications facilities can be used. • Migrate legacy software. • Retire software Tasks of a maintainer The maintainer does the following functions: • Maintain control over the software´s day-to-day functions. • Maintain control over software modification.
    [Show full text]
  • Structured Programming A.P.I.C
    ¢ . , v'~.1 c: STRUCTURED PROGRAMMING A.P.I.C. Studies in Data Processing General Editor: C. A. R. Hoare 1. Some Commercial Autocodes. A Comparative Study E. L. WiUey, A. d'Agapeyeff, Marion Tribe, B. J. Gibbens and Michelle Clarke. 2. A Primer of ALGOL 60 Programming E. W. Dijkstra 3. Input Language for Automatic Programming A. P. Yershov, G. I. Kozhukhin and U. Voloshin 4. Introduction to System Programming Edited by Peter Wegner 5. ALGOL 60 Implementation. The translation and use of Algol 60 Programs on a Computer B. RandeU and L. J. Russell 6. Dictionary for Computer Languages Hans Breuer 7. The Alpha Automatic Programming System Edited by A. P. Yershov 8. Structured Programming O.-J. Dahl, E. W. Dijkstra and C. A. R. Hoare In preparation Operating Systems Techniques Edited by C. A. R. Hoare and R. H. Perrott A.P.I.C. Studies in Data Processing No. 8 STRUCTURED PROGRAMMING O.-J. DAHL Universitet i Oslo, Matematisk Institut, Blindern, Oslo, Norway E. W. DIJKSTRA Department of Mathematics, Technological University, Eindhoven, The Netherlands C. A. R. HOARE Department of Computer Science, The Queen's University of Belfast, Belfast, Northern Ireland 1972 ACADEMIC PRESS LONDON AND NEW YORK ACADEMIC PRESS INC. (LONDON) LTD. 24]28 Oval Road, London NW1 United States Edition published by ACADEMIC PRESS INC. 111 Fifth Avenue New York, New York 10003 Copyright © 1972 by ACADEMIC PRESS INC. (LONDON) LTD. Second printing 1973 All Rights Reserved No part of this book may be reproduced in any form by photostat, microfilm, or any other means, without written permission from the publishers Library of Congress Catalog Card Number: 72-84452 ISBN: 0--12-200550-3 PRINTED IN GREAT BRITAIN BY WHITSTABLE LITHO~ STRAKER BROTHERS LTD.
    [Show full text]
  • Read Ms. Shaw's First Amended Complaint
    Janet L. Goldstein Peter W. Chatfield THE MARTYN FIRM, PLLC PHILLIPS & COHEN LLP 1054 31st Street, NW 2000 Massachusetts Ave., NW Washington, D.C. 20007 Washington, D.C. 20036 Tel: (202) 965-3060 Tel: (202) 833-4567 Fax: (202) 965-3063 Fax: (202) 833-1815 Jonathan A. Willens (JW-9180) JONATHAN A. WILLENS LLC 217 Broadway, Suite 707 New York, New York 10007 Tel: (212) 619-3749 Fax: (800) 879-7938 Attorneys for qui tam plaintiff Ann-Marie Shaw UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF NEW YORK UNITED STATES OF AMERICA ) 06 CV 3552 (DLI) (SMG) ex rel. ANN-MARIE SHAW ) and ) AMENDED COMPLAINT ) FOR VIOLATIONS OF STATE OF CALIFORNIA ex rel.ANN-MARIE SHAW ) FEDERAL AND STATE DISTRICT OF COLUMBIA ex rel.ANN-MARIE SHAW ) FALSE CLAIMS ACTS STATE OF FLORIDA ex rel.ANN-MARIE SHAW ) STATE OF HAWAII ex rel.ANN-MARIE SHAW ) STATE OF ILLINOIS ex rel.ANN-MARIE SHAW ) COMMONWEALTH OF MASSACHUSETTS ) ex rel.ANN-MARIE SHAW ) STATE OF NEVADA ex rel.ANN-MARIE SHAW ) COMMONWEALTH OF VIRGINA ) ex rel.ANN-MARIE SHAW ) STATE & CITY OF NEW YORK ) ex rel.ANN-MARIE SHAW, ) ) JURY TRIAL DEMANDED Plaintiffs, ) ) FILED UNDER SEAL v. ) ) CA, INC., ) ) Defendant. ) _______________________________________________ ) Through her attorneys, plaintiff and qui tam relator Ann-Marie Shaw, for her Amended Complaint against Defendant CA, Inc. (“CA”), formerly known as Computer Associates International, Inc. or “Computer Associates,” alleges as follows: FACTS COMMON TO ALL COUNTS A. Introduction 1. This is a civil action to recover damages and civil penalties arising from false and/or fraudulent statements, records, and claims made and caused to be made by the Defendant CA and/or its agents and employees in violation of the Federal Civil False Claims Act, 31 U.S.C.
    [Show full text]