Structure for Dependability: Computer-Based Systems from an Interdisciplinary Perspective / Edition 1 available in Paperback
Most Helpful Customer Reviews
Structure for Dependability: Computer-Based Systems from an Interdisciplinary Perspective based on 0 ratings. 1 reviews.
This volume consists of chapters which are written to support and reinforce one another. They occur in a logical simple-to-complex sequence. However, each chapter may be considered as a stand-alone contribution. The role of structure: a dependability perspective. (Cliff B Jones, Brian Randell) identifies a number of technical terms in the socio-technical domain, defines them and provides examples. The role of structure: a software engineering perspective. (Michael Jackson) Presented at the first level of detail, it explains various methods of designing software for large computer systems. Knowledge of computer systems is necessary to interpret the information. Structuring evolution: on the evolution of socio-technical systems. (Massimo Felici) Emphasis is placed on understanding the social aspect of socio-technical computerized systems. There is considerable reference to Kripke models. Knowledge of logic mathematics is essential to fully comprehend the various concepts presented. Time bands in systems structure. (Alan Bums, Gordon Baxter) Computer systems are examined from a time aspect -- from less than a microsecond to more than a month. A band is represented by its granularity (a unit of time that has meaning within the band) and its precision (a measure of the accuracy by the time frame defined by the band). Procedures, programs and their impact on dependability. (Denis Besnard) Attention is given to the basic man-machine (human-computer) system with a dual emphasis on human and machine system error. This area historically has been called by many names including: human performance engineering, human factors engineering, ergonomics, engineering psychology, and systems engineering to name a few. In essence, it deals with the man-machine relationship in all of its many forms. Cognitive conflicts in dynamic systems. (Denis Besnard, Gordon Baxter) Cognitive conficts describe the inability of system elements to reach a satisfactory goal or conclusion. All of the examples provided are in the commercial aircraft environment and more specifically in the cockpit or flightdeck. Architectural description of dependable software systems. (Cristina Gacek, Rogerio de Lemos) The architecture of a system is what determines the system behavior. Architectural Description Languages (ADLs) are used by software engineers to support the hardware structure. Computational diagrammatics: diagrams and structure. (Corin Gurr) Diagrams, including graphs and flowcharts, are described as being useful in representing system elements and procedures. Ethnography and the social structure of work. (David Martin, Ian Sommerville) This chapter deals with 'the world of work' as it has been known historically to vocational/occupational educators. While it focuses on some ethnographic issues there is no recognition of methods of job and task analysis or industrial engineering commonly used in the U.S. and other developed nations involving man-machine systems. Faults, errors and failures in communications: a systems theory perspective on organisational structure. (Peter Andras, Bruce Charlton) While attention is directed to systems theory in general, little is given to human error analysis in computer-based software/hardware systems. Security implications of structure. (Jeremy Bryans, Budi Arief) A brief general overview of several basic issues dealing with security problems in large social-technical computer-based systems. The structure of software development thought. (Michael Jackson) The separation of software engineering from physical science engineering in the real-world is noted. A series of problems and their solutions is provided to illustrate how the designer reasons through the parameters and assigns parameter values. A reader with a technical orientation should have little difficulty in understanding the process which is couched in software terminology. On the use of diverse argument