spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Zendee«

Mich würde mal interessieren wer von euch in der Spiele (und Software)-Branche arbeitet. Vielleicht könnt ihr ja mal erzählen wie es da vor sich geht ;-)

Zitat

5.5 Phasenmodell der Softwareentwicklung

Trennung zwischen Algorithmus und Programm spiegelt sich im zeitlichen Ablauf der Softwareentwicklung wieder: Software wird
zuerst entworfen (Ergebnis ist Algorithmus, z.B. in Form eines Struktogramms),
anschließend implementiert (Ergebnis ist fehlerfrei übersetzbares Programm);

Entwurf findet auf dem Reißbrett (im Kopf) statt; Programmtechnische Details bleiben unberücksichtigt; Im Idealfall neutral gegenüber der Implementierungssprache;

Implementierung hält sich strikt an den Entwurf; Findet am Rechner statt, nutzt die vorhandene Infrastruktur (in erster Linie die Entwicklungswerkzeuge);

5.5.1 Übersicht

Die beiden vorgenannten Schritte sind nur zwei aus einer längeren Folge von "Phasen";

Alle Phasen zusammen werden als "Software Lifecycle" bezeichnet;

Jede Phase liefert ein "Zwischenprodukt" als Ergebnis;

Das Produkt der vorhergehenden Phase dient der nächsten als Ausgangspunkt;

Phasen im Überblick:

Problemanalyse
Erste Phase im Prozeß der Softwareentwicklung. Vorgabe ist eine meist umgangssprachlich formulierte und entsprechend unscharfe Beschreibung des Problems. Ergebnis der Problemanalyse ist eine exakte und komplette Leistungsdefinition des zu entwickelnden Produktes. Dabei liegt das Gewicht auf dem "Was?" der angestrebten Lösung und bewußt nicht auf dem "Wie?".

Entwurf
Im Entwurf werden Algorithmen, Datenstrukturen, Schnittstellen usw. ausgewählt, mit denen die in der Leistungsdefinition fixierten Resultate erzielt werden können. Mit anderen Worten: Das "Wie?" wird festgelegt. Der Entwurf bezieht sich auf keine konkrete Programmiersprache, sondern sollte völlig neutral gegenüber einer späteren Entscheidung der Implementierungssprache gehalten werden. Ergebnisse des Entwurfes können z.B. Flußdiagramme oder Struktogramme enthalten, wahrscheinlich müssen für realistische Projektgrößen weitere Entwurfsdokumente dazu genommen werden.

Implementierung (Realisierung, Programmierung)
Die von der vorherigen Phase gelieferten Entwürfe werden in den Formalismus einer konkreten Programmiersprache gegossen. Obwohl der wahrnehmbare Aufwand in dieser Phase am größten ist, sind alle wichtigen Entscheidungen längst gefallen. Es geht nur noch um die technische Realisierung. Ergebnis der Implementierung ist ein ausführbares Programm.

Test
Es folgt die Testphase, in der das Programm systematisch durchgetestet wird. Diese Phase ist nach heutiger Erkenntnis eine der wichtigsten im ganzen Entwicklungsprozeß, weil Fehlerbehebung nach der Programmfreigabe sehr teuer kommt. Je früher Fehler behoben (oder von vorne herein vermieden) werden, desto rentabler ist ein Softwareprojekt. Ergebnis der Testphase ist ein einsatzbereites Produkt.

Wartung
Wird gerne verdrängt, ist aber von entscheidender Bedeutung. Software lebt oft viel länger als bei der Entwicklung geplant. Wartung umfaßt Fehlerkorrektur, Aktualisierung, Adaption an neue Hardware, Betriebssysteme, Umgebungen, etc.

Die hier genannten Phasen werden manchmal in feinere Schritte aufgelöst oder es werden zusätzliche Phasen dazugefügt. Über die oben beschriebenen Phasen besteht aber weitgehend Übereinstimmung. Einen guten und kompakten Überblick gibt z.B. [DeMarco79].

Entscheidender Punkt sind die Folgekosten eines Fehlers: Je später im "Software Lifecycle" ein Fehler aufgedeckt wird, desto höher sind die Kosten zur Behebung!

Die Konsequenz: Es lohnt sich viel mehr Aufwand in die frühen Phasen zu stecken, als in die späteren Phasen;

5.5.2 Wasserfall- und Spiralmodell

In früheren Jahren war das "Wasserfallmodell" populär.

Dieses ordnet die oben beschriebenen Phasen linear an: Jede Phase mündet in ein Zwischen- oder Endprodukt, das (zeitlich) anschließend von der nachfolgenden Phase aufgegriffen wird;

Es gibt keinen Rückweg! Das hat z.B. die Konsequenz, daß der Entwurf komplett abgeschlossen werden muß, bevor mit der Implementierung begonnen werden kann.

Dieses Wasserfallmodell hat sich bald als unrealistisch entpuppt, wird aber oft noch weiterhin propagiert, weil es sich vordergründig leicht verwalten und planen läßt.

Als viel wirklichkeitsnäher hat sich das "Spiralmodell" herausgestellt.

Im Spiralmodell folgen die Phasen nicht linear aufeinander, sondern wiederholen sie mehrfach reihum. Mit jedem Umlauf nähert man sich näher dem angestrebten Endprodukt an, bis letztendlich der Aufwand für die nächste Runde den zu erwartenden Fortschritt überwiegt.

Das Unangenehme am Spiralmodell ist die kaum vorhersagbare Anzahl Umläufe bis zur ausreichenden Nähe zum Idealprodukt.

5.5.3 Problemanalyse
Die Problemanalyse kämpft als Hauptproblem mit der Mehrdeutigkeit und Unvollständigkeit einer umgangssprachlichen Problembeschreibung. Auch Versuche, die Problemanalyse zu formalisieren, haben daran wenig geändert. Eine weitere Schwierigkeit ist das oft unterschiedliche Vokabular zwischen dem Informatiker, der die Problemanalyse betreibt, und dem Auftraggeber als Nicht-Informatiker, der die Lösung des Problems sucht.

Die Resultate der Problemeanalyse werden in einer Problembeschreibung gesammelt. Diese Problembeschreibung kann z.B. in Form eines "Pflichtenheftes" schriftlich niedergelegt werden. Beim Fixieren der Problembeschreibung muß darauf geachtet werden, daß keine stillschweigenden Annahmen gemacht werden oder scheinbare Selbstverständlichkeiten als beschlossen angenommen werden.

Ein allgemeines Rezept zur Abwicklung der Problemanalyse läßt sich nicht angeben. Die Art des Problems hat zu großen Einfluß auf die notwendigen Gewichte. Interaktive Probleme können z.B. einigermaßen erschöpfend in sogenannten "Szenarios" beschrieben werden, in denen typische oder kritische Abläufe als Sequenz von Dialog-Schnappschüssen vorgegeben werden. Für andere Problemstellungen, wie z.B. Systemsoftware, ist eine derartige Dialogbeschreibung weitgehend uninteressant.

In der Problemanalyse soll noch alle Alternativen bezüglich des weiteren Vorgehens offen lassen. Es werden lediglich die Fazetten des Problems untersucht, gesammelt und festgehalten. Ziel ist eine Bestandsaufnahme.
5.5.4 Entwurf
Der Entwurf spielt sich im Grunde auf dem Papier ab (auch wenn dabei graphische Software zur Unterstützung herangezogen werden kann). Im Entwurf werden die groben Entscheidungen über die Struktur des Produktes gefällt. Dabei werden implementierungstechnische Einzelheiten bewußt übergangen. Die Grenze zwischen Entwurfs- und Implementierungsentscheidungen ist aber verwaschen und nicht leicht zu ziehen.

Natürlich wird ein Entwurf schon mit Blick auf die nachher bei der Implementierung verfügbaren Möglichkeiten durchgeführt werden. Es hat nicht viel Sinn, Strukturen zu entwerfen, die nachher mit den verfügbaren Programmiersprachen und Systemmerkmale überhaupt nicht umgesetzt werden können.

Entwürfe haben Probleme mit Anforderungen, die nicht die Logik des Produktes betreffen. Ein Beispiel sind zeitliche Aspekte, wie etwa geforderte maximale Anwortzeiten im Dialog. Ein anderes Beispiel sind ergonomische Aspekte, die die leichte Bedienbarkeit betreffen. Derartige Randbedingungen sind nur mit sehr viel Erfahrung im Entwurf einzuhalten. In der Praxis läßt sich ein gewisses Maß an Experimentieren nicht umgehen. Dabei haben Methoden wie das "Rapid prototyping" Erfolg, bei denen Teile des Endproduktes schon frühzeitig bis zur Ausführbarkeit fortentwickelt werden, um erste Abschätzungen über das spätere Verhalten zu gewinnen.
5.5.5 Implementierung
Die Implementierung baut auf den Entwurfsdokumenten der Entwurfsphase auf und führt zu einem ausführbaren Programm. Dieser Phase wird meist ein zu hohes Gewicht eingeräumt, weil sie äußerlich den am leichtesten wahrnehmbaren Fortschritt mit sich bringt.

Die Implementierungphase erfordert weit mehr als bloß Kenntnisse der Syntax und Semantik einer Programmiersprache. Ganz ähnlich wie in natürlichen Sprachen lebt jede Programmiersprache von einem Schatz an Idiomen, d.h. Redewendungen, Ausdrucksweisen, stilistischen Regeln. Bezogen auf Programmiersprachen beschreiben Idiome funktionierende und bewährte Muster, nach denen sich Teilaufgaben lösen lassen. Im Gegensatz zu Syntax und Semantik sind Idiome kaum irgendwo ausdrücklich beschrieben, sondern werden von jedem Benutzer einer Programmiersprache im Laufe der Zeit durch Erfolge und Fehlschläge selbst zusammengetragen. Dieser Lernprozeß durch praktische Erfahrungen ist sehr mühsam, zeitraubend und kostspielig. In neuerer Zeit werden deshalb Ansätze unternommen, Programmieren von der syntaktischen und semantischen Ebene auf die höhere Ebene der Idiome zu verlagern. In diesem Gebiet findet gegenwärtig rege Forschungstätigkeit statt.

Endprodukt der Implementierungphase ist ein ausführbares Programm, das meist einige wenige grundlegende Tests bestanden hat.
5.5.6 Test
Die Testphase geht von einem in Grundzügen funktionierenden Programm aus und versucht, durch systematische Tests alle Schwachstellen aufzudecken. Die Testphase wird oft als destruktiv empfunden und daher mit innerlichen Vorbehalten angegangen. Man ist sich aus diesem Grund darüber einig, daß der Programmierer selbst den Test des eigenen Programms nicht in angemessener Tiefe durchführen kann. Statt dessen wird ein neutrale Instanz bemüht, die ohne Kontakt zu den Programmierern testet, um personenbezogene Beweggründe fernzuhalten.

Systematische Tests lassen sich grob in "black box tests" und "white box tests" einteilen.

"Black box tests"
betrachten das Programm als atomaren schwarzen Kasten ohne Innenstruktur, der auf gegebene Eingabedaten vorgeschriebene Reaktionen zu zeigen hat, wie es in der Problembeschreibung festgehalten ist. Auf dieser Grundlage werden Testdaten zusammengestellt, die systematisch Variationen und Grenzfälle von Eingabedaten durchspielen. Für jeden Testdatensatz wird die gezeigte mit der geplanten Reaktion verglichen.

"White box tests"
gehen von einer detaillierten Kenntnis des Entwurfs bzw. der Implementierung aus. Die Innenstruktur des Produktes liegt offen. Testeingaben werden gezielt so konstruiert, daß nacheinander jede Ecke des Programms ausgereizt und belastet wird. Für Kontrollstrukturen heißt das z.B., daß jede Abzweigung einer Alternative wenigstens einmal ausgeführt wird.

Tests sollten ausführlich samt den Ergebnissen dokumentiert werden, so daß bei Korrekturen, Modifikationen oder Erweiterungen ein Vergleich gezogen werden kann. Im einfachsten Fall können Testeingaben sowie gelieferte Ausgaben in den Quelltext selbst in Form von Kommentaren eingebaut werden. Eine andere Möglichkeit wäre das Programm um zusätzlichen Testcode zu erweitern, der mit einfachen Mitteln ein- oder ausgeblendet werden kann (z.B. bedingte Übersetzung mit Compilerschaltern). Ein und derselbe Code kann dann mit wenig Aufwand zum Selbsttest oder zum Einbau in das Gesamtprodukt verwendet werden.

Für größere Softwareprodukte, wie Compiler und Datenbanken, gibt es unabhängige Testsuites bzw. Institutionen, die auf kommerzieller Basis testen. So können z.B. neue C-Compiler einer Validierung unterzogen werden, die ihre Kompatibiltät mit dem ANSI-C-Sprachstandard überprüft. Nach einiger Zeit und einigen Kosten darf der Hersteller den Compiler als "ANSI-C-Compiler" bezeichnen.
5.5.7 Wartung
Die Wartung reiht sich nahtlos in die Reihe der vorangegangenen Phasen ein, auch wenn sie keine abgegrenzte Phase im Sinne von Entwurf oder Implementierung ist. Im Idealfall fällt sie einfach aus, weil keine Anlaß zu Wartungsarbeiten besteht.

Diese Vorstellung ist natürlich illusorisch. Software (insbesondere Systemsoftware) lebt i.d.R. viel länger als ursprünglich geplant. Mit Sicherheit übersteigt die Lebensdauer von Programmen die von Prozessoren.

Anpassungsarbeiten an neue Umgebungen (Hardware und andere Software) ist nicht vermeidlich und sollte als Kostenfaktor von vorne herein eingeplant werden.

Zitat von »Schrompf«

Zendee ist ein halbes Jahr dabei und hat es in der Zeit auf fast 300 Beiträge geschafft. Ich denke, das ist Aussage genug über die zu erwartende Qualität der Diskussion.