Beispiel aus der PraxisGelegentlich und bevorzugt in kleineren Unternehmen kommt es auch vor, dass die Anwendung eines definierten Prozess-Modells, dabei insbesondere eine dokumentenorientierte Arbeitsweise, als graue Theorie und akademische Weltfremdheit betrachtet wird. Dokumentation generell, sowie Qualitätsmanagement, das über einen unstrukturierten Test hinaus geht, wird mit dieser Argumentation abgelehnt. Dokumentation und auch eine genaue Analyse wird ausschließlich als Kostenfaktor angesehen.
Ein Fachanwender insistierte auf einer anderen Darstellung eines Algorithmus in einem Anforderungsdokument, der verbal und durch ein Beispiel beschrieben war. Der Algorithmus war dem technischen Personal klar, es handelte sich lediglich um eine lineare Gleichung. Der Fachanwender konkretisierte seinen Wunsch jedoch nicht weiter. Zudem schrieb er das Wort Algorithmus mit einem y. Der technische Projektleiter lehnte den Änderungswunsch auf dem formalen Wege ab.
Another prejudice about this super role (gemeint ist der Risikomanager) is that today's systems are too complex for any one person to really understand at the level of professional competence. Remember the following as a hard and fast rule: Having an opinion is a far cry from understanding, but an opinion is closer to understanding than understanding is to professional competence, and professional competence is the starting point for solving difficulty problems. From this perspective, understanding is a relatively cheap commodity, but even understanding is almost impossible across the full span of today's systems.Ich stelle hier für nicht IT-Spezialisten die gängigen Prozess-Modelle recht knapp vor, ohne sie im Detail zu vertiefen; auf das Spiralmodell wird verzichtet, da es lediglich ein Metamodell ist, das für einzelne Teilprojekte eine Auswahl eines geeigneten Prozess-Modells vorsieht, Prototyping existiert nicht für sich sondern ist stets Teil eines anderen Modells. Vom in Deutschland üblichen V-Modell abgesehen wird auch auf landesspezifische Vorgehensmodelle, die die jeweiligen Regierungen bei öffentlichen Projekten fordern (wie z.B. das britische SSADM ), verzichtet. In der Praxis werden diese Modelle unternehmensspezifisch und projektspezifisch angepasst, eine ultimate Wahrheit im Sinne eines auf jedes Problem anwendbaren Modells existiert m.E. nicht. Für eine gründlichere Einführung verweise ich auf das hervorragende "Lehrbuch der Software-Technik" (Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung) von Helmut Balzert (vgl. auch den Quellennachweis). Die Graphiken bei den einzelnen Modellen lehnen sich teilweise an diese Quelle an.
Beispiel aus der PraxisDas V-Modell in Reinkultur ist eher für sehr große Projekte geeignet, jedoch kann es an mittlere und kleinere Projekte angepasst werden. Routinemäßiges schreiben von Testklassen (und zwar noch bevor die zu testende Klasse gebaut wird) und regelmäßige automatisierte Integrationstests sollten grundsätzlich stattfinden, egal, welches Prozess-Modell verwendet wird. Eine konsequente Anwendung solch einer Test-Vorgehensweise verspricht eine hohe Produktqualität. Auch hier muss darauf geachtet werden, dass sich der Dokumentationsprozess nicht verselbstständigt und Dokumente zum Selbstzweck werden. Im schlimmsten Fall werden Zentimeter dicke Papierstapel nur deshalb ausgefüllt, weil dies vom Qualitätsmanagement so gefordert ist und eine Anpassung des Modells an die jeweiligen konkreten Projekte nicht möglich bzw. gewünscht ist.
Ein Tester sollte ein Produkt testen, das schon deutlich hinter dem Zeitplan geliefert wurde. Bereits im look and feel - Test (also nur unstrukturiertes herum tippen und herum klicken in der Anwendung) konnte er binnen zwei Tagen über 100 Fehler nachweisen, darunter Verletzungen der Constraints der Datenbank und Abstürze der Anwendung. Der Tester brach den Test ab. In einer hitzigen Diskussion mit dem Auftraggeber erklärte der Tester, dass er keine strukturierten Tests der eigentlichen Verarbeitungsprozesse vornehmen würde, wenn nicht einmal der Geradeausflug bei Eingaben in die Bildschirmmasken funktionierte und dass er davon ausgeht, dass das Produkt vor Auslieferung nicht getestet worden sei. Weder seine Aufgabe noch die des Business Analysten sei es, die Arbeit der Entwicklungsmannschaft zu machen. Der Entwicklungschef des Software-Hauses erklärte allen Ernstes, dass kein Produkt ungetestet das Haus verlassen würde. Monate später traf der Tester einen früheren Mitarbeiter des Software-Hauses wieder, der ihm bestätigte, dass die fragliche Software ohne Test ausgeliefert worden war.
Beispiel aus der PraxisSeite der IABG zum V-Modell: http://www.v-modell.iabg.de/
Ein Gruppenleiter einer IT-Abteilung eines großen Unternehmens aus dem Finanzbereich erklärte einmal, dass alle Aufgaben, die sich in weniger als sechs bis zwölf Wochen erledigen lassen, von ihm selbst bei Neuentwicklungen nicht als Projekt deklariert würden, da sonst der bürokratische Aufwand nur auf Grund der Bezeichnung "Projekt" in keiner Relation mehr zur tatsächlich zu leistenden Arbeit stünde. Statt dessen sprach er von Wartung und Pflege vorhandener Produkte, obwohl genau betrachtet komplett neue (Teil-) Produkte entwickelt wurde.
Beispiel aus der PraxisJedes Unternehmen, das selbst Software entwickelt, wird objektorientierte Ansätze berücksichtigen müssen. Wurde die Erzeugung von wiederverwendbaren Komponenten in den achtziger Jahren noch explizit gefördert und von vielen Unternehmen gegenüber den Mitarbeitern auch finanziell honoriert, wird dies heute vorausgesetzt.
Im Rahmen des Baus verschiedener finanznaher Web-Produkte konnte eine Reihe finanzmathematischer Berechnungsvorschriften erkannt werden, die in einer Klassenbibliothek gesammelt wurden. Manche dieser Vorschriften waren in den Vorjahren bereits mehrfach und in verschiedenen Programmiersprachen von verschiedenen Entwicklern implementiert worden.
Beispiele aus der PraxisDie fortwährende Wiederverwendung von Komponenten bringt mittelfristig nicht nur einen Kosten- und Effizienzvorteil, sondern auch einen Qualitätsvorteil. Komponenten die einmalig entwickelt werden, müssen nicht wiederholt getestet werden. Fehler, die sich im laufenden Betrieb in einem Produkt finden, in dem die Komponente eingebaut ist, werden implizit auch für alle anderen Produkte behoben, die diese Komponente verwenden.
Ein Entwickler reklamierte, dass er bereits wiederverwendbare Komponenten für bestimmte Aufgabenstellungen hätte, als der Aufbau einer entsprechenden Klassenbibliothek beauftragt wurde. Weder waren diese Komponenten dokumentiert, noch waren sie den anderen Entwicklern bekannt, noch waren sie tatsächlich wiederverwendbar im Sinne eines objektorientierten Ansatzes. Der Entwickler passte den Code jeweils an seine aktuellen Bedürfnisse an, anstatt tatsächlich eine Klassenbibliothek zu verwalten und fallabhängig neue Klassen von denen seiner Klassenbibliothek abzuleiten. Zudem war der Code nicht sonderlich stabil, weder existierte ein Anforderungsdokument noch war der Code systematisch getestet worden.
Im Rahmen eines Projekts von ca. zwei bis drei Personenjahren wurde ein Mitarbeiter von der Geschäftsführung gebeten, sich um die Wiederverwendbarkeit des zu erstellenden Codes zu kümmern. Der Mitarbeiter wies die Aufgabe zurück, da er bereits anderweitig vollständig eingebunden war. Der Geschäftsführer sagte etwas verwundert, dass er davon ausgegangen sei, dass sich dieser Auftrag mit einem Aufwand von ca. einer Stunde pro Woche erledigen ließe. (Hinweis für Nicht-IT-Spezialisten: Das ist ein Vollzeitjob im Rahmen des Designs.)
Beispiel aus der PraxisBei den Paarungen muss natürlich die Chemie stimmen. Sitzen zwei etwa gleich qualifizierte Leute vor dem Rechner, kann im Zweifelsfall rasch die Rolle gewechselt werden, d.h. der Kritiker wechselt mit dem Hacker ab. Ein Analytiker, der die verwendete Plattform nur passiv beherrscht und dann auch noch wichtigtuerisch seinem technischen Kollegen vorzugeben versucht, wie er einen technischen Ansatz realisieren soll (den der Analytiker alleine gar nicht realisieren könnte) ist eindeutig nicht für solch ein Vorgehen geeignet.
In einem Kleinprojekt mussten numerisch nicht ganz triviale Algorithmen umgesetzt werden. Ich hatte damals die Rolle des Analytikers und betrieb pair programming mit einer sehr talentierten Entwicklerin, der allerdings noch die Erfahrung für Algorithmik fehlte und die keine höhere mathematische Ausbildung hatte. Zwar hatte ich noch nie Java programmiert, konnte aber auf Grund meiner C++-Erfahrung den Code ohne Schwierigkeiten lesen. Die umgesetzten Algorithmen waren bereits in der ersten Version nach der Implementierung fehlerfrei. Leider hielten wir uns nicht konsequent an die 40-Stunden-Woche und wir schoben mehrere zwölf-Stunden-Schichten ein, die letztendlich nur ermüdend waren.