Chapter

Erstellung und Prüfung sicherheitsgerichteter Software

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

Die Qualitätssicherung von Software wird noch einmal aufgegriffen. Dazu werden durch Verschärfung und Vereinfachung aus einer internationalen Norm abgeleitete Richtlinien zur Konstruktion sicherheitsgerichteter Software angegeben. Es werden Verfahren zur Prüfung von Dokumentationen und Methoden zur effektiven und effizienten sowohl manuellen als auch automatisierten Prüfung eigentlicher Programme betrachtet. Analytische Qualitätssicherung wird anhand der industriellen Prüfung prozeßleittechnischer Software im Detail beschrieben.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

ResearchGate has not been able to resolve any citations for this publication.
Article
Substantial net improvements in programming quality and productivity have been obtained through the use of formal inspections of design and of code. Improvements are made possible by a systematic and efficient design and code verification process, with well-defined roles for inspection participants. The manner in which inspection data is categorized and made suitable for process analysis is an important factor in attaining the improvements. It is shown that by using inspection results, a mechanism for initial error reduction followed by ever-improving error rates can be achieved.
Article
This paper attempts to provide an adequate basis for formal definitions of the meanings of programs in appropriately defined programming languages, in such a way that a rigorous standard is established for proofs about computer programs, including proofs of correctness, equivalence, and termination. The basis of our approach is the notion of an interpretation of a program: that is, an association of a proposition with each connection in the flow of control through a program, where the proposition is asserted to hold whenever that connection is taken. To prevent an interpretation from being chosen arbitrarily, a condition is imposed on each command of the program. This condition guarantees that whenever a command is reached by way of a connection whose associated proposition is then true, it will be left (if at all) by a connection whose associated proposition will be true at that time. Then by induction on the number of commands executed, one sees that if a program is entered by a connection whose associated proposition is then true, it will be left (if at all) by a connection whose associated proposition will be true at that time. By this means, we may prove certain properties of programs, particularly properties of the form: ‘If the initial values of the program variables satisfy the relation R l, the final values on completion will satisfy the relation R 2’.
Article
For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.
Article
This paper describes an experiment in program testing, employing 59 highly experienced data processing professionals using seven methods to test a small PL/I program. The results show that the popular code walkthrough/inspection method was as effective as other computer-based methods in finding errors and that the most effective methods (in terms of errors found and cost) employed pairs of subjects who tested the program independently and then pooled their findings. The study also shows that there is a tremendous amount of variability among subjects and that the ability to detect certain types of errors varies from method to method.
Article
It is likely that most programmers who have heard anything at all about structured programming also have heard the mysterious names "Böhm" and "Jacopini." "Oh, yes," they'll say, "all that structured programming stuff was proved by those guys Böhm and Jacopini somewhere in Italy." And yet it's exceedingly unlikely that the average programmer has read the Böhm and Jacopini paper, "Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules," published in 1966. As you begin to read the paper, it will become immediately obvious that the discussion is of an extremely abstract, theoretical nature. Serious academicians accustomed to a regular diet of such papers will no doubt wade through this one, too --- but the average COBOL application programmer probably will be overwhelmed by the time he or she reaches the end of the first paragraph. I have read the paper myself several dozen times during the past twelve years, and honesty requires me to admit that I barely understand it for a period of five minutes after reading the last paragraph, it is certain that I would be at an utter loss to try to describe Böhm and Jacopini's proof to anyone else. I say this to help prevent an inferiority complex on the part of the average reader. This is an important paper, and it does form the theoretical basis of structured programming. So you should read it. But don't feel too embarrassed if most of it is over your head. Indeed, you'll find "The Translation of 'go to' Programs to 'while' Programs," by Ashcroft and Manna [Paper 6], to be much more understandable: They, too, show that any program can be written as a structured program by simply demonstrating that any program can be translated into an equivalent structured program. One last comment about the paper by Böhm and Jacopini: Note that it does not mention programming languages. It describes a set of flow diagrams as a "two-dimensional programming language," but it makes no mention of COBOL, ALGOL, PL/I, or any of the other languages that real-world programmers use. This is far more significant than you might think. What Böhm and Jacopini have proved in this paper is that any flowchart can be drawn from combinations of standard "structured" flowchart elements; they did not prove that any COBOL program can be written without goto statements. Indeed, if a programming language lacks the constructs to implement directly the Böhm and Jacopini flowcharts, goto-less programming is exceedingly difficult, if not impossible --- as witnessed by such degenerate languages as FORTRAN. This distinction between the theoretical possibility of structured programming, and the real-world practicality of structured programming is, of course, at the heart of the controversy and the squabbling that still goes on today, more than a decade after this paper was written. Examples of this controversy --- the theme of which is, "Yes, we know structured programming is theoretically possible, but do we really want to do it?" --- are seen in papers like Martin Hopkins' "A Case for the GOTO" [Paper 9], or Donald Knuth's "Structured Programming with go to Statements" [Paper 20].
Article
In this paper an attempt is made to explore the logical founda- tions of computer programming by use of techniques which were first applied in the study of geometry and have later been extended to other branches of mathematics. This in- volves the elucidation of sets of axioms and rules of inference which can be used in proofs of the properties of computer programs. Examples are given of such axioms and rules, and a formal proof of a simple theorem is displayed. Finally, it is argued that important advantages, both theoretical and prac- tical, may follow from a pursuance of these topics.
Verfahren und Werkzeuge zur Prüfung von DV-Software
  • P Muth
  • C Uhlig
Methoden und Verfahren zum systematischen Testen von Software
  • K Grimm
Automatische Prüfung der Software von Prozeßleitsystemen. GMA-Fachbericht 4, S. 79-89
  • R Konakovsky
  • P Woitzik
Merkmale von Wissens- und Informationstexten im Zusammenhang mit der Lerneffektivität
  • I Steinbach
  • I Langer
  • R Tausch
Softwaretechnologie. Reihe Informatik Nr. 33. B.I. Wissenschaftsverlag
  • F Stetter
Test-Techniken: methodisches Testen von Systemen und Programmen
  • P A Zimmermann
  • PA Zimmermann
Validation von Prozeßinformationssystemen
  • H Trauboth
Methoden und Werkzeuge eines Arbeitsplatzes für die Prüfung von Anwendersoftware
  • H Winkler
  • W.-S Schmied
Techniques of C1 coverage analysis
  • K Kishida
Ein Verfahren der rechnergestützten Messung der Software-Zuverlässigkeit. Tagungsband Technische Zuverlässigkeit, S. 245-253
  • R Konakovsky
Verständlichkeit von informationstexten: messung, verbesserung und validierung
  • F Schulz Von Thun