Abstract: What the software engineer can do for the computer user.- The design and construction of software systems.- Hierarchies.- Language characteristics programming languages as a tool in writing system software.- Low level languages summary of a discussion session.- Relationship between definition and implementation of a language.- Concurrency in software systems.- Modularity.- Portability and adaptabilty.- Debugging and testing.- Reliability.- Project Management.- Documentation.- Performance prediction.- Performance measurement.- Pricing mechanisms.- Evaluation in the computing center environment.

Abstract: What the software engineer can do for the computer user.- The design and construction of software systems.- Hierarchies.- Language characteristics programming languages as a tool in writing system software.- Low level languages summary of a discussion session.- Relationship between definition and implementation of a language.- Concurrency in software systems.- Modularity.- Portability and adaptabilty.- Debugging and testing.- Reliability.- Project Management.- Documentation.- Performance prediction.- Performance measurement.- Pricing mechanisms.- Evaluation in the computing center environment.

Abstract: Basic graphics software is system software for the application programmer designed to relieve him of the need for intimate knowledge of graphic devices. Ideally basic graphics software would be a common package for all users. However a more feasible approach would be to define distinct functions which should be common to the many packages which must be developed.

Abstract: To anyone that has had the slightest connection with the design and construction of large programs for digital computers, it is obvious that it is not a trivial task.What may not be so obvious is the almost complete lack of automation that has been applied to the task of software design. While computer scientists and technologists have been busy helping to apply computers to many other complex tasks, they have been notably tardy in applying the symbol-manipulating and decision-making power of the computer to the creation of software.While this has been the case in the past, there has recently been an upswing in activity aimed at automating software design. The purpose of this short paper is to provide some context, background, and initial roadmaps to people working in other areas of design automation who may wish to help us with the task of automating software design.

Abstract: Sometime in the future, the development of comple x application programs and large software systems wil l become a routine process . It will be possible to construct the most complex programs imaginable b y combining off the shelf subsystems in much the sam e way that houses are constructed today . Before soft ware development can become such a mechanica l process, however, it must undergo some majo r changes . One of the most important of these wil l be a shift in emphasis away from concern with th e details of \"programming\" and toward increased concern with the structure of programs and systems . The evolution of software development may parallel what has happened in the construction of house s and buildings . The latter are as complicated as mos t systems . The construction of a house or building would be an extremely challenging proposition if th e architect and contractor were required to start fro m scratch with raw materials . The construction of a house is greatly simplified by the existence of a larg e number of prefabricated subsystems, such as water heaters, air-heaters, windows, plumbing subsystem s and so on . It is interesting that houses are designe d by architects ; that is, by people whose primary concern is the \"fitting together of structures .\" By comparison, most software development is don e at the level of \"raw materials\" such as wood, sand , gravel, unforged metal and handmade tools . Th e major standard subsystems have yet to become avail able to the public, and most system designers ar e too involved with details to pay much attention t o architecture. As system development techniques mature, this will change. Designers will pay less attentio n to bits and condition codes and more attention t o system structure, until ultimately they become architects in the true sense of the word . The purpose of this paper is to describe the architectural side of software developments and to examine some of the changes that are likely to occur . On e

Abstract: : The objective of the Software Validation Study was to analyze the effectiveness of the development and testing process as it existed on a current ballistic system software development. For this case study, a Minuteman flight program R+D development, Flight Program 2, was examined. The report includes a description of the software development process, identification of project requirements and their sources, discussion of the testing process, and evaluation of these to identify areas for software technology development for future systems. (Author)

Abstract: Computer hardware and software; an interdisciplinary introduction , Computer hardware and software; an interdisciplinary introduction , مرکز فناوری اطلاعات و اطلاع رسانی کشاورزی

Abstract: : The Software Validation Study was undertaken to provide an understanding and assessment of the process used to develop the software for a current ballistic missile system, the Minuteman III system, particularly the process of identifying software requirements and performing software testing. This information is intended to provide the foundation for development of advanced techniques to be applied to future software developments.

Abstract: Since most CAMAC systems include computers, the generation and maintenance of computer programs may represent a substantial fraction of the effort involved in assembling a CAMAC system. The effort involved can be reduced if standard software can be used, but the generality of the hardware and the variety of computers and interfaces make the production of efficient, general software difficult. Some of the problems and some general approaches to them are discussed below. The NIM Software Working Group has been working on a set of FORTRAN subroutines for use with CAMAC systems. Though the effort is incomplete, it has reached a stage where its implementation is feasible and will prove useful. The working group has therefore concluded that it should be published in this tutorial issue to make it available to prospective users.

Abstract: Although minicomputer hardware costs are rapidly decreasing, minicomputer software seems to be continuously increasing in cost. A contributing factor to this situation is a lack of recognition of the scope of the problem of software production, which must be considered to include analysis, design, implementation, integration, testing, delivery, and maintenance. Various tools for minicomputer software production are discussed, including specification and design standards, software engineering techniques, implementation and testing methods, and project controls.

Abstract: A two-level software system for minicomputers suitable for use in real-time production monitoring and control applications has been designed and implemented. The first level consists of a general-purpose file system implemented in the form of a voluntary virtual memory which can be added to most minicomputer software systems. The second-level software is a set of data management primitives which permit the definition, creation, maintenance, modification, and referencing of large, interlinked, complex data bases which arise in discrete parts manufacturing applications. The software system is described. The application to a discrete parts manufacturing control system is described along with experimental measures of response time and memory requirements.

Abstract: A research program is underway with the purpose of developing a system to integrate the functions of Design, Programming, Debugging and Testing (DPDT) for achieving software reliability. Although we are aiming at developing an actual for realized system for this purpose, emphasis is being placed on the isolation of general principles that can be applied to a variety of programming environments. We are defining a model of computation through which the design phase will be formally described.1 The model will be required to handle a basic definition of modularity besides having features to be integrated with: a class of Algol-like languages (in which programs are to be written), the debugging facilities defined in the language, and a class of program testing strategies. Extensions to a programming language will be defined so as to make it support the requirements of the design model2 and to provide debugging facilities compatible with the design phase and measurements. The measurements will be handled by the systems testing phase for the establishment of some quantitative indices of test completeness. The testing activity will in turn reflect on the design and provoke iterations until a “sufficient verification” of the produced software is met.

Abstract: Software implementation for automatic test systems controlled by minicomputers can be a costly and time-consuming process. A procedure for implementing software which tends to minimize costs and avoid delays caused by unexpected problems is described. The procedure consists of completely defining the test system functions and performing a series of hardware versus software tradeoffs during the design and implementation process. The purpose of the tradeoffs is to determine the least costly method of implementing tester functions by either hardware, software, or some combination of hardware and software. Delays caused by unexpected problems are reduced by including hardware and software debugging aids which shorten the time to validate the tester system functions. An example of implementing an automatic test system in accordance with these procedures is provided.

Abstract: A recent trend in operating system design [1,2,6,7] is to consider the design as a hierarchy of abstract machines. The problem is viewed as constructing a “users' machine” from a given hardware machine by means of software. Rather than do this in one large step, a progression of abstract machines are defined starting at the hardware machine and ending with the users' machine. Each new machine is “built from” the earlier machines, adding to their capabilities.This approach appears to be a strong positive step toward bringing more discipline to the software development process. Liskov [6, 7] carefully documents the advantages. She also tries to establish formal rules to guide the process and relates this approach to structured programming [3, 8].

Abstract: : Historically, vehicle-borne, radio-hybrid navigation system software has too often been designed around preselected navigation hardware on an ad hoc, system-by-system basis. In these developments, little attention has been paid to the inherent physical and functional commonality which underlies much of this superficially quite different software. This report documents the methods, and the very promising results, of the second phase of a software development effort directed at identifying and specifying a standardized, modular, flexible, radio- hybrid navigation system software processor.

Abstract: Dynamic verification of a decision implies that every time the decision is made there is a consistency check performed on the decision using independent hardware and software. The dynamic verification of operating system decisions is used on the PRIME system being designed and constructed at the University of California, Berkeley. PRIME is an experimental time-sharing system which is to have the properties of continuous availability, data privacy, and cost effectiveness. The technique of dynamic verification allows the construction of an operating system which does not make certain decisions improperly even in the presence of a single hardware or software fault. Furthermore, multiple faults lead to unreliable operation only if the faults happen to reinforce each other. On PRIME, dynamic verification is used to ensure that one user's information cannot become available to another user gratuitously even in the presence of a single hardware or software fault. The amount of additional hardware and software required for dynamic verification can be modest.