Showing papers in "ACM Sigsoft Software Engineering Notes in 1985"
TL;DR: The software engineering baccalaureate program consists of a rigorous curriculum of science, math, computer science, and software engineering courses.
Abstract: Software engineers work on multidisciplinary teams to identify and develop software solutions and to maintain software intensive systems of all sizes. The focus of this program is on the rigorous engineering practices necessary to build, maintain, and protect modern software intensive systems. Consistent with this focus, the software engineering baccalaureate program consists of a rigorous curriculum of science, math, computer science, and software engineering courses.
1,124 citations
TL;DR: In this paper, a new approach for proving theorems in first-order predicate calculus is developed based on term rewriting and polynomial simplification methods, where a formula is translated into an equivalent set of formulae expressed in terms of 'true', 'false', 'exclusive-or', and 'and' by analyzing the semantics of its top-level operator.
Abstract: A new approach for proving theorems in first-order predicate calculus is developed based on term rewriting and polynomial simplification methods. A formula is translated into an equivalent set of formulae expressed in terms of 'true', 'false', 'exclusive-or', and 'and' by analyzing the semantics of its top-level operator. In this representation, formulae are polynomials over atomic formulae with 'and' as multiplication and 'exclusive-or' as addition, and they can be manipulated just like polynomials using familiar rules of multiplication and addition.
Polynomials representing a formula are converted into rewrite rules which are used to simplify polynomials. New rules are generated by overlapping polynomials using a critical-pair completion procedure closely related to the Knuth- Bendix procedure. This process is repeated until a contradiction is reached or it is no longer possible to generate new rules. It is shown that resolution is subsumed by this method.
123 citations
TL;DR: The Editors of American Scientist believe that it would be useful to the scientific community to reprint these essays in their entirety to stimulate scientific discussion of the feasibility of the project.
Abstract: A former member of the SDIO Panel on Computing in Support of Battle Management explains why he believes the “Star Wars” effort will not achieve its stated goals.
71 citations
TL;DR: This paper will try to expose the theoretical and practical aspects of the evolutionary delivery method in a fuller perspective, so that the theory fully is applied and the practical aspects can be applied completely.
Abstract: The conventional wisdom of planning software engineering projects, using the widely cited "waterfall model" is not the only useful software development process model. In fact, the "waterfall model" may be unrealistic, and dangerous to the primary objectives of any software project.The alternative model, which I choose to call "evolutionary delivery" is not widely taught or practiced yet. But there is already more than a decade of practical experience in using it. In various forms. It is quite clear from these experiences that evolutionary delivery is a powerful general tool for both software development and associated systems development.Almost all experienced software developers do make use of some of the ideas in evolutionary development at one time or another. But, this is often unplanned, informal and it is an incomplete exploitation of this powerful method. This paper will try to expose the theoretical and practical aspects of the method in a fuller perspective. We need to learn the theory fully, so that we can apply and learn it completely.
51 citations
16 citations
TL;DR: In this article, the authors propose a method to improve the quality of the data collected by the data collection system, which can be found here: http://www.m.y ff 0 0 p M-a a o o o.a p
Abstract: y ff 0 0 p M-a a o o .a p..
12 citations
9 citations
TL;DR: This book contains significant wisdom that should be totally absorbe d and internalized by every software engineer -regardless of for whom he/she is writing software, and regardless of how widely used the interface may be.
Abstract: This is a remarkable and unusual book . You may find it to be an ideal present for some of you r friends who are vague on what computers are all about . You may also find some interesting food for thought yourself . You should not expect to find anything deeply technical, although many of th e examples will strike technical chords -and indeed are technically motivated . The book is aime d primarily at the interested layman, along the lines of The Tao of Physics, The Dancing Wu L i Masters, and Lives o f a Cell . (Apparently Viking is trying to make sure that the book appears o n many different parts of the bookstore -perhaps psychology, education, and self-help, but not among the computers books .) I think that this book will actually be quite useful in increasing the genera l level of computer literacy -an increasingly essential goal for our society . But even though it appear s to be written at a relatively high level, it contains significant wisdom that should be totally absorbe d and internalized by every software engineer -regardless of for whom he/she is writing software an d regardless of how widely used the interface may be .
8 citations
TL;DR: The Microelectronics and Computer Technology Corporation (MCC) is an industry consortium formed to conduct long-range research and develop computer technology in seven general areas, specifically the technology employed during the development of software systems.
Abstract: The Microelectronics and Computer Technology Corporation (MCC) is an industry consortium formed to conduct long-range research and develop computer technology in seven general areas. One of those areas is software technology, specifically the technology employed during the development of software systems. This paper outlines that research program, the MCC Software Technology Program.
7 citations
TL;DR: A system is described which builds a directly executable model of an application from a data flow diagram/application dictionary specification, which has certain analogies with data flow machines and languages, and with simulation systems.
Abstract: Data flow diagrams are commonly used in a semi-formal way (together with other associated tools) for the specification of a wide range of data processing applications. The main associated tools are those used for the definitions of data flows and processes, namely so-called data dictionaries, better perhaps lerned system or application dictionaries. A system is described which builds a directly executable model of an application from a data flow diagram/application dictionary specification. The system has certain analogies with data flow machines and languages, and with simulation systems. It is described as a rapid prototyping system because the application specification requirements are minimal, although performance may not be particularly efficient.
7 citations
TL;DR: This paper indicates how conditional (directed) equations provide a paradigm of computat that combines the clean syntax and semantics of both the logic programming and applicative/functional programming paradigms in one, uniform manner.
Abstract: In this paper, we indicate how conditional (directed) equations provide a paradigm of computat.ion that combines the clean syntax and semantics of both the logic programming and applicative/functional programming paradigms in one, uniform manner. Programming styles such as this impact verification in two ways: by reducing the disparity between specification and programming languages and by provided a potentially convenient language in which to spe:-cify, if not implement, verifier components.
TL;DR: In this article, the authors discuss the origins and evolution of the term configuration management and survey the software tools which have evolved to support that need, and present a survey of the most popular tools.
Abstract: The practice of documenting the components of a product, identifying the components of a product, controlling changes to the product and tracking those changes are part of a task called configuration management. This paper discusses the origins and evolution of the term and surveys the software tools which have evolved to support that need.
TL;DR: Why the software community has not yet automated the process of developing software is considered and some of the major factors which inhibit the establishment of a unifying view are identified.
Abstract: This paper considers why the software community has not yet automated the process of developing software. It identifies some of the major factors which inhibit the establishment of a unifying view. The paper considers alternate views of the development process and discusses implications of each. Finally, it reviews some of the non-technical issues related to software development. This is a paper of ideas; no solutions are offered.
TL;DR: US programmers shave days off software development time while squandering weeks on ad-libbed software maintenance, according to a study of Soviet and Japanese companies.
Abstract: U.S. programmers shave days off software development time while squandering weeks on ad-libbed software maintenance. Soviet and Japanese companies have a jump on developing rigorous methods.
TL;DR: The use of the specification/programming language Lucid to specify secure distributed systems is proposed and the status of work to develop a formal model of security for the SNet multi-level secure distributed system is reported on.
Abstract: This paper proposes the use of the specification/programming language Lucid to specify secure distributed systems. It reports on the status of work to develop a formal model of security for the SNet multi-level secure distributed system, and to specify it in Lucid.
TL;DR: 0 O O O a) c d .9 a) n a O 0) Y (_) C a E O U cD 0 U a) a E a~) y n O OA) W a 0 Q a) (d) v a) o L m o 0 O U r _ /A co O a a)
Abstract: This paper is a progress report on an experimental system, the state delta verification system (SDVS), for verifying microcode correctness. The goal of this project is to solve some of the problems, both theoretical and engineering, obstructing the realization of a usable and applicable program for checking proofs of microcode correctness. The ideal result would be a system that could be naturally incorporated into the specification-implementation cycle of, for example, microcoded machine instruction sets.
TL;DR: In this paper, a case study is made of a project in which software was delivered on time and under budget, and the factors contributing to the success are emphasized as well as some factors which prevented an even greater success.
Abstract: The literature is replete with software horror stories. Despite all the planning and case studies, software projects all too frequently fall short of expectations or utterly fail. In this article, a case study is made of a project in which software was delivered on time and under budget. The factors contributing to the success are emphasized as well as some factors which prevented an even greater success. This article describes the development of a General Electric Company product, but the opinions expressed herein are solely those of the author. The procedures described and comments made do not reflect an official endorsement by General Electric Company or its employees.
TL;DR: Mastro as discussed by the authors is a Consultant for Technology Information Products Corporation (TIPC) and is involved in the teaching and consulting of their technologies, which through analysis, design and implementation develop more effective information systems.
Abstract: Vincent Mastro is currently a Consultant for Technology Information Products Corporation. He is involved in the teaching and consulting of their technologies, which through analysis, design and implementation develop more effective information systems.
TL;DR: The original ESTCA rule to detect erroneous relations required tes t data variablel-variable2 = 0,e and +e, and neither variabl e = to a constant, but it is not reliable in detectin g variable mis-references.
Abstract: INTRODUCTIO N This note revises and re-substantiates the original ESTCA rul e EFOST80] for generating or evaluating test data for simpl e conditional or comparison expressions. Comments on other method s are included. The rules apply to the lowest program component-\"variabl e operator variable-or-constant\" expressions. Clearly, if any par t of any expression is incorrect, then so is the program. Rule s developed in this continuing study are intended to identify dat a that meets error sensitivity criteria for all expression types. Rules for logic expressions and combinations of comparisons ar e in CFOST84]. PROBLEM Consider the code fragment : 1 ACCEPT X,Y,Z (integers X<=Y<=Z) 2a IF X = Y THEN \"equal\" ELSE \"unequal\" (incorrect) 2b IF Y = 2 THEN \"equal\" ELSE \"unequal\" (incorrect) 2c IF X = 2 THEN \"equal\" ELSE \"unequal\" (correct) The original rule to detect erroneous relations required tes t data variablel-variable2 = 0,-e and +e, and neither variabl e = to a constant. Teat data meeting this rule for all line 2a ar e X/Y/Z = 1/1/1 and 2/3/4. (The +e=+1 difference is assume d impossible due to the input constraint). These test data do no t reveal that lines 2a and 2b are incorrect. The rule detects incorrect relations and modification of correc t variables by a constant. But it is NOT reliable in detectin g variable mis-references. Revision is necessary. DISCUSSIO N Let X be a variable identifier and Y be a variable identifier o r constant value. Define X?Y as a source code compariso n expression where ? is any one of the operators <
TL;DR: My goal is to make maintenance programming a highly respected discipline, and I would even dare to call it "Softwar e Maintenance Engineering".
Abstract: Herewith I am starting a new column titled \"Software Maintenance Notes .\" I have suffered (believe me, it was painful) software maintenance for at least half (doe s that sound familiar?) of my over 14 years of programming experience . That set me thinking, studying (i .e., researching), writing, and (at the cost of bein g outspoken) doing something to make maintenance programming a decent work . My goal is to make it a highly respected discipline, I would even dare to call it \"Softwar e Maintenance Engineering .\" I have found that some of the \"structured\" vendors (s o called experts selling structured methodology courses, books, snake-oil bottles, an d so on), and structured gurus have done very little to help the poor maintenanc e programmer . Was it because \"maintenance\" was a dirty word, and the subject was no t easy to sell? I am sure they were not naive to believe that by following thei r methods all the maintenance problems will go away . And assuming that with the new structured software, the maintenance problems will go away (which is unlikely), how about the billions of lines of existing software, mostly unstructured .
TL;DR: • ri UC ,1 a) • L .0 0 L.. V) A • ro L. 0. r l • U 0 .0 L.
Abstract: • ri UC ,1 a) • L .0 0 L.. V) A • ro L. r l • U 0 .0 L. 0. 0 4 4 • 0 no L C • m 14 no o m U U A rov .) • N 0 .0 C ro m al co A m 4-) A-L.
TL;DR: The role of the tools group is described, the expected benefits of software tools and techniques are discussed and the characteristics of members of a tools group are discussed.
Abstract: This paper addresses the issue of productivity in the software industry It discusses the expected benefits of software tools and techniques It describes the role of the tools group in this regard and, finally, discusses the characteristics of members of a tools group
TL;DR: Methods for decomposing large conjectures into smaller ones in order to make their proof easier and for limiting the amount of reproving that occurs when a specification is modified are described.
Abstract: This paper describes methods for decomposing large conjectures into smaller ones in order to make their proof easier and for limiting the amount of reproving that occurs when a specification is modified. It proposes a tool, based on these methods, for managing the proofs of conjectures about an evolving specification.
[...]
TL;DR: I believe that Dennis Geller gets off course in his interpretation of the information that is to be reported i n the B5 and C5 and therefore his conclusions are erroneous.
Abstract: I believe that Dennis Geller gets off course [\"B-ware -Contradictions in a Software Development Plan\"] (SEN January 1985, pg . 48) in his interpretation of the information that is to be reported i n the B5 and C5 and therefore his conclusions are erroneous . In his 4th paragraph he refers to \"C5 (detailed design) document --\" and in the 8th paragraph refers to \"B-5 is to contain a top-leve l description of each functional item--such items may be tasks, packages or procedures . \
TL;DR: There are currently many systems which cannot be fully tested, but the Range Safety Command Destruct system at Cape Canaveral Air Force Station, which provides the commands necessary to destroy errant missiles which may threaten populated areas, is among them.
Abstract: There are currently many systems which cannot be fully tested. One example is the software used in our present defense early warning system. ?:,nother example, one with which I am personally familiar, is the Range Safety Command Destruct system at Cape Canaveral Air Force Station. This system provides the commands necessary to destroy errant missiles which may threaten populated areas; I wrote most of the software for the central computer in this system. The system can never be fully tested in the sense implied above, for to do so would involve the intentional destruction of a missile for testing purposes only. On the other hand, it must be reliable: a false negative (failure to destroy a missile which endangers a populated area) could cause the loss of thousands of lives; a false positive (unintentional destruction of, say, a Space Shuttle mission) is equally unthinkable. There are many techniques available to produce fault-tolerant, reliable software, just as there are for hardware; the Range Safety system was designed by some of the best people at NASA, the U. S. Air Force, and several contractors. I do not claim that a failure of this system is "impossible", but the risk of a failure, in my opinion, is acceptably low.
TL;DR: The IEEE P1074 Software Life Cycle Process Standard Working Group is undertaking the task of defining the processes occurring within each software life cycle phase, including both the traditional and less traditional phases of software development.
Abstract: The IEEE P1074 Software Life Cycle Process Standard Working Group is undertaking the task o f defining the processes occurring within each software life cycle phase. This will include both th e traditional phases of software development and the less traditional phases of Concept Exploration , Operation, Maintenance, and Retirement. The goal is to produce a software standard that makes a statement representing industry consensus. Interested persons are invited to join in the effort .