Requirements-Management bei AdNovum

0

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.

Zunahme der Produktivität von 1990 bis 2010

Entsprechend sind aber auch die Anforderungen an das Know-How der Mitarbeiter gestiegen.

Aufstellung diverser IT-Disziplinen

Requirements im Projekt

Der Business Analyst ist die Schnittstelle zwischen Kunde und Entwickler, Tester, Quality Engineer

Zusammenarbeit der verschiedenen Projektdisziplinen

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

Gegenüberstellung der benötigten Dokumente

Beschreibungsbausteine

Verstärkt setzt man auf Use-Cases. Entscheidend ist, wie man die Komplexität eines Systems auf Use-Cases herunterbricht.

Beschreibungsbausteine

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.

Ãœbersicht der Prozesse und ihr Einfluss auf das Change Management

Quality Assurance

Quality Assurance auf drei Ebenen

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.

Farbliche Einfärbung von Klassen für eine Risk Based Coverage Analysis

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 Requirements Dokumente

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.

Danke fürs teilen meines Beitrags ;-)

Wer schreibt hier?

Walter Schärer bloggt über neuste Internet-Trends im Online Marketing, Social Media, Blogs, Web Analytics, SEO, Mobile und so.

Hinterlässt Du einen Kommentar?