Content uploaded by Roland Petrasch
Author content
All content in this area was uploaded by Roland Petrasch on Dec 09, 2014
Content may be subject to copyright.
A preview of the PDF is not available
Einführung in das Software-Qualitätsmanagement
Abstract
Dieses Buch richtet sich an Software-Entwickler und Projektleiter in der Praxis, die einen Einstieg in das Thema Software-Qualitätsmanagement suchen und an Studierende, die das Lehrgebiet Software-Engineering in Richtung Qualitätsmanagement vertiefen wollen. Voraussetzungen für das Lesen sind prinzipiell nicht vorhanden, allerdings erleichtern Grundkenntnisse des Software-Engineering und speziell im Bereich der Entwicklung von Software-Systemen mit einer Hochsprache das Verstehen der Thematik.
Die Einführung in das Software-Qualitätsmanagement will in erster Linie die Software-Entwicklung mit dem Begriff Qualität derart verbinden, dass die Leserin oder der Leser eine Vorstellung von der mittlerweile recht eigenständigen und umfangreichen Disziplin des Qualitätsmanagements und den damit verbundenen Tätigkeiten, Dokumente und Rollen erhält, wobei der Schwerpunkt auf dem eigentlichen Software-Entwicklungsprozess liegt und die sicherlich ebenfalls wichtigen Bereiche wie das Projekt- und Konfigurationsmanagement nicht näher betrachtet werden.
Eine weitere Intention ist die Darstellung verschiedener Aspekte des Qualitätsmanagements: Es existiert eine Vielzahl von Normen, Standards und Methoden bzw. Techniken, so dass zumindest einige davon eine einführende und beispielhafte Erläuterung verdienen, z. B. die ISO 9000, das Capability Maturity Model, der Rational Unified Process, das V-Modell 97, das W-Modell und das Test Process Improvement (TPI®). die eine große praktische Bedeutung besitzen. Einige dieser Themen werden durch Gastbeiträge behandelt. Die Autoren der Beiträge, Thomas Blum, Ralf Kneuper, Tim Koomen, Martin Pol, und Andreas Spillner, sind Spezialisten im Bereich Qualitätsmanagement mit fundierten theoretischen Kenntnissen und langjährigen praktischen Erfahrungen (s. Autorenverzeichnis, S. 268f.).
Weiterhin sollen Verfahrensanweisungen, die bei einem Qualitätsmanagementsystem eine zentrale Rolle einnehmen, in leicht verständlicher Form und konkreten Ablaufbeschreibungen vermittelt werden, so dass eine Vorstellung von der Anwendung des Qualitätsmanagements entstehen kann. Auch auf die Problembereiche im QM-Umfeld sei hingewiesen, z. B. die Gefahr der Unflexibilität bei der Festschreibung der Prozesse in der Software-Entwicklung. Analytische Qualitätssicherungsmaßnahmen, die „nah“ am Code zur Anwendung kommen, z. B. der objektorientierte Modultest, und die Verifikation seien nur im Überblick beschrieben – zu groß wäre der Umfang durch die Vielzahl der Qualitätstechniken und Programmiersprachen.
... Standards shall and can help to define terms like quality [9]. Nevertheless, the means of expression used in standards are often not appropriate for the practice. ...
Probably everyone has an idea about the meaning of quality. However, when it comes to quality in the real world, i.e. in conjunction with a software development project, disagreements between the persons involved often lead to further problems. Especially in the case of customer complaints about faults in a software product, it seems to be unclear not only what the requirements are, but also if the software has the „right“ characteristics with regard to these requirements. This article aims to reduce the confusion arisen about quality, requirement and characteristic.
Wohl jeder hat eine Vorstellung über „Qualität“. Allerdings kommt es bei diesem Thema in der Praxis oft zu Differenzen, besonders bei der Diskussion über Qualitätsmängel zwischen Kunde und Software-Hersteller. Dabei genügt es nicht, den Qualitätsbegriff zu
definieren, um ein einheitliches Verständnis für Qualität bei den Beteiligten zu erreichen. Vielmehr sind qualitätsbestimmende Begriffe wie „Forderung“ und „Merkmal“
zu klären, Auch deren Verwendung im Entwicklungsprozessen ist zu anzugeben. Leider kommt die erwartete Unterstützung (noch) nicht von Normen und Standards wie beispielsweise der ISO9001 oder dem V-Modell 97, so daß es jedem Software-Entwicklungsprojekt selbst überlassen ist, was es unter Qualität versteht und wie mit
den Begriffen verfahren wird. Dieser Beitrag zeigt die Problematik des Qualitätsbegriffes auf und hilft, ein Verständnis für Qualität zu entwickeln, welches dem Stand der Wissenschaft der Informatik entspricht und dessen Vermittlung praxisnah und leicht nachvollziehbar ist. Die Erfahrungen mit dem hier vorgestellten Ansatz waren in Projekten, in denen er vermittelt und verwendet wurde, durchweg positiv.
Denver's new international air port was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously-in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag. At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its 1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open. To veteran software developers, the Denver debacle is notable only for its visibility. Studies have shown that for every six new large-scale software systems that are put into operation, two others are canceled. The average software development project overshoots its schedule by half; larger projects generally do worse. And some three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all. Photo of Dallas International Baggage Handling System: SOFTWARE GLITCHES in an automated baggage-handling system force Denver International Airport to sit empty nine months after airplanes were to fill these gates and runways (top). The system that is supposed to shunt luggage in 4,000 independent "telecars" along 21 miles of track still opened, damaged and misrouted cargo as testing continued in July (bottom). The art of programming has taken 50 years of continual refinement to reach this stage. By the time it reached 25, the difficulties of building big software loomed so large that in the autumn of 1968 the NATO Science Committee convened some 50 top programmers, computer scientists and captains of industry to plot a course out of what had come to be known as the software crisis. Although the experts could not contrive a road map to guide the industry toward firmer ground, they did coin a name for that distant goal: software engineering, now defined formally as "the
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’.
With the historical characterization of software development as being costly due to massive schedule delays, incorporation
of the ever-changing technology, budget reductions, and missing customer requirements, the trend of the 1990s in establishing
a quality improvement or a quality assurance programme has been over-whelming. The two popular models or frameworks for assessment
of a quality assurance programme are the US government-sponsored Capability Maturity Model (CMM) and the internationally recognized
ISO-9000 quality standards. Both of these two frameworks share a common concern regarding software quality and process management.
Since it is not clear which of these two frameworks is most effective in achieving their shared objectives, it is valuable
and timely to provide an objective overview of both models and to compare and contrast their features for quality software
development. Because there are many legitimate areas for comparison, we have selected the two most important as a basis for
comparison: (1) the role of management, and (2) the application of measurements. We also provide a summary of the reported
impact of these two models on the organizations adhering to their standards, and include our observations and analysis.
Successful management of any process requires planning, measurement, and control. In programming development, these requirements translate into defining the programming process in terms of a series of operations, each operation having its own exit criteria. Next there must be some means of measuring completeness of the product at any point of its development by inspections or testing. And finally, the measured data must be used for controlling the process. This approach is not only conceptually interesting, but has been applied successfully in several programming projects embracing systems and applications programming, both large and small. It has not been found to “get in the way” of programming, but has instead enabled higher predictability than other means, and the use of inspections has improved productivity and product quality. The purpose of this paper is to explain the planning, measurement, and control functions as they are affected by inspections in programming terms.
A method and a set of supporting tools have been developed for an improved integration of user interface design with software engineering methods and tools. Animated user interfaces for database-oriented applications are generated from an extended data model and a new graphical technique for specifying dialogues. Based on views defined for the data model, an expert system uses explicit design rules derived from existing guidelines for producing the static layout of the user interface. A petri net based technique called dialogue nets is used for specifying the dynamic behaviour. Output is generated for an existing user interface management system. The approach supports rapid prototyping while using the advantages of standard software engineering methods.
The author examines the state of computer science education and discusses the trend whereby computer science graduates are ending up in engineering jobs. He questions whether this back door to engineering is in the best interests of the students, their employers, and society. He argues that computer science programs must return to a classical engineering approach that emphasizes fundamentals.< >
Zusammenfassung Die Dienstleistungsgesellschaft stellt hohe Anforderungen an einen Software-Ingenieur1 in heutigen Industrieprojekten. Punktuelle Erfahrungen aus der Praxis zeigen Defizite der Ausbildung bezüglich dieser Anforderungen
auf, geben aber auch Hinweise zur Behebung dieser Defizite. Dabei wird deutlich, daß eine Konzentration der Ausbildung auf
Objektorientierung nicht nur einen Bedarf der Industrie per se erfüllt, sondern zusätzliche Chancen für eine Verbesserung
der Ausbildung bietet. Wichtiger sind Ausbildungsschwerpunkte auf Kommunikation, Modellierung, Entwurf und Entwurfsmuster
als auf bestimmten Programmiersprachen.