Please enable JavaScript.
Coggle requires JavaScript to display documents.
Organisation von Softwareprojekten - Coggle Diagram
Organisation von Softwareprojekten
Vom Prozessparadigma zum Softwareprozess
Softwareprozesse können nicht adhoc oder chaotisch organisiert werden ⇨ Grund: Komplexität, Beteiligung vieler Rollen, vielfältige Aktivitäten
Prozessparadigma
allgemeine Vorgehensmodelle
geben grobe Struktur von Softwareprozessen vor, ohne Details
Grundprinzip eines Softwareprozessmodells ohne konkrete Rollen, Zuständigkeite oder detaillierte Abläufe
Beispiele: Wasserfallmodell, V-Modell, evolutionäre Entwicklung
Softwareprozessmodell-Rahmenwerk
als Basis für Gestaltung von organisationsspezifischen Softwareprozessen wurden detaillierte Softwareprozessmodell-Rahmenwerke erstellt
dienen als Vorlage bei Erstellung eines eigenen Softwareprozessmodells ⇨ individuelle Vorgaben und Rahmenbedingungen werden hinzugefügt
folgt der im Prozessparadigma vorgegebenen Struktur und erweitert diese um detaillierte Beschreibungen zu Rollen, Zuständigkeiten, konkreten Aktivitäten und Abhängigkeiten
Beispiele: V-Modell XT, Rational Unified Process (RUP), Scrum
Individuelles Softwareprozessmodell
individuelle Softwareprozessmodelle werden auf Basis von Vorgaben der Softwareprozessmodell-Rahmenwerke erarbeitet
transparente Beschreibung für alle Beteiligten, wie Entwicklungsprozess ablaufen soll
legt folgendes fest
welche Aktivitäten während Entwicklung durchzuführen sind
Reihenfolge der Aktivitäten
Rollen und Organisationseinheiten, die für Aktivitäten verantwortlich sind
Werkzeuge und Methoden zur Unterstützung der Aktivitäten
Typen der Objekte, die erzeugt und verarbeitet werden
Softwareprozess
einzelner Softwareprozess (ganz konkretes Softwareprojekt) ist eine Ausprägung des individuellen Softwareprozessmodells
zu einem Softwareprozessmodell gibt es eine Menge von Softwareprozessen, die nach Vorgaben der Rahmenbedingungen ausgeführt werden
Folgende Festlegungen sind nötig:
welche Aktivvität wann von wem durchgeführt wird
welche Objekte bei der Durchführung einer Aktivität verarbeitet bzw. erzeugt werden
Prozessparadigmen
Definition: Allgemeine Vorgehensmodelle im Software Engineering
Wasserfallmodell
Allgemein
1970 von Royce, ältestes Prozessparadigma
Grundidee: schrittweise Bearbeitung der einzelnen Phasen Anforderungen, Analyse, Entwurf, Implementierung, Test und Betrieb in einer festgelegten Reihenfolge
jede einzene Phase wird vollständig fertiggestellt bevor die nächste Phase beginnt
zwischen zwei benachbarten Phasen gibt es die Möglichkeit der Rückkopplung
Rückkehr auf vorherige Phase möglich, wenn Fehler gefunden werden oder es Probleme mit dem Ergebnis einer Phase in der nachfolgenden Phase Probleme gibt
Besonderheiten
feste Struktur wurde vorgegeben
strikte Trennung der Phasen
legt großen Wert auf vollständige und aktuelle Dokumentation
Phasenübergang nur bei vollständiger und ausführlicher Dokumentation und Qualitätssicherung
Vorteile
Softwareprozess in klare Phasen mit definierten Ergebnissen gegliedert
klare organisatorische Zuständigkeiten
Überwachung von aktuellem Zustand und Projektfortschritt
v.a. in verteilten Projekten mit mehreren Organisationen und Standorten, sind Aufgabenbereiche klar gliederbar
Übergabepunkte zwischen einzelnen Organisationen können vertraglich festgelegt werden
Nachteile
starre Reihenfolge steht der Natur der Erkenntnisgetriebenheit von Softwareprojekten gegensätzlich
Anforderungen an industrielle Informationssysteme lassen sich nicht zu Beginn vollständig beschreiben
strikte Einhaltung des Wasserfallmodells verhindert den Start von Nachfolgephasen von bereits fertiggestellten, einzelnen Elementen
es muss auf Abschluss der Prüfung der Qualitätssicherung gewartet werden vor Weiterarbeit
heute
nur als grobe Orientierungshilfe
V-Modell
Ende 1970er
Basis versch. Softwareprozessmodelole im öffentlichen Sektor
Grundgedanke: 1 zu 1 Zuordnung von konstruktiven Phasen (linke Seite) und zu prüfende Phasen (rechte Hälfte)
Weg durch Softwareprozess: ergibt sich aus Reihenfolge der festgelegten Phasen
fachliche Anforderungsanalyse ⇨ Software Engineering Kernaktivitäten bis zur fertigen Konstruktion werden durchgeführt ⇨ über versch. Teststufen bis zur Abnahme des Systems
jeder Phase der Konstruktion wird eine konkrete Teststufe zugeordnet, die sich auf gleicher Detaillierungsebene befindet wie konstruktive Phase
Vorgängerphase muss erfolgreich abgeschlossen sein
Evolutionäre Entwicklung
Zyklus
Festlegen welche Funktionen umgesetzt werden sollen
Umsetzen der Funktionen
Integration der neuen Funktionen
Testen und Bewerten der aktuellen Softwareversion
Allgemein
allgemeines Vorgehensmodell
Grundidee: Erstellung des Systems in mehreren sich wiederholenden Zyklen
mit jeder Version wächst Funktionsumfang des Systems
Erkenntnisse, die bei Umsetzung und Bewertung gewonnen werden, können in folgenden System-Versionen berücksichtigt werden
nicht strikt entlang der Kernaktivitäten
Softwareprozess „dreht sich“ im Kreis um ein fertiges Stück Software
Kernaktivitäten nicht am Stück vollständig durchgeführt und dokumentiert, sondern kleinteiliger und miteinander verzahnt in jedem Zyklus ein bisschen
zu Beginn wird keine vollständige Spezifikation erstellt
Vorteile
berücksichtigt, dass viele Erkenntnisse erst während des Prozesses gewonnen werden könen ⇨ werden dann direkt eingebracht
Fehler und Ungenauigkeiten in Spezifikation und Programmcode können schnell erkannt und behoben werden
schnelle Verfügbarkeit eines grundsätzlich lauffähigen Systems
Nachteile
scheint aus Managementsicht unstrukturiert und ohne klar definiertes Ergebnis ⇨ konkreter Funktionsumfang wird erst während Entwicklung festgelegt
Risiko, begleitende Architektur- und System-Dokumentation wird vernachlässigt
Spiralmodell