Der Software Entwicklungsplan
- Teil: Was ist ein Software-Entwicklungsplan
- Teil: Wie sieht ein Software-Entwicklungsplan aus
Wie sieht ein Software-Entwicklungsplan aus, gemäß den Anforderungen der 62304
Nachdem wir nun wissen, was ein Software-Entwicklungsplan ist, stellt sich natürlich die Frage, was der Inhalt eines solchen Planes konkret sein könnte.
Eine gute Grundlage mit doch recht konkreten Forderungen liefert uns die IEC 62304 in Kapitel 5.1.
Im folgenden Beitrag gehe ich Anforderungen der 62304 durch und erörtere wie man diese konkret im Projekt umsetzt. Die 62304 hat ganze 11 Unterkapitel spendiert um aufzuzeigen was man sich unter einer „Planung der Software-Entwicklung“ vorstellt.
Generell sollten Sie bei der Erstellung eines Planes immer darauf achten, dass dieser Plan auch eingehalten wird und Sie den Nachweis am Ende antreten können, dass Sie das, was Sie geplant haben auch wirklich umgesetzt haben. Gibt es berechtigte Gründe, warum der Plan nicht eingehalten wurde, so ist dies zu dokumentieren und zu begründen.
Schauen wir uns die Anforderungen der 62304 zum Thema Software-Planung an.
| Kapitel 5.1.1 | a. Prozesse die angewendet werden, müssen angegeben werden |
| Hier werden Sie aufgefordert festzulegen wie Sie entwickeln. Geben Sie eine Referenz auf Ihren SW-Entwicklungsprozess an, wenn Sie einen allgemeingültigen Prozess haben, oder aber, sie definieren innerhalb des SW-Entwicklungsplanes, konkret für Ihr Projekt, wie Sie arbeiten.
Wenn Sie Referenzen nutzen, vergessen Sie nicht, dass diese eindeutig sein müssen, also die konkreten Prozesse inklusive den konkreten Versionen. |
|
| Kapitel 5.1.1 | b. die zu liefernden Ergebnisse (einschließlich der Dokumentation) der Aktivitäten und Aufgaben |
| Hier können Sie analog zu 5.1.1.a auf den allgemeingültigen SW-Entwicklungsprozess verweisen, welcher hoffentlich die Outputs Ihrer Entwicklung festlegt, oder aber sie definieren wiederum im Plan, welche Ergebnisse konkret während der Entwicklung entstehen. Beispiele hierfür sind: Eine Software-Architektur, eine Fein Spezifikation, Review Ergebnisse, oder das Software Release als Binary.
Diese Aufführung der Ergebnisse hilft Ihnen dabei, vor der Freigabe der Software zu prüfen, ob alles erledigt und verfügbar ist. So erkennen Sie eventuelle Lücken sehr schnell und können diese bewerten oder aber natürlich schließen. |
|
| Kapitel 5.1.1 | c. Rückverfolgbarkeit zwischen System-Anforderungen, Software-Anforderungen, Software-System-Prüfungen und Risikokontroll-Maßnahmen, die in Software implementiert werden; |
| Dieser Punkt heißt nichts anderes wie Traceability. Legen Sie fest wie Sie die Traceability sicherstellen. Wie in den Punkten zuvor, können Sie auf den allgemeingültigen SW-Entwicklungsprozess referenzieren, der das festlegt, oder sie definieren es hier für Ihr konkretes Projekt.
Sie haben alle Freiheiten, aber legen Sie es eindeutig und verbindlich fest! |
|
| Kapitel 5.1.1 | d. Software-Konfigurations- und Änderungsmanagement, einschließlich SOUP-Konfigurationselementen und Software, die zur Entwicklungsunterstützung verwendet wird |
| Beschreiben Sie hier wie Ihr Konfigurations- und Änderungsmanagement konkret funktioniert.
Das Vorgehen kann für den Quellcode, für SOUP Elemente und für Werkzeuge unterschiedlich aussehen. Sie können auf entsprechende Prozesse verweisen oder es für das jeweilige Projekt konkret beschreiben. Beispiel:
Führen Sie die eingesetzten SOUP Komponenten und Entwicklungswerkzeuge in Ihrem Plan auf und vergessen Sie nicht, dass es eindeutig sein muss (siehe auch Kapitel 5.1.4). |
|
| Kapitel 5.1.1 | e. Software-Problemlösung und Behandlung von Problemen, die bei Software-Produkten, zu liefernden Ergebnissen und Aktivitäten in jeder Phase des Lebenszyklus entdeckt werden |
| Wie gehen Sie mit Problemen (Bugs) um, welche Sie finden? Probleme treten nicht nur im Quellcode und damit im Software-Produkt auf. Probleme können auch in der Dokumentation in der eingesetzten SOUP Software oder aber in den Software Werkzeugen auftreten.
Beschreiben Sie konkret das Vorgehen oder verweisen Sie auf übergeordnete Prozesse die das Vorgehen beschreiben. Wie beim Änderungsmanagement kann bei der Problemlösung je nach Phase des Projektes unterschiedlich vorgegangen werden. Je weiter Ihre Entwicklung fortgeschritten ist und sich dem Ende nähert, desto formaler gehen Sie vor. Nutzen Sie die Möglichkeit, unterschiedliche Vorgehensweisen ja nach Phase zu definieren. Beispiel: Probleme mit eingesetzten Entwicklungswerkzeugen können vor Software Quality Gate 1 direkt mit der zentralen IT geklärt werden. Nach Quality Gate 1 ist ein Ticket zu erstellen und eine erste Risikoabschätzung bzgl. der Auswirkungen auf das Projekt zu machen. Nach Quality Gate 2 sind die Probleme an den Projektleiter zu eskalieren. |
|
| Kapitel 5.1.2 | Aktualisierung des Software-Entwicklungsplanes |
| Diese Aktivität ist nicht allzu schwierig, wird aber häufig nicht gemacht. Passen Sie den Plan an, falls sich etwas ändert. Vergessen Sie nicht in der History den Grund der Änderung zu dokumentieren.
Wie der Name schon sagt, wir reden hier von einem Plan. Ein Plan wird zu Beginn erstellt. Somit kann der Plan nicht schon alles in der Version 1 beinhalten. Der Plan ist ein lebendes Dokument. Die Norm fordert Sie sogar expliziert dazu auf, ihn aktuell zu halten und den Gegebenheiten anzupassen. |
|
| Kapitel 5.1.3 | a. Der Hersteller muss System-Anforderungen im Software-Entwicklungsplan als Vorgaben für die Software-Entwicklung referenzieren |
| Bei dieser Forderung gibt es eine enge Verbindung zu Anforderung 5.1.1.c (Rückverfolgbarkeit / Traceability).
Nehmen Sie eine Referenz auf die Systemanforderungen in Ihren Plan auf, welche die Grundlage für die Software sind. Vergessen Sie nicht Ihren Plan zu aktualisieren und damit auch die Referenzen, wenn sich Änderungen in den Systemanforderungen ergeben. Siehe hierzu auch Kapitel 5.1.2. |
|
| Kapitel 5.1.3 | b. Der Hersteller muss im Software-Entwicklungsplan Verfahren zur Koordination von Software- Entwicklung und Design- und Entwicklungs-Validierung einschließen oder referenzieren; dies ist für die Erfüllung von 4.1 erforderlich. |
| Die Anforderung kommt uns schon bekannt vor. Bereits in Kapitel 5.1.1 wurde gefordert zu definieren nach was man arbeitet. Dieser Punkt geht in die gleiche Richtung. Legen Sie im Plan fest oder referenzieren Sie auf die Prozesse und Methoden, wo ersichtlich ist, wie Sie bei der Validierung vorgehen. Es wird auf Kapitel 4.1 verwiesen. Dort wird unter anderem von der Erfüllung von Kundenanforderungen gesprochen, was ein klarer Hinweis auf das Thema Validierung ist.
Wie kann das nun konkret aussehen: Zur Sicherstellung das die Software die Kundenanforderungen erfüllt, wird wie folgt vorgegangen:
|
|
| Kapitel 5.1.4 | Planung von Normen, Methoden und Werkzeugen der Software-Entwicklung |
| Definieren Sie im SW-Entwicklungsplan die Normen die Sie für Ihre Software berücksichtigen (z.B. die 62304 oder die 60601-1-8), legen Sie die Werkzeuge fest, wie z.B. die Compiler, die Versionsverwaltung, Testtools. Vergessen Sie dabei nicht auch die konkrete Version mit anzugeben.
Dies geht stark in Richtung Konfigurationsmanagement. Zu einer vollständigen Konfiguration gehört alles, um eine Software eindeutig und reproduzierbar zu identifizieren. Auch Ihre eingesetzten Werkzeuge, Normen und die Art der Vorgehensweise, wie z.B. die Methoden der Verifizierung gehören dazu. Alles muss eindeutig identifiziert werden, da all diese Punkte Einfluss auf die Entwicklung haben und geklärt sein müssen. |
|
| Kapitel 5.1.5 | Planung der Software-Integration und der Integrationsprüfung |
| Legen Sie fest, wie Sie bei der Integration der Software vorgehen wollen. Beschreiben Sie das Vorgehen.
Die Norm schreibt Ihnen nicht vor wie Sie integrieren, es kann von einer „Big Bang“ Vorgehensweise bis zu einer „iterativen“ Vorgehensweise alles sein. Achten Sie aber darauf, dass das Vorgehen der Kritikalität des Projektes entspricht. Die Vorgehensweise bei der Integration der Software hängt stark von Ihrer Software Architektur ab. Nehmen Sie diese als Grundlage der Integrationsstrategie! Damit haben Sie definiert wie Sie Ihre Software zusammenbauen. Sie haben aber noch nicht definiert, zu welchem Zeitpunkt Sie welche Prüfungen machen! Aus diesem Grund, legen Sie fest, welche Prüfungen Sie während der Integration planen. Dies kann wie folgt aussehen:
Sie haben viele Freiheiten und damit Möglichkeiten. Definieren Sie die optimale Vorgehensweise und achten Sie darauf, dass Sie das anschließend auch so durchführen wie geplant. Beachten Sie auch, dass Sie die Integrationsprüfungen und die Systemprüfungen zusammenlegen können, sie sollen aber auch diese Vorgehensweise, wie immer, planen und schriftlich festlegen. |
|
| Kapitel 5.1.6 | Planung der Software-Verifizierung |
| Wie haben Sie vor Ihre Software zu verifizieren? Da die Verifizierung einen nicht unerheblichen Anteil der Entwicklung in Anspruch nimmt, muss dieses Vorgehen sehr genau geplant werden.
Definieren Sie, was alles zu erstellen ist, dies fängt bei der Testspezifikation an, geht über den Entwurf der Tests, über die Durchführen der Tests, bis zur Erstellung von Testreports. All das sind Ergebnisse der Verifizierungsaktivitäten, welche geplant werden müssen. Für diese Ergebnisse müssen Sie auch festlegen, wann sie Sie akzeptieren. Ein Akzeptanzkriterium für eine Testspezifikation wäre z.B.: Jede Anforderung muss mindestens einen Testfall besitzen und die festgelegten Testmethoden wurden angewendet. Definieren Sie was zu welchem Zeitpunkt verfügbar sein muss. Die Planung der Verifizierung ist eine sehr komplexe Aufgabe. Diese Tätigkeit wird typischerweise in einem Testplan oder in mehreren Testplänen (z.B. ein Testplan pro Level) definiert. Oft laufen diese planerischen Aktivitäten auch unter dem Begriff „Verifizierungsstrategie“ In so einer Verifizierungsstrategie können Sie sehr gut die hier geforderten Punkte beschreiben und klar aufzeigen wie Sie vorgehen. Einer Verifizierungsstrategie findet man auch häufig als Projekt übergreifende Beschreibung für alle Projekte. Eine eventuell notwendige Konkretisierung wird dann noch im jeweiligen Projekt vorgenommen. |
|
| Kapitel 5.1.7 | Planung des Software-Risikomanagements |
| Ähnlich dem vorherigen Kapitel „Planung der Software Verifizierung“ ist das Software Risikomanagement zu planen. Typischerweise verweist man hier auf den zu Grunde liegenden Risikomanagementprozess und auf den für das Projekt geltenden Risikomanagementplan.
Handelt es sich bei Ihrem Produkt um ein System mit embedded Software, so wird das Software Risikomanagement ein Teil des Risikomanagements Ihres Gesamtsystems sein. |
|
| Kapitel 5.1.8 | Planung der Dokumentation |
| Während der Entwicklung entsteht eine Vielzahl von Artefakten, welche nicht nur der Quellcode ist, sondern auch die dazugehörige Dokumentation.
Dies fängt bei der Software System Spezifikation an, geht weiter über die Software Architektur, Testspezifikationen, usw. Identifizieren Sie alle Dokumenttypen die entstehen und legen Sie fest:
|
|
| Kapitel 5.1.9 | Planung des Software-Konfigurationsmanagements |
| Das Konfigurationsmanagement ist eine sehr wichtige Aufgabe in den Projekten. Hierüber wird die eindeutige Zusammensetzung der Software eines Produktes sichergestellt.
Konfigurationselemente sind alle Softwaremodule bzw. Quellcodedateien sowie eingesetzte SOUP-Komponenten. Des Weiteren gelten alle Dokumente, die während der Software-Entwicklung bzw. –Wartung erstellt werden als Konfigurationselemente.
Beachten Sie den Aufwand der je nach gewählter Definition entsteht. Legen Sie die für Sie sinnvolle Vorgehensweise fest, ab wann der Problemlösungsprozess genutzt werden soll. |
|
| Kapitel 5.1.10 | Zu kontrollierende unterstützende Komponenten |
| Wie bereits in Kapitel 5.1.9 erwähnt, gehört nicht nur der Quellcode in eine Versionsverwaltung. Sie müssen auch jederzeit in der Lage sein, die genutzten Versionen Ihre Tools zu identifizieren, wie z.B. Compiler, Testframeworks oder ähnliches. Vergessen auch nicht die zugehörigen Konfigurationsdateien oder die make Files.
Alles was Sie benötigen, um einen Stand einer Software erneut zu bauen, gehört versioniert und kontrolliert. Nur so stellen Sie sicher, dass Sie zu jedem Zeitpunkt eine ganz bestimmte Softwareversion wieder erstellen können. Sie werden spätestens dann merken wie wichtig das Konfiguationsmanagement ist, wenn Sie Rückmeldungen aus dem Feld erhalten. Die Rückmeldungen müssen untersucht werden, die Ursache gefunden werden und von Ihnen wird eine klare Aussage verlangt, welche Software Versionen von dem möglichen Fehler betroffen sind. |
|
| Kapitel 5.1.11 | Kontrolle der Software-Konfigurationselemente vor der Verifizierung |
| Um eine reproduzierbare Verifizierung zu beginnen, müssen die entsprechenden Komponenten bereits versioniert sein und in die Versionsverwaltung eingepflegt sein. Nur so können Sie auf eine eindeutige Version referenzieren auf den sich die Verifizierung bezieht.
Pflegen Sie also die Komponenten zunächst in die Versionsverwaltung ein und geben Sie die entsprechenden Versionen in Ihren Testberichten an! Wie in den vorherigen Abschnitten erwähnt, ist damit nicht nur der Quellcode gemeint, sondern alles, was Sie benötigen um die Verifizierung reproduzierbar zu machen. Das beginnt bei der Spezifikation, geht weiter über die Testspezifikation, die verwendeten Tools, usw. Stellen Sie sich immer die Frage, ob Sie alles unter Kontrolle haben, um zu einem späteren Zeitpunkt genau diesen Test wieder durchzuführen und das gleiche Ergebnis zu erhalten. Erfassen Sie alle diese Informationen in Ihrem Testbericht! |
|
Ich hoffe, ich konnte Ihnen mit der Erläuterung der 11 Punkte aus der 62304 ein wenig helfen und für mehr Klarheit sorgen. Die Norm arbeitet immer darauf hin, von Beginn an Klarheit zu schaffen, um das Risiko von Fehlern, Lücken, usw. zu vermindern. Nehmen Sie den Software-Entwicklungsplan als Hilfsmittel, als Zielvorgabe im Projekt, um genau diese Planung übersichtlich und für alle Beteiligten verständlich aufzuzeigen und allen Beteiligten klar zu machen, was für Aktivitäten und Ergebnisse notwendig sind. Diskutieren Sie den Plan auch im Projektteam, dies hilft Ihnen wiederum das Wissen zu streuen und Widersprüchlichkeiten oder Lücken aufzuspüren. Viele Augen sehen mehr als zwei.
Falls Sie noch Fragen haben oder ergänzende Bemerkungen und Erfahrungen, lassen Sie es mich wissen. Auch hierfür gilt: Mehrere Personen wissen mehr als eine Person!
