Softwaretechnik Folge 2 Prinzipien und Modelle der Softwaretechnik

Transkript

1 Skript zur Vorlesung Folge 2 Prinzipien und Modelle der IT Kompaktkurs Sommersemester 2001 Prof. Dr. Georg Herde Fachhochschule Deggendorf

2 In dieser Folge werden wir uns mit den Grundprinzipien der oder man kann auch sagen dem Software Engineering beschäftigen. Sie sehen die englische Bezeichnung hat die ingenieurmäßige Ausrichtung bereits im Namen verankert und trifft damit den Sachverhalt m.e. einwenig besser. Lassen Sie uns zu Beginn noch einmal eine Definition von bzw. Software Engineering ansehen, die Helmut Balzert favorisiert. Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen. Zielorientiert bedeutet die Berücksichtigung z.b. von Kosten, Zeit, Qualität. Nun das erste wichtige was uns die Definition mitteilt, ist das die Software-Technik planerisch bzw. zielorientiert vorgeht und dazu entwickelte Prinzipien, Methoden und Werkzeuge zur Verfügung stellt. Das bedeutet, das die Software-Technik hauptsächlich auf umfangreiche Software-Systeme abstellt, die arbeitsteilig durchgeführt werden und sich somit also hauptsächlich an größere Entwicklungsteams richtet. Die Definition legt anscheinend nahe, das kleinere Softwareschmieden mit ein paar Mitarbeiter und überschaubaren Projekten nicht unbedingt die Zielgruppe der Software- Technik sind!? Ich glaube das alle Personen, die sich mit der professionellen Entwicklung von Software beschäftigen, Nutzen aus der Beschäftigung mit der Software-Technik besser dem Software Engineering ziehen können, denn die Entwicklung von Software ist ein industrieller Prozess und hat nichts mehr mit einem freischaffenden Künstlertum zu tun. Der Wettbewerb diktiert Kosten, Zeit und Qualität, so dass auch kleinere Softwareunternehmen moderne, effiziente und kostengünstige Verfahren zur Softwareentwicklung anwenden müssen. (Folie: Methodenkomponenten) Wissenschaftliche Prinzipien: Bei der Abstraktion versucht man z.b. Klassen oder Gruppen von Objekten zu bilden die sich bezüglich ausgewählter Eigenschaften zusammen fassen lassen. Z.B. in der Biologie spricht man von der Gruppe der Paarhufer, oder der Gruppe der Säugetiere, d.h. es wird nur auf ein paar kennzeichnende Merkmale bei der Klassifizierung abgestellt. (Folie: Wissenschaftliche Prinzipien) Methodenkomponenten: In der Software-Technik stellen die Prinzipien somit den theoretischen Rahmen dar. Die Software-Technik stellt aber gleichzeitig Methoden als Hilfsmittel zur Verfügung um die Prinzipien zu operationalisieren. (Folie: Methodenkomponenten) So können wir mit Hilfe von methodischen Vorgehensweisen, die uns konkrete Schritte, Regeln und Verfahren zur Verfügung stellen unsere Prinzipien umsetzten, d.h. die Prinzipien zeigen uns den Weg zu etwas hin. (Folie: Prinzip Vorgehensweise) Seite: 2 von 6

3 Die Kontrollstruktur der Wiederholung, d.h. ein Programm soll eine bestimmte Anweisung oder eine Gruppe von Anweisungen einige Male wiederholen, kann als ein solches Konzept bezeichnet werden, denn dieses Konzept kommt in den verschiedensten Programmiersprachen vor. Auf Kontrollstrukturen und Algorithmen gehen wir aber noch genauer in der nächsten Folge ein. Konzepte Notationen: Die einzelnen Konzepte werden durch verschiedene Notationen dargestellt und vermittelt. Die verschiedenen Notationsformen reichen von einer kaum formalisierten bis zu sehr formalisierten Arten. So finden wir als mögliche Formen der Notation Klartexte, Struktogramme, Programmablaufpläne, Entity-Relationship-Diagramme, Petrinetze oder den Pseudocode einer konkreten Programmiersprache. (Folie: Konzepte -> Notation) Verfahren Werkzeuge: Wie der Name schon sagt, Werkzeuge helfen uns bei der praktischen Umsetzung unserer Verfahren. So wie ein Autofahrer weiß das er auf bestimmten Streckenabschnitten der Autobahn nur 130 km/h fahren darf, so sehr hilft ihn ein Tempomat der ihm automatisch bei der Umsetzung unterstützt. Ein Softwareentwickler möchte strukturiert programmieren und nur bestimmte Kontrollstrukturen anwenden und nun gibt es Werkzeuge die seinen Quellcode überprüfen das z.b. keine Labelvereinbarungen oder Sprungbefehle verwendet wurden, d.h. ein sogenannter Spagetticode wird dadurch vermieden. (Folie: Verfahren -> Werkzeuge) Nachdem wir uns mit Prinzipien und Methoden beschäftigt haben wollen wir uns jetzt mit Modellen beschäftigen. Nun es werden keine räumlichen Modelle gebaut sondern man modelliert die Vorgehensweise, d.h. man überlegt in welcher Reihenfolge läuft ein typischer Softwareentwicklungsprozess ab. Gibt es bestimmte Stationen oder bedeutende Schritte die man erreichen oder ausführen sollte? (Folie: Softwarelebenszyklus) Es wird davon ausgegangen das Software nicht unbegrenzt im Einsatz ist und vom Zeitpunkt ihrer Entwicklung bis zur Ablösung durch eine andere Software bestimmte Stationen erreicht. Man spricht vom sogenannten Softwarelebenszyklus. (Folie: Lebenszyklusphasen) Für diese einzelnen Phasen, deren Übergänge teils fließend andere wiederum auf einen definierten Zeitpunkt fixiert werden können, werden die einzelnen Tätigkeiten und die Rollen und Aufgaben der beteiligten Personen (Entwickler, Kunde und Anwender) genau festgelegt. Ferner wird vereinbart welche Dokumente nach welchem Muster zu erstellen sind und ob bestimmte Werkzeuge eingesetzt werden sollen. (Folie: Die Planungsphase) In einem ersten Schritt (der Planungsphase) wird hier durch Voruntersuchungen getestet ob das Entwicklungsprojekt überhaupt durchführbar und realisierbar ist. Als greifbares Ergebnis erhält man ein Pflichtenheft, das zu diesem Zeitpunkt noch recht allgemein formuliert ist und als Lastenheft bezeichnet wird. Hier werden auch die Begrifflichkeiten festgelegt und definiert, so dass alle Projektbeteiligten die gleiche Sprache sprechen und die gleichen Termini verwenden. Seite: 3 von 6

4 Durch genau abgegrenzte Begriffe sollen Missverständnisse zwischen Auftraggeber, Entwickler und Anwender vermieden werden, so dass die Software sich nachher möglichst so verhält wie von allen Beteiligten erwartet. Dieser Punkt bekommt in der nächsten Phase noch größere Bedeutung. In dieser ersten Phase werden darüber hinaus aber noch wirtschaftliche Aspekte betrachtet, z.b. zu welchen Kosten ist so eine Entwicklung zu bewerkstelligen, mit anderen Worten wie viele Mitarbeiter sollen wie lange für das Projekt eingesetzt werden. Das wichtigste Ergebnis dieser Phase heißt Stop or Go! Wird das Projekt durchgeführt werden oder sprechen zu viele Argumente gegen eine Realisierung, d.h. das Projekt wird eingestellt. Das können viele Argumente sein, sie reichen von fehlendem Personal in der Entwicklung, der zeitliche Rahmen kann zu eng gesteckt sein, dass Budget ist zu knapp bemessen oder eine Kombination mehrerer dieser Gründe. (Folie: Definitionsphase) Heißt jedoch die Entscheidung Go nach der ersten Phase werden in der Definitionsphase grundsätzliche Weichen für die spätere Zufriedenheit aller Beteiligten gestellt. Hier sollte klar und unmissverständlich dargelegt werden was man sich von dem System verspricht, was es können muss und welche features nice to have sind. Das Begriffslexikon wird erweitert, das Lastenheft wird zu einem konkreten Pflichtenheft und das bindet schließlich den Entwickler aber auch den Auftraggeber. Eventuell gibt es bereits einen kleine Prototyp oder aber die Benutzeroberfläche wird schon mal programmiert so dass man sich die zukünftige Funktionalität des Programms schon einmal anschauen kann. Manche Entwickler legen schon zu diesem Zeitpunkt die erste Version des zukünftigen Benutzerhandbuches vor, dass natürlich im Laufe des Entwicklungsprozesses vervollständigt wird. (Folie: Die Designphase) Ziel der Entwurfsphase ist es aufbauend auf der Produktdefinition gemäß der Anforderungsund Definitionsphase ein Produktentwurf zu erstellen. Hier werden die Rand- und Umweltbedingungen in denen das System funktionieren soll spezifiziert. Es ist die Arbeit eines Architekten der die Systemkomponenten beschreibt. Ähnlich wie beim Hausbau fragt sich der Architekt in dieser Phase wo kommen die Anschlüsse des Hauses für die Energie-, Wasser- und Abwasserversorgung her? Wie soll die Hausfront gestaltet werden um sich möglichst harmonisch in die Umgebung einzupassen? In der Softwareentwicklung nennt man die Planungsphase Programmieren im Großen, d.h. es werden Fragen der Systemsoftware (Betriebssystem), der Datenbank, der grafischen Benutzeroberfläche geklärt. Wie soll das System eingesetzt werden, handelt es sich um ein Echtzeitsystem, um Single- oder Multiusersystem. Wie wird die Vernetzung aussehen, und zu welche anderen Systeme müssen Verbindungen aufgebaut werden. (Folie: Implementierungsphase) In der Implementierungsphase findet schließlich die Programmierung im Kleinen statt, d.h. die eigentliche Softwaresystem entsteht. Seite: 4 von 6

5 Um in unserem Hausbaubeispiel zu bleiben wird jetzt Beton gemischt, der Keller gegossen, gemauert und Decken und Dachstühle werden hochgezogen. Bei der Softwareerstellung werden nun die Datenstrukturen und Algorithmen festgelegt und es wird in einer Programmiersprache codiert. Die gewählten Problemlösungen werden dokumentiert. Es wird ausgiebig getestet und geprüft und man versucht eine möglichst hohe Korrektheit und Zuverlässigkeit des Programms zu erreichen. Es werden Aussagen über die Leistungsfähigkeit und das Laufzeitverhalten bei bestimmten Beanspruchungen gemacht. Als greifbares Ergebnis liegen der Quell- und Objektcode mit seiner Dokumentation sowie Test- und Prüfberichte vor. (Folie: Abnahmephase) In der Abnahmephase wird nun die Software an den Auftraggeber übergeben und es wird ein Abnahmetest durchgeführt. Die Software wird beim Auftraggeber installiert und die Endanwender werden geschult. Es erfolgt letztendlich die offizielle Inbetriebnahme, d.h. der Produktivbetrieb wird gestartet. Als greifbares Ergebnis liegen jetzt die gesamte Dokumentation des Produktes, ein Abnahmeprotokoll und ein Einführungsprotokoll, dass den Übergang vom Test- zum Produktivsystem dokumentiert, vor. (Folie: Wartungsphase) Die Wartungsphase kann in der Regel als die längste Phase angesehen werden, sie läuft bis das System letztendlich komplett durch ein anderes System ausgetauscht wird. In dieser Phase werden vier Hauptaktivitäten unterschieden. Das System wird stabilisiert und es werden Korrekturen vorgenommen. Das System wird getuned um z.b. einer gestiegenen Benutzeranzahl oder einer stärkeren Auslastung gerecht zu werden (Optimierung und Leistungsverbesserung). Es werden die ersten Anpassungen und Änderungen vorgenommen Das System wir erweitert und den gestiegenen Anforderungen angepasst. Auch hier sind wieder Parallelen zu unserem Hausbaubeispiel zu erkennen. Pflege und Wartung des Hauses ist unerlässlich und dauert eigentlich so lange wie das Haus genutzt wird. Die Fassade wird neu angestrichen, die alte Isolierung wird durch eine bessere ausgetauscht und ein plötzlicher Kindersegen macht den Dachausbau notwendig. die einzelnen Phasen des Softwarelebenszyklus haben wiederum zu Vorgehensmodellen bei der Softwareentwicklung geführt. Ein bekanntes aber in der Literatur stark kritisiertes Modell ist das sogenannte Wasserfallmodell. (Folie: Wasserfallmodell) Hier finden sich die einzelnen Phasen wieder und so wie ein Wasserfall über mehrere Stufen fließt, kann hier erst mit der nächsten Stufe begonnen werden, wenn die vorhergehende beendet ist. Vorteil ist hier das die Aktivitäten logisch gegliedert sind und die einzelnen Gruppen definierte Vor- und Nachbedingungen erhalten und das jede Phase kosten- und terminmäßig besser überschaubar ist. Seite: 5 von 6

6 Allerdings stecken in diesem Ansatz auch eine Menge von Probleme. So wird z.b. unterstellt das sich während des Projektes nichts ändert. (no change assumption). Modifizierte Verfahren erlauben jedoch Rückgriffe zwischen den Stufen. Nachteile sind das eine stark serialisierte Projektentwicklung unterstellt wird und das am Ende einer Phase alle Probleme vollständig erkannt (perfect understanding) und gelöst wurden. Dieses Modell bietet immerhin eine Dokumentationsvorschrift, wenn auch böse Zunge behaupten das zumindest der Misserfolg dokumentiert wird. Ich habe dieses Modell hier ausgewählt weil es u.a. den Entwicklungsprozess in der Wissenschaft der Softwareentwicklung einwenig zeigen kann. Zu Beginn der Softwareentwicklungszeit, ähnlich der damals vorherrschenden Technologie wurde sequentiell gedacht und programmiert. Ein Programm entwickelt sich Schritt für Schritt nach einander. Von diesem reinen sequentiellen Ansatz ist man weggegangen. Heute werden andere Modellansätze verfolgt. Objektorientierte Ansätze folgen einem inkrementellen bzw. evolutionären Modellansatz. Eine Gemeinsamkeit von Evolutionärem Modell und dem Wasserfallprinzip ist, dass die Entwicklung stufenweise erfolgt. Dies Stufen sind jedoch nicht identisch mit den Stufen des Wasserfallmodell, denn in diesen neuen Ansätzen werden z.b. innerhalb einer Stufe für alle Teilprodukte alle Phasen durchlaufen. Im inkrementellen Ansatz werden daher ausgehend von einem Teilprodukt stufenweise die anderen Teilprodukte in Ausbaustufen mit dem Kernprodukt zusammengesetzt, wobei für alle Teilprodukte die herkömmlichen Phasen der Softwareentwicklung durchlaufen werden. Die Wartung wird somit integrativer Bestandteil der Entwicklung. Das evolutionäre Modell liefert bereits nach einer kurzen Entwicklungsdauer eine sogenannte Nullversion. Aufbauend auf den Erfahrungen der Benutzer werden dann stufenweise neue Anforderungen ergänzt. Böse Zungen würden hier behaupten es handelt sich um sogenannte Bananensoftware die erst beim Kunden reifen würde. Der Unterschied zu einer Bananensoftware liegt dagegen darin, das der Reifeprozess mit dem Kunden von vornherein vereinbart wurde, er ist sozusagen Bestandteil des Entwicklungsprozesses. Der Anwender und Kunde wird mit in die Entwicklung mit einbezogen, man spricht auch von Pilotkunden. Seite: 6 von 6