Durch diese Bemerkungen sind einige Forderungen an Softwaresysteme skizziert, die in der "Softwarekrise" vor knapp drei Jahrzehnten artikuliert wurden und die dazu geführt haben, daß die Softwaretechnik eine eigenständige Disziplin der Informatik wurde. In der praktischen Arbeit lassen sich die einzelnen Phasen des Softwarelebenszyklus nicht beliebig scharf voneinander abgrenzen; in jeder Phase können sich Unvollständigkeiten oder Inkonsistenzen mit den Arbeitsergebnissen vorheriger Phasen herausstellen, die deren Modifikation oder Erweiterung erzwingen (Jedes Modell des Softwarelebenszyklus geht letztlich von einem verhältnismäßig starren Phasenkonzept aus und wird dem dialektischen Wechselspiel der Phasen untereinander nicht genügend gerecht.)

Insbesondere ist die Revision eines Systems nicht von der Veränderung oder Erweiterung der Aufgabenstellung zu trennen, die Anlaß zu einer vertieften Systemanalyse gibt; ein erneuter Einstieg in den Softwarelebenszyklus mit dem Ziel der Produktion eines im Leistungsumfang erweiterten Systems ist die Folge. Das genannte Kernmodell ist auch auf die Erstellung von Prototypen anwendbar, wobei Software unter mehrfachem, sich teilweise überschneidendem Phasendurchlauf systematisch entwickelt wird.

Projektarbeit

• eine Aufgabenstellung zu analysieren, wobei sie sich ggf. in ein fachfremdes Thema so weit wie nötig einarbeiten,
• ein Softwaresystem
  • in hinreichend exakter verbaler Form zu planen,
  • zu entwerfen,
  • zu implementieren und zu testen und
  • weiterzuentwickeln,
• die Qualität von Software nach gängigen Kriterien zu beurteilen
• und die Leistungsfähigkeit von Programmiersprachen als Werkzeuge zur Unterstützung der erlernten Konzepte abzuschätzen.

Situation eines Lehrprojektes

• Lernende (in der Situation als Lehrende im beruflichen Alltag)
• Mitwirkende bei der Aufgabenstellung und Systemanalytiker,
• Mitglieder eines Teams von Programmierern,
• Endabnehmer und ggf. Benutzer,
• Beobachter der Projektorganisation, die ihre zukünftige Rolle als Projektleiter im Informatikunterricht an der Schule im Auge haben.

• das Praktikum durch den Charakter einer Lehr- und Lernsituation geprägt ist,
• die Teilnehmer bisher nur über Programmiererfahrungen im kleinen verfügen, wie sie zum Lösen von Übungsaufgaben im Grundstudium notwendig sind,
• die Wahl der Plattformen stark durch die Rücksichtnahme auf die Verfügbarkeit von Rechnern, Betriebssystemen und Entwicklungsumgebungen im persönlichen Umfeld der Teilnehmer beeinflußt wird,
• in der Regel keine reale "Marktsituation" herrscht (daß aus dem Bereich der Schule Wünsche für ein bestimmtes "Softwareprodukt" erwachsen, ist zwar ein reizvoller Gedanke, bleibt aber anläßlich der meist hoffnungslosen Überschätzung dessen, was in einem Lehrprojekt machbar ist, wohl eher ein Wunschtraum),
• der zeitliche Rahmen um Größenordnungen kleiner ist, d.h. die Größe des im Praktikum vorgesehenen Projektes nicht einmal ansatzweise quantitativ mit kommerziellen Projekten vergleichbar ist,
• die Aufgaben in der Regel nicht so präzise umrissen sind, sodaß die Projektteilnehmer einen größeren Einfluß auf die Aufgabenstellung haben,
• eine genaue Abstimmung auf die absolut festgelegten zeitlichen Ressourcen erforderlich ist, die nicht (z.B. durch Überstunden oder Einbeziehung weiterer Mitarbeiter) erweiterbar sind,
• die Projektleitung für die "Machbarkeit des Themas" innerhalb des äußerst schmalen zeitlichen Rahmens gerade steht,
• die Projektorganisation im Hinblick auf die spätere eigene Rolle als Lehrer reflektiert wird.

• Es gibt in der Lehre keine Projekte, sondern nur Lehrprojekte.
• Die Themenstellung darf nicht deutlich größer als die Abgrenzung der Aufgabenstellung nach der Systemanalyse sein.
• Die Anforderungsdefinition darf nicht viel komplizierter werden, als man sich das jemals vorgestellt hat; insbesondere darf sie nicht zur Festlegung der vielen interessanten Dinge ausarten, die alle nicht zu schaffen sind.
• Die Spezifikation darf nicht weniger rigide sein, als man es im Grundstudium gelernt hat.
• Die Implementierung muß in ihrem Umfang für die Teilnehmer auf der Basis ihrer Kenntnisse zumutbar sein.
• Aus alledem folgt: Projektleiter müssen das Projekt im Prinzip vorher fertig haben; mindestens aber muß sich das Projekt in wesentlichen Teilen auf Vorhandenes stützen.

• hinreichender Komplexität zum Studium typischer Probleme der Softwareerstellung im Großen und
• der notwendigen didaktischen Reduktion.

Literatur:

Balzert, H.:

Lehrbuch der Software-Technik (2 Bände), Spektrum Akademischer Verlag (1996)

Denert, E.:

Software Engineering, Springer-Verlag (1991)

Kimm, R.:, Koch, W.:, Simonsmeier, W.:, Tontsch, F.:

Einführung in Software Engineering, de Gruyter (1979)

Löhr, K.-P.:

SOFTWARE-Bausteine: Wiederverwendbare Komponenten vereinfachen die Programmentwicklung, LOGIN 9, Heft 6 (1989), 15-21

Meyer, B.:

Object-oriented Software Construction (2nd Edition), Prentice Hall (1997)

Nagl, M.:

Softwaretechnik - Methodisches Programmieren im Großen, Springer (1990)

Nievergelt, J., Ventura, A.:

Die Gestaltung interaktiver Programme, Teubner (1983)

Parnas, D. L.:

On the Criteria To Be Used in Decomposing Systems into Modules, Comm. ACM 15 (1972), 1053-1058

Pagel, B.-U., Six, H.-W.:

Software Engineering, Addison-Wesley (1994)

Pomberger, G.:

Softwaretechnik und Modula-2, Hanser Verlag (1984)

Sommerville, I.:

Software Engineering (Fifth Edition), Addison-Wesley (1996)

weitergehende Hinweise:

Literaturliste von Prof. Dr. K.-P. Löhr zur Vorlesung Softwaretechnik