ein praktischer Ansatz zur Aufwandsminimierung im Prozessumfeld

Größe: px

Ab Seite anzeigen:

Download "ein praktischer Ansatz zur Aufwandsminimierung im Prozessumfeld"

Hedwig Linden
vor 8 Jahren
Abrufe

Nicht nur der Problemlösungsvorgang an sich, auch die Herangehensweise und die Dokumentation der einzelnen Schritte bis hin zum qualitativ

1 Systemen Aufwandsminimierung im Prozessumfeld 1. Softwarelebenszyklus-Prozesse Normen und Prozesse stellen die Entwicklung von komplexer Software vor immer größere Herausforderungen. Nicht nur der Problemlösungsvorgang an sich, auch die Herangehensweise und die Dokumentation der einzelnen Schritte bis hin zum qualitativ hochwertigen Endprodukt bedürfen eines erheblichen Arbeitsaufwands. Der Vorgang der Softwareentwicklung sieht im Rahmen des Qualitätsmanagements weitere Aktivitäten vor, die den Entwicklungsprozess und den Wartungsprozess begleiten (s. Abbildung 1). Abbildung 1 - Prozesse Seite 1/6

2 Systemen Parallel zum Entwicklungs- und Wartungsprozess wird verlangt Risikomanagement, Änderungsmanagement, Konfigurationsmanagement, Issutracking und damit verbunden einen Problemlösungsprozess durchzuführen. Genauso muss Software getestet werden und die jeweiligen Ergebnisse der einzelnen Prozesse durch zu definierende Maßnahmen sowohl in den Entwicklungsprozess, als auch in den Wartungsprozess einfliessen. 2. Die Herausforderungen Aus diesen Forderungen erwächst ein immenser Aufwand für die Erstellung der notwendigen Artefakte. Zudem wird ein ebenso hohes Maß an Struktur und Übersicht gefordert. Der (Arbeits-) Zeitaufwand wächst für alle Aktivitäten proportional zum Komplexitätsgrad der Software. Die notwendige Arbeitskraft muss in jedem Fall zur Verfügung gestellt werden, allerdings ist es möglich auf lange Sicht viel Arbeitsaufwand zu sparen. 3. Ansätze zur Aufwandsminimierung 3.1 Aufwandsreduktion im Entwicklungsprozess a) Tools zur Unterstützung der Software-Prozesse Dokumentation, Änderungen und Rückverfolgbarkeit lassen sich ohne den Einsatz von Software-Werkzeugen auf Dauer nicht übersichtlich realisieren. Der Einsatz eines transparenten Dokumentationssystems (Wiki, Sharepoint/MSProject, Doors) zur Unterstützung der Planungsphasen, der Anforderungsanalyse und der Designphasen, genauso wie der Einsatz einer Versionsverwaltung (SVN, CVS, Synergy, Perforce, usw.) zur Unterstützung der Implementierungs-, Integrations-, Prüfungs- und Freigabephase (Baseline) sind unabdingbar und stellen eine Minimalforderung für effiziente Arbeitsprozesse dar. b) Aufwandsersparnis durch eine fundierte Basis Aus Erfahrungen des Autors werden die folgenschwersten Fehler während der Anforderungsanalyse gemacht: 1. Nicht alle Stakeholder werden miteinbezogen 2. Requirements sind nicht ausreichend Strukturiert 3. Requirements werden aufgrund von Zeitdruck zu oberflächlich erstellt, ein möglicher Lernerfolg bei den Beteiligten wird nicht berücksichtigt 4. Requirements sind unverständlich beschrieben 5. Designphase wird vor der Anforderungsanalyse begonnen Seite 2/6

Genauso muss Software getestet werden und die jeweiligen Ergebnisse der einzelnen Prozesse durch zu definierende Maßnahmen sowohl in den Entwicklungsprozess, als auch in den Wartungsprozess

3 Systemen Durch solche Lücken im Requirementsengineering entstehen große Verständnisprobleme, mitunter bauen die Beteiligten ihr eigenes (falsches) Verständnis auf, was zu Fehlinformationen führt. Zudem entsteht eine immense Last auf dem Changemanagement. Um effektiv Requirements zu generieren, sollten viele Reviewzyklen von möglichst allen Stakeholdern durchgeführt werden. Je größer der Kreis der Reviewer gewählt ist, desto höher ist die Wahrscheinlichkeit, spätere Änderungen im Vorfeld zu vermeiden (Mehr-Augen-Prinzip). Zudem baut sich so bei allen Projektbeteiligten ein gemeinsames und auch gegenseitiges Verständnis auf. Der Vorteil, der daraus entsteht, ist, dass in den anschließenden Entwicklungsprozessen (s. Abbildung 1) weniger Änderungen folgen und daraus ein deutlich geringerer Aufwand im Changemanagement resultiert. c) Aufwandsersparnis durch eine Dokumentationsstrategie Dass Änderungen im Entwicklungsprozess und die daraus resultierende Dokumentenpflege unvermeidbar sind, ist für jeden Projektmanager / Projektleiter ein bekanntes Phänomen. Aus diesem Wissen heraus sollte die Dokumentenstruktur so angelegt werden, dass einerseits die Übersicht gewährleistet ist und andererseits Änderungen mit möglichst minimalen Zeitaufwand nachgepflegt werden können. Um dies zu erreichen, hat es sich bewährt, anstelle von großen umfassenden und damit auch unübersichtlichen Dokumenten, in drei Kategorien zu teilen: 1. Dokumente, die die Breite der Applikation beschreiben 2. Viele kleine Dokumente, die die Softwareeinheiten beschreiben 3. Dokumente, die die Schnittstellen beschreiben Die positiven Effekte sind: 1. Bessere Übersicht 2. Für eine Änderung muss meist nur 1 Dokument geändert werden 3. Die Änderungen sind schneller erfassbar 4. Die Zuordnung zur Zielgruppe des Dokuments fällt leichter 5. Revisionierung der Softwareeinheiten wird möglich 6. Änderungsfrequenz der Softwaremodule ist direkt ablesbar 3.2 Lösungsansätze im Design- / Implementierunsgprozess Voraussetzungen: Als Grundlage für die folgende Betrachtung dient ein eingebettetes verteiltes System, dessen Applikationen hardwarenah implementiert sind. Seite 3/6

Je größer der Kreis der Reviewer gewählt ist, desto höher ist die Wahrscheinlichkeit, spätere Änderungen im Vorfeld zu vermeiden (Mehr-Augen-Prinzip).

4 Systemen Bisherige Beobachtungen: 1. verschiedene Designstrategien in einer Applikation jeweils zum Teil umgesetzt 2. (fast) komplette Neuerfindung einer Applikation bei einer Weiterentwicklung 3. Schnittstellen mit aktuellem Usecase zu 100% ausgelastet 4. mehrere Funktionen erfüllen die gleiche Funktionalität 5. mangelnde Abstraktionsmaßnahmen / mangelnde Kapselung von Modulen 6. prototypische Implementierungen bleiben im Release erhalten 7. Inkonsistente- oder Mehrfachdatenhaltung 8. Ablaufsteuerung durch globale Variablen 9. Mängel in der Prozess- und Resourcensynchronisation 10. unvollständige Protokolle zur Datenübertragung 11. keine festgelegte Debuggingstrategie Durch derartige Design- und Implementierungsfehler können selbst kleinere Bugfixes bzw. Changerequests Dominoeffekte mit unvorhersehbarem Aufwand nach sich ziehen. Die Lösung für die Vermeidung vieler dieser Fehler ist der Einsatz eines auf die Produktlinie abgestimmten Frameworks. Ein embedded Framework sollte eine Basisfunktionalität gewährleisten, die für spätere Weiter- und Neuentwicklungen hinreichend ist. Die Software auf eingebetteten verteilten Systemen verfügt in ihrer Struktur über Basisanforderungen, die so abstrakt implementiert werden können, dass sie für viele Anwendungen und verschiedene Plattformen wieder verwendbar sind. Die Konsequenz daraus ist, dass der Aufwand für Tests und die zu erstellenden Artefakte nur einmal betrieben werden muss, und in neuen oder weiterführenden Projekten auf diese verwiesen werden kann. Darüber hinaus kann auf Basis eines solchen Embedded Framework vorausgesetzt, dass die Schnittstellen zwischen Applikation und Framework ausreichend abstrakt definiert sind sehr viel schneller implementiert werden. Zusätzlich stellen abstrakte Schnittstellen eine große Vereinfachung für die Erzeugung von automatisierten Tests dar, die mit hoher Wahrscheinlichkeit in anderen Projekten erneut Verwendung finden. Beispielkonzept Embedded Framework : Aus der Sicht des Autors benötigt jede eingebettete Applikation fünf grundlegende Bausteine als Zentrum, um das weitere Softwaremodule im Sinne der Hauptapplikation angeordnet werden (s. Abbildung 2: Prinzip "Embedded Framework"): Seite 4/6

prototypische Implementierungen bleiben im Release erhalten 7. Inkonsistente- oder Mehrfachdatenhaltung 8. Ablaufsteuerung durch globale Variablen 9.

5 Systemen 1. Einen Zeitdienst (Timer) 2. Einen Nachrichtendienst zum Daten-/Ereignistransport 3. Einen IO-Handler 4. Einen Debugger 5. Einen Satz von Basisfunktionen (BaseUtils) Jeder dieser Bausteine kann zumindest teilweise so abstrakt implementiert werden, dass die resultierenden Module problemfrei auf andere Plattformen portierbar sind und in verschiedensten Anwendungen wiederverwendet werden können. Ein gutes Beispiel hierfür ist der Softwaretimer. Selbstverständlich muss dieser Softwaretimer durch die zur Verfügung stehende Zeitbasis der Zielplattform bedient werden. Abstrakt können aber Mechanismen geschaffen werden, die es erlauben, einen oder mehrere Timer zu setzen, die bei Ablauf via Callback oder mittels des Nachrichtendienstes dieses Ereignis mitteilen. Abbildung 2: Prinzip "Embedded Framework" Der Nachrichtendienst kann beispielsweise aus drei Komponenten bestehen: 1. einer oder mehrerern Warteschlangen für Nachrichten/Ereignisse 2. einem Dispatcher für die Verteilung der Nachrichten/Ereignisse 3. einer Funktion aus den Baseutils zur Nachrichtengenerierung Seite 5/6

portierbar sind und in verschiedensten Anwendungen wiederverwendet werden können. Ein gutes Beispiel hierfür ist der Softwaretimer.

6 Systemen Die Warteschlange(n) und das enthaltene Protokoll sind vollständig applikationsunabhängig realisierbar, während der Dispatcher mindestens aus einem allgemeinen Teil und einem Konfigurationsteil besteht, in dem erlaubte Sender und Empfänger festgelegt werden. Effekt: Mit diesem Verfahren wird einer Applikation im Idealfall ein dokumentierter und verifizierter Basissatz an Funktionalitäten zur Verfügung gestellt, 1. der es allein durch die Definition einer konkreten Hardwareschnittstelle ermöglicht, mit weiteren Teilnehmern in einem verteilten System zu kommunizieren. 2. der es gewährleistet, innerhalb einer Applikation durch Verwendung des gleichen Mechanismus Daten und Ereignisse zwischen Softwaremodulen auszutauschen. 3. der es jedem neuen Modul gestattet, direkt auf Zeit und Nachrichtendienste zuzugreifen. 4. der es ermöglicht, die Aktivitäten jedes Moduls durch den Debugger zu tracen. 5. deren Wirksamkeit (Modultest) für alle Applikationen, in denen er Anwendung findet, nur einmal nachgewiesen und dokumentiert werden muss. Amerikastr Zweibrücken Seite 6/6

Effekt: Mit diesem Verfahren wird einer Applikation im Idealfall ein dokumentierter und verifizierter Basissatz an Funktionalitäten zur Verfügung gestellt, 1.

Ähnliche Dokumente

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat