Aus der Erfahrung von fast 25 Jahren individueller Softwareprojekte kann ich sagen, dass dieses Thema von vielen Auftraggebern unterschätzt wird. Dabei gibt es in jeder Phase des Projekts Datenschutzrelevante Herausforderungen.

Es genügt nicht, eine Geheimhaltungsvereinbarung zu unterschreiben

Viele meinen, es sei mit einer schriftlichen Vereinbarung getan, in der sich der Software-Dienstleister verpflichtet, mit den Daten, die er vom Kunden erhält, ordentlich umzugehen. Hier werden oft seitenlange Standardverträge unterschrieben – und auf der Basis glaubt man dann, im Projekt alle möglichen Echtdaten verwenden zu können. Aber so einfach ist das nicht. Denn eine Vereinbarung zwischen Softwareentwickler und Auftraggeber erlaubt es beiden noch lange nicht, Daten von Kunden, Lieferanten und Mitarbeitern des Auftraggebers im Projekt zu verwenden. Außerdem ist es ohnehin besser, dass solche Daten gar nicht erst im Projekt auftauchen, als dass man sich darüber verständigt, aufpassen zu wollen, dass diese Daten nicht „in falsche Hände geraten können“.

Deshalb sollten sich Softwarehaus und Auftraggeber gleich zu Beginn des Projekts darüber verständigen, wie die notwendigen Informationen bereitgestellt werden können, ohne dass Echtdaten im Projekt verwendet werden. Das kostet Aufwand und der muss im Budget und im Zeitplan berücksichtigt werden – aber unterm Strich tut man das Richtige.

Genau genommen muss das Thema aber schon beachtet werden, bevor überhaupt ein Vertrag unterschrieben wird. Wenn der Kunde dem Lieferanten beschreiben will, was er überhaupt mit dem Projekt erreichen will, braucht er Beispiele: Dokumente, die gegenwärtig verwendet werden, Listen, die verarbeitet werden sollen, und so weiter. Überall sind Daten von Kunden und Mitarbeitern zu sehen. Oft werden diese Informationen dem (potentiellen) Vertragspartner schon im ersten Gespräch vorgelegt oder zum Zwecke des besseren Verständnisses des Themas übermittelt.

Jedem sollte klar sein, dass ein solcher Umgang mit Daten nicht in Ordnung sein kann, selbst wenn der potentielle Dienstleister zuvor eine Erklärung unterschrieben hat in der er sich verpflichtet, die übergebenen Daten geheim zu halten. Also muss schon vor Vertragsschluss ein gewisser Aufwand getrieben werden, Daten zu anonymisieren und unkenntlich zu machen.

Datenschutz während der Anforderungsanalyse und der Software-Spezifikation

Oft werden für die Anforderungsanalyse und die Softwarespezifikation realistische Beispieldaten gebraucht, sei es in Form von Dokumenten, die durch das System später erzeugt werden sollen, Screenshots von Systemen, die bereits mit den Daten arbeiten, oder Listen und Berichten, die die benötigten Daten enthalten. Es führt kein Weg daran vorbei: Diese Daten müssen anonymisiert werden. Das muss natürlich auf eine Weise geschehen, dass wichtige Informationen für die Softwarespezifikation nicht verloren gehen – und deshalb ist die Sache auch hin und wieder aufwändig. Nur selten wird der Aufwand, der hier getrieben werden muss, in das Zeit- und Kostenbudget dieser Projektphase eingeplant.

Natürlich kann ein professioneller Software-Dienstleister bei der Anonymisierung der Daten unterstützen. Wie werden Namen und Adressen unkenntlich gemacht, ohne dass die Information verschwindet, um was für Daten es sich handelt? Darin hat ein Softwarehaus natürlich Erfahrungen.

Test mit produktionsnahen Daten – Anonymisierung ist nötig

Dies umso mehr, als sich der Aufwand ja lohnt, denn für die Testphase des Projekts werden ohnehin produktionsnahe Daten gebraucht – also muss man Wege finden, Echtdaten zu anonymisieren. Ein Konzept zur Bereitstellung von Testdaten sollte ohnehin schon in der Spezifikationsphase entstehen. In dieses Konzept muss das Thema Anonymisierung und Pseudonomisierung mit einbezogen werden. Meistens lohnt es sich, dafür ein paar automatische Routinen zu schreiben, denn für die Tests werden Testdatensets mit unterschiedlichem Umfang und Ausprägungen benötigt.

Ob für die endgültigen Abnahmetests Echtdaten verwendet werden können, hängt vom Einzelfall ab – wie wird wo getestet, wer hat Zugriff auf die Ergebnisse, und wie wichtig ist die Erkennbarkeit von „echten Daten“ im Fachtest? Immer, wenn Testergebnisse an den Lieferanten übergeben werden, müssen diese aber anonymisiert sein – somit ist fraglich, ob es sinnvoll ist, mit Echtdaten zu arbeiten.

Ein weiterer Aspekt, der mit dem Datenschutz im Sinne der DSGVO wenig zu tun hat, ist der Schutz von Geschäftsgeheimnissen. Wer in Softwareprojekten, vor allem in Tests, mit anonymisierten oder pseudonomisierten Echtdaten arbeitet, muss sich darüber im Klaren sein, dass die Daten hinsichtlich der Geschäftsvorfälle immer noch „echt“ sind – Umsatzzahlen, Produktinformationen oder Geschäftsstrukturen lassen sich daraus immer noch ableiten. Natürlich sollten Kunde und Lieferant einander vertrauen, aber manchmal geraten solche Daten auch durch Unachtsamkeit in falsche Hände. Ein Bewusstsein für die Vertraulichkeit solcher Daten immer wieder zu schaffen, sollte selbstverständliche Aufgabe von Management und Projektleitung sein.

Der Beitrag Wie organisiert man Datenschutz im Softwareprojekt erschien zuerst auf INDAL Software-Spezialist.

In Communities wird geteilt

Communities werden dazu gebildet, etwas zu teilen: Ein Interesse, Wissen, Erfahrungen. Diese Communities sind somit für den Alltag unterstützend, ohne direkt in die tägliche Arbeit einzugreifen. Allerdings wissen gerade Entwickler, welche große Rolle sie heute beim schnellen Finden von Problemlösungen spielen können. Für Organisationen kann es deshalb ein Produktivitätsgewinn sein, den Mitarbeitern die Möglichkeit der Teilnahme an Communities zu geben. Andererseits befürchten manche Unternehmen zu recht, dass Know How abfließen könnte, welches einen Wettbewerbsvorteil darstellt. (Dieses Thema werde ich demnächst bei der Diskussion eines weiteren Papers aus diesem Umfeld aufgreifen).

Eine Ausnahme bilden Communities of Practice, darunter werden diejenigen Strukturen verstanden, die gemeinsam an offenen Systemen arbeiten, etwa an Open Source Projekten.

Allen Communities gemeinsam ist, dass die Mitglieder recht einfach und ohne Zutrittsregeln Mitglied werden können, und dass sie die Community genauso einfach wieder verlassen können. Entscheidungsprozesse sind in einer Community, wenn überhaupt, nur durch die Ausbildung einer impliziten Kultur möglich.

Netzwerke nutzen Technik

Das wichtigste Merkmal eines Netzwerkes ist die Sicherstellung einer gegenseitigen Erreichbarkeit. Tamburri verweist deshalb darauf, dass Netzwerke zumeist an Technologien (E-Mail, Soziale Medien, Kollaborationsplattformen) gebunden sind. Netzwerke bilden letztlich die Infrastruktur für andere kollektive Strukturen. Andererseits, und das ist für die Frage der kollektiven Entscheidungsfindung bedeutsam, erlauben Netzwerke, vorgegebene und definierte Entscheidungswege zu umgehen, Entscheidungsmechanismen, die unserer eigenen Forschung nach die Rationalität der Organisation ausmachen, können durch Netzwerke ausgehebelt werden.

Teams und Gruppen

Die eigentliche Arbeit wird in Teams und Gruppen durchgeführt, diese werden überhaupt zu dem Zwecke gebildet, die Projektarbeit zu organisieren. Tamburri unterscheidet zwischen ihnen: Gruppen werden projektunabhängig und langfristig gebildet, sie bieten den Rahmen, in dem die Arbeit organisiert wird. Abteilungen, aber auch Entwickler- und Testteams können dazu gezählt werden. Das, was Tamburri als Teams, oder Projektteams bezeichnet, sind kollektive Strukturen, die innerhalb des Projekts aus Personen zusammengesetzt werden, die gemeinsam eine bestimmte Aufgabe innerhalb des Projekts lösen sollen.

Entscheidungsfindung und Rationalität

Für unsere Forschung bei INDAL ist diese Klassifikation insofern interessant, dass die verschiedenen kollektiven Strukturen jeweils eine bestimmte Art von Rationalität in der Entscheidungsfindung zeigen, deshalb können sie in der Perspektive der ökonomischen Theorie unterschiedlich als rationale Akteure angesehen werden, für deren Beschreibung und Erklärung ökonomische Theorien herangezogen werden können. Gruppen haben durch ihre langfristige Struktur feste kulturelle regeln der Entscheidungsfindung, die entweder durch Autorität von Führungspersonen oder durch Regelwerke abgesichert sein können. Allerdings kann ihre Rationalität durch Netzwerke, aber auch durch Communities unterlaufen werden. Teams bilden selten eine kollektive Rationalität aus, da sie zu kurzzeitig existieren und die Teilnehmer oft aus unterschiedlichen Kulturen kommen. Ihre Entscheidungen sind deshalb im Sinne der ökonomischen Theorie selten als rational zu betrachten.

Auch für die unmittelbare Unternehmenspraxis können die Ergebnisse sinnvoll genutzt werden, indem auf ihrer Basis eine systematische Analyse der kollektiven Strukturen im Unternehmen und in Projekten durchgeführt wird. Letztlich ist das immer ein Teil der Anforderungsanalyse für komplexe Individualsoftware. Im Ergebnis können Schwachstellen erkannt und Optimierungen in den Entscheidungsstrukturen vorgenommen werden.

Tamburri, D., Lago, P., & Vliet, H. (2013). Organizational social structures for software engineering ACM Computing Surveys, 46 (1), 1-35 DOI: 10.1145/2522968.2522971

Der Beitrag Kollektive Strukturen im Software-Engineering erschien zuerst auf INDAL Software-Spezialist.

Ein Softwareprojekt ist zum großen Teil Kooperation, in der Menschen auf die Beiträge anderer Menschen angewiesen sind,um ihren eigenen Beitrag erbringen zu können. Doch oft bleiben die anderen hinter den Mauern der anderen Abteilung oder des Partnerunternehmens verborgen, sie bleiben anonym.

Oft wird gesagt, das sei auch ganz gut so. Die Beiträge der jeweils anderen zum Projekterfolg bestehen in der Zulieferung von Informationen, und diese Informationsbereitstellung soll, damit sie zuverlässig, vollständig und vertragsgerecht erfolgt, am Besten auf dem Postwege erfolgen, heute natürlich per E-Mail oder unter Verwendung eines Task- und Dokumentmanagementsystems.

Das ist natürlich auch richtig, insbesondere weil bei informeller Bereitstellung von Informationen vieles im Unklaren bleibt, was bei schriftlicher Formulierung präzise und nachprüfbar wird. Das ist notwendig, weil ein Softwareprojekt auch eine vertragliche Seite hat, es wird ein Werk geliefert, das Anforderungen erfüllen soll, und dafür wird eine vereinbarte Gegenleistung erbracht.

Manche Projektverantwortliche meinen deshalb, dass es überhaupt am Besten ist, wenn sich nur Vertrieb und Einkauf persönlich miteinander austauschen und jede weitere Kommunikation zwischen Projektbeteiligten schriftlich erfolgt. Ist, etwa zum Erfassen von Anforderungen, das persönliche Gespräch doch notwendig, so sollte dieses hochgradig formalisiert und strukturiert ablaufen und die Ergebnisse exakt protokolliert werden.

Dieser Ansatz verkennt jedoch, dass in solchen Projektstrukturen keine gemeinsamen Ziele entstehen können – es entsteht kein Gefühl für ein “Wir”, eine Gemeinschaft, die zusammen Erfolg haben möchte, es entsteht kein Gewinner-Team. Aber ein Wir-Gefühl ist notwendig für den Erfolg, das zeigen viele menschliche Tätigkeiten, vom Fußballspiel bis zu Kollaborationen im Internet. Gerade wenn es schwierig wird, wenn ungeahnte Probleme auftauchen, ist es wichtig, dass sich alle Beteiligten schon zuvor die Gewissheit gebildet haben, dass auch die Anderen den Erfolg wollen, dass sie mit mir “am gleichen Strang” ziehen, dass “wir das schaffen können”.

So ein “Wir” entsteht nicht durch den formalisierten Austausch von Anforderungsdokumenten und JourFix-Protokollen. Dazu braucht es Zeit und Raum für persönliche Begegnungen, nicht nur zu Beginn des Projekts, sondern auch immer wieder zwischendurch, nicht nur, um Erfolge zu feiern, sondern auch, wenn es schwierig wird. Gemeinsamkeiten müssen erlebt und gepflegt werden können. Und dafür sollten sich alle Zeit nehmen. Natürlich bei den Anlässen, die das Projekt bietet, dem Start, dem Erreichen wichtiger Zwischenetappen, der Übergabe der Lösung, aber auch zu Beginn eines JourFix und einer Telefonkonferenz, am Abend nach dem Workshop, am Ende jeder Mail.

Der Beitrag Software wird von Menschen gemacht erschien zuerst auf INDAL Software-Spezialist.

An dieser Stelle fangen die Unterschiede an: Während beim Haus Abstriche an den Anforderungen gemacht werden, auf teure Materialien verzichtet wird, alles etwas kleiner dimensioniert wird oder verzichtbare Teile ganz gestrichen werden, wird beim Softwareprojekt erst einmal verhandelt. Verzichtbar ist nichts, trotzdem muss der Preis runter. Zugegeben, das ist etwas holzschnittartig übertrieben, liegt aber nicht völlig neben den Realitäten.

Ein entscheidender Unterschied zwischen dem Hausbau und dem Softwareprojekt sieht man schon, wenn man die Angebote betrachtet: Während das Angebot des Bauunternehmens den Preis für jede Position einzeln ausweist und viele Alternativpositionen enthält, sodass die Möglichkeit von Verzicht und Einsparungen schnell sichtbar sind, enthalten Angebote für Software-Individual-Projekte selten Einzelpreise, und noch seltener Varianten für verschiedene Umsetzungsalternativen.

Aber es geht auch anders: Tatsächlich kann durch die richtige Anforderungszerlegung und -priorisierung auch im Softwareprojekt Flexibilität für die Anforderungserfüllung geschaffen werden. Manche Anforderungen sind zwingend umzusetzen, andere sind verzichtbar oder können skaliert werden. Fast immer gibt es Umsetzungsalternativen, die unterschiedliche Kosten nach sich ziehen.

So wird ein wirkliches Design-2-Budget möglich, bei denen am Ende beide Seiten zufrieden sind. Wenn Sie Details zu diesem Konzept wissen wollen, nehmen Sie Kontakt mit uns auf.

Der Beitrag Festpreisprojekt und Anforderungserfüllung erschien zuerst auf INDAL Software-Spezialist.

Eine davon ist die Methode 635.

Die Methode 635
Der Name ergibt sich aus:
6 Teilnehmer
3 Ideen
5 mal weitergeben

Man setzt sich mit 6 Personen in eine Runde. Jeder der Teilnehmer notiert, auf einem gleichgroßen Blatt Papier, 3 Ideen in der ersten Zeile einer Tabelle mit 3 Spalten. Jede Spalte hat 6 Zeilen.

Nach einer vordefinierten Zeit wird gleichzeitig das Blatt nach rechts weitergereicht.

Im nächsten Zeitintervall erweitert dann jeder die 3 Ideen, die er auf seinem Blatt hat.

Dieses wird solange wiederholt, bis alle einmal jedes Blatt in der Hand hatten.

Danach kann das Ergebnis ausgewertet werden.

Auf diesem Weg kann man bei leichten bis mittleren Problemen ggf. schnell zu neuen Ideen und Lösungen kommen.

Der Beitrag Kreativität beschleunigen – Methode 635 erschien zuerst auf INDAL Software-Spezialist.

Nach den Vorstellungen des klassischen Wasserfall-Modells müsste der Business Analyst das DV-Konzept abnehmen und die Realisierung müsste auf der Basis dieses abgenommenen DV-Konzeptes erfolgen. Das ist aber nur zum Teil richtig.

Richtig ist, dass der Business Analyst das DV-Konzept eingehend prüfen muss, er soll ermitteln, ob alle Anforderungen der Fachseite im DV-Konzept aufgenommen wurden und ob Richtlinien und Vorgaben berücksichtigt worden sind. Eine Abnahme aber würde bedeuten, dass der Business Analyst die Verantwortung dafür übernimmt, dass das DV-Konzept die Anforderungen der Fachseite erfüllt – und das ist nicht möglich. Dem Lieferanten würde sozusagen eine Zwischen-Entlastung erteilt ohne dass er sicherstellt, dass die Software den Anforderungen der Fachseite wirklich gerecht werden wird. Das aber ist nicht möglich.

Zum einen kann der Business Analyst im Allgemeinen die Spezifikationsdetails des DV-Konzeptes nicht einschätzen, da es sich dabei um Vorgaben an den Entwickler handelt, dessen technische Know How der Business Analyst nicht hat und nicht haben muss. Zum Anderen kann eine Spezifikation nicht getestet werden wie eine Software, und nur wenn das möglich wäre, wenn man durch einen Test, durch Ausprobieren könnte, ob die Spezifikation “funktioniert”, könnte man auf das technische Know How zur Prüfung des DV-Konzeptes verzichten.

Das heißt jedoch nicht, dass das DV-Konzept nicht abgenommen werden sollte. Die Abnahme soll prüfen, ob die Anforderungen berücksichtigt werden, ob nicht-funktionale und funktionale Anforderungen abgestimmt sind, ob Richtlinien eingehalten wurden. Die Abnahme stellt fest, dass keine Mängel gefunden wurden – nicht, dass keine Mängel vorhanden sind.

Werden im Software-Abnahmetest Fehler gefunden und stellt sich heraus, dass diese Fehler bereits im DV-Konzept vorhanden sind, so hat der Auftraggeber ein Nachbesserungsrecht sowohl auf das DV-Konzept als auch auf die Software. Optimal ist allerdings, wenn vereinbart wird, dass dies nur für Fehler gilt, die der Business Analyst bei der Abnahme des DV-Konzeptes nicht finden konnte.

Das klingt kompliziert – und ehrlich gesagt, das ist auch kompliziert. Wie ein solcher Vertrag ausgestaltet werden kann, hängt sehr stark vom konkreten Projekt ab. Letztlich ist natürlich das Vertrauensverhältnis zwischen den Partnern und die Bereitschaft zum pragmatischen Kompromis ausschlaggebend – aber das lässt sich im Vertrag nicht festschreiben.

Der Beitrag Spezifikationen abnehmen? erschien zuerst auf INDAL Software-Spezialist.

Auf der anderen Seite ist eine Vor-Schrift vielleicht nicht mehr als eine Absichtserklärung, oder ein Vorhaben sich in der Zukunft auf eine bestimmte Weise zu verhalten, das Dokumentieren eines Zieles. Partei-Programme haben diesen Charakter – sie enthalten „programmatische Ziele“.

Schaut man sich vor diesem Hintergrund die IT-Welt an dann fällt zweierlei auf:

Einerseits gibt es in einem IT-Projekt beide Sorten von Programmen: Der Code der Software ist – jedenfalls auf den ersten Blick – ein Programm im ersten Sinne, eine Folge von Befehlen, die auszuführen sind, eine Vorschrift, die das Verhalten des programmierten Systems berechenbar macht. Anforderungsspezifikationen sind hingegen eher programmatische Dokumente, sie beschreiben Ziele, die erreicht werden sollen. Auch Architektur-Richtlinien haben diesen „programmatischen Charakter“. Nützlich ist, ein solches Programm zu haben, bevor der Programmierer seine Arbeit beginnt. Über den Projekterfolg entscheidet die Klarheit des Programms der Fachseite, nicht das Programm des Software-Entwicklers.

Andererseits ist der Trend zu beobachten, dass der Code, die Folge von Programmier-Befehlen, immer weniger das Verhalten des Systems vorher bestimmt. Umso größer die Durchdringung des Alltags mit Software-Systemen ist, desto mehr ist das Verhalten dieser Systeme durch die Daten, die es verarbeitet, und die Umwelt, mit der es verbunden ist, verbunden. Welche Ergebnisse eine Internet-Suche mir liefert, wird weniger durch den Code der Suchmaschine bestimmt als durch die Struktur der Informationen, die im Internet abgelegt wird. Was Wikipedia, Facebook und Twitter wirklich sind oder sein können, ist nicht durch eine Datenbank-Struktur und ein PHP-Script definiert, sondern durch das, was die Benutzer damit machen.

Das muss auch auf die Programme selbst Auswirkungen haben. Wenn sich das Verhalten eines Systems nicht mehr befehlen lässt, muss die ganze System-Entwicklung programmatischer werden. Architekturen und Design sind nur gut, wenn sie zum Nutzen passen, wenn dieser Nutzen und die Benutzung aber nicht vorhersehbar sind, müssen die Vor-Schriften programmatischer werden.

Der Beitrag Programmatische Programme programmieren erschien zuerst auf INDAL Software-Spezialist.

Oft wartet man mit einer solchen Migration so lange, bis sie unumgänglich ist – außerdem macht das Unternehmen, bei dem die Individuallösung im Einsatz ist, auch nicht jeden Plattformwechsel mit. Deshalb muss bei einem Migrationsprojekt oft ein Sprung über drei oder vier Zwischenversionen geschafft werden – und da kann es schon eine Menge von wesentlichen und überraschenden Unterschieden in den genutzten Schnittstellen geben.

Wie soll man in einer solchen Situation vorgehen, und vor allem, wie viel Zeit und Ressourcen muss man einplanen?

Migrationen sind zunächst ganz normale Softwareprojekte, und wie bei diesen gibt es paradigmatisch auch hier zwei Vorgehensmodellen: Phasenmodelle und agile Vorgehensweisen. In einem phasenorientierten Vorgehensmodell wird man zunächst den Migrationsbedarf als funktionale Anforderungsmenge analysieren und spezifizeren, dann ein Umsetzungskonzept entwickeln und schließlich die Migration als Neuimpementierung von Funktionalität umsetzen.

Gerade bei Migrationen ist allerdings der Anteil der Unbekannten Anforderungen besonders groß. Migrationen sind Entdeckungsreisen in die unbekannte Welt der neuen Plattform – und selbst, wenn man Experten für die neue Welt als Lotsen an Bord hat, weiß man nicht, wie das alte Schiff in den neuen Fahrwassern wirklich reagieren wird, welche Schwachstellen in der “Neuen Welt” erst zum Tragen kommen, die man zuvor gar nicht bemerken konnte.

Deshalb bieten sich gerade bei Migrationen agile Vorgehensmodellen an. Kurz gesagt: Man startet mit einem Experiment und schaut, was passiert. Man wagt die ersten vorsichtigen Schritte und beobachtet, wie System und Kontext reagieren. Man löst die auftretenden Probleme und geht den nächsten Schritt – so lange, bis das System in de Ziel-Umgebung stabil läuft.

Agile Projekte dieser Art haben den Nachteil, dass man zu Beginn nicht weiß, wie lange sie dauern und wie aufwändig sie sind – aber paradoxerweise sind sie preiswerter und effizienter als das phasenorientierte Vorgehen, bei dem man zwar immer eine plausible Aufwands- und Kostenschätzung hat – die aber leider nie stimmt, weil man die Überraschungen, die unweigerlich auftreten, nicht einkalkulieren kann.

Natürlich liegt in der wirklichen Projektwelt – wie immer – die Wahrheit in der Mitte. Eine Analyse der entscheidenden Plattform-Differenzenen mit Relevanz-Betrachtung und Risikobewertung soll und kann immer am Anfang stehen und eine intensive Beschäftigung mit den Möglichkeiten und konzeptionellen Neuigkeiten des Zielsystems ist ebenfalls sinnvoll.

In jedem Fall sollte zu Beginn des Migrations-Projektes die Erstellung eines detaillierten Testkonzeptes stehen. Nirgends ist der Einsatz eines Testfall-getriebenen Entwicklungsansatzes so sinnvoll wie bei Migrationen. Die Testfälle sollten hier als White-Box-Tests geplant werden, da der Code der Individual-Anwendung ja bekannt ist. Die Codeabdeckung der Testfälle sollte Risiko-abhängig vorab festgelegt werden.

Der Beitrag Plattform-Migrationen erschien zuerst auf INDAL Software-Spezialist.

Häufig wird zu Beginn des Projektes zwar versucht, ein paar Regeln für das Schreiben von Spezifikationen zu definieren, aber das war’s dann oft auch schon. Bald schreibt ein jeder die Dokumente, die er für notwendig hält – das gilt zwar nicht so sehr für Fachkonzepte und DV-Spezifikationen, aber ziemlich häufig schon für so zentrale Artefakte wie das Glossar oder den Geschäftsregelkatalog, ganz zu schweigen von Leitlinien, Vorgaben und Design-Hinweise, die eigentlich die regeln für das Schreiben guter Dokumente vorgeben sollten.

Eine gut gepflegte Dokumentenlandschaft hat vier Bereiche:

1. Spezifikationsdokumente, jeweils einem bestimmten Spezifikationsschritt zugeordnet (Fachkonzept, DV-Konzept,…)
2. Übergreifende Projektdokumente (Glossar, Konzeptionelles Datenmodell, Geschäftsregelkatalog)
3. Leitfäden, Richtlinien und Templates für die Dokument-Erstellung, allgemein (für alle Typen gültig) oder spezifisch für einen Dokumenttyp
4. Prozess-Definitionen (allgemein oder Dokumenttyp-Spezifisch)

Jeder dieser Bereiche wäre wenigstens einmal ein eigener Blogbeitrag zu widmen, hier nur noch ein paar Hinweise:

Spezifikationsdokumente sind projektspezifisch, übergreifende Projektdokumente können in anderen Projekten teilweise wieder verwendet werden. Leitfäden und Prozess-Definitionen werden oft in mehreren Projekten verwendet und als Unternehmensweiter Standard definiert. Sie werden meist für ein Projekt erstellt und später verallgemeinert.

In der Beschreibung der Dokumenten-Landschaft muss für jeden Dokumenttyp definiert sein, welche Projekt-Rolle Besitzer von Dokumenten des Typs ist, wer Reviews und Freigaben durchführt und wer auf welche Weise an weiteren Prozessen beteiligt ist. Die Projekt-Rollen sind in einem Projekt-Handbuch zu beschreiben – auch die Dokumenten-Landschaft kann im Projekt-Handbuch beschrieben sein.

Beziehungen zwischen den Dokumenten einer Dokumenten-Landschaft werden hergestellt, indem im Vorspann zum Dokument zwei Tabellen vorgesehen werden, die Verweise auf

• Verwendete Standards (Leitlinien, Richtlinien, Templates, Prozess-Definitionen)
• Referenzierte Dokumente, die als projektspezifischer Input für das Dokument verwendet wurden

enthalten.

Für jeden Dokumenttyp wird bei der Definition der Dokumenten-Landschaft festgelegt, welche Standards für welchen Dokumenttyp zu verwenden sind und auf welche Dokument-Typen als Input verwiesen werden kann.

Das sind ein paar Grundregeln, die für den Aufbau einer guten Dokumenten-Landschaft zu beachten sind. Das klingt vielleicht nach harter Arbeit ohne schnellen Erfolg. Aber auch hier gilt, was jeder Gärtner weiß: Ist die Grundordnung erst einmal hergestellt, dann fällt die Pflege leicht, und der Ertrag ist bedeutend.

Der Beitrag Projektdokumente – gepflegte Landschaft oder Wildnis? erschien zuerst auf INDAL Software-Spezialist.

In der Literatur wird dazu oft das System als derjenige Teil der Realität definiert, der durch das Projekt verändert, beeinflusst oder neu gestaltet wird. Der Kontext hingegen ist der Teil, der das System zwar beeinflusst, der aber durch das Projekt selbst nicht verändert wird.

So weit – so gut. Leider wird in der Literatur im Weiteren beim “System” nur von der Software, die neu entwickelt oder angepasst werden soll, geschrieben, vielleicht noch von der Hardware und der Infrastruktur, die diese Software benötigt. Und da beginnt ein wesentliches konzeptionelles Problem des Projektes.

Praktisch jedes Softwareprojekt greift auch in die Geschäftsprozesse ein, in denen die Software, die der eigentliche Gegenstand des Projektes ist, zum Einsatz kommt. Es ist gut, wenn diese Geschäftsprozesse deshalb mit zum System und nicht zum Kontext gezählt werden. Dann wird eine grundsätzliche Analyse der bestehenden Prozesse und eine Spezifikation der geänderten Prozesse in fachlichen Use Cases nicht mehr dem Zufall überlassen, sondern als notwendiger Teil des Spezifikationsprozesses betrachtet.

Das hat zur Folge, dass parallel zur Softwareentwicklung der Prozess des Change Managements in der betroffenen Organisation startet. So kann man dafür sorgen, dass das Change Management nicht mehr Stiefkind des Projektes ist, sondern so priorisiert wird, wie es seinem Anteil am Projekterfolg – oder Misserfolg – in der Praxis entspricht.

Der Beitrag Was ist System, und was ist Kontext erschien zuerst auf INDAL Software-Spezialist.