Abstract: Software designed to function in a hard-real-time environment where strict timing constraints must be met often entails implicit assumptions about a programming language and the underlying system which supports it. Programs which are logically correct, i.e., they implement the intended algorithms, may not function correctly if their assumed timing characteristics of the software or if the expressible timing characteristics cannot be verified before run time. For distributed systems in particular, the software must be tailored to a myriad of implementation parameters, e.g., communication bandwidth, thus rendering subsequent modifications hazardous. Our research investigates the basic problems in automating the design and maintenance of hard real-time software. After examining the limitations of the traditional approach to real-time software design via process-based models, we shall provide a graph-based computation model which is more suitable for expressing the computation requirements of the real-time environment. This model is an extension of CONSORT (Control Structure Optimized for Real-Time), an experimental software design system which has been implemented to generate process control application programs from block diagram schemata. While our graph-based model is abstract, it can serve as a useful intermediate representation between textual requirements specifications and target application programs. Using the graph-based model, the complexity of the relevant resource allocation problems for meeting stringent timing constraints is investigated.

Abstract: This book should be either read carefully, or at least skimmed, by almost all programmers, programming managers, and any people concerned with the realities of software and software systems The author defines "Software psychology" on p 3 as:The study of human performance in using computer and information systems Understanding of human skills and capacity to design effective computer systems can be improved by application of the techniques of experimental psychology; the analysis of cognitive and perceptual processes; the methods of social, personnel and industrial psychology; and the theories of psycholinguistics

Abstract: Numerical Methods, Software, and Analysis, Second Edition introduces the methods, tools, and ideas of numerical computation.

Abstract: With the increased use of software controls in critical realtime applications, a new dimension has been introduced into software reliability–the "cost" of errors. The problems of safety have become critical as these applcations have increasingly included areas where the consequences of failure are serious and may involve grave dangers to human life and property. This paper defines software safety and describes a technique called software fault tree analysis which can be used to analyze a design as to its safety. The technique has been applied to a program which controls the flight and telemetry for a University of California spacecraft. A critical failure scenario was detected by the technique which had not been revealed during substantial testing of the program. Parts of this analysis are presented as an example of the use of the technique and the results are discussed.

Abstract: Software engineering: design, reliability, and management , Software engineering: design, reliability, and management , مرکز فناوری اطلاعات و اطلاع رسانی کشاورزی

Abstract: Methods proposed for software reliability prediction are reviewed. A case study is then presented of the analysis of failure data from a Space Shuttle software project to predict the number of failures likely during a mission, and the subsequent verification of these predictions.

Abstract: The theory of software science was developed by the late M. H. Halstead of Purdue University during the early 1970's. It was first presented in unified form in the monograph Elements of Software Science published by Elsevier North-Holland in 1977. Since it claimed to apply scientific methods to the very complex and important problem of software production, and since experimental evidence supplied by Halstead and others seemed to support the theory, it drew widespread attention from the computer science community.

Abstract: A decision procedure to determine when computer software should be released is described. This procedure is based upon the cost-benefit for the entire company that has developed the software. This differs from the common practice of only minimizing the repair costs for the data processing division. Decision rules are given to determnine at what time the system should be released based upon the results of testing the software. Necessary and sufficient conditions are identified which determine when the system should be released (immediately, before the deadline, at the deadline, or after the deadline). No assumptions are made about the relationship between any of the model's parameters. The model can be used whether the software was developed by a first or second party. The case where future costs are discounted is also considered.

Abstract: This paper discusses the goals and methods of the Toolpack project and in this context discusses the architecture and design of the software system being produced as the focus of the project. Toolpack is presented as an experimental activity in which a large software tool environment is being created for the purpose of general distribution and then careful study and analysis. The paper begins by explaining the motivation for building integrated tool sets. It then proceeds to explain the basic requirements that an integrated system of tools must satisfy in order to be successful and to remain useful both in practice and as an experimental object. The paper then summarizes the tool capabilities that will be incorporated into the environment. It then goes on to present a careful description of the actual architecture of the Toolpack integrated tool system. Finally the Toolpack project experimental plan is presented, and future plans and directions are summarized.

Abstract: The results of a survey of software development practice are reported and analyzed. The problems encountered in various phases of the software life cycle are measured and correlated with characteristics of the responding installations. The use and acceptance of the term "software engineer" is investigated, and the functions and background of persons identified as software engineers are reported. The usage of a wide variety of software engineerilng tools and methods is measured; conclusions are drawn concerning the usefulness of these techniques.

Abstract: The availability of good software tools is vitally important to practitioners of simulation. The purpose of this paper is to identify significant improvements that will be made in simulation software in the next 10 years. While based upon review of ongoing research efforts in programming systems, a paper such as this is necessarily speculative. Substantial research effort is already underway. Numerous papers-even entire books-describe current research and comment upon trends for the future. Since most of the current research in programming systems is being conducted in other problem contexts, we must look outside the discipline of simulation for most of our examples. In doing so, we must be careful to assess the applicability of such examples to simulation, for techniques that are successful within a narrow focus may not be readily extended to such a broad discipline as simulation. There is great cause for optimism: it appears likely that simulation practitioners of the future will work in an environment comprised of well-integrated software tools. The integrated software environment of the 1990s will make present state-of-the art simulation software tools look as primitive as the building of simulation models entirely in high-level languages like Fortran looks today.

Abstract: : With the ever-increasing role that software is playing in the weapon systems, a great need has arisen for tools that are useful in developing cost-effective software. An area of research has arisen over the last 10 years in providing a software manager quantitative statements about the reliability of the software. Using this quantitative measure, the manager can make a determination of when software testing should terminate and how to best utilize testing personnel. This report discusses the various approaches that have been advocated for reliability estimation. It reviews the various models that have been proposed for this estimation process, providing the model assumptions, the estimates of reliability, the precision of those estimates, and the data required for their implementation. A comparison is then made among some of these models based upon studies that have been done. General comments concerning software reliability implementation are discussed in the final section of the report.

Abstract: Similarly, \"superior communication\" in the manmachine interface refers to an approximation of human communication. Users want software that allows input and otput in less esoteric formats. The operator should have to descend to the level of the machine and Agage in dialog at each and every step. Voice I/O and dati processing in natural languages are sterling examples of superior communication. The rapid growth of software

Abstract: A set of criteria is proposed for the comparison of software reliability models. The intention is to provide a logically organized basis for determining the superior models and for the presentation of model characteristics. It is hoped that in the future, a software manager will be able to more easily select the model most suitable for his/her requirements from among the preferred ones.

Abstract: Software project scheduling is one of the major problem areas faced by software project managers today. While several quantitative software project resource and schedule estimation methods have been developed, such techniques raise some important, but as yet unresolved, dynamic issues. A systems dynamics (SD) approach is used to analyze several key dynamic software project scheduling issues.

Abstract: In this article* wxe oftfei a VisiOI of the future. It has beconme evidenit that there are serious problems to address concerning the productioni and suppoi-t of computer software and that a significanit effort is needed to improve the situationi. The demand for computeisoftware is skvrocketing, anid the meanis to meet this demand are glaringly inadequate. In the national economy, the need for software is groving rapidly as organizations strive to increase productivitv through automationi and to improve product versatility and market appeal through the use of coinputers. In systems where software is a ci-itical component, it is essential to obtain software that performs well, doesn't cost too mnuch, and is mainitainable over the projected systemn lifetime in short, software that is reliable, afJfordable, and adaptable. The cenitral questioni we address in this article is how to achieve a state-of-practice in the 1990's where we can build emibedded computer system software with adequate levels ot productiuit'v, udaptability, and reliabilitv-that is, what will it take to achieve PAR by 1990? To answver this question, wve take a gliiripse at the quan titative dimensions of the sotxtware demand-supply gap. How bie is it? AWe cite sevexial economic analyses of pioductivitx that lead rather torcefullv to the conclusioni that there are no sinple panaceas for the software problemiis we face. To the contrary, the economic analyses stronglv indicate that xve must rnake a wide-ranging, Lubstanitial attack on many constituent problems over a long period of time if we are to be successful. In short, the overall improvement we need must come from a large number of component improvements, each of which cointributes meaningfully, bLut not overwhelmingly, to the whole. We are convinced that success in cornbatting the software demanid-supply gap can conme only if we learn to rnanage a large nuimbei of vaiiables skillfully and if the coiriponents to the overall solution integrate well. Cottpleteness and integration are, therefore, tvo key concepts in our vision. Many componenits of the software production infrastiucture need to be improved and integrated, anid we examine various stages of growth of the computer industry vith an eye toward identifying catalytic forces that cain be employed to stimulate the adoption of greater levels of shared infrastructure oIn which value-added productioni methods can be based and that allow, for irnproved productivity. this sets the stage for introducing the various elements of our vision of the future: how the Ada program can be shaped to seive as a catalyst for the introduction of highly integrated, complete software life-cycle support environments of high potential payoff; effective policies for technology insertion; policies for stimulating the adoption of greater levels of shared infrastructure; and how a proposed Software Engineering Institute can play a key role in collecting, integrating, and spreadinig improved tools, practices, and skills. Howimight the future be different if the improved elements we have envisaged were in place and operating successfully in the 1990's? W'hile we believe that no new technological breakthroughs will be needed to accomplish the improvements we seek, achieving organizcational breakthroughs will be essential. Such organizational breakthroughs must succeed in collecting and integrating tools and in providing integrated support for softvare practices of proven effectiveness.

Abstract: ion/Refinement • develop a systematic approach to the development of a solution • the top-down approach to solution development • refinement of a proposed solution • modification of an existing solution Data types • select the most appropriate data type for the solution to a particular problem and discuss the merit of the chosen type • data types used in solutions, including: – integer – string – floating point – boolean – date and currency format • data structures, including: – one-dimensional array – record – sequential files • limits of particular data types • integer representation in binary, decimal, octal and hexadecimal • the impact of hardware/software limits on different data types Structured algorithms • interpret and create algorithms represented in both pseudocode and flowcharts • methods for representing algorithms: – pseudocode – flowcharts • identify control structures in an algorithm • control structures: – sequence – selection (binary, multiway) – iteration (pre-test, post-test), including: for ... next loops • software structure – subroutines • detect logic errors in an algorithm by performing a desk check – modularity • use of standard algorithms, including: – load and print an array • gather solutions from a number of sources and modify them to form an appropriate solution to a specified problem – process records from a sequential file • checking the algorithm for errors • historical events that led to the development of a structured approach to algorithm design

Abstract: Software is increasingly being used in the control of potentially hazardous systems Software fault-tree analysis is a technique for analyzing the logic of software for any potential contribution to system mishaps The technique is described using Ada as an example real-time language Special consideration is given to the problems of concurrency and real-time constraints which are common in these types of applications

Abstract: Issues in the development of a new package of computer-aided control system design software are presented. The scope of the project is limited to the organization of existing results into a unified body of software, and the development of a standardized set of tools and services which allow long-term maintenance and growth of the package and support the user community. Issues which influence language selection, graphics requirements, core algorithm selection, model description requirements and software tools, and future hardware expectations are addressed.

Abstract: A brief introduction describes the characteristics of configuration management and outlines the key issues of knowledge and control of content, along with the targets developed for configuration management. Software, as a relatively new discipline, is still evolving standard techniques. The special properties of software which cause difficulty in configuration management are discussed. The theme moves to the planning of configuration management in order to support the reliability program. While many organisations consider con-figuration management at the end of development, the reasoning and recommendations (based on experience) are given for applying configuration management during the entire development and life of a project. The paper shows how to implement software configuration management and describes the method used in YARD. It concentrates on the view of the system by all users, and the impact on the ability to send software to customers with confidence, keep track of reported defects, and trace the effect of modifications on all issued software. The software configuration control system is the foundation on which all reporting systems must be based. It is an entirely different matter accumulating and analysing failure reports on some object like a pressure transducer, the configuration control for which is easily identified, than a large software-based system undergoing continual evolution and correction. The use of computers to maintain configuration control discipline on software is essential and, in our experience, works.

Abstract: The 3B20D Processor software development system is an integrated collection of tools and procedures that is used in the development and administration of all 3B20D Processor software. This article describes the tools and procedures and their use in developing the 3B20D Processor software. These tools and procedures include compilers, assemblers, and loaders, as well as change-administration and load-building procedures. The most important characteristic of the development system is the balance between the enforcement of the project standards and the flexibility offered to developers.