Sie sind hier: HomeRubrikenSonstige

News, Produkte, Fachartikel zu Stromversorgungen, Batterien, Akkus, AC/DC-Wandler, DC/DC-Wandler, Energy Harvesting, Power Management, Wireless Power

Entwicklungsmethodik: Nutzerinteraktion im Fokus

Nach der Idee für ein neues Medizinprodukt steht laut Edison dann 99% Transpiration - also harte Arbeit. Steht die Interaktion der Nutzer mit dem Medizinprodukt im Fokus der Entwicklung, lässt sich die Wertschöpfung des Gerätes beträchtlich erhöhen. Zudem ist so eine bessere Kommunikation zwischen Auftraggeber und Requirements-Engineer, Interaktionsdesigner und Entwicklern gewährleistet. Dies ermöglicht eine schnellere und auch kostengünstigere Entwicklung, da späte Änderungen an grundlegenden Konzepten vermieden werden.

Mittelpunkt der im Folgenden beschriebenen Entwicklungsmethodik bildet eine kurze, aber extrem wertvolle Analysephase, um die Produktidee und Anforderungsspezifikation zu erarbeiten. Damit lässt sich dann die Produktidee schnell und konsequent umsetzen. Dabei ist die Anforderungsspezifikation keinesfalls ein notwendiges Übel, sondern vielmehr die Grundlage für Verträge mit Dienstleistern, Arbeitsanweisung für die Entwicklung und risikominimierend bei Ausfall oder Tausch von Know-how-Trägern. Zudem erlaubt eine Anforderungsspezifikation bereits die erste Validierung der Produktidee und beantwortet somit die Frage, ob überhaupt das richtige Produkt entwickelt werden soll.
In der ersten Phase wird die Idee hinter dem Medizinprodukt entwickelt. Dazu ist die Produktidee kurz und prägnant zu beschreiben. Dies kann in Form einer Zweckbestimmung erfolgen, wie sie für das Risikomanagement normativ vorgeschrieben ist. Zudem lassen sich jetzt erste Betrachtungen der regulatorischen Rahmenbedingungen durchführen, damit bekannt ist, welche Normen und Gesetze einzuhalten sind. Des Weiteren werden die Zielgruppen, die Anwendergruppen und der Kontext analysiert, in dem das Produkt zum Einsatz kommt. Diese Ergebnisse werden durch eine Kontextanalyse verifiziert, ergänzt oder falsifiziert. Die Ergebnisse aus der Kontextanalyse sind die Voraussetzung, um eine stringente Risikoanalyse durchführen zu können. Ein weiterer Punkt ist, bereits jetzt mit einer Literaturrecherche zu beginnen. Dies bewahrt davor, spät im Projekt festzustellen, dass eine klinische Studie erfolgen muss.
Parallel dazu erfolgt eine Wirtschaftlichkeitsbetrachtung. Ist die Wirtschaftlichkeit gegeben, kann die nächste Phase beginnen.
Ist die Produktidee aufgestellt, ist diese weiter auszuarbeiten. Dies hilft zum einen, den Umfang der Entwicklungsaktivitäten zu erfassen, und zum anderen ist die Dokumentation ein Vehikel zur Kommunikation mit dem Lieferanten, den Entwicklern und weiteren Interessengruppen. Die Anforderungen werden jedoch nicht nur in Textform, sondern auch als Diagramme oder »Wireframes« dokumentiert, abhängig davon, welche Dokumentationsform am schnellsten die Essenz der Anforderungen vermittelt. Wireframes sind konzeptuelle »Drahtrahmen«, die wichtige Bildschirmelemente darstellen, jedoch ohne Anspruch auf endgültiges Aussehen und Funktion. Die Interaktion mit dem Produkt ist aus diesen Wireframes erkennbar. Somit ergibt sich die Möglichkeit, die Hauptbedienfunktionen bereits jetzt, im Rahmen von formativen Usability-Tests, mit zukünftigen Nutzern auszuprobieren.
In der nun folgenden Phase entwickelt beispielsweise ein Dienstleister das Produkt auf der Grundlage der Anforderungsspezifikation des Auftraggebers. Jetzt entstehen die Architektur und das visuelle Design. Die Entwickler implementieren das Produkt und führen die notwendigen Tests durch. Durch die Anforderungsspezifikation kann der Dienstleister das Produkt effizient und qualitativ hochwertig entwickeln. Zum Abschluss wird das Produkt einem summativen Usability-Test unterzogen, um zu prüfen, ob das Produkt für die Nutzer tatsächlich gebrauchstauglich ist.

Die Produktidee entwickeln

Um diese Entwicklungsmethodik zu veranschaulichen, dient im Folgenden der Zahnarztstuhl »dentamatic« als Beispiel. Er soll eine Touch-Bedienoberfläche für integrierte Geräte wie Bohrer, Bewegung des Stuhls, Lampe, Wasser für den Patienten etc. besitzen.

Bild 1: So soll die Mensch-Maschine-Schnittstelle des Zahnarztstuhls »dentamatic« aussehen Bildquelle: © macio

Bild 1: So soll die Mensch-Maschine-Schnittstelle des Zahnarztstuhls »dentamatic« aussehen

Die Formulierung der Produktidee sollte nicht mehr als etwa zehn Sätze umfassen und drei bis fünf essenzielle Punkte des neuen Produktes herausstellen. Im Falle von »dentamatic« ist dies beispielsweise die intuitive Steuerung des Zahnarztstuhls mittels Touch-Display (Bild 1).
Im nächsten Schritt ist der regulatorische Rahmen für das Medizinprodukt festzulegen. Hier muss der Auftraggeber die Länder bestimmen, in denen er das Produkt verkaufen will. Dies ist eine Frage der Investitionskosten. Es gilt: je mehr Länder, desto mehr regulatorische Vorschriften, desto höher die Entwicklungskosten. Es ist nicht ratsam, die Entscheidung, welcher regulatorische Rahmen einzuhalten ist, auf einen späteren Zeitpunkt zu verschieben. Haben die Entwickler bestimmte Regularien nicht bereits während der gesamten Entwicklung berücksichtigt, kann eine Neuentwicklung für den Eintritt in einen neuen Markt erforderlich sein.
Als nächstes sind die Nutzergruppen und Patientengruppen des Produktes zu analysieren. Wer wird das Produkt bedienen? Wer wird von dem Medizinprodukt behandelt? In unserem Beispiel sind die Benutzer Zahnärzte und Zahnarzthelfer, wobei manche Funktion nur vom Zahnarzt (Bohrer) und andere auch von der Zahnarzthelferin benutzt werden (Steuerung des Stuhls). Die Patientengruppe ist sehr umfangreich: von Kleinkindern bis zu Rentnern, die sich in Größe, Gewicht und Beweglichkeit stark unterscheiden. Hier müssen Studien über die Größe und das Gewicht herangezogen werden, um auch Spezialfälle mit einzubeziehen.
Der Arbeitskontext ist im Fall des Zahnarztstuhls sehr klar definiert: in einer Zahnarztpraxis. Es gibt jedoch auch weitere Szenarien wie Feldlazarette oder Operationssäle, in denen andere Anforderungen an Hygiene und Beweglichkeit gestellt werden. Bei einem Blutzuckermessgerät ist der Kontext beispielsweise noch sehr viel breiter: Von der Wohnung des Patienten bis hin zur freien Natur, also von starker Sonneneinstrahlung bis hin zu schummrigem Licht. Dies beeinflusst beispielsweise die Leistungsfähigkeit und Steuerung des Displays stark. Während dieser Aktivitäten werden auch die wichtigsten Funktionen aus Sicht der Anwender analysiert, soweit dies ohne eine Kontextanalyse vor Ort möglich ist.
Aus den bisher beschriebenen Aktivitäten entsteht bereits die erste Fassung des Dokuments, das für die Konformitätserklärung beziehungsweise Zulassung wichtig ist: die Spezifikation der Anwendung nach IEC 62366. Darauf aufbauend lassen sich schon einmal grob Gefährdungen, Gefährdungssituationen und das Risiko analysieren. Somit können erste kritische Punkte identifiziert werden, die während der Kontextanalyse zu berücksichtigen sind. Diese Risikoanalyse erfolgt innerhalb eines interdisziplinären Teams, in dem Mediziner und Entwickler verschiedener Disziplinen unter Führung des Auftraggebers miteinander agieren.
Parallel hierzu analysiert der Auftraggeber die Wirtschaftlichkeit des Produktes und die Zielgruppe der Käufer. Bis zu diesem Punkt müssen alle Aktivitäten vom Auftraggeber geführt werden. Der Auftragnehmer kann den Auftraggeber jedoch sehr gut unterstützen und beraten. Für den Auftraggeber mag es auch sinnvoll sein, eine dritte Person seines Vertrauens hinzuzuziehen.
Aus den bisherigen Aktivitäten ergibt sich, ob der nächste Schritt stattfinden soll: Um die Zweckbestimmung, die Aufgaben der Anwender, ihren Kontext, die Patientengruppen und Anwendergruppen genau kennenzulernen, ist eine Kontextanalyse nötig. Dabei suchen Vertreter des Auftraggebers, und falls Unterstützung nötig ist auch Mitarbeiter des Auftragnehmers, gemeinsam den Einsatzort des zukünftigen Produktes auf und analysieren, welche Tätigkeiten die Nutzer ausführen und in welcher Umgebung das Produkt eingesetzt wird. Im Anschluss wird dann die Spezifikation der Anwendung aktualisiert.
Nun sind im besten Fall die Ergebnisse aus der Entwicklung der Produktidee bestätigt. Ist dies nicht der Fall, kann entweder eine Adaption erfolgen oder die Entwicklung des Produktes wird an dieser Stelle abgebrochen. Soll die Entwicklung fortgesetzt werden, muss jetzt auf Basis der Ergebnisse der Kontextanalyse die erste wirklich stringente Risikoanalyse erfolgen.

Die Anforderungsspezifikation erstellen

Bild 2: Mithilfe der Anforderungsspezifikation können Interaktionsdesigner ein erstes Bedienkonzept in Form von Wireframes erarbeiten Bildquelle: © macio

Bild 2: Mithilfe der Anforderungsspezifikation können Interaktionsdesigner ein erstes Bedienkonzept in Form von Wireframes erarbeiten

Ein zentraler Punkt in der Softwareentwicklung nach IEC 62304 ist die Anforderungsspezifikation (Bild 2, links). An sie sind alle anderen Aktivitäten geknüpft. Abgesehen von der Zulassung, spielt sie aber auch eine wesentliche Rolle für die erfolgreiche Produktentwicklung und dient zudem als gemeinsame Arbeitsgrundlage für Hersteller und Dienstleister. Kurz gesagt, die Anforderungsspezifikation soll helfen und nicht aufhalten. Um diese Funktion auszufüllen, muss sie also für Produktmanager, Architekten, Entwickler und Tester gleichermaßen verständlich geschrieben sein. Ein generiertes Enterprise-Architekt-Dokument etwa mag zwar den regulatorischen Anforderungen genügen, ist aber ohne entsprechende Anpassungen des Templates nicht ausreichend lesbar. Vielmehr sind Handarbeit und ein guter Aufbau in Kombination mit Visualisierungen des Beschriebenen gefragt.
Auf Basis der Ergebnisse aus der ersten Phase und in enger Zusammenarbeit mit Produktmanagern und Nutzern, erarbeitet der Interaktionsdesigner ein erstes Bedienkonzept und stellt es in Form von Wireframes dar. Sind die wesentlichen Anwendungsfälle abgedeckt, lässt sich das richtige Verständnis für die Problemstellung und die Tragfähigkeit der angedachten Lösung bereits jetzt validieren. Durch Korrekturzyklen kann in der Regel schnell ein gutes Ergebnis erzielt werden.
Im Folgenden gilt es, detaillierter zu werden. Für die funktionalen Anforderungen bietet es sich an, Wireframe für Wireframe vorzugehen. Konkret bedeutet das, ein Wireframe zu Beginn eines Kapitels in die Spezifikation aufzunehmen und im Folgenden die Funktion dieses Wireframes mit Hilfe von Anforderungen zu beschreiben (Bild 2, Mitte und rechts). In komplexeren Fällen lassen sich Teile eines Wireframes einzeln beschreiben und später zu einem ganzen Screen zusammensetzen. Das ist besonders dann hilfreich, wenn diese Teile an verschiedenen Stellen wiederholt zum Einsatz kommen.

Das Produkt entwickeln

Eine eindeutige Nummerierung jeder einzelnen Anforderung ist selbstverständlich. Nicht nur für die Traceability, sondern um sich in der nachfolgenden Diskussion klar auf eine Anforderung beziehen und einzelne Punkte als freigegeben markieren zu können. Ein Interaktionsdesigner mit Requirements-Engineering Hintergrund kann die funktionalen Anforderungen oft sehr gut beschreiben. Technische, nicht-funktionale Anforderungen sollte ein Entwickler aufnehmen und im Dokument ergänzen. Bei dieser Rollenverteilung werden die Ideen vom Reißbrett des Interaktionsdesigners direkt auf technische Machbarkeit geprüft und wichtige Fragen geklärt.
Ein so gestaltetes Dokument kann vom Produktmanagement verstanden und freigegeben werden. Es dient dem Architekten und Entwickler als klar definierte Aufgabenbeschreibung und liefert dem Tester unverzichtbaren Input für seine Arbeit. Es senkt somit direkt die Kosten für unnötige Korrekturschleifen, bereits in einer frühen Phase der Entwicklung. Durch die Verwendung von Wireframes ist es außerdem der kürzeste Weg zur Entwicklung und bietet die Chance, den weiteren Weg aktiv zu gestalten.

Bild 3: Durch ein gutes Requirements-Engineering und Wireframes können Arbeitsschritte des Designs und der Architektur parallel bearbeitet werden Bildquelle: © macio

Bild 3: Durch ein gutes Requirements-Engineering und Wireframes können Arbeitsschritte des Designs und der Architektur parallel bearbeitet werden

Mit dem vorliegenden Bedienkonzept, den Wire-frames und den Anforderungen lässt sich bereits ein umfangreicher Klick-Dummy oder Prototyp erstellen, mit dessen Hilfe sich die angestrebte Lösung in tatsächlichen Nutzungsszenarien validieren lässt.
Alternativ oder nach einer solchen Studie können die nun folgenden Arbeitsschritte des Designs und der Architektur parallel bearbeitet werden (
Bild 3). Zum Ende der Designphase steht so bereits die wesentliche Softwarearchitektur und beides lässt sich sofort umsetzen. Auch die beste Anforderungsspezifikation kann nicht alle Fragen beantworten, die im Laufe der Umsetzung aufkommen. Lässt man das Entwicklungsteam mit diesen Fragen alleine, können eigenwillige und technisch geprägte Lösungen die Folge sein. Deshalb ist auch während der Umsetzung eine Begleitung durch den Interaktionsdesigner und Requirements-Engineer sinnvoll. Sie stellen sicher, dass Ideen richtig verstanden und umgesetzt werden, und können bei Konflikten zu konzeptkonformen Lösungen beitragen.

Über die Autoren:

Michael Engler ist freier Berater für Requirements und Usability Engineering sowie agile Methoden und Oliver Niemann ist Projektleiter bei macio.