Ich möchte hier einen kleinen Überblick über verschiedene Softwareentwicklungsprozesse, Standards und Methoden geben.
Für die erfolgreiche Durchführung eines Projektes ist es wichtig, Kenntnisse über adäquate Softwareentwicklungsprozesse und deren Bestandteile (im Sinne einer Werkzeugsammlung) zu besitzen - das allein reicht allerdings nicht aus.
Ein Prozess muss zu der Aufgabe und, noch wichtiger, zu dem Team passen, welches das Projekt durchführt. Von daher kann es nicht den "einen", allgemeingültigen Prozess geben. Stattdessen ist für jedes neue Projekt ein passender Prozess auszuwählen (dies wird u.a. von Alistair Cockburn in dem Artikel Just-In-Time Methodology Construction sehr gut beschrieben). Kent Beck hat auch mal den Begriff der "DNA des Teams", welche im Prozess enthalten sein müsse, geprägt. Je kleiner das Team ist, desto einfacher kann auch der Prozess gestaltet werden - wenn 7 Leute zusammen in einem Raum sitzen, offen miteinander kommunizieren können und der Anwender ebenfalls zum Team gehört, braucht man fast keine Vorgabe für einen Prozess. Je größer das Team wird, umso aufwändiger wird auch der Prozess.
Auch innerhalb der Durchführung eines Projektes muss immer wieder der Prozess an sich in Frage gestellt werden. Nach jeder Iteration sollte dazu ein Prozess-Review (oder Retrospektive) durchgeführt werden, in dem die Erkenntnisse aus dem bisherigen Projektverlauf diskutiert werden und der Prozess entsprechend optimiert wird.
Nach Abschluss eines Projektes ist eine (Post-Mortem) Analyse des Projektes besonders wichtig. Hier sollte der Prozess und die Schwierigkeiten bzw. Erfolge mit dem Prozess diskutiert und dokumentiert werden. Für folgende Projekte können diese Erkenntnisse wichtig werden, wenn es darum geht, den neuen Prozess zu gestalten.
Dieses Vorgehen ist natürlich nichts neues, die ständige Verbesserung des Prozesses ist ein Kernelement des Kaizen (dem der kontinuierliche Verbesserungs-Prozess nachempfunden wurde).
Übrigens geht Alistair Cockburns Meinung mittlerweile folgerichtig dahin, dass eine Implementation eines Prozesses in einem Team eine Lebensdauer von maximal 3 Monaten haben kann, dann wird er durch eine neue, adaptierte und verbesserte Version verdrängt. Philip G. Armour beschreibt in seinem Buch The Laws Of Software Process (siehe Literatur), warum ein Prozess nie 100% für ein Projekt richtig stimmen kann - denn er kann nur durch die im Projekt entstehenden Erfahrungen reifen und ist somit vielleicht am Ende eines Projektes ausgereift. Da dann ein neues Projekt anfängt und dieses nie dem vorhergehenden absolut entspricht, passt der im vorigen Projekt genutzte Prozess in dem neuen nicht völlig.
Ich habe hier auf einigen Seiten ein paar Informationen zu einigen der aktuellen Softwareentwicklungsprozesse zusammengetragen, quasi als Überblick für den Anfang. Einen wirklichen Einstieg in die jeweiligen Prozesse erhält man/frau aber nur durch das Anwenden eines solchen Prozesses in einem realen Projekt - dabei kann ich gerne helfen.