Qualitätsanforderungen, auch nicht-funktionale Anforderungen genannt, sind schwierig in einer agilen Umgebung umzusetzen. Denn die Erfüllung dieser Kriterien ist wichtig, aber auch umständlich und zeitaufwendig. Um all diese Kriterien zu erfüllen, sind eine Menge Abteilungen und Teams beteiligt, die ihre Arbeit unbedingt aufeinander abstimmen müssen.
Gewisse Qualitätsanforderungen, bzw. nicht-funktionale Anforderungen, kurz NFR genannt, sind schwierig in einer agilen Umgebung umzusetzen. Denn die Erfüllung dieser Kriterien ist wichtig, aber auch umständlich und zeitaufwendig.
Das Besondere und gleichzeitig Schwierige an Qualitätsanforderungen ist, dass sie zu 100% erfüllt sein müssen. 95% reichen nicht aus, um den Qualitätskriterien zu genügen. Viele dieser Anforderungen verlangen ausserdem, dass die Erfüllung stets im Rahmen eines Audits oder eines Zertifikats nachgewiesen werden kann. Und dafür wiederum ist ein ganzes Set an Detailanforderungen zu erfüllen.
Nehmen wir als Beispiel das Thema Datenschutzverordnung, weil es bekannt und gerade in aller Munde ist. In der Datenschutzverordnung steht sinngemäss folgende zu erfüllende Qualitätsanforderung: „Enrcrypt, pseudonymize, or anonymize personal data wherever possible”. Um diese Anforderung zu realisieren, bedarf es unter anderem:
- eines Konzepts für Identity- and Access-Management, auch IAM-Konzept genannt.
- der Implementierung des Konzepts – sowohl in der Organisation als auch in der Software, unabhängig davon, ob es sich um Standardsoftware (z.B. SAP) handelt oder um eine Eigenentwicklung.
- eines Test- und Validierungskonzepts.
- der Implementierung dieses Test- und Validierungskonzepts
- eines Prozesses zum Erstellen der geforderten Dokumentation als Nachweis der Konformität, mit der Anforderung für einen Auditor oder eine Zertifizierungsstelle.
Viel Abstimmung nötig
Um all diese Kriterien zu erfüllen, sind eine Menge Abteilungen und Teams beteiligt, die ihre Arbeit unbedingt aufeinander abstimmen müssen. Typische Beteiligte sind der Chief Information Security Officer (CISO), die System-Architekten, Entwicklung und Betrieb. Auch für kleine Unternehmen müssen in einem regulierten Umfeld diese Verantwortungen besetzt sein.
Klassisch vs. agil
In einem klassischen Arbeitsmodell (etwa nach V-Modell XT oder Hermes) war es „einfach“, diese Anforderung zu erfüllen und den Nachweis der Konformität zu erbringen – zumindest aus Prozess-Sicht. Es gab klare Vorgehensweisen in der Entwicklung (wie z.B. Grobkonzept, Feinkonzept, Design, Implementierung, Test, Abnahme, Betrieb) und bei jedem Übergang gab es vordefinierte Validierungen, deren erfolgreiche Durchführung vom CISO überwacht und dokumentiert wurde. Die Validierungspunkte und der Scope der Validierung waren also an jedem dieser Übergänge klar festgelegt und die Durchführung nachvollziehbar.
Bei einem agilen Vorgehen ist es nicht mehr so einfach. Nehmen wir als Beispiel ein grosses Unternehmen, welches einen Teil seiner Software nach dem Scaled Agile Framework SAFe selbst entwickelt. Ein Entwicklerteam (eines von vielleicht 50 Teams im Unternehmen) implementiert die Software für die Angebotserstellung und setzt alle zwei Wochen eine neue Version der Software ein. Um nun die Qualitätsanforderung der Datenschutzverordnung „Enrcrypt, pseudonymize, or anonymize personal data wherever possible“ zu erfüllen, müssen alle zwei Wochen alle oben aufgezählten Teilanforderungen erfüllt sein.
Die spannende Frage ist: Wie synchronisieren wir diese Tätigkeiten, die auf verschiedenen Abstraktionsebenen im Unternehmen stattfinden, unterschiedliches Know-how in unterschiedlichen Teams benötigen und zu unterschiedlichen Zeiten passieren?
Im nächsten Beitrag dieser Blog Serie stellen wir Ihnen ein auf dem Scaled Agile Framework (SAFe) als Prozess Framework basierendes Konzept vor, das in Zusammenarbeit mit einem grossen Schweizer Unternehmen aufgebaut und umgesetzt wurde.
