Methodisches Vorgehen
Unsere Methoden für Ihren Erfolg
Unser Vorgehensmodell verbindet verschiedene Ansätze und Projektvorgehensmodelle miteinander und schafft somit einen sehr guten Kompromiss aus Formalismus und Pragmatismus. Verbesserung der Kommunikation, Minimierung der Projektrisiken, Erreichung aller Projektziele, Gewährleistung der Qualität und Eindämmung der Gesamtkosten stehen dabei grundsätzlich im Hauptfokus.
Ein zusätzlicher Mehrwert ergibt sich beim Einsatz des Vorgehensmodells von ISB auch in der Verwendung der durch uns gestellten, bereits vorhandenen Dokumentenvorlagen, die auf das Vorgehensmodell abgestimmt sind. Damit stellen wir sicher, dass alle Ergebnisse in der notwendigen Form, geforderten Detaillierung und erwünschten Qualität erfolgen.
Agiles Vorgehen
Agil – schnell und transparent
Das agile Softwareentwicklungsvorgehen nach klassischem SCRUM-Modell gliedert sich in mehrere inkrementelle Iterationen, die in sogenannten zwei- bis vierwöchigen Sprints abgearbeitet werden. Nach jedem dieser Sprints liegt eine auslieferbare und lauffähige Anwendung als Produktinkrement vor.
Dazu wird zum Projektstart der Product Backlog definiert. Er enthält alle während des Projekts durchzuführenden Leistungen und Aufgaben in Form von erarbeiteten und umzusetzenden Anforderungen, den sogenannten UserStories. Diese werden – einsehbar für alle Projektbeteiligten – auf die Sprints verteilt und permanent während des Projekts weiterentwickelt und verfeinert.
Jeder Sprint beginnt mit einem gemeinsamen Sprint Planning. Die Aufgaben werden gemäß Priorität und Dringlichkeit aus dem Product Backlog ausgewählt und zeitlich geplant. Dabei wird auch geprüft, ob die Spezifikation ausreichend ist. Ein wichtiges Kriterium ist dabei die „Definition of Done“. Es wird gemeinsam festgelegt, wie das Ergebnis aussehen soll, um nach Durchführung der Implementierung und der Qualitätssicherung eine erfolgreiche (Teil-) Abnahme zu gewährleisten.
Am Ende eines jeden Sprints findet ein gemeinsames Sprint Review statt. Hier werden die Ergebnisse des jeweiligen Sprints vorgestellt und gegen die vorher definierten Abnahmekriterien (Definition of Done) geprüft. Anforderungen, die nicht komplett umgesetzt wurden, kommen zurück in das Product Backlog. Da alle Anforderungen in kleinen Iterationen entwickelt werden und für jede Anforderung im Voraus die „Definition of Done“ definiert wurde, kann auch hier die Qualitätssicherung in enger Zusammenarbeit mit dem Kunden als agiler Prozess gelebt werden.
Vorteil dieses Vorgehens ist eine sehr enge Zusammenarbeit zwischen dem Auftraggeber und unserem Team. In einer sehr frühen Phase sind bereits erste Module fertiggestellt; der Auftraggeber hat einen frühen Eindruck, ob die Entwicklung wie gewünscht erfolgt.
SCRUM-Modell
Ein agiles Vorgehen gemäß dem SCRUM-Modell bietet sich immer dann an, wenn im Vorfeld des Softwareentwicklungsprozesses noch nicht alles detailliert feststeht oder
- eine ständige Anpassung des Systemumfelds notwendig ist,
- der Time-to-Market-Druck sehr hoch ist,
- neue Technologien zum Einsatz kommen,
- besondere Aufmerksamkeit auf die Zusammenarbeit und die Kommunikation zwischen Auftraggeber und -nehmer gelegt werden soll,
- ein frühzeitiger und ständiger Einblick in den Status der Implementierung zur kontinuierlichen Verifizierung der Anforderungen gefordert ist oder
- eine detaillierte und umfassende Dokumentation des Prozesses nicht die höchste Priorität hat.
Vorgehen nach V-Modell
Auch das V-Modell hat hin und wieder noch seine Berechtigung
Nicht jedes Projekt eignet sich für ein agiles Vorgehen. Insbesonders wenn die Anforderungen bereits detailliert definiert sind, der Auftraggeber keine aktive Rolle während der Softwareentwicklung wahrnehmen will und der Anforderungs- und Budgetrahmen absolut fix sind, ist in der Regel ein Vorgehen nach V-Modell vorzuziehen.
Dabei gliedert sich das Softwareentwicklungsvorgehen nach klassischem V-Modell in mehrere ziel- und ergebnisorientierte Prozessphasen, die sequentiell abgearbeitet werden, d.h. jeder Phasenbeginn bedingt den Abschluss der vorherigen.
Den spezifizierenden Phasen stehen jeweils testende Phasen gegenüber, was in der Darstellung das charakteristische, imaginäre „V“ ergibt. Diese Gegenüberstellung führt zu einer möglichst hohen Testabdeckung, weil die Spezifikationen der jeweiligen Entwicklungsstufen die Grundlage für die Tests (Testfälle) in den entsprechenden Teststufen sind. Treten dabei Unstimmigkeiten auf, muss zu der jeweils überprüften Phase, welche sich auf der linken Seite befindet, zurückgekehrt werden.
Im ersten Schritt werden im Rahmen der Analyse die Anforderungen an das System definiert. Das Fachkonzept beschreibt dann die Prozesse, die von der Anwendung unterstützt werden sollen. Mit Hilfe von Prozessmodellen folgt die Analyse von Inhalt und Ziel der einzelnen Prozessschritte. Am Ende stehen für die wesentlichen Prozessschritte detaillierte Ablaufbeschreibungen mit Voraussetzungen und Nachbedingungen in Form von UseCases.
Nachdem im Rahmen der Fachkonzeption das „Was“ analysiert worden ist, geht es in der DV-technischen Feinspezifikation (Design) um das „Wie“. Wie erfolgt die technische Umsetzung der Prozesse in IT-Abläufe? Als konkrete Vorlage für die anschließende Implementierung werden u.a. folgende Konzepte und Modelle erstellt:
- Architekturkonzept
- Datenmodell / Objektmodell
- Berechtigungskonzept
- Oberflächenmodell
- Maskendesign (funktional / look and feel)
- Schnittstellenkonzept
Bei der Realisierung werden die im DV-Konzept beschriebenen Vorgaben konsequent umgesetzt und so die Konzepte in ein IT-System überführt. Diese Projektphase gliedert sich in die Abschnitte Systementwurf und Implementierung.
Im Rahmen der Übergabe erfolgen dann die abschließenden System- und Integrationstests, die Bereitstellung des Systems sowie anschließend dessen Abnahme.
Projektmanagement
Immer wissen, wo man steht
Jederzeit wissen, wo man steht – das macht eine gute Projektsteuerung aus. Dafür braucht es durchgängige Transparenz hinsichtlich Restaufwand, Kosten, Terminen und möglichen Risiken. Erst dann lassen sich Projekte wirklich zielgerichtet planen und steuern.
Als Ergebnis langjähriger Erfahrung in der Steuerung teilweise sehr großer Projekte nutzen wir etablierte Methoden und Instrumente für ein professionelles, systematisches Projektmanagement. Der Einsatz dieser Tools garantiert Effizienz, Termintreue und damit den Projekterfolg.
Neben der persönlichen Erfahrung in der Steuerung komplexer Projektteams sind ISB-spezifische Controlling- und Steuerungsinstrumente wie z.B.
- Risikoanalysen,
- Restaufwandsschätzungen,
- Meilensteintrendanalysen oder
- Statusberichte
das Handwerkszeug jedes ISB-Projektmanagers. Wie die Erfahrung aus vielen erfolgreich abgeschlossenen Projekten zeigt, stellen unsere Standards eine optimale Balance aus größtmöglicher Transparenz und gesundem Pragmatismus dar. Sie garantieren die zielgerichtete Steuerung von Projekten mit dem nötigen Augenmaß.
Qualitätsmanagement ohne Kompromisse
Unser Qualitätsmanagement stellt sicher, dass die gestellten Anforderungen an das zu erstellende System für jede Projektphase kompromisslos erfüllt werden. Folgende drei Phasen sind dabei wesentlich:
Planungsphase
In der Planungsphase werden alle Richtlinien, Aktivitäten und Konzepte beschrieben und vorbereitet, die im Rahmen des Projekts zum Einsatz kommen. In unserer Sichtweise ist Qualität planbar und Teil des Planungs- und Design-Prozesses.
Qualitätssicherung
Ein Team von QS-Beauftragten prüft die Korrektheit von Ergebnissen in Bezug auf Pläne, Konzepte, Dokumentationen, Oberflächen etc. Auch die vollständige und korrekte Durchführung von QS-Maßnahmen (z.B. Tests) wird durch das QS-Team geprüft. Diese QS-Prozesse sind klar definiert, werden durch standardisierte Dokumente unterstützt und manuell durchgeführt.
Test
Systemkomponenten werden in verschiedenen Stufen und unter verschiedenen Qualitätsaspekten getestet. Diese Tests können automatisiert und/oder manuell erfolgen. Testprozesse und -standards werden folglich gesondert definiert oder bilden komplexe eigenständige Prozesse als Ausprägung des Qualitätsmanagements. Die Testergebnisse und -reports fließen wiederum in die QS-Prozesse zur formalen Prüfung ein.
Für all das haben wir ein methodisches Vorgehensmodell zur qualitätssichernden Projektbegleitung entwickelt, das sich an den Vorgaben der ISO 9001 und den Richtlinien des PMI orientiert. Das Qualitätssystem ist durch seinen modularen Aufbau so flexibel, dass nur die Elemente eingesetzt werden müssen, die auch einen Kundennutzen realisieren und gleichzeitig eine größtmögliche Kosteneffizienz realisieren. Projekte „in quality, time & budget“ sind damit eine logische Konsequenz.