Durchgängiges Requirement Tracing mit Visual Studio 2010 ALM

Wenn man Software Entwicklung betreibt kann man das auf unterschiedlichste Arten tun. Im Allgemeinen ist das abhängig davon, was man macht und wofür man es macht. Ein privates Tool wird wohl eher einem pragmatischen Entwicklungsansatz folgen. Ein professionelles Produkt sollte bestimmte Qualitätsrichtlinien einhalten. Ein kommerzielles Medizinprodukt muss unter vom Gesetzgeber vorgegebenen Qualitätsrichtlinien entwickelt worden sein – hier ist also sogar nicht nur die Qualität im Produkt sondern auch auf dem Weg dahin entscheidend. Anderenfalls darf das Produkt nicht verkauft werden.

Die Anforderung an Anforderungsmanagement aus der Q-Sicht

Einer dieser Qualitätsansprüche bei der Entwicklung von Medizinprodukten ist es, Anforderungen über den ganzen Entwicklungsprozess, also vom Anforderungsdokument  bis in den Code hin zu Testplänen nachverfolgbar zu machen. Das heißt überspitzt gesagt, es muss von jeder Zeile Code aus möglich sein, zu sagen, warum sie codiert wurde und wo sie getestet ist. Umgedreht muss es zu jeder Anforderung möglich sein, die Codezeile zu finden, die sie implementiert.

Ich mag jetzt gar nicht darüber schreiben, ob das sinnvoll ist, oder nicht. Die Frage wird abhängig davon, mit wem man darüber spricht sehr kontrovers diskutiert. Es gibt die Partei, die hier von Überregulierung, Behördentum und Bürokratie spricht und es gibt die Partei, die bei medizinischer Software einfach höchste Qualität erreichen will und dafür eben schonmal den Holzhammer auspackt. Je nachdem, ob man die Software gerade entwickelt und dadurch Leidtragender ist oder selbst (z.B. als Patient – also erst recht Leidtragender :-) ) auf funktionierende medizinische Software angewiesen ist, sind beide Positionen zumindest nachvollziehbar.

Was bisher geschah…

Die Ansätze, die zur Erreichung der durchgängigen Nachvollziehbarkeit in der Vergangenheit verfolgt wurden, haben zwar das Problem gelöst, waren aber meist für den jeweiligen Entwickler mit einem gewissen Zusatzaufwand verbunden – ohne einen gleichzeitigen Mehrwert in der täglichen Arbeit zu bieten.

Eine Möglichkeit ist zum Beispiel die Arbeit mit sogenannten “Requirement Keys”. Dabei wird jeder Anforderung ein eindeutiger sogenannter “Requirement Key” zugeordnet. Der Key lautet dann meist ungefähr so: RK_FEATURE_1234_5678. Überall wo ein Dokument oder Code oder ein Testplan für dieses Requirement entsteht wird dann eben ins entsprechende Kapitel des Textes dieser Key manuell eingefügt. Um sicherzustellen, dass kein Key vergessen wurde, gibt es Tools, die wiederum nichts anderes tun, als die entsprechenden Dokumente auf genau diese Keys hin zu durchsuchen. Wenn einer fehlt, meckern die Tools. Das hat in der Vergangenheit gut funktioniert, die gefürchteten Q-Audits, die über Leben und Tod eines Medizinprodukts am Markt entscheiden können erfolgreich absolviert werden. Aufwand für die Entwicklungsabteilung: Ja. Mehrwert? Kaum.

Der Ansatz in VS2010 und Team Foundation Server

Es muss aber doch auch anders gehen. Aufwand zu leisten, um eine Prüfung zu bestehen erinnert ein bisschen an die alten Schultage in denen man Texte auswendig gelernt hat, ohne den Inhalt zu verstehen – um gute Noten zu erhalten. Wenn ich heute Aufwand leiste, will ich nicht eine gute Note dafür – ich will einen echten Vorteil, einen Mehrwert. Bin ich mit der Meinung alleine? Hoffentlich nicht.

In Microsoft Visual Studio 2010 in Verbindung mit Team Foundation Server gibt es zur Verwaltung von beliebigen Arbeitspaketen  sogenannte “Work Items”, die auf die persönlichen Bedürfnisse anpassbar sind. Mit VS 2010 kann man diese bequem in Verbindung miteinander setzen. Wenn man einmalig Requirements und Testfälle sowie die zugehörigen Implementierungstasks verlinkt erhält man ein durchgängiges Requirement Tracing – for free. Es ist zu jedem Zeitpunkt möglich, sich von einer Anforderung zu den Testfällen und zurück zu hangeln. Moment – da war noch was mit dem Quellcode! Ahja – wenn ich meine Checkins auf TFS immer fleißig mit einem  Workitem assoziiere, bekomme ich eine durchgängige Tracability auch im Code – und zwar nicht pro File, Klasse oder Methode – sondern pro Zeile! Mehraufwand: Kaum!  Mehrwert: JA!

 

Der Mehrwert

Bei der Frage nach dem Mehrwert, unterscheidet sich die Tracability auf Basis von verlinkten, hierarchischen Workitems zum Arbeiten mit Keys wesentlich! Der “alte” Mechanismus auf Basis von Keys ist zwar ausreichend für eine erfolgreiche Zertifizierung, bietet aber darüberhinaus kaum praktischen Nutzen – im Gegenteil: Pflege und Suche nach Keys sind eher hinderlich.

Durch die auf Changesets verlinkten Workitems in VS2010 bekommt die Entwicklungsabteilung ein sehr mächtiges Werkzeug an die Hand. Wer kennt die Situation nicht, in der man wissen will, aus welchem Grund eine Zeile Code geschrieben wurde? Heute wird einmal auf “Annotate” geklickt und wir finden den Schuldigen. Mit VS2010 sogar unabhängig von Branch- und Merge-Vorgängen. Und heute muss man sich auch nicht mehr Gedanken darüber machen, was sich der “Schuldige” dabei gedacht hat, oder was er erreichen wollte – einfach mal schauen, welche Work Items mit dem Checkin vernüpft sind, schon finden wir den entsprechenden Kundenwunsch dahinter. Und wenn wir uns dann fragen, ob das jemals getestet wurde, hangeln wir uns eben ein bisschen weiter. Also nochmal für alle: Mehrwert? Riesig!

Na, wenn das die Prüfer von LGA, FDA und Konsorten mal nicht zufrieden stellt…