Es existiert eine Vielzahl von mehr oder weniger ausgereiften Vorschlägen, wie man Software erfolgreich konzipieren und realisieren kann. Einige dieser Modelle beleuchten mehr den organisatorischen bzw. prozessualen Aspekt (also quasi die "Makromechanik"), andere fokussieren mehr auf die Details, also auf die Mikro-Mechanik. Einige dieser Methoden decken den ganzen Entwicklungsprozess ab, andere wiederum fokussieren nur einen Ausschnitt, also z.B. die Ermittlung der Anforderungen oder den (technischen) Entwurf der eigentlichen Programme. Entsprechend gibt es natürlich viele philosophische Streitereien, welche Methode am besten sei. Immerhin herrscht im Allgemeinen Einigkeit über folgende Punkte:
● Mehr oder weniger jede Methode ist besser als keine Methode.
● Ein sektiererisch genauer bzw. übertriebener und allenfalls inadäquater Einsatz kann allerdings ebenso schädlich sein, wie der Einsatz keiner Methode.
● Jede Methode muss letztlich auf das jeweilige Projekt bzw. Projektumfeld angepasst werden.
● Zwischenergebnisse einer Methode sind immer nur ein Mittel zum Zweck, das Ziel ist und bleibt ein eingeführtes, stabiles Softwaresystem, welches dem Kunden hilft, seine Tätigkeiten effizienter durchzuführen.
In den 90-er Jahren wurde der Methodendschungel erheblich vereinfacht: Diverse kompetente Autoren "proprietärer" Methoden haben sich zusammengefunden und ihre Vorschläge in der sog. "Unified Modelling Language (UML)" vereint. UML ist im Wesentlichen eine Norm für "technische Zeichnungen" (Diagrammen) zur Dokumentation eines geplanten (oder allenfalls existierenden) Softwaresystems. Dazu werden ca. 8 Diagrammtypen geliefert, mit welchen z.B. das dynamische Verhalten sowie statische Zusammenhänge grafisch beschrieben werden können.
UML selber enthält keine Vorschläge darüber, wann und wie diese Diagramme nun in einem konkreten Projekt einzusetzen sind. Dieser Vorschlag wurde relativ kurz nach der Veröffentlichung von UML durch 3 wesentliche Autoren von UML in Form des sog. "Unified Process (UP)" nachgeliefert. Weil die drei Autoren damals bei der Firma Rational arbeiteten, wurde die Methode dann rasch als Rational Unified Process (RUP) bezeichnet.
In der Schweiz hat die Projektführungsmethode HERMES eine grosse Verbreitung. HERMES ist ein offener Standard der Schweizerischen Bundesverwaltung für die Führung und Abwicklung von Informations- und Kommunikationstechnologie (IKT) Projekten.
Das vorliegende Dokument ist ein Vorgehensmodell zur Führung, Konzeption, Realisierung und Einführung von Softwareprojekten basierend auf HERMES, RUP/UML sowie der Entwicklungsumgebung AdeNet.