Qualitätssicherung im Softwareentwicklungsprozess der Software Life GmbH

Aus Winfwiki

Wechseln zu: Navigation, Suche
Namen der Autoren: Alexander Beljaev, Marcus Brock, Gino Buhrau, Stefan Schulz
Titel der Arbeit: "Qualitätssicherung im Softwareentwicklungsprozess der Software Life GmbH"
Hochschule und Studienort: FOM Berlin


Inhaltsverzeichnis


1 Abkürzungsverzeichnis

Abkürzung Bedeutung
DAUDümmster anzunehmender User
IECInternational Electrotechnical Commission
ISOInternational Organization for Standardization
NWANutzwertanalyse
SL GmbHSoftware Life GmbH
XPExtreme Programming
PBProduct-Backlog
SPSprint-Backlog
BCBurndown-Chart
DSDaily-Scrum
SLAService Level Aggreement

2 Abbildungsverzeichnis

Abb.-Nr. Abbildung
1Softwareentwicklungsprozess (IST)
2Wasserfallmodell
3Spiralmodell
4V-Modell
5Extreme Programming
6SCRUM
7Optimaler Testumfang
8Phasenmodell für den Testprozess
9Black-Box und White-Box-Test
10Gängige Testautomatisierungstools
11Softwareentwicklungsprozess (SOLL)

3 Tabellenverzeichnis

Tabelle Nr. Bezeichnung
1Modellbewertung (Worten)
2Modellbewertung (Noten)
3Gewichtung und Kriterien
4Auswertung der Nutzwerte
5Rangfolge der Vorgehensmodelle

4 Abstract

Die Software Life GmbH möchte auf Grund von vermehrten Kundenreklamationen über fehlerhafte Software, unzureichende Dokumentationen der erstellten Anwendungen und Verärgerungen über Zeitverzögerung in der Auftragsbearbeitung eine Veränderung des Bearbeitungsprozesses hinsichtlich der Softwareentwicklung vornehmen. Nach der Aufnahme des IST-Zustandes wird im Rahmen der Fallstudie ein Konzept zur Optimierung des Softwareentwicklungsprozesses sowie zur Sicherung der Softwarequalität erstellt. Primäres Ziel der vorzunehmenden Änderungen am Softwareentwicklungsprozess ist die Steigerung der Qualität der Software. Langfristig soll dadurch ein besseres Image und Reduzierung der Kosten (Wartung usw.) erreicht werden. So wurden folgende Anforderungen an zukünftige Kundensoftware ermittelt, die innerhalb der Softwareentwicklung mit höchster Priorität umzusetzen sind.

  • Funktionalität
  • Zuverlässigkeit
  • Bedienerfreundlichkeit
  • Effizienz
  • Skalierbarkeit
  • Übertragbarkeit, Weiterverwertung des Quellcodes

Neben der Auswahl eines geeigneten Vorgehensmodells, werden weitere Qualitätssicherungsmaßnahmen in diesem Zusammenhang betrachtet. Die Rolle der Dokumentation sowie Softwaretests spielen dabei eine sehr wichtige Rolle.

5 Einleitung

„Aufgrund ungenügender Entwicklungsmethoden ist die Qualität der Anwendungen oft schlecht. Dies zeigt eine Bestandsaufnahme der deutschen Softwarebranche, die das Bundesforschungsministerium in Auftrag gegeben hat.“[1] Dabei gehen nur die wenigsten Unternehmen, systematische Wege um eine Anwendung entstehen zu lassen. Rund die Hälfte der Firmen programmieren einfach ins Blaue hinein, ohne sich groß Gedanken über den Ablauf der Softwareerstellung zu machen.[2]
Das Ergebnis ist die Überschreitung von gesetzten Terminen und geplanten Kosten. Entwicklungsentscheidungen können häufig nicht nachvollzogen werden. Auch eine langfristige Wartung der Anwendungen ist nur mit großem Aufwand möglich.[2] Dies sind nur einige Gründe, die sich unmittelbar auf die Qualität der entwickelten Produkte und damit auch auf die Kundenzufriedenheit auswirken.
In der Gesamtbetrachtung wirkt sich die Kundenzufriedenheit auf die zukünftigen Aufträge aus, da negative Rezessionen leichter an andere potenzielle Kunden weitergegeben werden als positive.

5.1 Unternehmen

Das Untersuchungsobjekt der Fallstudie ist Software Life GmbH (SL GmbH). Die Software Life GmbH ist ein reales Unternehmen, dass für die vorliegende Arbeit verfremdet wurde. Das Unternehmen wurde im Jahr 2002 in Berlin gegründet. Die SL GmbH ist in den Bereichen der IT-Infrastruktur und Softwareentwicklung tätig. Der Kundenstamm umfasst mittelständische Unternehmen sowie den öffentlichen Dienst im Bereich Infrastruktur. In der SL GmbH werden zurzeit ca. 18 Mitarbeiter beschäftigt. Diese bearbeiten unter anderem die Aufgaben im Unternehmensinternem Bereich wie z. B. Finanzen und Controlling. Für die Softwareentwicklung arbeiten fünf Mitarbeiter an verschiedenen Projekten in kleineren Teams. Weitere sieben Angestellte übernehmen die Einrichtung der IT-Infrastruktur beim Kunden und bei der SL GmbH. Durch eine gute Auftragslage in der Softwareentwicklungsbranche sollen weitere Kunden im Umland Brandenburg akquiriert werden um das Gesamtwachstum des Unternehmens zu stärken.

5.2 Zielsetzung

Ziel der vorliegenden Arbeit ist die Entwicklung eines Konzeptes zur Sicherung der Qualität im Softwareentwicklungsprozess des Unternehmens SL GmbH. Als primäres Ziel soll dadurch die Steigerung der Softwarequalität ermöglicht werden. Langfristig könnten dadurch ein besseres Image und die Reduzierung der Kosten (Entwicklung, Wartung usw.) erreicht werden. Zur Entwicklung eines Konzeptes ist eine Analyse der aktuellen Vorgehensweisen sowie die Probleme und Schwachstellen im Entwicklungsprozess, eine wichtige Voraussetzung. Aus den daraus gewonnenen Ergebnissen kann anschließend die Auswahl eines geeigneten Vorgehensmodells erfolgen. Aber auch weitere Qualitätssicherungsmaßnahmen werden in diesem Zusammenhang betrachtet und fließen in das Konzept ein. Die Rolle der Dokumentation sowie Softwaretest spielen dabei eine sehr wichtige Rolle.

6 Qualitätsmerkmale von Software

Um die Qualität eines Entwicklungsprozesses und einer Software messen und bewerten zu können, muss erst einmal klar definiert werden, was Qualität in diesem Zusammenhang überhaupt bedeutet.
International Organization for Standardization (ISO) und International Electrotechnical Commission (IEC) definieren Qualität als Ergebnis des Vergleiches des fertigen Produktes mit den vorher definierten Anforderungen, also als „Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“[3] bzw. als „Übereinstimmung zwischen den festgestellten Eigenschaften und den vorher festgelegten Forderungen einer Betrachtungseinheit“.[4]

Wie aus den zitierten Normen ersichtlich, existiert nicht eine universelle Qualität, sondern sie ergibt sich aus den Anforderungen sowie deren Umsetzung. In diesem Abschnitt werden Merkmale beschrieben, die eine Software mindestens erfüllen muss, um als qualitativ hochwertig betrachtet werden zu können. Es existieren verschiedenste Modelle, welche Softwarequalität sowie deren Sicherung beschreiben. Die ISO/IEC 9126, welche inzwischen in der Norm ISO/IEC 25000 aufgegangen ist, nennt folgende Qualitätsmerkmale, welche die SL GmbH bei ihren Produkten umzusetzen wünscht:

Funktionalität: Die Software besitzt alle geforderten Funktionen mit den vorher festgelegten Eigenschaften.
Zuverlässigkeit: Die Software weist eine möglichst geringe Versagenshäufigkeit auf und hält auch unvorhergesehenen Eingaben durch "Dümmst Anzunehmende User" (DAU) stand.
Benutzbarkeit: Die Software sollte, mit möglichst geringem Schulungsaufwand für den Benutzer, bedienbar sein.
Effizienz: Die Software zeichnet sich durch geringen Ressourcenbedarf sowie geringe Antwort- und Verarbeitungszeiten aus.
Änderbarkeit: Der Aufwand zur Fehlerbeseitigung oder Anpassung an neue Bedürfnisse ist relativ gering.
Übertragbarkeit: Die Software kann in eine andere organisatorische Umgebung oder auf eine neue Hardware- oder Software-Umgebung übertragen werden.

Diese Merkmale sind jedoch sehr allgemein gehalten und lassen sich nur schwer auf individuelle Softwareentwicklungsprojekte übertragen. Im Rahmen der vorliegenden Arbeit wird am Beispiel der SL GmbH ein Konzept aufgezeigt, mit dem diese Qualitätsmerkmale der entwickelten Softwareprodukte erreicht werden können.

7 Analyse des Entwicklungsprozesses

7.1 Aktueller Softwareentwicklungsprozess

7.1.1 Auftragsannahme

Der Entschluss über die Annahme eines Kundenauftrags geschieht durch eine Machbarkeitsanalyse die auf Grund der Auftragsbeschreibungen des Kunden erstellt wird und ihr Ergebnis in einer Aufstellung der Kosten und des Zeitaufwands hat. Durch Rückmeldung des Kunden wird die Entscheidung mitgeteilt, ob der Auftrag an die SL GmbH vergeben wurde oder ein anderes Softwareentwicklungsunternehmen den Zuschlag für den Kundenauftrag bekommen hat. Im nächsten Schritt werden die detaillierten Anforderungen des Kunden aufgenommen oder, im Optimalfall, wird der SL GmbH ein Lastenheft über die gewünschten Fähigkeiten des Produkts zur Verfügung gestellt. Auf Grundlage der Kundenbeschreibungen oder des Lastenhefts wird durch die SL GmbH ein Pflichtenheft bzw. eine detaillierte Beschreibung über das Umsetzungsvorhaben des Auftrags erstellt. Nachdem die Klärung der Einzelheiten zwischen Auftraggeber und Auftragnehmer stattgefunden hat wird mit der Umsetzung des Kundenauftrags begonnen.

Je nach Größe und Umfang des Auftrags werden ein oder mehrere Entwickler mit der Umsetzung des Kundenvorhabens beauftragt. Da alle Softwareentwickler mit annähernd gleichen Fähigkeiten ausgestattet sind, werden Mitarbeiter entsprechend der Ressourcenplanung ausgewählt.

7.1.2 Softwareentwicklung

Die Entwicklung der Software obliegt dem/der jeweiligen Entwickler. Da die erfolgreiche Umsetzung der Anwendung im Vordergrund steht, liegt auch die Art der Umsetzung in den Händen des/der Entwickler/s. Vereinbarte Konventionen hinsichtlich der Unterteilung in eine Drei-Schichten Architektur, einer Effizienten Gestaltung des Quellcodes, Dokumentation des Quellcodes, bzw. einer technischen Dokumentation werden angestrebt, jedoch nicht kontrolliert.

Die Qualität der Softwareentwicklung hängt somit von den „Fähigkeiten“ des/der jeweiligen Softwareentwickler/s und von der Entwicklungszeit der Anwendung ab. Weitergehende Betreuung und Wartung der Software wird von den jeweiligen Entwicklern übernommen und nur im Krankheitsfall oder Urlaubszeiten durch eine Vertretung wahrgenommen.

7.1.3 Testen der entwickelten Software

Die Tests der Software finden nahezu ausschließlich nur in der dafür vorgesehenen Testphase statt. Durch festgelegte Fertigstellungstermine und Überziehung der vorhergehenden Phasen, bleibt in den meisten Fällen für das Testen kaum Zeit. Dies führt dazu, dass Softwaretests nur unzureichend oder gar nicht durchgeführt werden. Um den Fertigstellungstermin einzuhalten, wird damit fehlerhafte Software in Kauf genommen.

Die Softwaretests werden überwiegend von den Entwicklern selbst durchgeführt. Eine ausführliche Dokumentation der Tests findet nicht statt. Es wird lediglich festgehalten, dass während der Entwicklung Tests durchgeführt wurden. Gefundene Fehler werden direkt von derselben Person behoben.

Nach Fertigstellung der Software findet bei der Übergabe, zusammen mit dem Kunden ein Abnahmetest statt. Dabei wird dem Kunden das entwickelte Produkt vorgeführt und die Funktionen, gemäß den Kundenspezifikationen, ausprobiert.

7.1.4 Nachbetreuung und Wartung

Für die weitergehende Betreuung wird zwischen der SL GmbH und dem Kunden ein Service Level Agreement (SLA) abgeschlossen, indem genau geregelt ist, welche weiterführende Dienstleistung in welcher Qualität durch die SL GmbH wahrgenommen wird.

Die Betreuung wird soweit möglich von den Entwicklern übernommen, die auch schon für die Erstellung der Anwendung verantwortlich waren. Eine mögliche Kontrolle der Softwarequalität durch einen weiteren Mitarbeiter ist hiermit ebenfalls nicht gegeben, da auch nur im Falle von Krankheit oder Urlaub eine Vertretung für die Betreuung der Anwendung bereitsteht, die sich um Fragen hinsichtlich Bedienung, Fehlerkorrektur und Anpassungen kümmert, sollte dies nötig sein. Aufgrund der knappen Ressourcenplanung wird diese Tätigkeit von der Vertretung jedoch nur „nebenbei“ erledigt und zeitaufwendige Änderungen bis zur Wiederkehr des zuständigen Entwicklers „liegengelassen“.

Die Betreuung und Wartung der Software ist in der jährlichen Ressourcenplanung einkalkuliert, richtet sich jedoch auch nach der aktuellen Auftragslage, bzw. der momentanen Auslastung der Mitarbeiter. Eine Unterbrechung aktueller Softwareprojekte bleibt somit nicht aus und es muss oftmals nach Prioritäten abgewogen werden.

7.2 Strategien

7.2.1 Planungsstregien/Ressourceneinsatz

Die Planung des Ressourceneinsatzes findet am Ende jedes Geschäftsjahres für das kommende Geschäftsjahr statt. Berücksichtigt wird der zeitliche Aufwand, der für abgeschlossene Kundenaufträge hinsichtlich der Wartung benötigt wird, Kundenaufträge, dessen Umsetzung im laufenden Geschäftsjahr stattfinden und die Prüfung von neuen Aufträgen. Anhand dieser Planung werden die Mitarbeiter zu 100% ihrer Arbeitszeit „verplant“ und es wird entschieden, ob weitere Mitarbeiter nötig sind, die für einen befristeten Zeitraum von 12 Monaten eingestellt werden.

Nicht berücksichtigt innerhalb des Ressourceneinsatzes ist die Dauer für die Einarbeitungszeit in neue Entwicklungsmethoden und Entwicklungswerkzeuge. Des Weiteren übersteigt der zeitliche Aufwand für Wartungsarbeiten oftmals den im Voraus kalkulierten Zeitraum, sodass Verzögerungen bei aktuell zu bearbeitenden Aufträgen entstehen unter denen die Qualität der zu erstellenden Software leidet.

Innerhalb der Auftragsbearbeitung wird eine Terminplanung erstellt, in der die Abhängigkeiten hinsichtlich der Start- und Endtermine der einzelnen Teilprojekte dargestellt sind. Sind mehrere Entwickler beteiligt, dann findet ebenfalls eine Einsatzplanung statt, für welchen Zeitraum die jeweiligen Entwickler für den Kundenauftrag eingesetzt sind.

7.2.2 Kommunikationsstrategien

Kommunikation mit dem Auftraggeber:

Eine intensive Kommunikation mit dem Auftraggeber findet während der Phase der Erstellung des Pflichtenheftes statt. Eine detaillierte Beschreibung der zu erstellenden Anwendung wird besprochen und Einzelheiten über die zu erfüllenden Funktionalitäten und das Layout der Anwendung wird festgehalten. Während des Entwicklungsprozesses findet eine Kommunikation mit dem Kunden nur dann statt, wenn Fragen hinsichtlich Einzelheiten bezüglich einzelner Funktionen erneut zu klären sind oder der Auftraggeber über zeitliche Verzögerungen informiert werden muss.

Nach Fertigstellung der Software wird dem Kunden ein Produkt überreicht, welches ihm in seinen Einzelheiten vorgestellt wird und mit dem der Kunde Funktionstests durchführt. Nach Ablauf der Funktionstests werden, wenn nötig, weitere Anpassungen vorgenommen.

Mit Beendigung der Anpassung wird dem Kunden das Fertige Produkt überreicht und der Auftrag ist abgeschlossen.

Kommunikation innerhalb der SL GmbH:

Für den Zeitraum der Umsetzung eines Auftrags findet eine Kommunikation der beteiligten Entwickler untereinander statt. Es wird ein Projektleiter ernannt, der sich um die Festlegung der einzelnen Teilprojekte kümmert und diese an die einzelnen Teammitglieder vergibt. In wöchentlichen Meetings werden die Fortschritte besprochen, mögliche Verzögerungen festgestellt und ob Änderungen innerhalb der Umsetzung vorzunehmen sind.

Der Projektleiter stimmt die Ergebnisse der Besprechung mit dem Terminplan des Kundenauftrags ab und nimmt, wenn nötig, Kontakt mit dem Auftraggeber auf, um ihn über Veränderungen der Umsetzung zu informieren.

7.3 Qualitätssicherungsbereich

Ein eigenständiges Konzept für Maßnahmen der Qualitätssicherungen existiert nicht in der SL GmbH, vielmehr wurden Konventionen aufgestellt, die während des Prozesses der Entwicklung von Anwendungen einzuhalten sind. Diese wurden jedoch seit der Einführung nicht mehr verändert oder auf ihren Nutzen überprüft.

Das „Dokument“ informiert unter anderem über die Vorgehensweise, wie Kundenaufträge durchgeführt werden, wann mit dem Kunden während des Entwicklungsprozesses Kontakt aufgenommen wird, wer mit dem Kunden Kontakt aufnimmt, Beschreibungen über die theoretischen Grundlagen von Softwarearchitektur und das diese bei der Entwicklung von neuen Anwendungen anzuwenden sind, dass eine Sicherung des Quellcodes von jedem Softwareentwickler vorzunehmen ist und wo diese Sicherung stattzufinden hat. Des Weiteren sind einige Angaben gemacht worden, wie der Quellcode zu gestalten ist, dass der Quellcode zwecks nachträglicher Verständlichkeit zu kommentieren ist und eine vollständige technische Dokumentation anzufertigen ist.

Die Existenz und der Inhalt des Dokuments ist jedem Anwendungsentwickler bekannt und es wird vorausgesetzt, dass diese Vereinbarungen eingehalten werden, kontrolliert werden diese Vereinbarungen aufgrund des Zeitmangels jedoch meistens nicht.

7.4 Fazit des Entwicklungsprozesses

Abbildung 1: Softwareentwicklungsprozess (IST)
Abbildung 1: Softwareentwicklungsprozess (IST)[5]

Anhand der vorliegenden Analyse des IST-Zustandes ergibt sich folgende Darstellung des Softwareentwicklungsprozesses inklusive der Auftragsbearbeitung.

Durch die Kapitel 7.1 - 7.3 wird nochmal deutlich, wo die Mängel innerhalb des Entwicklungsprozesses hinsichtlich der Qualität der Anwendungen liegen.

  • Keine Kontrolle über die Einhaltung von vereinbarten Konventionen hinsichtlich Quellcodegestaltung, technische Dokumentation, Kommentaren innerhalb des Quellcodes
  • Keine Kontrolle über die Softwarearchitektur was eine Einhaltung der drei Schichten-Architektur betrifft
  • Kein Konzept für den unterbrechungsfreien Projektverlauf im Fall von Mitarbeiterausfall
  • Fehlendes Konzept für die weitergehende Betreuung von Anwendungen
  • Methodik des Testens liegt fast ausschließlich beim zuständigen Entwickler
  • Verzögerungen der Fertigstellung durch falschen Ressourceneinsatz, bzgl. der doppelten Verantwortung des Entwicklers für laufende Aufträge und Wartungsarbeiten
  • Der Kunde ist nicht im Entwicklungsprozess eingebunden; Änderungswünsche des Kunden werden der SL GmbH somit erst nach der Präsentation des Produktes mitgeteilt
  • Keine Berücksichtigung von Fortbildungsmaßnahmen; Einarbeitung in neue Techniken erfolgen auftragsbezogen und wirken sich somit negativ auf die kalkulierte Entwicklungszeit aktueller Aufträge aus

Aufgrund eines fehlenden Konzeptes und Durchführung geeigneter Testmethodiken lassen sich bzgl. der Qualität der Software keine genauen Angaben machen hinsichtlich Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Skalierbarkeit, Übertragbarkeit der Anwendung.

8 Qualitätssicherungsmaßnahmen

8.1 Vorgehensmodelle und ihre Bedeutung für Qualität der Software

Vorgehensmodelle bilden einen Hauptbestandteil der Softwareentwicklung und wirken so unmittelbar auf die Umsetzung des Projektes und Produktes ein. Im Prozessablauf der Softwareentwicklung wird durch ein Vorgehensmodell bestimmt, auf welche Art und Weise die Software vom Team entwickelt wird. Ein grundlegendes Unterscheidungskriterium stellt dabei der Ablauf des Prozesses dar, dieser kann sequentiell, iterativ oder inkrementell (agil) erfolgen.

  • sequentiell: aufeinanderfolgende Schritte in einer bestimmten Reihenfolge
  • iterativ: wiederholender Prozess, der das Produkt in jedem Durchlauf verfeinert
  • inkrementell: aufeinander aufbauender Prozess, zur Schrittweisen Vervollständigung

Zusätzlich zum Ablauf eines Vorgehensmodells gibt es weitere spezielle Eigenschaften die mit Hilfe einer Analyse herausgefiltert werden sollen. Die zu prüfenden Eigenschaften zielen auf die zu erreichende Qualität und Flexibilität des Entwicklungsprozesses ab. Die zu prüfenden Kriterien werden danach wie folgt beschrieben.[6]

  • Projektgröße: Geeignete Projektgröße für das Vorgehensmodell
  • Benutzerbeteiligung: Eingriffsmöglichkeiten des Kunden in den Entstehungsprozess
  • Managementaufwand: Anforderungen an den Projektleiter für die Steuerung des Projektes
  • Anpassbarkeit: Möglichkeiten zur Änderung von Anforderungen im Projekt
  • Zulässiger Änderungszeitpunkt: Die zeitliche Möglichkeit Anpassungen durchführen zu können
  • Risikominimierung: Alternativenauswahl und Risikomanagement
  • Qualität: Qualität des Ergebnisses aus dem Entwicklungsprozess
  • Entwicklungszeit: Dauer bis wann ein verwendbarer Prototyp bereitsteht

Die Qualität des Entwicklungsprozesses bestehen im Grunde aus den Merkmalen im Kapitel 6. Diese Punkte können auch hier eine unterschiedliche Gewichtung einnehmen, um genauer zu Beschreiben wie die Anforderungen an die Qualität sind. In der Untersuchung werden die folgenden Modelle auf dessen Einsatz in der SL GmbH auf die Vor- und Nachteile geprüft.

  • Wasserfallmodell
  • Spiralmodell
  • V-Modell
  • Extreme Programming
  • SCRUM

8.1.1 Wasserfallmodell

Abbildung 2: Wasserfallmodell
Abbildung 2: Wasserfallmodell[7]

Das Wasserfallmodell stellt für die sequentiellen Vorgehensmodelle einen typischen Vertreter dar. Wie auch in anderen Modellen werden in diesem auch bestimmte Phasen festgelegt die zur Erreichung des Gesamtziels beitragen. Der Wasserfall in diesem Modell bezieht sich auf die Phasen zueinander (Abbildung 2). Diese werden wasserfallartig von einer Ebene auf die nächste erreicht. Bedingung für die Erreichung der nächsten Phase ist der Abschluss der vorhergehenden, da im ursprünglichen Modell kein Rückschritt möglich ist. Im modifizierten Modell hingegen ist es möglich, einen Schritt zur vorhergehende Phase zurückzugehen. Durch diese Eigenschaft ist es möglich, einen geringen Grad an Flexibilität zu erreichen. Das nachfolgende Schema umfasst 6 Phasen die zur Nutzung des entwickelten Produktes führen sollen.

  • Initialisierung: Stellen der Anforderungen an das Produkt (Zieldefinition).
  • Analyse: Überprüfung bereits vorhandener Programme oder Prozesse im Unternehmen, welche wiederverwendet werden können.
  • Entwurf: Grobkonzept oder Prototyp der Software, welcher für das weitere Vorgehen verwendet wird.
  • Realisierung: Verfeinerung des Prototyps und Realisierung des gesamten Funktionsumfangs
  • Einführung: Umfangreiche Systemtests und Abnahme durch den Auftraggeber
  • Nutzung: Verwendung im Produktivsystem

Für das Wasserfallmodell ergeben sich daher folgende Merkmale bezogen auf die Anforderungen des Unternehmens.

Vorteile:

  • geeignet für kleine Projekt
  • geringer Managementaufwand

Nachteile:

  • geringe Anpassungsmöglichkeit während der Entwicklung
  • minimale Benutzerbeteiligung beim Prozess
  • keine Risikominimierung
  • nur mittlere Qualität durch fehlende Eingriffsmöglichkeit während der Entwicklung
  • sehr hohe Entwicklungszeit auf Grund fehlender Prototypen

8.1.2 Spiralmodell

Abbildung 3: Spiralmodell
Abbildung 3: Spiralmodell[8]

Im Bereich der iterativen Vorgehensmodelle wird häufig das Spiralmodell verwendet. Diese Modellart ermöglicht es, die vorhandenen vier Phasen mehrfach zu durchlaufen, um so eine Verfeinerung des Ergebnisses zu erzielen. Wie in der Abbildung 3 zu erkennen ist, werden die Phasen in vier Quadranten unterteilt über die eine Spirale gelegt wird. Diese Art und Weise des Vorgehens ermöglicht es, bei jedem Durchlauf die Ziele und Risiken neu zu definieren. So können die Schwerpunkte der Entwicklung auf die jeweilige Situation angepasst werden.

In den Phasen des Modells werden dabei folgende Aufgaben durchgeführt.

  • Festlegen der Ziele: Anforderungen definieren und mögliche Alternativen bereitstellen.
  • Beurteilung von Alternativen, Risikoanalyse: Umfangreiche Analyse der Risiken und Bewertung möglicher Alternativen und deren Risiko.
  • Entwicklung und Test: Umsetzung des Entwicklungsschrittes und Abnahme des Ergebnisses.
  • Planung des nächsten Zyklus: Weitere Vorgehensweise im nächsten Zyklus klären und planen.

Durch den iterativen Durchlauf werden in den verschiedenen Stufen Prototypen entwickelt, die zum Schluss zu einem betriebsfähigen Prototyp führen. Die Anforderungen werden so von einer Stufe zu nächsten verfeinert. Für das Unternehmen ergeben sich somit folgende Vor- und Nachteile.
Vorteile:

  • ständiger Eingriff in den Entwicklungsprozess durch den Kunden
  • starke Risikominimierung durch ausführliche Analyse und Alternativen
  • ständige Möglichkeit Änderungen an den Anforderungen vorzunehmen

Nachteile:

  • hoher Managementaufwand durch langen Prozess
  • geeignet für sehr große Projekte
  • relativ hohe Entwicklungszeit bis zu einem Nutzbaren Prototypen

8.1.3 V-Modell

Abbildung 4: V-Modell
Abbildung 4: V-Modell[9]

Das V-Modell stellt ein erweitertes sequentielles Modell dar, welches die Bestandteile einer Qualitätssicherung beinhaltet. Der Aufbau des Modells ähnelt dem des Wasserfallmodells (Abbildung 2) mit dem Unterschied eines zusätzlich parallel aufsteigenden Wasserfalls. Dieser steuert die einzelnen Testphasen (Abbildung 4) im Entwicklungsprozess.

Mit Hilfe der entwickelten Testfälle des Entwicklungszyklus ist es möglich, beim Durchlaufen der Tests die Ergebnisse zu überprüfen und gegebenenfalls Änderungen einzubringen, um die Qualität und die Anforderungen umzusetzen. Die einzelnen Tests werden dabei auch in verschiedene Bereiche unterteilt. Die Verifikation umfasst dabei, nach Abbildung 4 die Unit-Tests, Integrations-Tests und die System Integration, dabei werden die gestellten Spezifikationen und das Produkt auf Übereinstimmung überprüft. Der zweite Bereich, die Validation, beinhaltet die Abnahme und Nutzung, dabei wird bestimmt, ob das Produkt für den Einsatzzweck geeignet ist.

Vorteile:

  • strukturierter Ablauf des Entwicklungsprozesses und Abbildung einer Qualitätssicherung
  • kleinere Anpassung während der Entwicklung sind möglich
  • geeignet für mittlere Projekte

Nachteile:

  • geringe Kundenbeteiligung im Prozess
  • geringe Risikominimierung durch geringe Anpassbarkeit
  • hohe Entwicklungszeit bis zu einem Prototypen

8.1.4 Extreme Programming

Abbildung 5: Extreme-Proramming
Abbildung 5: Extreme-Proramming[10]

Extreme Programming (XP) ist ein bekanntes Vorgehensmodell im Bereich der agilen Softwareentwicklung. Das Modell verfolgt die Ansätze sich jederzeit flexibel anzupassen und am Menschen zu orientieren.[11]

Für die Grundbasis beim XP sorgen die 4 teilweise auch 5 Grundpfeiler:[12]

  • Kommunikation
  • Einfachheit
  • Feedback
  • Mut
  • Respekt[11]

Die Kommunikation bei der XP ist ein wichtiger Schlüsselpunkt, der es ermöglicht ein gutes und schnelles Feedback auf verschiedene Probleme zu erhalten. Durch die stetige Kommunikation und den Austausch mit den Teamkollegen ist es somit einfacher, anstehende Problemstellungen besser und gemeinsam zu lösen.

Das Feedback kann sowohl positiv als auch negativ ausfallen und benötigt daher auch einen gewissen Mut dies anderen Teammitgliedern mitzuteilen. Negatives Feedback soll sich für das betreffende Mitglied aber eher positiv auswirken, um es in anderen Situationen besser zu machen.

Aus den Grundpfeilern können wir verschiedene Prinzipien ableiten, welche uns bei der Entwicklung helfen. Als primäre Grundprinzipien gelten folgende: [13]

  • Unmittelbares Feedback
  • Einfachheit anstreben
  • Inkrementelle Veränderung
  • Veränderung wollen
  • Qualitätsarbeit

Dies bedeutet im Einzelnen, dass ein unmittelbares Feedback einen besseren Einfluss auf den Lernprozess erzielt, als wenn die Informationen mit einer großen Zeitverzögerung von Tagen oder Wochen bei einem anderen Entwickler eintreffen.[13] Durch das schnelle Feedback lassen sich die gewonnen Kenntnisse auch schneller auf mögliche andere Probleme anwenden.

Die Einfachheit beim XP beschreibt die Umsetzung der einzelnen Module durch die Entwickler. Die Problemstellungen sollen als einfach angesehen werden, um diese so schnell und effizient zu realisieren. Durch die Einsparungen bleiben so mehr Zeit und Ressourcen für die wenigen wirklich komplexen Anforderungen.[14]

Zusätzlich wird durch die inkrementelle Veränderung bewirkt, dass die Probleme in mehreren Schritten umgesetzt werden. So entsteht aufeinander aufbauend eine fertige Software. Veränderung wollen bedeutet die Strategie zu wählen, welche ihnen verschiedene Möglichkeiten offen hält, aber dennoch das dringendste Problem löst.

Als Hauptmerkmal wird auch die Qualitätsarbeit beschrieben. Die Qualität ist nur relativ messbar und spiegelt unter anderem die Zufriedenheit des Kunden wider. Auf Grund dessen ist es wichtig, die Anforderungen an die Qualität auch mit dem Kunden abzustimmen und sich diese auch öfters kontrollieren zu lassen.[15] Weitere weniger zentrale Prinzipien sind folgende:[14]

  • lernen lehren: ständiger Lernprozess
  • kleine Anfangsinvestition: Fokussierung auf wirklich wichtige Bereiche
  • Spielen, um zu gewinnen: aus Fehlern lernen und auf Sieg spielen
  • Gezielte Experimente: Risikominimierung durch einzelne Tests
  • Offene, ehrliche Kommunikation: Basis für die Zusammenarbeit im Team
  • Die Instinkte der Mitarbeiter nutzen, nicht dagegen arbeiten: Nutzung von Denkansätzen (Brainstorming)
  • Verantwortung übernehmen: Eigenverantwortung durch den Entwickler
  • An örtliche Gegebenheiten anpassen: Prüfung der Anforderungen und richtiges Einsetzen von XP
  • Mit leichtem Gepäck reisen: keine Zusätzliche Features einbauen, sondern nur das was gefordert ist
  • Ehrliches Messen: richtiges Einschätzen von Projektfortschritten

Aus den Merkmalen und der Vorgehensweise ist erkennbar, das XP auch ein iteratives Modell darstellt. Jede Problemlösung durchläuft den Lebenszyklus des XP-Prozesses (Abbildung 5).

Vorteile:

  • kleine bis mittlere Projekte
  • mittlerer Managementaufwand durch Eigenverantwortung der Entwickler
  • leicht Anpassungsfähig zu einem beliebigen Zeitpunkt
  • kurze Entwicklungszeit

Nachteile:

  • mittlere Risikominimierung auf Grund der Augenblicksbetrachtung eines Problems und deren Lösung
  • mittlere Qualität durch fehlende Wiederverwendbarkeit von Programmen, da häufig Momentlösungen erstellt werden

8.1.5 SCRUM

Abbildung 6: SCRUM
Abbildung 6: SCRUM[16]
Abbildung 7: Burndown-Chart
Abbildung 7: Burndown-Chart[17]

Der Begriff SCRUM bedeutet „Gedränge“ und umschreibt ein agiles Vorgehensmodell welches im Jahr 1996 seine Anfänge findet. [18]

Dieses Vorgehensmodell ist ein inkrementelles sowie ein iteratives Modell, was eine starke Ausprägung zur Teamarbeit fordert. Es werden daher drei verschiedene Rollen in einem SCRUM-Projekt beschrieben:[19]

  • Product Owner: Bestimmt das Ziel des Projektes und legt die Anforderungen in User-Stories fest.
  • Scrum-Master: Verteilt die Rechte und Rollen und stellt sicher, dass das Team eine produktive und angenehme Arbeitsweise hat.
  • Team: Ist verantwortlich für die Produktentwicklung.

Für die Umsetzung des Produktes und den Anforderungen aus den User-Stories werden die sogenannten „Artefakte“ benötigt, um die Ergebnisse zu erreichen. Ein Bestandteil dieses Artefakts ist das „Product-Backlog“ (PB) (Abbildung 6). Das PB enthält die gestellten Anforderungen mit einer entsprechenden Priorisierung der gesamten Aufgaben des Produktes, welche nach jedem Sprint aktualisiert werden.[19]

Ein Sprint im SCRUM ist einem Entwicklungszyklus gleichzusetzen und umfasst eine Dauer von 14 bis 30 Tagen. [19] Für diesen Sprint gibt es ein speziellen „Sprint-Backlog“ (SB) der Aufgaben umfasst die in diesem Zyklus umgesetzt werden sollen. Ein Sprint sollte aber nur so viele Aufgaben umfassen, wie Kapazitäten zur Verfügung stehen. Die Kapazität wird entsprechend nachfolgender Formel berechnet: Kapazität (in Stunden) = Arbeitstage × Anzahl Personen × 7 h. (8h Tag inkl. 1h Puffer) [20]

Ein zusätzliches Instrument während eines Sprints ist das „Burndown-Chart“ (BC). Das BC beschreibt auf den Erfahrungswerten aus vorhergehenden Sprints die noch offene Arbeit in einem Sprint (Abbildung 7).

Neben BC werden noch täglich die Daily-Scrums (DS) durchgeführt. Dieses DS ist ein kurzes Meeting von 15 Minuten, was den Beteiligten die Möglichkeit gibt sich über Probleme und den aktuellen Stand auszutauschen. [21]

  • Was wurde seit dem letzten SCRUM fertig gestellt?
  • Was wird bis zum nächsten Meeting fertig sein?
  • Gibt es Hindernisse?

Nach Abschluss eines Sprints wird noch ein „Sprint Review Meeting“ abgehalten. Das Meeting gibt dem Product Owner die Möglichkeit die Ergebnisse des Sprints zu sehen und den Beteiligen ein Rückblick auf Erfolge und Misserfolge des Sprints zu besprechen. [22]

Der Abschluss eines Sprints leitet beim SCRUM automatisch den nächsten Sprint ein bis das Produkt fertig gestellt wurde.

Vorteile:

  • beliebiger Änderungszeitpunkt nach jedem Backlog
  • geringer Managementaufwand durch eigenverantwortliches Handeln der Teammitglieder
  • hohe Qualität durch tägliche Problembesprechung und Gedankenaustausch

Nachteile:

  • nur mäßige Risikominimierung durch Eigenverantwortung
  • mittlere Dauer von Prototypentwicklungen durch lange Sprints
  • starke Anforderungen an die Organisationsfähigkeit des Teams

8.1.6 Nutzwertanalyse

Für die Auswahl des geeigneten Vorgehensmodells wurde die Nutzwertanalyse (NWA) gewählt, um so die bestmögliche Alternative anhand ihrer Kriterien herauszufiltern. Das Ziel der Nutzwertanalyse ist es daher, ein Modell zu finden, welches die Qualitätsanforderungen der Software umsetzen kann und die Möglichkeiten bietet auf verschiedene Einflüsse und Änderungen einzugehen.

8.1.6.1 Bewertung der Vorgehensmodelle

Für die Bewertung der einzelnen Modelle wurden die aus Kapitel 8.1 benannten Untersuchungskriterien herangezogen. Mit Hilfe der Vor- und Nachteile der Untersuchungen konnten dabei die in Tabelle 1 festgehaltenen Ergebnisse erzielt werden.

Tabelle 1: Modellbewertung (Worten)
Wasserfallmodell Spiralmodell V-Modell Extreme-Programming SCRUM
Projektgröße kleingroßmittelmittelmittel
Benutzerbeteiligung minimalgroßgeringmittelmittel
Managementaufwand minimalgroßgeringmittelgering
Anpassbarkeit schwerleichtermittelleichtleicht
zulässiger Änderungszeitpunkt AnfangbeliebigAnfang bis Realisierungbeliebigbeliebig
Risikominimierung keinehochgeringmittelmittel
Qualität mittelgeringmaximalmittelhoch
Entwicklungszeit sehr hochmittelhochkurzmittel

Mit Hilfe der erfassten Daten können die Beurteilungen in messbare Werte umgewandelt werden (Tabelle 2). Die Wertigkeit entspricht von 1 am ungeeignetesten bis 4 am geeignetesten.

Tabelle 2: Modellbewertung (Noten)
Wasserfallmodell Spiralmodell V-Modell Extreme-Programming SCRUM
Projektgröße 31222
Benutzerbeteiligung 14233
Managementaufwand 41323
Anpassbarkeit 14233
zulässiger Änderungszeitpunkt 13233
Risikominimierung 14233
Qualität 21423
Entwicklungszeit 13243
8.1.6.2 Gewichtung

Für die Berechnung der Werte und dessen Wichtigkeit werden diese in einer bestimmten Rangfolge angeordnet (Tabelle 3). Diese entspricht den gestellten Zielanforderungen. Dementsprechend hat die Qualität und Anpassbarkeit einen hohen Einfluss auf die Bewertung der Vorgehensmodelle. Im Gegensatz dazu ist die Projektgröße und Entwicklungszeit eher geringer beeinflussend.

Tabelle 3: Gewichtung von Kriterien
Rang Gewichtung
Qualität 130%
Anpassbarkeit 220%
Benutzerbeteiligung 315%
zulässiger Änderungszeitpunkt 412%
Managementaufwand 59%
Risikominimierung 67%
Projektgröße 75%
Entwicklungszeit 82%
Summe 100%
8.1.6.3 Berechnung und Auswertung

Die bewerteten Vorgehensmodelle können in den entsprechenden Bereichen mit deren Gewichtungen multipliziert werden. Dabei wird die Wertungsnote mal den Gewichtungsfaktor durch 100 geteilt (Tabelle 4). Beispielsweise am Wasserfallmodell: Projektgröße mit Note 3 * (5 / 100) = 0,15

Tabelle 4: Auswertung der Nutzwerte
Wasserfallmodell Spiralmodell V-Modell Extreme-Programming SCRUM
Projektgröße 3 * 0,051 * 0,052 * 0,052 * 0,052 * 0,05
Benutzerbeteiligung 1 * 0,154 * 0,152 * 0,153 * 0,153 * 0,15
Managementaufwand 4 * 0,091 * 0,093 * 0,092 * 0,093 * 0,09
Anpassbarkeit 1 * 0,204 * 0,202 * 0,203 * 0,203 * 0,20
zulässiger Änderungszeitpunkt 1 * 0,123 * 0,122 * 0,123 * 0,123 * 0,12
Risikominimierung 1 * 0,074 * 0,072 * 0,073 * 0,073 * 0,07
Qualität 2 * 0,301 * 0,304 * 0,302 * 0,303 * 0,30
Entwicklungszeit 1 * 0,023 * 0,022 * 0,024 * 0,023 * 0,02
Summe 1,672,542,692,582,95

Durch die Berechnung der Werte mit den Gewichtungen ist es möglich, eine Rangfolge über die Vorgehensmodelle zu erstellen. Diese Rangfolge spiegelt den besten Nutzungsfaktor für die SL GmbH wider. (Tabelle 5)

Deutlich zu erkennen ist, dass das Wasserfallmodell am ungeeignetesten für das Unternehmen ist, da dieses eher eine starre Form des Entwicklungsprozesses abbildet. Im mittleren Bereich bewegen sich das Spiralmodell und Extreme Programming, auf Grund geringer qualitativer Resultate sind diese Vorgehensmodelle nicht die optimale Lösung um die Anforderungen an die Qualität zu erfüllen.

Geeigneter für das Unternehmen hingegen ist das V-Modell. Dieses erfüllt einen hohen Grad an Qualität der Software hat aber Schwachpunkte im Bereich der Anpassungsfähigkeit. Die Kriterien mit den entsprechenden Gewichtungen wurden vom Vorgehensmodell SCRUM am besten abgedeckt. Somit stellt es sich am geeignetesten dar.

Tabelle 5: Rangfolge der Vorgehensmodelle
Vorgehensmodell Bewertung Rang
Wasserfallmodell 1,675
Spiralmodell 2,544
V-Modell 2,692
Extreme Programming 2,583
SCRUM 2,951
8.1.6.4 Fazit der Auswertung

Das durch die Nutzwertanalyse erreichte Resultat ist bedingt aussagekräftig. Sofern sich die Anforderungen (Gewichtungen) an ein Vorgehensmodell ändern sollten, wird so auch das Gesamtergebnis beeinträchtig. Es ist daher möglich die Gewichtungen anzupassen, um sich das Vorgehensmodell bestätigen zu lassen oder womöglich eine für die getestete Konstellation besseres Vorgehensmodell in Erfahrung zu bringen. Beispielsweise könnte sich eine Verschiebung zwischen den Modellen dann bemerkbar machen, wenn die Prioritäten für Anpassbarkeit und Managementaufwand sich verändern.

8.2 Dokumentation

Die gegenwärtige Praxis der Dokumentation bei den Projekten der SL GmbH fördert nur wenig Brauchbares zutage. Die Folge sind fehlende oder nur unvollständige Projekt- bzw. Entwicklungsdokumentationen. Dies erschwert nicht nur eine Kontrolle des Arbeitsfortschritts und der Erfüllung der Anforderungen, darunter leidet auch die Wartbarkeit der Software.

Für viele Entwickler stellt das Erstellen einer Dokumentation nur eine unnötige Arbeitsverzögerung dar. Jedoch übersehen sie den Aufwand, den eine nachträgliche Modifizierung des Programmes bei unzureichender oder gar fehlender Dokumentation mit sich bringt. Hier gilt es auch, die Geschäftsführung und die Kunden für einen erhöhten zeitlichen Aufwand bei den Projekten zu sensibilisieren.

8.2.1 Qualitative Anforderungen an die Dokumentation

Um ein Qualitätsmanagement hinsichtlich des Entwicklungsprozesses sowie des Endprodukts durchführen zu können, bedarf es einer umfassenden Dokumentation aller Anforderungen, Prozesse, Ergebnisse, Änderungen sowie auch der Verfahrensanweisungen, wie und wann Dokumente zu ändern sind. Des Weiteren sind regelmäßige Überprüfungen nötig, inwieweit die bestehende Dokumentation den tatsächlichen Stand des Projektes/Produktes widerspiegelt.

Ähnlich Kapitel 6 „Qualitätsmerkmale von Software“ gibt es auch qualitative Anforderungen an Dokumente. In der DGQ95 werden folgende Qualitätsmerkmale für Dokumente vorgeschlagen:

Änderbarkeit: Eignung von Dokumenten zur Ermittlung aller von einer Änderung betroffenen Dokumententeile und zur Durchführung der Änderung.
Aktualität: Übereinstimmung der Beschreibung des Programms in der Dokumentation mit dem jeweils geltenden Zustand des Programms.
Eindeutigkeit: Eignung von Dokumenten zur unmissverständlichen Vermittlung von Information an jeden Leser.
Identifizierbarkeit: Eindeutige Ansprechbarkeit der Teile von Dokumenten, die Angaben zu einem abgegrenzten Sachverhalt geben, die den Leser interessieren.
Normkonformität: Erfüllung der für die Erstellung von Dokumenten geltenden Vorschriften und Normen.
Verständlichkeit: Eignung von Dokumenten zur erfolgreichen Vermittlung der darin enthaltenen Informationen an einen sachkundigen Leser.
Vollständigkeit: Vorhandensein der für den Zweck der Dokumentation notwendigen und hinreichenden Information.
Widerspruchsfreiheit: Nichtvorhandensein von einander entgegenstehenden Aussagen im Dokument.

8.2.2 Maßnahmen zur Förderung der projektbegleitenden Dokumentation

Folgende Punkte werden als förderlich zur Beseitigung der Dokumentationsprobleme angesehen:

Einstellung, Ziele und Ausbildung: Das Dokumentieren ist als gleichwertige Tätigkeit neben dem Codieren und Testen anzusehen und sollte daher auch zeitlich eingeplant und erfasst werden. Termindruck im Projekt darf nicht zu einer Vernachlässigung der Dokumentationsprozesse führen. Zudem sollte in der Aus- und Weiterbildung auch auf das Dokumentieren Wert gelegt werden.
Infrastruktur des Arbeitsplatzes: Zur Dokumentationserstellung sind dem Entwickler am Arbeitsplatz Geräte und Werkzeuge bereitzustellen. Ebenso ist der papierlose Austausch von Dokumenten zu ermöglichen.
Dokumentenmuster/-vorlagen: Die Bereitstellung von Dokumentenmustern mit Inhaltsverzeichnissen und gegebenenfalls vorgefertigten Textbausteinen ist eine hilfreiche und Qualität fördernde Maßnahme.
Werkzeugunterstützung: Durch den Einsatz von Software-Werkzeugen für die Dokumentation ergeben sich eine Reihe von Vorteilen. Die Dokumentation ist leichter zu aktualisieren, formatieren, papierlos zu übermitteln und zu verwalten.
Qualitätsmaßnahmen: Nach seiner Erstellung ist jedes Dokument zu prüfen, um die inhaltliche und formale Qualität festzustellen.
Managementunterstützung und Akzeptanzstrategien: Das Management muss eventuell seine Prioritäten anders setzen und den Entwicklern Zeit zum Dokumentieren einräumen sowie eine Akzeptanz der Mitarbeiter durch ausreichende Hilfestellung und Kommunikation der Neuerungen schaffen.

8.3 Qualitätsbeeinflussung durch menschliches Verhalten

Im Rahmen eines Softwareentwicklungsprozesses gibt es zwei Parteien die an diesem Prozess beteiligt sind, der Auftraggeber, der ein Problem mit den Mitteln der Informatik lösen möchte und der Auftragnehmer, der bereit ist, eine Lösung zu entwickeln. Im Folgenden sei nur die Rolle des Auftragnehmers betrachtet.[23]
Um eine angestrebte Produktqualität zu erreichen, gilt es Anforderungen zu definieren, die sowohl den Produktionsprozess als auch die am Produktionsprozess beteiligten Personen betreffen. Die Definition von Anforderungen wie auch die gezielte Förderung von Anforderungen, bzw. Fähigkeiten soll in den folgenden Punkten beleuchtet werden.
Eine Analyse der unterschiedlichen Organisationsformen eines Unternehmens hinsichtlich der Qualitätssicherung während der Bearbeitung von Kundenaufträgen soll hier nicht zum Gegenstand werden. Diese Betrachtung und mögliche Anwendung auf die Organisation der SL GmbH würde den Rahmen dieser Fallstudie sprengen, da evtl. ein vollständiges Veränderungsmanagement/Change-Management zusätzlich mit betrachtet werden müsste. Ziel dieser Fallstudie soll weiterhin ausschließlich die Qualitätssicherung während des Softwareentwicklungsprozess bleiben.

8.3.1 Der Projekteigentümer

Bei der Durchführung eines Projektes wird zwischen dem Projekteigentümer, dem Träger der Verantwortung für die Durchführung der Entwicklung, und dem Projektleiter, der das Projektteam führt und das Projekt gegenüber dem Auftraggeber und dem Projekteigentümer repräsentiert, unterschieden. Der Projekteigentümer ist verantwortlich für das Erreichen der Projektziele, der Planung und Steuerung des Projekts und für die Bewertung des Projektstands und der Berichterstattung an Auftraggeber und Projekteigentümer.
Der Projekteigentümer hat folgende Aufgaben:

  • Initiiert das Projekt
  • Ernennt den Projektleiter
  • Berät beim Planen, prüft die Planung
  • Überwacht den Fortschritt
  • Ist für den Projektleiter das erste Sicherheitsnetz bei Problemen
  • Vertritt die Projektinteressen in der Organisation des Herstellers
  • Vertritt die Interessen der Organisation gegenüber dem Projektleiter
  • Löst das Projekt auf
  • Trägt das finanzielle Risiko der Entwicklung, d. h. die Differenz zwischen Kosten und vereinbartem Preis
  • Koordiniert konkurrierende Projekte in seinem Verantwortungsbereich[23]

8.3.2 Der Projektleiter

Mit der Zustimmung des Kunden zur Durchführung des Projektes beginnt die Umsetzung des Auftragnehmers.
Die Rollen des Auftraggebers und des Projekteigentümers sind zu diesem Zeitpunkt bereits bekannt. Durch die Wahl eines Projektleiters wird die Person festgelegt, die das Projekt verkörpert und seine Interessen vertritt. Zu den Aufgaben eines Projektleiters gehören:

  • Abgrenzung des Liefer- und Leistungsumfangs
  • Definieren und Gliedern der Aufgaben
  • Festlegen des Berichtswesens innerhalb des Projektteams sowie an der Schnittstelle zum Auftraggeber
  • Abschätzen des Personalbedarfs
  • Erstellen des Budgets und der Terminpläne
  • Aufgabenzuteilung
  • Bereitstellen der notwendigen Unterstützung
  • Identifizieren von Risikobereichen. [24]

Das Ergebnis nach Erfüllung der an den Projektleiter gestellten Aufgaben ist der Projektplan. In diesem wird weiterhin darauf eingegangen was getan wird, wann es getan wird, wie viel finanzielle Mittel benötigt werden, von wem die Aufgaben erledigt werden und wie sie erledigt, bzw. womit sie erledigt werden. [25]
Weiterhin werden besondere Fähigkeiten an den Projektleiter gestellt. Dazu gehört das Führen von Mitarbeitern, technisches Verständnis, Entscheidungskraft, Integrität und Weitsicht.

8.3.3 Das Projektteam

Weniger die organisatorischen sondern die technischen Fähigkeiten, die zu Lösung eines Problems nötig sind, stehen bei den Mitgliedern des Projektteams im Vordergrund.
Die einzelnen Mitglieder des Projektteams sind für die Tätigkeiten verantwortlich, die laut Projektplan als Aufgaben definiert wurden.
Die Organisation des Projektteams ist einerseits durch die Firmenkultur und andererseits durch die Persönlichkeit des Projektleiters geprägt.[26]
In einem anarchischen Team wird im Wesentlichen autonom nach eigenen Vorgaben und Maßstäben gearbeitet. Hierarchische Strukturen fehlen oder werden ignoriert. Vorteile sind die Selbstbestimmung der Teamteilnehmer, es gibt keine hierarchischen Probleme und kaum bürokratische Hemmnisse. Nachteile sind jedoch, dass sich Standards und Normen nicht durchsetzen lassen, erforderliche Resultate, wie z. B. die Erstellung von Dokumenten, fehlen, das Projektteam ist nicht lernfähig, Einführung neuer Methoden und Werkzeuge gestaltet sich schwierig. [26]
Ein demokratisches Projektteam arbeitet mit Vereinbarungen über Projektziele und –wege. Das Verhalten der Beteiligten Teammitglieder ist diszipliniert. Die Fähigkeiten aller Beteiligten werden so optimal genutzt, Probleme frühzeitig erkannt und gemeinsam gelöst. Der Nachteil dieser Form der Zusammenarbeit ist der hohe Kommunikationsaufwand und führt im schlimmsten Fall zur Beeinträchtigung der Arbeit, da Ziele nicht ausreichen, um Entscheidungen zu treffen oder Fraktionen entstehen. [26]
Bei einem hierarchischen Team stehen die Projektmitglieder unter der Leitung einer Person. Es liegt eine einfache und übersichtliche Kommunikationsstruktur vor und klare Zuständigkeiten. Nachteilig wirkt sich hier der lange Kommunikationsweg aus, oftmals eine schlechte Information der Projektmitglieder und dem Risiko, dass der Projektleiter seiner Aufgabe nicht gewachsen ist und die Projektmitglieder kaum zur Kooperation bereit sind.[27]

8.3.4 Unternehmenskultur und Kommunikationsstrategien

Wie im vorangegangenen Abschnitt erwähnt ist die Organisation eines Projektteams stark durch die Firmenkultur geprägt, das auch sein Verhalten während der Arbeit bestimmt. Somit werden auch die Qualität der Arbeitsleistung und damit die Qualität des Produkts direkt dadurch beeinflusst. Einzelleistungen die Auswirkungen auf die Qualität eines Produktes haben wirken sich nicht positiv auf den Entwicklungsprozess aus, wenn nicht parallel dazu eine Veränderung innerhalb der Unternehmenskultur stattfindet. [28]
Primär liegt die Verantwortung zur Verbesserung der Unternehmenskultur beim Unternehmer, bzw. der oberen Führungsebene. Sekundär wird sie aber durch die vorherrschenden politischen und wirtschaftlichen Verhältnisse geprägt. Weiterhin sind die Mitarbeiter und die mittlere und untere Führungsebene für die Entwicklung der Firmenkultur verantwortlich. [28]
Ein großer Faktor bei der Bewertung von Quellen für die mangelnde Qualität der Produkte nimmt die Kommunikation ein. Dabei handelt es sich um die Kommunikation mit den Anwendern, der Kommunikation innerhalb des Projektteams sowie der Kommunikation innerhalb der unterschiedlichen Hierarchiestufen. [29]
Kommunikation findet stets auf zwei Verhaltensebenen statt, der Beziehungsebene und der Fachebene. Erfolgreiche Kommunikation erfordert eine Balance zwischen beiden Ebenen. Schulungen und Selbsterfahrungskurse sind Möglichkeiten auf Kommunikationsschwächen hinzuweisen und eine positive Kommunikationsgestaltung zu erreichen.[30]

8.3.5 Ressourcenplanung

Die Ressourcenplanung muss die Arbeitszeiten der Mitarbeiter für bereits abgeschlossene Kundenaufträge hinsichtlich der Wartung und Erweiterung, für laufende Kundenaufträge hinsichtlich der Umsetzung und für zukünftige Kundenaufträge berücksichtigen. Schwerpunkt bei dieser Planung ist die tägliche Arbeitszeit des Mitarbeiters. Berücksichtigt werden muss der Ausfall der Mitarbeiter durch Krankheit, Urlaub und Schulungsmaßnahmen, der Aufwand und die Anzahl der durch Serviceleistungen zu betreuenden Kundenprojekte und die Prüfung von Kundenaufträgen hinsichtlich der Umsetzungsmöglichkeiten, bzw. Machbarkeitsuntersuchungen.

8.4 Softwaretests

Softwaretests bilden einen weiteren wichtigen Bestandteil der Qualitätssicherungsmaßnahmen in der Softwareentwicklung. Die Zielsetzung dieser Tests ist in erster Linie das Aufdecken von Fehlern. Nur wenn die Fehler bekannt sind, können diese korrigiert und damit die Qualität des Produktes ein Stück weit gesichert werden. Softwaretests beweisen jedoch nicht die Abwesenheit von Fehlern in einer Software. Ein erfolgreicher Test – ein Test ohne gefundene Fehler – ist demnach kein Beweis für ein korrektes Programm. Er zeigt lediglich auf, dass keine Fehler gefunden wurden.[31]

8.4.1 Umfang der Softwaretests

Abbildung 8: Optimaler Testumfang
Abbildung 8: Optimaler Testumfang [32]

Je nach Komplexität und Umfang einer Anwendung, erfordern Softwaretests einen erheblichen Aufwand. Dieser kann sich sowohl auf die Zeit als auch auf die Kosten des Projektes negativ auswirken. Werden die Tests jedoch nur in einem geringen Umfang oder gar nicht durchgeführt, bleiben mögliche Fehler unentdeckt und werden u.U. erst nach der Auslieferung des Produktes an den Kunden entdeckt.
Um dem entgegen zu wirken und dennoch den Aufwand an Zeit und Kosten für Softwaretests möglichst gering zu halten, ist es wichtig die Tests im angemessenen Umfang durchzuführen (Abbildung 8). Der Testumfang sollte für jedes Projekt individuell geplant werden, da dieser u.a. stark von Spezifikationen und Komplexität der Software, sowie den verfügbaren Ressourcen des Projektes abhängig ist.

8.4.2 Testzeitpunkt im Softwareentwicklungsprozess

Im Softwareentwicklungsprozess spielt der Zeitpunkt der Test eine sehr wichtige Rolle. Entgegen dem Vorgehen der SL GmbH, bei dem die Softwaretests erst in der Testphase nach Fertigstellung des Produktes erfolgen, ist es effizienter die Testphase bereits in der Planung der Anwendung zu beginnen. Denn je früher ein Fehler gefunden wird, desto geringer ist der Aufwand diesen zu beheben. So verursacht ein Fehler der bereits bei der Konzeption der Software gefunden wird, kaum Kosten. Wird dieser Fehler erst nach der Fertigstellung einzelner Softwaremodule entdeckt, kann die Korrektur im Code schon 10 € bis 100 € kosten. Wenn jedoch der Fehler erst vom Kunden bemerkt wird, kann die Korrektur des Fehlers in der Software schnell tausende oder gar millionen Euro nach sich ziehen.[33]

8.4.3 Testprozess

In den meisten Vorgehensmodellen ist der Testprozess konzeptionell verankert. Um diesen möglichst effizient, plan- und kontrollierbar zu gestalten, bedarf es dennoch weiterer Konzepte und Maßnahmen. So können die Tester unabhängig von den Entwicklern und Organisationsmaßnahmen bei der Planung sowie Kontrolle der Tests vorgehen.
Im Folgenden ist ein möglicher Ablauf des Testprozesses nach Pol et. al. 2000, als Phasenmodell beschreiben:

Planung und Steuerung: Die Phase Planung und Steuerung umfasst neben der Zeit- und Ressourcenplanung, die administrativen Tätigkeiten im Testprozess, die Festlegung der Teststrategie, der Testziele sowie die Erstellung des Testplans mit den einzelnen Testaufgaben (Kapitel 8.4.5). Die Steuerung soll während des Testprozesses sicherstellen, dass das Geplante eingehalten wird. Aus der Sicht des Qualitätsmanagements kann die Qualität des Testprozess an sich, ebenfalls bewertet werden. Wallmüller 2001 legt dafür drei Hauptmerkmale fest. Diese Merkmale Spezifikationsbezug, Reproduzierbarkeit, Nachvollziehbarkeit für Projekt-Außenstehende zeigen die Güte des Testens auf. Werden diese bei der Testplanung berücksichtigt, werden durch den Testprozess mit hoher Wahrscheinlichkeit Probleme und Fehler gefunden.[34]
Abbildung 9: Phasenmodell für den Testprozess
Abbildung 9: Phasenmodell für den Testprozess [35]
Vorbereitung: Die Phase der Vorbereitung beschäftigt sich mit der Analyse der Anforderungen und Festlegung der zu testenden Komponenten sowie der Auswahl der geeigneten Tests. Hier werden detailliert die Testmethoden festgelegt, wie die im Testplan festgelegten Ziele zu erreichen sind. Aufbau der Testumgebung bzw. Infrastruktur findet ebenfalls in dieser Phase statt, falls nicht bereits vorhanden.
Spezifikation: In der Phase Spezifikation werden konkrete Testfälle anhand der Testanforderungen spezifiziert. Es wird im Detail festgelegt, welches Testobjekt bei der Ausführung bestimmter Testfälle, mit welchem Input, welchen Output als Ergebnis liefern soll.[36]
Durchführung: Diese Phase beschreibt die Durchführung. Hier werden die geplanten Testläufe durchgeführt. Der Ablauf sowie jegliche Vorfälle und Probleme werden dokumentiert.[36] Für eine effiziente Koordination der Entwicklungs- und Testaktivitäten empfiehlt sich ein strukturierter Prozess der Fehlermeldung und Fehlerverfolgung. Dieser Prozess sollte durch Bug-Tracking-Tools wie z.B. Jira[37] oder Bugzilla[38] unterstützt werden.
Abschluss: Als Abschluss werden in dieser Phase die Testergebnisse analysiert und zusammengefasst. Hier wird geprüft ob die Testziele erreicht werden konnten und ob bestimmte Tests wiederholt werden sollten.

8.4.4 Testmethoden

Wie in Kapitel 8.4.2 beschrieben werden in der Testplanung Ziele festgelegt, die durch die Zusammenstellung geeigneter Testfällen zur Aufdeckung möglichst vieler Fehler führen sollen. Die Testfälle werden auf Basis von Testmethoden entworfen. Gegenwärtig werden die Testmethoden in zwei Gruppen unterschieden, die White-Box-Testmethoden und die Black-Box-Testmethoden.[39]

8.4.4.1 Black-Box-Testmethoden
Abbildung 10: Black-Box und White-Box-Test
Abbildung 10: Black-Box und White-Box-Test [40]

Bei den Black-Box-Testmethoden (funktionale Testmethoden) liegen dem Tester keine Informationen zu den Strukturen der Anwendung vor. Ihm liegt lediglich eine Leistungsbeschreibung vor (Abbildung 10). Damit ist bekannt welche Ergebnisse bei bestimmten Eingabewerten zu erwarten sind. Bei diesen Testmethoden sollte der Entwickler einer Anwendung nicht gleichzeitig auch der Tester dieser Anwendung sein. Ein vollständiger Test ist mit den Black-Box-Testmethoden praktisch unmöglich, da jede Kombination der zulässigen und unzulässigen Eingabewerte getestet werden müsste. Black-Box-Tests erfordern eine genaue Spezifikation des zu testenden Objektes. Die einzelnen Testfälle können damit auf Grundlage der beschriebenen Funktionalitäten der Anwendung erstellt werden.[39]

8.4.4.2 White-Box-Testmethoden

White-Box-Testmethoden (strukturelle Testmethoden), setzten die Kenntnis über die Struktur des zu testenden Programms voraus. Damit kann der Tester die Testfälle von der Struktur ableiten (Abbildung 10). Ein White-Box-Test ist erst dann vollständig, wenn alle Pfade in einem Modul der Anwendung von jedem Eingang bis zu jedem Ausgang durchlaufen werden. Eine vollständige Pfadabdeckung ist aufgrund der kombinatorischen Explosion nur sehr schwer zu realisieren. (Bsp.: Bei einer Schleife, die 20 Mal durchlaufen wird und zwei Verzweigungen beinhaltet, ergeben sich 320 mögliche Pfade).[41]

8.4.4.3 Gray-Box-Testmethoden

„Ein vollständiger Test basierend auf Black-Box-Methoden ist dem vollständigen Pfadtest (den White-Box-Methoden) überlegen.“[42] Da jedoch die Tests nach keiner der beiden Methoden vollständig durchführbar sind, werden die beiden Methoden ergänzend angewandt.[43] Diese Art des Testens wird auch Gray-Box-Methode genannt. Dabei werden die Testfälle nach der Black-Box-Methode erstellt und soweit wie nötig mit den White-Box-Methoden ergänzt.

8.4.5 Testaufgaben

Während des Entwicklungsprozesses fallen unterschiedliche Testaufgaben, je nach Fortschritt und Umfang des Projektes an. Die Testaufgaben (Testphasen) basieren auf den im Kapitel 8.4.4 beschriebenen Testmethoden. In Anlehnung an den Vorschlag der Testaufgaben der IEEE-Norm 1012-1986 („Software Verification and Validation Plans“), werden nach Wallmüller folgende Testaufgaben als Minimum festgelegt:

Modultests: Die Modultests (Komponenten- oder auch Unit-Tests) haben das Ziel Fehler in der Implementierung aufzudecken. Dabei werden die einzelnen Module separat betrachtet und getestet.[44]
Integrationstests: Bei Integrationstests (Subsystemtests) werden die einzelnen Module miteinander verknüpft und ihre Interaktion untereinander getestet. Ziel dabei ist es die Module als ein Subsystem zu testen. Man geht von bereits sehr gut getesteten Modulen aus. Der Fokus bei Integrationstests liegt vorrangig auf den Modulschnittstellen.[45]
Systemtests: Systemtests betrachten das Gesamtsystem als solches und werden durchgeführt um einerseits die funktionalen Leistungen und andererseits die Grenzen der Leistungsfähigkeit der Software zu prüfen.[46] “Bridges don't fall down because of bad steel, but because of bad architecture.”[47] Der Fokus liegt demnach auf dem Gesamtsystem, nicht auf den einzelnen Modulen.
Abnahmetests: Die Abnahmetests (Akzeptanztests) dienen dazu, die entwickelte Software dem Kunden vorzustellen und zu zeigen, dass diese die ursprünglich gestellten Anforderungen erfüllt. Zusammen mit dem Auftraggeber werden Testfälle erstellt, die die Erfüllung des Auftrages widerlegen sollen. Sind die Testfälle nicht erfolgreich, gilt die Software als abgenommen.[48]

8.4.6 Testautomatisierung

Mit dem Einsatz von Testautomatisierungssoftware kann der Testaufwand minimiert werden. Dabei werden die Tests durch Software übernommen. Dennoch müssen auch hier die Testszenarien geplant und Testskripte geschrieben werden. Nach Patton haben Testautomatisierungstools folgende Haupteigenschaften:

Geschwindigkeit: Ein automatisierter Test kann viel mehr Testfälle abarbeiten als ein menschlicher Tester.
Effizienz: Durch den Einsatz von Testautomatisierungstools kann die Zeit effizienter genutzt werden. Der Tester kann diese Zeit z.B. zur Planung weiterer Tests nutzen.
Genauigkeit: Nach einigen hundert Testfällen lässt die Aufmerksamkeit eines menschlichen Testers nach. Durch die Testautomatisierung bleibt die Genauigkeit konstant erhalten.
Simulation und Emulation: Schnittstellen, sowie von Hard- bzw. Software kann durch die Testtools simuliert werden.
Reduzierung der Ressourcen: Durch den Einsatz von Testtools können neben der Zeit, auch physische Ressourcen, wie z.B. Hardware, durch Simulation eingespart werden.
Beständigkeit: Testautomatisierungswerkzeuge werden weder müde noch geben diese nach.

Demnach erfolgen die Tests durch den Einsatz von Testautomatisierungswerkzeuge u.a. effizienter, benötigen weniger Ressourcen, sind schneller und ausdauernder. Die Automatisierung stellt zudem eine gleichbleibende Qualität der Tests sicher, da die Fehler der menschlichen Tester auf ein Minimum reduziert werden. Dennoch sollte an dieser Stelle erwähnt werden, dass Testautomatisierungswerkzeuge trotzdem nur Werkzeuge sind und je nach Einsatz durch den Tester ihre Vorteile hervorbringen können.[49]

Gängige Werkzeuge für automatisierte Softwaretests sind u.a. Cactus, JMeter und JUnit für Java-Projekte, sowie QF-Test, TestComplete und Selenium für Web-Projekte.

9 Evaluation des Entwicklungsprozesses hinsichtlich der Qualitätssicherungsmaßnahmen

9.1 Vorgehensmodelle

Aus der Nutzwertanalyse ist hervorgegangen, dass das Vorgehensmodell SCRUM für die SL GmbH die gestellten Anforderungen an ein Modell am besten abdeckt. Bezogen auf den aktuellen Entwicklungsprozess bleibt die Hauptproblematik die Kommunikation und Realisierung der Software.

Die bisherige Selbstständigkeit der Entwickler soll auch beim Vorgehensmodell SCRUM gewährleistet sein, um den Selbstlernprozess zu erhöhen. Zusätzlich wird aber durch eine regelmäßige Kommunikation durch die DS gewährleistet, dass Probleme frühzeitig erkannt werden und vor allem Inhalte zu einzelnen Modulen ausgetauscht werden. Dies hat zur Folge, dass während der Abwesenheit eines Mitarbeiters auch ein Kollege anfallende Wartungen durchführen kann.

Durch die wachsende Erfahrung beim SCRUM, die durch die jeweiligen Sprints gewonnen wird, ist es im Laufe des Projektes besser möglich, Dauer und Aufwand der einzelnen Anforderungen besser einzuschätzen und diese in einem Sprint auch zu erreichen. Dabei wird vor allem ein lauffähiges Produkt bereitgestellt, was auch in einem eingeplanten Umfang getestet wurde.

Wichtig für die erfolgreiche Umsetzung ist die Einhaltung der Grundsätze für die agile Softwareentwicklung und die Durchführung der täglichen Meetings und Reviews am Ende eines Sprints.

Das Vorgehensmodell birgt aber auch Gefahren im Bereich des selbstständigen Arbeitens und Planen. Dies kann dazu führen, dass die Mitarbeiter immer wieder Aufgaben im gleichen Themengebiet aufgetragen bekommen, da diese bereits vertiefte Kenntnisse haben. Somit besteht die Möglichkeit, dass wie auch im aktuellen Prozess nur der bearbeitende Mitarbeiter die Kenntnisse über ein Modul kennt.

9.2 Dokumentation

Wie unter Kapitel 8.2 beschrieben, sind Maßnahmen seitens des Managements sowie auch ein Umdenken bei den Mitarbeitern nötig. Gezielte Schulungen und Kommunikation, um auch bei den Mitarbeitern ein Verständnis für die "Mehrarbeit" des Dokumentierens zu schaffen, sind erste Schritte auf dem Weg der Qualitätsverbesserung und -sicherung. Auch hier können die DS helfen, Probleme frühzeitig zu erkennen sowie einen Erfahrungsaustausch/Hilfestellung unter den Kollegen zu gewährleisten. Des Weiteren sind den Mitarbeitern die Zeit und die Werkzeuge zum Dokumentieren zur Verfügung zu stellen bzw. dieser Aufwand bereits bei der Planung der Projekte zu berücksichtigen.
Als Software-Dokumentationswerkzeug könnte Doxygen von Dimitri van Heesch eingesetzt werden, da es auf jedem Betriebssystem einsetzbar ist und auch Kommentare mehrerer Programmiersprachen, z.B. C++, C, Java, Python und Fortran, auswerten kann.

9.3 Organisatorische Maßnahmen

Innerhalb der organisatorischen und personellen Strukturierung der SL GmbH müssen Veränderungen stattfinden, damit eine nachhaltige Verbesserung der Softwarequalität erreicht werden kann, bzw. dauerhaft bestehen bleibt.

9.3.1 Projektleiter

Die Aufgaben des Projektleiters sind klar definiert. In SCRUM wird ihm die Rolle des SCRUM-Masters zugeteilt. Die Person, die diese Aufgabe übernimmt, sollte die entsprechenden fachlichen und sozialen Kompetenzen mitbringen, um diese Aufgabe auszufüllen. Genaue Kenntnis des Vorgehensmodells und wie es funktioniert, ist hier eine entscheidende Voraussetzung. Wichtig ist die Fähigkeit der Leitung von Mitarbeiten, dem Team, die Kommunikation mit dem Product Owner und Kreativität.

Ein „angehender“ SCRUM-Masters muss nicht alle sozialen Anforderungen zwingend erfüllen. Defizite lassen sich trainieren. Wichtig ist jedoch herauszufinden, wo die sozialen und fachlichen Stärken und Schwächen des Mitarbeiters liegen. Unter anderem lässt sich dieses in Mitarbeitergesprächen feststellen, die in regelmäßigen Zeitabständen durchgeführt werden.

9.3.2 Team

Anhand der unterschiedlichen Arten von Teams, wie sie in Kapitel 8.3.3 beschrieben wurden, kann man die derzeitige Situation der Teams bzw. die Arbeitsweise der Mitarbeiter am besten als anarchisches Team beschreiben. Größtenteils findet eine derzeitige Selbstbestimmung der Teamteilnehmer statt. Laut Kapitel 7.4 war das Fazit der Analyse des Entwicklungsprozesses die fehlende Kontrolle über die Anfertigung von Dokumentationen, der Quellcodegestaltung, etc. Im Großen und Ganzen ist das Ziel des Entwicklungsprozesses ein fertiges Produkt ohne zu hinterfragen, wie es entstanden ist und was unter der Oberfläche des Produktes steckt.

Die Teambildung sollte dementsprechend demokratisch oder hierarchisch ausfallen. Da sich das demokratische Team in Forschungsgruppen und kleinen Softwarehäusern bewährt hat[50] sollte diese Art der Zusammenarbeit in einem Team gewählt werden, da die Fähigkeiten der einzelnen Teammitglieder so optimal genutzt werden, Probleme frühzeitig erkannt und gemeinsam gelöst werden. In SCRUM ist der demokratische Umgang miteinander Bestandteil der erfolgreichen Umsetzung von Kundenaufträgen.

9.3.3 Projektplanung/Ressourcenplanung

Bei der Planung der Mitarbeiter für Tätigkeiten innerhalb eines Kundenprojektes muss eine genaue Analyse des Aufwands für sonstige Tätigkeiten, die neben der Projekttätigkeit anfallen, erstellt werden. Unter anderem handelt es sich dabei um die Serviceleistungen für die Wartung und Betreuung abgeschlossener Projekte.

Während der Arbeit in einem Projekt sollten die Tätigkeiten für projektfremde Aufgaben wegfallen, da dort der Aufwand meist nicht abschätzbar ist.

Die Serviceleistungen, die aufgrund von Service Level Agreements (SLA) mit Kunden vertraglich festgehalten sind, sollten in einem eigenen Mitarbeiterteam bearbeitet werden, die sich ausschließlich mit der Betreuung und Wartung von Kundensystemen beschäftigen. Je nach Umfang dieser Tätigkeiten wäre eine strikte Trennung in Projekttätigkeiten und Servicetätigkeiten denkbar, ebenso auch in der Darstellung der Unternehmensorganisation. Folge wäre einerseits ein hoher Kommunikationsaufwand, der aber andererseits mit der Verantwortung an die Entwicklerteams einhergeht, qualitativ hochwertige Software an das Serviceteam zu übergeben. Somit wäre eine schnelle Einarbeitung möglich, um den Kunden nach Abschluss der Softwareentwicklung eine sofortige umfassende Betreuung zukommen zu lassen.

Bezüglich der Auslastung der Mitarbeiter sollte eine Planung zu 100% der Arbeitszeit vermieden werden. Folge sind meistens Verzögerungen, die sich durch nicht vorherzusehende Umsetzungsschwierigkeiten, Ausfall durch Urlaub oder Krankheitsfälle ergeben können. Eine gewisse Pufferzeit sollte in der Planung der einzelnen Teilaufgaben, die innerhalb des Projektes anfallen, eingeplant werden. Bewährt hat sich bei SCRUM eine Auslastung der Teammitglieder mit 7 Stunden/Tag bei einem 8 Stunden umfassenden Arbeitstag.

9.3.4 Unternehmenskultur/Kommunikation

Wie in Kapitel 8.3.4 beschrieben, findet eine sehr starke Prägung der Arbeit eines Mitarbeiters/ Projektteams durch die gelebte und erlebte Unternehmenskultur statt. In erster Linie ist die Unternehmensleitung für Veränderungen hinsichtlich der Unternehmenskultur zuständig.

Eine Unternehmenskultur definiert sich durch Werte, Unternehmensethik, Normen und Denkhaltungen und zeigt sich in der Zusammenarbeit und Kommunikation der Mitarbeiter nach innen und außen.[51]

Wichtig ist, dass die Mitarbeiter sich mit der Unternehmenskultur identifizieren können, um eine positive Grundlage für die Arbeit in dem Unternehmen zu schaffen. Das heißt, dass schon bei der Auswahl von neuen Mitarbeitern darauf geachtet wird, dass die entsprechende Person sich gut einfügt in das Ensemble von bisherigen Mitarbeitern und Unternehmenskultur.

Die Kommunikation untereinander, als auch mit dem Kunden ist einer der größten Faktoren für die mangelnde Qualität der Produkte. Eine Veränderung des Kommunikationsverhaltens lässt sich nur durch Analyse der Kommunikationsschwächen allein oder in der Gruppe feststellen. Schulungen und Selbsterfahrungskurse helfen bei der Verbesserung der Kommunikation.

9.4 Softwaretests

Die Softwarequalität kann in dem Entwicklungsprozess der SL GmbH erheblich verbessert werden, wenn die Softwaretest strukturiert nach den im Kapitel 8.4 beschriebenen Konzepten erfolgen. Die Grundlage für die Sicherstellung der Qualität durch Tests, bilden dabei die dokumentierten Spezifikationen des zu entwickelnden Produkts. Da besonders die Funktionstests sich an den festgelegten Anforderungen orientieren.
Softwaretest müssen eine feste Größe im Entwicklungsprozess der SL GmbH bilden, um bessere Qualität der Produkte erreichen zu können. So sollte der im Kapitel 8.4.3 beschriebene Testprozess in den einzelnen Sprints berücksichtigt und nach dem beschriebenen Ablauf erfolgen. Dabei ist es wichtig, genügend Ressourcen nur für die Tests einzuplanen, um diese erfolgreich durchführen zu können.
Um die Qualität von Software durch Tests in einem angemessenen Umfang, angemessener Zeit und zu angemessenen Kosten sichern zu können, muss ein optimaler Testumfang anhand der Anforderungen und Rahmenbedingungen festgelegt werden. An dieser Stelle sollten die Tester in Rücksprache mit dem Projektverantwortlichen (Product Owner) den angemessenen Testumfang festlegen und bei der Planung der Sprints im Rahmen des SCRUM berücksichtigen. Durch den Einsatz von Testautomatisierungstools (siehe Tabelle) kann der Testaufwand reduziert und menschliche Fehler minimiert bzw. vermieden werden. Besonders Funktions- und Regressionstests können damit genauer und in kürzerer Zeit durchgeführt werden.
Zurzeit erfolgen die wenigen Tests durch die Entwickler selbst. Das sollte in Zukunft geändert werden, da die Durchführung der überwiegenden Tests die Black-Box-Methode voraussetzt, wie im Kapitel 8.4.4 beschrieben. Langfristig ist zu überlegen, Testspezialisten mit langjähriger Erfahrung einzustellen. Bis dahin sollten die Testaufgaben im SCRUM-Team verteilt werden.

9.5 Zusammenfassung

Abbildung 11: Softwareentwicklungsprozess (SOLL)
Abbildung 11: Softwareentwicklungsprozess (SOLL)[52]

Aus dem vorangegangenen Kapiteln 9.1 - 9.4 ist deutlich geworden, dass die stattfindenden Veränderungen hauptsächlich in der Kommunikation, der Dokumentation der Anwendungen, fachliche und soziale Kompetenzen und die optimale Nutzung der Fähigkeiten der einzelnen Mitarbeiter stattfinden müssen. Aufspaltung des Softwareentwicklungsbereiches in ein Entwicklerteam und ein Serviceteam erscheint ebenfalls sinnvoll, da mit jedem neuen Auftrag auch die Serviceleistungen wachsen. Die erforderlichen Änderungen lassen sich somit in 4 Schritte zusammenfassen:

  • Die Implementierung des Vorgehensmodells
  • Verbesserung der Dokumentation des Entwicklungsprozesses
  • Implementierung von Softwaretests als feste Größe im Entwicklungsprozess
  • Umstrukturierung des Bereiches Softwareentwicklung in Projektteam und Serviceteam zur Verbesserung der Serviceleistungen

Diese Änderungen kurzfristig zu realisieren ist nicht möglich. Eine schrittweise Umstellung der Maßnahmen ist hier zu bevorzugen.

Die Umsetzung des Vorgehensmodells SCRUM beinhaltet bereits eine Verbesserung der Kommunikation der Mitarbeiter untereinander, legt Wert auf ihre einzelnen Fähigkeiten, bezieht den Auftraggeber in die Entwicklung mit ein und verbessert die Ressourcenplanung, womit der erste Schritt der Veränderungen im Entwicklungsprozess feststeht. Eine schrittweise Einführung ist hier nicht möglich, da Vorgehensmodelle nur dann erfolgreich sind, wenn sie in ihrer Gesamtheit umgesetzt werden. Die Ausbildung eines SCRUM-Masters ist hier Voraussetzung, da es eine Person geben muss, die sich mit dem Vorgehensmodell genauestens auskennt und weiß, wie es funktioniert. Eine anfängliche Betreuung durch einen Berater ist zu empfehlen.

Aufbauend auf den Burn-Down-Charts des Vorgehensmodells lässt sich ebenfalls eine Verbesserung der Dokumentation erreichen. Anforderungen eines modernen Berichtswesens sind hiermit erfüllt und es sind alle Teammitglieder in der Erstellung eingebunden. Mithilfe dieser Berichte ist ein genauer Verlauf des bisherigen Fortschritts zu erkennen und die Teammitglieder sind jederzeit über den aktuellen Stand der Entwicklung informiert. Mit dem Einsatz von Dokumantationswerkzeugen wie Doxygen und z.B. Jira, wird die Dokumentation unterstützt und damit auch die Nachvollziehbarkeit in und nach der Entwicklung unterstützt.

Im Anschluss an die Implementierung von SCRUM lässt sich mithilfe der Burn-Down-Charts eine Dokumentation über den gesamten Entwicklungsverlauf erstellen. Eine Erstellung der technischen Dokumentation über den Aufbau der erstellten Software wird somit erheblich erleichtert. Durch die Beschreibung der einzelnen User-Stories wird die Erstellung einer Benutzerdokumentation ebenfalls in kurzer Zeit möglich.

Die Aufspaltung des Entwicklungsbereiches in Projektteam und Serviceteam sollte dann umgesetzt werden, wenn die Voraussetzungen für eine qualitativ hochwertige Software geschaffen sind. Die Anforderung an eine ausführliche technische Dokumentation, die Beschreibung der Prozesse die innerhalb des Quellcodes stattfinden, bildet hier die Grundlage für eine schnelle und effiziente Kundenbetreuung.

Folgende Darstellung ergibt sich nun für den Softwareentwicklungsprozesses (Soll) für die SL GmbH. Das Testen von Software, bzw. der einzelnen Sprints ist zu einem zentralen Bestandteil geworden.

10 Fazit und kritische Würdigung

„Es ist zwar nicht gesagt, dass es besser wird, wenn es anders wird; wenn es aber besser werden soll, muss es anders werden.“[53]

Veränderungen dürfen nicht beschlossen, sondern müssen gestaltet werden. Die umfassende Information aller Beteiligten ist eine Voraussetzung für einen erfolgreichen Wechsel der Strategie nicht nur im Prozess der Softwareentwicklung. Dazu zählt auch, dass Mitarbeiter aktiv an der Umgestaltung beteiligt sind und eigene Ideen und Vorschläge mit einbringen können. Um alle Beteiligten von dem Nutzen der Veränderungen zu überzeugen müssen die Initiatoren glaubwürdig die Maßnahmen vertreten und die Neuerungen nicht durch „Überzeugungsarbeit“, sondern durch nachvollziehbare Argumentation näherbringen.

Eines der obersten Ziele ist die nachhaltige Verbesserung des Softwareentwicklungsprozesses in der SL GmbH. Daher reicht es nicht aus die vorgestellten Maßnahmen nur umzusetzen, sondern auch aktiv an der Einhaltung und weiteren Ausgestaltung der gestellten Vorgaben zu arbeiten. Zukünftige Zertifizierungen zeigen auch dem Kunden in welcher Qualität die Produkte hergestellt und Unternehmensprozesse gestaltet werden.

11 Fußnoten

  1. ↑ Reite (2001)
  2. ↑ 2,0 2,1 Vgl. Reite (2001)
  3. ↑ ISO 9000:2008
  4. ↑ IEC 2371
  5. ↑ http://winfwiki.wi-fom.de/index.php/Bild:Softwareentwicklungsprozess.jpg, Stand 22.02.2010
  6. ↑ Vgl. http://winfwiki.wi-fom.de/index.php/Überblick_Vorgehensmodelle_im_Projektmanagement#Wertermittlung, Stand 22.02.2010
  7. ↑ Maciej Jaros, http://commons.wikimedia.org/wiki/File:Wasserfallmodell.svg, Stand 04.09.2006
  8. ↑ http://winfwiki.wi-fom.de/index.php/Überblick_Vorgehensmodelle_im_Projektmanagement, Stand 22.02.2010
  9. ↑ Vgl. http://www.projektmanagementhandbuch.de/cms/wp-content/uploads/2008/09/v-modell.jpg, Stand 22.02.2010
  10. ↑ Michael Hüttermann, http://de.wikipedia.org/w/index.php?title=Datei:XP-Life.png&filetimestamp=20060616063618, Stand 16.06.2006
  11. ↑ 11,0 11,1 Vgl. Woywood (2009) S. 43
  12. ↑ Vgl. Beck (2003) S. 29
  13. ↑ 13,0 13,1 Vgl. Beck (2003) S. 37
  14. ↑ 14,0 14,1 Vgl. Beck (2003) S. 38
  15. ↑ Vgl. Woywood (2009) S. 45
  16. ↑ Darrel Norton, http://headsurge.wordpress.com/2009/04/22/lecture-10-development-processes/, Stand 22.02.2010
  17. ↑ Pablo Straub, http://en.wikipedia.org/wiki/File:SampleBurndownChart.png, Stand 26.06.2009
  18. ↑ Vgl. Wirdemann (2009) S.26
  19. ↑ 19,0 19,1 19,2 Vgl. Woywood (2009) S.49
  20. ↑ Vgl. http://de.wikipedia.org/wiki/Scrum#Sprint_Backlog, Stand 22.02.2010
  21. ↑ Vgl. Woywood (2009) S.50f
  22. ↑ Vgl. Wirdemann (2009) S.31
  23. ↑ 23,0 23,1 Vgl. Frühauf et al. (2002) S. 28
  24. ↑ Vgl. Frühauf et al. (2002) S. 31 f.
  25. ↑ Vgl. Frühauf et al.(2002) S. 32 f.
  26. ↑ 26,0 26,1 26,2 Vgl. Frühauf et al. (2002) S. 43
  27. ↑ Vgl. Frühauf et al. (2002) S. 44
  28. ↑ 28,0 28,1 Vgl. Wallmüller (2001) S. 190
  29. ↑ Vgl. Wallmüller (2001) S. 192
  30. ↑ Vgl. Wallmüller (2001) S. 193
  31. ↑ Vgl. Patton (2006) S. 41
  32. ↑ Vgl. Patton (2006) S. 40
  33. ↑ Vgl. Patton (2006) S. 18
  34. ↑ Vgl. Wallmüller (2001) S. 242 f
  35. ↑ Vgl. Pol et al. 2000
  36. ↑ 36,0 36,1 Vgl. Wallmüller (2001) S. 227
  37. ↑ http://www.pixsoftware.de/JIRA/10-gruende-fuer-jira.html, Stand 22.02.2010
  38. ↑ http://www.mozilla-europe.org/de/products/bugzilla, Stand 22.02.2010
  39. ↑ 39,0 39,1 Vgl. Wallmüller (2001) S. 228
  40. ↑ Vgl. Wallmüller (2001) S. 228
  41. ↑ Vgl. Wallmüller (2001) S. 229
  42. ↑ Wallmüller (2001) S. 229
  43. ↑ Vgl. Wallmüller (2001) S. 230
  44. ↑ Vgl. Wallmüller (2001) S. 248 f
  45. ↑ Vgl. Wallmüller (2001) S. 250 f
  46. ↑ Vgl. Wallmüller (2001) S. 251
  47. ↑ Beizer 1984
  48. ↑ Vgl. Wallmüller S. 253 f
  49. ↑ Vgl. Patton (2006) S. 232
  50. ↑ Vgl. Frühauf et al. (2002) S. 43
  51. ↑ Vgl. http://www.arbeitsratgeber.com/unternehmenskultur_0198.html, Stand 22.02.2010
  52. ↑ http://winfwiki.wi-fom.de/index.php/Bild:Softwareentwicklungsprozess_Soll.jpg
  53. ↑ Gattermeyer et al. (2001) S. 13

12 Literatur- und Quellenverzeichnis

Beck (2003): Beck, Kent: Extreme Programming, Addison-Wesley, München 2003
Beizer (1984): Beizer, Boris: System Testing and Quality Assurance, van Nostrand 1984
Frühauf et al. (2002): Frühauf, Karol; Ludwig, Jochen; Sandmayr, Helmut: Software- Projektmanagement und -Qualitätssicherung, 4. Auflage, vdf Hochschulverlag AG an der ETH Zürich, Zürich 2002
Gattermeyer et al. (2001): Gattermeyer, Wolfgang; Ayad, Al-Ani: Change Management und Unternehmenserfolg, 2. Auflage, Betriebswirtschaftlicher Verlag Dr. Th. Gabler, Wiesbaden 2001
Patton (2005): Patton, Ron: Software Testing, 2nd Edition, Sams, Indiana 2005
Pol et al. (2000): Pol, Martin; Koomen, Tim; Spillner, Andreas: Management und Optimierung des Testprozesses: ein praktischer Leitfaden für Testen von Software, mit TPI und TMap, Dpunkt Verlag, 2000
Reite (2001): Reite, Michael: Für Softwareentwickler ist Qualität ein Fremdwort, Computer Zeitung Nr. 3 / 18. Januar 2001, Abgerufen am 20.09.2009 von http://www.computer-zeitung.de
Wallmüller (2001): Wallmüller, Ernst: Software-Qualitätsmanagement in der Praxis, 2. Auflage, Carl Hanser Verlag München, Wien 2001
Woywood (2009): Woywood, Rebecca: Extreme Programming goes offshore, 1. Auflage, GRIN Verlag, Nordstedt 2008
Wirdemann (2009): Wirdemann, Ralf: SCRUM mit User Stories, Carl Hanser Verlag München, Hamburg 2009
Von „http://winfwiki.wi-fom.de/index.php/Qualit%C3%A4tssicherung_im_Softwareentwicklungsprozess_der_Software_Life_GmbH“
Persönliche Werkzeuge