Swiss Requirements Day, Erfahrungsbericht von Marcel Raymann, Projektportfolio Management, AdNovum Informatik AG
Das Requirement Engineering hat an Bedeutung gewonnen. In Projekten sind frühe Kostenzusagen mit hohem Kostendruck üblich. Die Realisierungszyklen werden immer kürzer bei Forderung hoher Flexibilität und Anpassungsfähigkeit, z.T. auch mit direkter Einbindung des Kunden.
Die Lösungen werden immer komplexer, die Qualitätsansprüche sind sehr hoch, weil sich Kunden an der Best Practice von Produktherstellern orientieren.
D.h. es braucht ein innovatives Technologiemanagement: Wie gut kann der Anbieter mit den Technologien der Technologie-Wave umgehen?
Ein effektives Requirement Engineering ist unerlässlich und unterstützt eine genaue Kostenschätzung basierend auf einer Dreipunkteschätzung.
Der Software-Engineering-Prozess ist standardisiert. Toolgestützte, automatisierte Qualitätssicherung ist unabdingbar.
Externe Anforderungen an Software-Hersteller
Das Projektportfolio umfasst
Fachanforderungen
– Finanz
– Government
– Logistik
– Teco
– Assekuranz
Individuelle Kunden
– Firmengrösse
– Firmen- & Projektkultur
– Umgang mit externen Lieferanten
– IT Standards / Richtlinien
Projektarten
– Business-Applikationen
– Security-Applikationen
– Integrationsprojekte
– Wartungsprojekte
– Grössenordnungen (5 Personenmonate bis 50 Personenjahre)
Schneller, kosteneffizinter produzieren
Produktivität
Die Produktivität hat sich über die letzten 20 Jahre exponentiell erhöht, u.a. dank eines iterativen Vorgehens.
Entsprechend sind aber auch die Anforderungen an das Know-How der Mitarbeiter gestiegen.
Requirements im Projekt
Der Business Analyst ist die Schnittstelle zwischen Kunde und Entwickler, Tester, Quality Engineer
Die Zusammenarbeit mit kundeneigenen Analyseteams ist wichtig. Interne Businessanalysten sind deshalb von Vorteil, weil sie den Entwicklern zeitnah mit relevantem Knowhow zur Verfügung stehen.
Der Dokumentensetup und -organisation
Beschreibungsbausteine
Verstärkt setzt man auf Use-Cases. Entscheidend ist, wie man die Komplexität eines Systems auf Use-Cases herunterbricht.
Change Management
Während der Entwicklung tauchen immer Fragen, Lücken, Fehler auf. Dies muss strukturiert über den Change Management Prozess aufgefangen werden, möglichst mit einem Ticketing-System.
Quality Assurance
Jede Applikation wird über Nacht durch einen Integrationsbuild geschleust (Nightly Build).
Die Klassen und Methoden werden visualisiert. Rot können sehr kritische Applikationen eingefärbt werden, grün sind weniger kritische Features. So kann der Fokus der Tests gesteuert werden.
Requirement Management «Next Generation»
«Gläserner Entwicklungsprozess»
Man versucht Medienbrüche zu vermeiden zwischen den verschiedenen Disziplinen.
Unstrukturierte Business-Informationen werden bereits auf die Requirements gemapped. Das bedeutet man braucht ein konsistentes Naming. Die Requirements gehen nicht in Word, sondern direkt in eine Datenbank.
Durchgängige Verlinkung der Information ist heute in Software-Tools möglich. Daraus können Code-Hülsen generiert werden, die zu den Requirements passen.
Einige Tools generieren sogar fertigen Code.
Aus solchen Tools kann dann auch automatisiert die Dokumentation generiert werden, man geht also nicht vom Dokument in die Entwicklung, sondern von der strukturierten Anforderungserfassung.
Im Extremfall kann von einer Codezeile auf den Business-Case gefolgert und im Falle eines technischen Ausfalls eine Business-Meldung generiert werden.
In der Praxis ist es nicht einfach, «weiche» oder unterschiedliche Businessanforderungen in strukturierte Prozesse zu giessen. Dies muss von den Business Analysten geleistet werden, diese Koordination leistet kein Tool.
Oft müssen die Requirements auch an das Budget angepasst werden.
Die Verwendung von Use-Cases wird von Kunden gut akzeptiert, wenn sie in der richtigen Granularität vorliegen. Dies funktioniert besser als lange Prosatexte, die dann für den Entwickler sowieso strukturiert werden müssen.
Vollständige AdNovum Präsentation hier herunterladen.