infforum

Vorgehensmodelle Software-Entwicklung

Verbindlichkeit von Entwicklungsschritt und Ergebnis

Startseite Informatik Forum

Anforderungsanalyse

Prozess-Modellierung

Anwendungsentwicklung

Projektmanagement

Entwicklung Phasenmodelle software engineering Prince2 Produktmodell Phasenmodell agil Prozessmodell Bank Ablauf Arbeitsschritte Entwicklungsphasen Programm Optimierung Eigenschaft Ergebnistyp Prozessmanagement

INffORUM Leistungen

Projekt-Beispiele

Kontakt zu INffORUM

Ziele Themen SIP - Strategische Informationssystemplanung GPM - Geschäftsprozess-Modellierung Anforderungsanalyse Anforderungsmanagement Vorgehensmodell Methoden Systemabgrenzung PZR-Analyse Problemanalyse / Schwachstellenanalyse Zielanalyse Restriktionsanalyse Affinitätsanalyse Durchführbarkeitsanalyse / Wirtschaftlichkeitsanalyse Werkzeuge Requirements Engineering Anwendungsentwicklung Vorgehensmodelle Wasserfall-Modell Spiral-Modell V-Modell Evolutionäre / inkrementelle Vorgehen RUP - Rational Unified Process Agile Softwareentwicklung MDA - Model Driven Architecture Methoden Methode SA - Strukturierte Analyse Methode ESA - Essentielle System-Analyse Methode SD - Strukturiertes Design Methode ERM - Entity-Relationship-Modellierung Methode RM - Relationen-Modellierung Methode UML - Unified Modeling Language Werkzeuge Software Engineering case/4/0 Innovator objectiF Projekt-Management Vorgehensmodell Projektstrukturplanung Aktivitätenplanung Arbeitsplanung Kapazitätsplanung / Ressourcenplanung Change-Management Konfigurations-Management Methoden/Techniken Netzplan-Technik Balkenplan-Technik Methoden Aufwandsschätzung Methode NuWA - Nutzwertanalyse Werkzeuge Projekt-Management in-Step Primavera Übersicht Leistungen Organisationskonzepte Studien, Gutachten Auswahl Requirements Engineering (CARE) Tool Auswahl Software Engineering (CASE) Tool Auswahl Projekt-Management (PM) Tool Projektleitung Coaching Projektleiter Know-how-Transfer Projekte Beratung und Unterstützung Software Einsatz case/4/0 Software Einsatz Innovator Software Einsatz ObjectiF Seminare Projektbeispiele Informationssystem-Planung IV-Rahmenplanung Museum Kommunikationsanalyse Versicherung Organisation ORG-BW-Gesamtmodell Prozessmodellierung und Ablauf-Organisation Rating Versionskontrolle Logistik Know-how-Transfer Software-Entwicklung Vorgehensmodell Analyse mit Einsatz case/4/0 Vorgehensmodell mit Word-Dokumentation Werkzeug-Einführung Innovator Simulation Tour de France Cockpit - Steuerung der Simulation Anleitung und Hilfe für Sudoku-Rätsel Mitarbeiter-Profil Kontakt Kontakt-Formular Impressum	Unser Thema Vorgehensmodelle der Anwendungsentwicklung
		Vorgehensmodelle beschreiben die Strukturierung und Steuerung der Prozesse im Software Engineering (Prozess-Management) für ein Informatik-Projekt. Die Projektabwicklung wird von der Systemplanung, über die Systemanalyse, den Software-Entwurf bis zur Abnahme und Software-Verteilung systematisiert. Ein Vorgehensmodell beschreibt damit den Software-Lebenszyklus von der Analyse der Anforderungen für eine Anwendung bis zur Pflege und Wartung der Software-Produkte. Das Ziel der Nutzung der Vorgehensmodelle in der Anwendungsentwicklung ist die Beherrschung der Komplexität. Erreicht wird dieses Ziel durch die Organisation der Software-Entwicklung und die Definition der notwendigen Aktivitäten der Projektdurchführung. Über das Prozessmanagement wird der Entwicklungsprozess in klare und für alle Entwickler verbindliche Arbeitsschritte eines Workflow aufgeteilt (Prozessentwicklung). Ein weiteres Ziel der Vorgehensmodelle besteht darin, den Entwicklern eine Arbeitsanleitung für alle Arten der Anwendungsentwicklung mitzugeben. Ein Vorgehensmodell kann damit als Check-Liste für die Prozessmodellierung und die Softwareentwicklung dienen. Über ein Projekt-Management-Werkzeug kann das Vorgehensmodell zusätzlich als Workflow-Steuerung im Vorgehen der IV-Projekte eingesetzt werden. Ein Vorgehensmodell bietet zu jeder Aktivität der Systementwicklung eine Unterstützung in Form einer Checkliste, Leitlinie, Methode, eines Template oder eine Sammlung von Best Practices. Im Allgemeinen ist ein Vorgehensmodell des Software Engineering eine sehr umfangreiche, für viele denkbare Ablauf-Varianten geeignete Beschreibung von						weiterführende externe Links
			Aktivitäten (Phasenmodell)	und	Ergebnistypen (Produktmodell)
		Das Phasenmodell als Komponente der Vorgehensmodelle sorgt für die Einteilung des gesamten Software Engineering Prozesses in Hauptphasen und dazugehörige Arbeitsschritte der Software-Entwicklung. Das Phasenmodell liefert eine standardisierte Abfolge der Aktivitäten für die Prozessmodellierung und die Anwendungsentwicklung (Software Life Cycle). Für die zeitliche Anordnung bzw. zustandsabhängige Ausführung der Aktivitäten wird der Begriff Prozessmodell verwendet. Phasenmodelle ohne Berücksichtigung der Produkte stellen nur eine unzureichende Basis für das Entwickeln von Anwendungen dar. Das Produktmodell im Vorgehensmodell der Anwendungsentwicklung liefert die Beschreibung der Gesamtheit der funktionalen, technischen und administrativen Eigenschaften der Produkte der Software-Entwicklung. Im Produktmodell sind auch die Verknüpfungen der (Teil-)Produkte als Voraussetzung für die Entwicklung jeweils neuer (Teil-)Produkte festgehalten. Durch die Festlegungen zur Gestaltung der einzelnen Produkte wird die Wartbarkeit der entstehenden Applikationen entscheidend erhöht. Das Produktmodell und die Behandlung der Produkte gewinnt auch in den Projektmanagement- und Workflow-Tools (zum Beispiel bei in-Step) eine immer größere Bedeutung im Vergleich zum Phasenmodell. Sowohl im Phasenmodell als auch im Produktmodell spielen die Zustände eine wichtige ergänzende Rolle. Für die Aktivitäten können beispielweise die Aussagen, ob eine Aktivität für das Projekt erforderlich ist, ob die Voraussetzungen für die Durchführung erfüllt sind oder ob die Aktivität erledigt ist, von Bedeutung sein. Bei den Produkten sind es beispielweise die Zustände "bereit", "in Bearbeitung", "fertiggestellt", "freigegeben", usw., die zur Steuerung des Projektablaufs über Zustandsautomaten oder eine Workflow-Engine genutzt werden können. Die gemeinsame Sicht auf Phasenmodell und Produktmodell in der Softwareentwicklung liefert den Vorteil der Zuordnung jeweils einer passenden Methode zu einem Ergebnistyp bzw. zur Durchführung der Aktivität. Die Definition von Methoden zu den Aktivitäten im Phasenmodell / Prozessmodell und deren Anwendung bewirkt, dass die Beschreibung der erwarteten Ergebnisse auch in einer gleichartigen Qualität erfolgt.
			Vorgehensmodelle bzw. Phasenmodelle für die Anwendungsentwicklung sollten im Rahmen des Prozess-Management durch die Erfahrungen mit der Vorgehensweise im Unternehmen fortgeschrieben werden. Die Modelle bieten dann die Sicherheit, dass die folgenden Ziele erreicht werden: Wenig erfahrene Projektleiter werden zu einem bewährten Vorgehen der SW-Entwicklung hingeführt. Erfahrene Projektleiter nutzen nicht zu stark ihre persönlichen Vorgehensweisen. Die Vorgehensweise wird nicht zum täglichen Diskussionspunkt im Projekt. Notwendige Schritte einer Phase der Anwendungsentwicklung werden nicht umgangen, um Probleme oder Konflikte zu verschieben. Planbarkeit und Transparenz bezüglich Terminen, Kosten und Qualität werden durch das Vorgehensmodell geschaffen. Der Entwicklungsprozess wird messbar und lässt kontinuierliche Verbesserungen am Vorgehensmodell, im Prozess-Management und in der SW-Entwicklungsumgebung zu. Im Vorgehensmodell muss ein Mittelweg zwischen Vereinheitlichung der Prozesse der Modellierung im Software Engineering und Raum für die Kreativität der Entwickler gefunden werden.
		Um diese Anforderungen zu erfüllen, muss ein Vorgehensmodell der Anwendungsentwicklung einige Eigenschaften besitzen: Das Ergebnis jeder Aktivität muss im Vorgehensmodell klar als Produkt beschrieben sein. Es muss eine Software Engineering Methode oder Technik für die Entwicklung / Modellierung der Ergebnisse bzw. eine Form für deren Darstellung zugeordnet sein. Das Ergebnis einer Aktivität muss anderen Aktivitäten im Vorgehensmodell als Voraussetzung im Workflow zugeordnet sein, um alle Möglichkeiten der Reihenfolge (auch Parallelität) in der Projektarbeit klarzustellen. Das gleiche wie im Phasenmodell gilt für das Produktmodell: Auch hier müssen Produkte definiert und als Voraussetzung für Erzeugung weiterer Produkte verknüpft sein. Einzelne Aktivitäten und Produkte im Vorgehensmodell der SW-Entwicklung müssen für bestimmte Projektklassen der Anwendungsentwicklung (Unterscheidung nach Typ, Größe, usw.) von Seiten des Prozessmanagement als optional gekennzeichnet sein. Für manche Projektklassen können Aktivitäten und Produkte sogar im Projektvorgehen ganz entfallen. Projekt-spezifisch müssen sich durch das Projektmanagement zusätzliche Aktivitäten und Produkte mit jeweils einem speziellen Ergebnistyp in allen Phasen im Vorgehensmodell einbinden lassen. Fachliche Lösungen müssen durch das Prozess-Management getrennt und im Vorgehen der Phasenmodelle / Prozessmodelle zeitlich vor technischen Lösungskomponenten erarbeitet werden.
		Aus den Standard-Verfahren der Informatik für die Abbildung des Software Life Cycle, wie Wasserfallmodell, prototypische Vorgehensmodelle (meist auf Realisierung von Prototypen der Benutzeroberfläche beschränkt), Spiralmodell, V-Modell 97 und V-Modell XT , PRINCE 2 (GB), HERMES (CH), Evolutionäre bzw. inkrementelle Vorgehensmodelle, STEPS (SW-Technik für Evolutionäre Partizipative Systementwicklung), Rational Unified Process (RUP), agile Prozesse, eXtreme Programming (XP), Model Driven Architecture (MDA) haben sich im Laufe der Jahre mehr oder weniger viele unternehmensspezifische Varianten der Modelle, meist Phasenmodelle, gebildet. Diese Anpassungen der Vorgehensmodelle können sich auf objektorientierte und/oder strukturierte Anwendungsentwicklung beziehen. Dabei muss es für ein Unternehmen nicht nur ein einziges Vorgehen im Software Engineering geben. Abhängig von der Thematik und der Größe der Projekte, der bereits eingesetzten Methoden in der IV, der Software-Entwicklungs-Umgebung (SEU), der Stabilität der Anforderungen und den abschätzbaren Risiken kann jeweils ein anderes Vorgehensmodell am besten geeignet sein. Die Beschreibungen im Vorgehensmodell enthalten verallgemeinerte Formen oder die konkret benötigten Entwicklungsprozesse für Systemplanung, Geschäftsprozess-Modellierung, Anforderungsanalyse (Requirements Engineering), System-Analyse und Design in der Anwendungsentwicklung mit Funktionsanalyse (Methode der Strukturierte Analyse oder der Essentielle System-Modellierung), Analyse Informationsbedarf (Entity-Relationship-Modellierung), Software-Entwurf (Strukturiertes Design) und Daten(bank)-Design (Relationen-Modellierung). Test, Qualitätskontrolle / Qualitätssicherung und Abnahme, Projektmanagement und Change-Management, Konfigurationsmanagement und Softwareverteilung, Software-Einsatz Reengineering / Reverse Engineering. Im Unterschied zum Vorgehensmodell werden durch das Prozess-Management meistens auch die Aufbauorganisation und die benötigten Rollen für die Durchführung der Projekte je Phase beschrieben. Die Darstellung der Aufbauorganisation beschränkt sich auf die beteiligten oder Einfluss nehmenden Stellen zum Beispiel in der Anwendungsentwicklung, der Betriebsorganisation und in den Fachbereichen. Die aus diesen Abteilungen für das IT-Projekt verfügbaren Mitarbeiter müssen den notwendigen Rollen im Projekt zugeordnet werden. Zu einzelnen Aktivitäten im Vorgehensmodell sind Richtlinien für Erstellung und Darstellung der jeweiligen Produkte bzw. Vorlagen für die Produktbeschreibung zugeordnet. Neben den zu nutzenden Methoden sind dies zum Beispiel eine Dokumentations-Richtlinie oder eine Programmier-Richtlinien. Die Anleitungen für die Durchführung können selten in einem annähernd vollständigen Umfang genutzt werden. Es bedarf im Rahmen des Projektmanagement einer jeweils Projekt-spezifischen Anpassung der Softwareentwicklung, dem Tailoring. Die Durchführung des Tailoring sorgt meist für eine erhebliche Reduzierung der im konkreten Projekt durchzuführenden Aktivitäten, kann aber auch zu zusätzlichen Projekt-spezifischen Aktivitäten führen. Für das Tailoring ist mit entsprechendem zeitlichem Aufwand zu rechnen und das dafür notwendigen Know-how einzuplanen.						Prototypische Vorgehensmodelle (in Kap. 2.4.4) PRINCE2 Prozessmodell, Komponenten, Techniken Die Methode HERMES STEPS in Management von SW-Projekten (Kap. 3) eXtreme Programming (XP)
Copyright © Informatik Forum Simon GmbH. Alle Rechte vorbehalten. Stand: 1. März 2010		Zum den Themen Vorgehensmodelle der Anwendungsentwicklung und Prozess-Management bietet INffORUM einen Vergleich möglicher Arten von Vorgehensmodellen bzw. konkreter Modelle und Bewertung bezüglich ihrer Eignung für den Einsatz in einer spezifischen Entwicklungsumgebung, die Einführung eines der Standard-Vorgehensmodelle: V-Modell, PRINCE2, HERMES oder RUP, die Definition, Ausarbeitung oder Weiterentwicklung unternehmenseigener Vorgehensmodelle der Software-Entwicklung (s.a. Projekt-Beispiele: Vorgehensmodell Analyse mit Einsatz case/4/0, Vorgehensmodell mit Word-Dokumentation) mit der Prozessmodellierung für den Software-Entwicklungsprozess,
		die Optimierung der Prozesse, um sie auf eine möglichst hohe Stufe der Reife gemäß den Kriterien von CMM / CMMI (Capability Maturity Model Integration) des SEI (Software Engineering Institute) zu heben, die Beschreibung der anzuwendenden Regeln für alle Arten des Tailoring der Vorgehensmodelle, den Vergleich, die Auswahl und die Einrichtung der geeigneten Software-Entwicklungsumgebung (SEU), die Abbildung der Methoden auf die Schritte der Software-Entwicklung in der vorhandenen SEU bzw. Workbench, die Erstellung einer Arbeitsanleitung zur optimalen Anwendung von Methoden und Werkzeug für die Entwickler sowie den zugehörigen Know-how-Transfer in Form von Schulung (Seminar, Workshop, Tutorial), Coaching und Beratung im IT-Projekt. Das Training zu einem Vorgehensmodell, sowohl Seminar als auch Workshop und Tutorial, kann dabei auf den speziellen Bedarf einer Projekt-Gruppe zugeschnittenen werden. Profitieren Sie von den langjährigen Erfahrungen der INffORUM Berater.						CMM / CMMI in 'Methode zur Leistungsbewertung ...' (Kap 4.1) SEI - Software Engineering Institute