Best Practices

Ziel des Projekts PQ4Agile ist es, agilen Entwicklern mit erprobten Best Practices eine möglichst effiziente und systematische Unterstützung bei der Erreichung nichtfunktionaler Qualitätsmerkmale zu bieten. Die Sammlung umfasst Best Practices aus den Bereichen Requirements Engineering, Softwarearchitektur, Usability/User Experience und Testen sowie unterstützende Praktiken. Alle beschriebenen Methoden und Aktivitäten können von den Mitgliedern eines agilen Teams flexibel und nach Bedarf eingesetzt und leicht in agile Entwicklungsprozesse integriert werden.

Best-Practice-Kompendium (42 PDF-Dateien) downloaden:
PQ4Agile – AP 2.2 – Best-Practice-Kompendium

Best Practices – Requirements Engineering

Produktvision erstellen

Eine überzeugende Produktvision gibt dem Team ein klares Ziel vor, das von allen Mitgliedern geteilt wird. Sie zeigt die Richtung auf, die eingeschlagen werden muss, um dieses Ziel zu erreichen, und leitet das selbstorganisierte Team auf seinem Weg dorthin an. Zugleich lässt sie genug Freiraum, damit sich die Mitglieder kreativ in das Projekt einbringen können. Die Produktvision motiviert und inspiriert das Entwicklungsteam, sie begeistert aber auch die übrigen Beteiligten (z. B. Auftraggeber, Kundenvertreter, Marketing und Vertrieb) für das Produkt und schafft die Grundlage für eine wirkungsvolle Produktstrategie.

[collapse]
Systemkontext und -umfang festlegen

Die Festlegung des Systemkontexts und -umfangs erfolgt zu Beginn eines neuen Projekts bzw. sobald ein Projekt vorgeschlagen wurde, also noch vor dem ersten Sprint eines agilen Entwicklungsprozesses. In Gesprächen mit Vertretern des Auftraggebers (auch Vorgesetzte innerhalb des eigenen Unternehmens) wird über die Projektmotivation, die Projektziele, die Unternehmensziele, die zu unterstützenden Stakeholder, Projekteinschränkungen (z.B. Zeit, Budget, Mitarbeiter) und technische Einschränkungen (z.B. Rechenkapazität, Entwicklungsumgebungen) gesprochen und die jeweiligen Anforderungen erhoben. Somit wird bereits zu Beginn eines Projekts sichergestellt, dass die fachliche Einsatzumgebung des zu entwickelnden Systems und dessen funktionaler Umfang feststehen sowie die für die Umsetzung der dafür relevanten Anforderungen benötigten Kosten und Zeit geschätzt wurden.

[collapse]
Product Canvas erstellen

Das Product Canvas ist ein visuelles Produktplanungstool, das in leicht verständlicher und strukturierter Form die wichtigsten Informationen zusammenfasst, die bei der Entwicklung eines neuen Produkts benötigt werden. Es enthält Angaben zu den Benutzern bzw. den Kunden und ihren Bedürfnissen, zum Big Picture (Features, UI-Design und Benutzerinteraktion) sowie zu den aktuell wichtigen Produktdetails. Das Product Canvas soll dabei helfen, Ideen und Annahmen über ein Produkt zu erfassen, zu kommunizieren und zu überprüfen, Feedback zu adaptieren und Änderungen sichtbar zu machen. Es stellt den jeweils aktuellen Stand des Produktentwicklungsprozesses übersichtlich auf einer Seite dar. Dadurch ist es jedem an der Entwicklung Beteiligten möglich, die zentralen Aspekte des Produkts schnell zu erfassen und sich jederzeit über den aktuellen Zustand des Planungsprozesses zu informieren.

[collapse]
Aufwand für die Anforderungsentwicklung bestimmen

Hochwertige Anforderungen sorgen für reduzierte Entwicklungsaufwände und für eine höhere Produktqualität. Vor allem bei der Entwicklung komplexer Produkte und Systeme sind daher Aktivitäten zur systematischen Ermittlung, Prüfung, Dokumentation und Abstimmung von Anforderungen notwendig. Die Rahmenbedingungen und bestimmte Einflussfaktoren eines Projektes geben Auskunft darüber, in welchem Umfang Tätigkeiten für die Anforderungsentwicklung eingeplant und durchgeführt werden sollten.

[collapse]
Funktionale Anforderungen erheben

Bei der Erhebung der funktionalen Anforderungen wird ermittelt, was ein Produkt aus Sicht der Stakeholder leisten können soll (in Bezug auf systeminterne Funktionen und Benutzerinteraktionen). Um diese Anforderungen vollständig zu ermitteln, können verschiedene Erhebungstechniken eingesetzt bzw. miteinander kombiniert werden.

[collapse]
Nichtfunktionale Anforderungen erheben

Bei der Erhebung der nichtfunktionalen Anforderungen wird ermittelt, welche Qualitätseigenschaften ein Produkt bzw. die von ihm bereitgestellten Dienste aus Sicht der Stakeholder haben sollen. Um diese Anforderungen vollständig zu ermitteln, können verschiedene Erhebungstechniken eingesetzt bzw. miteinander kombiniert werden.

[collapse]
Anforderungen wiederverwenden

Neue Projekte haben oft eine große Ähnlichkeit mit vergangenen Projekten oder sie setzen direkt auf Vorgängerprojekten auf. Die Anforderungen, die im Rahmen dieser Projekte erhoben und dokumentiert wurden, werden bei dieser Aktivität vollständig oder teilweise übernommen, anschließend geprüft und bei Bedarf angepasst.

[collapse]
Anforderungen mit Hilfe von Prototypen erheben

Um die aufgeführten Ziele zu erreichen, kann ein Prototyping Prozess durchgeführt werden, der aus drei Phasen besteht: zunächst wird ein geeigneter Prototyp konzipiert, dieses Konzept wird in der zweiten Phase implementiert und schließlich in der dritten Phase durch Stakeholder evaluiert. Diese drei Phasen werden iterativ durchlaufen. Somit wird ermöglicht, dass kontinuierlich bestimmte Mengen von Anforderungen erhoben, diskutiert, verfeinert und evaluiert werden, bis schließlich das Gesamtbild der Art und Weise, wie welche Anforderungen umgesetzt werden sollen, vervollständigt wird.

[collapse]
Experimentelles und exploratives Prototyping durchführen

Experimentelle und explorative Prototypen dienen der Veranschaulichung komplexer Sachverhalte innerhalb eines Systems. Sie helfen, vor allem funktionale Anforderungen zu erkennen und deren Ausprägung frühzeitig zu beurteilen. Anhand von Prototypen können technische Sachverhalte und Lösungsansätze erläutert (Experimentelles Prototyping) oder Lösungsmöglichkeiten demonstriert werden (Exploratives Prototyping).

[collapse]
Systematisch vom Groben ins Feine vorgehen

Die unterschiedlichen Sichten verschiedener Stakeholder auf Anforderungen für eine Software-Anwendung müssen während der Anforderungserhebung kontinuierlich verfeinert werden. Dadurch entsteht das Big Picture der unterschiedlichen Anforderungen, die Anforderungen der verschiedenen Stakeholder werden berücksichtigt und Anforderungen liegen so detailliert vor, dass von ihnen Systemanforderungen abgeleitet werden und sie in Programmcode umgesetzt werden können. Dafür sind verschiedene Entscheidungen zu treffen und Systemaspekte zu diskutieren bzw. zu spezifizieren.

[collapse]
Anforderungen reviewen

Bei einem Review von Anforderungen diskutieren mehrere Stakeholder oder Anforderungskonsumenten aus nachgelagerten Entwicklungsaktivitäten über die bereits erhobenen und spezifizierten Anforderungen und deren potentielle Mängel. Dabei gehen sie systematisch vor und wenden die Review-Technik der Inspektion an. Diskutiert wird, welche der identifizierten potentiellen Mängel tatsächliche Mängel sind, die behoben werden müssen. Erst wenn die erhobenen und spezifizierten Anforderungen keine Mängel mehr aufweisen und somit qualitativ hochwertig sind, werden sie zur weiteren Verwendung im Softwareentwicklungsprozess freigegeben.

[collapse]
Kundenanforderungen dokumentieren

Funktionale Anforderungen und Qualitätsanforderungen werden in Gesprächen mit dem Kunden strukturiert erfasst. Der Kunde ist jeder beliebige Anforderungssteller; er kann sowohl der Auftraggeber einer Software als auch der Endkunde (Anwender) selbst sein.

[collapse]
Begründungen für Anforderungen dokumentieren

Da in der agilen Entwicklung ohnehin Anforderungen mit Hilfe von Satzschablonen erfasst werden, bietet es sich an, in diesen Satzschablonen den Begründungen der Anforderungen besondere Aufmerksamkeit zukommen zu lassen. Bisher benutzte User Story-Schablonen sehen die Angabe einer Begründung bereits vor, liefern aber nur unmittelbare Begründungen, die ohne Kontext nicht unbedingt verständlich sind. Oft handelt es sich bei den Begründungen nur um Wünsche, nicht aber um deutliche Gründe, die auf eine echte Anforderung schließen lassen. Es sollte daher eine erweiterte User Story-Schablone verwendet werden, die Kontextinformationen integriert, die Begründungen für Begründungen liefern, also den Wunsch in einen bestimmten Kontext stellen und somit nachvollziehbar werden lassen, warum er geäußert wird.

[collapse]
Soll-Ist-Vergleich durchführen

Durch einen Vergleich des vorhandenen Systems bzw. des aktuell durchgeführten Prozesses mit dem durch die Menge der Anforderungen beschriebenen zu entwickelnden System, lässt sich die Menge der umzusetzenden Anforderungen ermitteln. Dadurch wird sowohl vermieden, dass positive Aspekte des aktuellen Systems bzw. Prozesses im zukünftigen System nicht mehr berücksichtigt werden als auch, dass im zukünftigen System Anforderungen umgesetzt werden, die sich im aktuellen System bzw. Prozess als wenig sinnvoll erwiesen haben.

[collapse]
Aufwand für das Anforderungsmanagement bestimmen

Anforderungen werden nach der Erhebung weiterverwendet und sie ändern sich im Laufe eines Projektes. Vor allem bei der Entwicklung komplexer Produkte und Systeme sind daher Aktivitäten zur systematischen Steuerung, Kontrolle und Verwaltung der erhobenen Anforderungen notwendig. Die Rahmenbedingungen und bestimmte Einflussfaktoren eines Projektes geben Auskunft darüber, in welchem Umfang Tätigkeiten für das Requirements Management eingeplant bzw. durchgeführt werden sollten.

[collapse]
Kundenanforderungen in technische Anforderungen übertragen

Der Anforderungskatalog wird in Anwendungsfälle (Use Cases) mit klarem Anfangs- und Endzustand unterteilt und mit funktionalen Merkmalen, Qualitätsmerkmalen und Randbedingungen versehen.

[collapse]
Entwickleranforderungen dokumentieren

Die Kunden-Anforderungen werden in technische Anforderungen übertragen, sodass definierte, klar strukturierte, zeitlich kleine Arbeitspakete (Tasks, Tickets) entstehen, die in ein Ticket-System eingepflegt und im Rahmen eines agilen Entwicklungsprozesses abgearbeitet werden können.

[collapse]
Anforderungen kontinuierlich priorisieren

Eine Priorisierung der Menge der initial erhobenen Anforderungen bringt die Anforderungen in eine absteigende Reihenfolgegemäß ihrer Wichtigkeit. Sie legt somit die Relevanz der einzelnen Anforderungen fest und impliziert letztendlich die Reihenfolge ihrer Umsetzung. Durch die kontinuierliche Priorisierung von Anforderungen in jedem Sprint wird ersichtlich, wie relevant die Anforderungen für einzelne Stakeholder sind. Mit diesen Anforderungen kann anschließend weiter gearbeitet werden. Man stellt somit schon früh fest, auf welche Anforderungen man sich im Entwicklungsprojekt am stärksten konzentrieren sollte, um die späteren Nutzer zufrieden zu stellen.

[collapse]
Viele Augen sehen mehr

Diese Best-Practice sieht vor, in kurz gehaltenen Gesprächsrunden mit intensivem Workshop-Charakter unter Beteiligung einer heterogenen Personengruppe Anforderungen der Software zu beleuchten und deren Beschreibung zu vervollständigen. Neben Spezialisten, die die Facette einer Anforderung besonders gut überblicken, werden auch Personen aus Randgebieten eingebunden. Die Workshops sollten nicht länger als eine Stunde in Anspruch nehmen, dafür aber so oft wiederholt werden, bis ein zufriedenstellendes Ergebnis erzielt wurde. Wichtig ist, dass ein offenes Gesprächsklima gepflegt wird, damit auch Randaspekte zu ihrem Recht kommen, die sonst unberücksichtigt bleiben würden. Unter diesen Voraussetzungen werden Risiken frühzeitig benannt, der Qualitätsgedanke im Allgemeinen hochgehalten; man zeigt früh Interesse an der Wiederverwendbarkeit, der Generalisierung und Verständlichkeit der Lösung. Ausschlaggebend für den erfolgreichen Einsatz dieses Best-Practice ist die Kombination einfacher und bewährter Mittel, die für sich genommen trivial erscheinen, aber im Zusammenspiel Entscheidendes erreichen. Wichtig ist also, dass die Meetings kurz gehalten, gut vorbereitet und zeitnah nachbearbeitet werden und dass der Personenkreis viele Interessen und Sichtweisen abdeckt, um eine möglichst vollständige Erfassung sämtlicher Aspekte der Spezifikation zu erreichen.

[collapse]
Projekttag durchführen

Ein Projekttag sieht die Abspaltung eines sich für einen Tag formierenden und auf wenige Personen (in der Regel 2 bis 4) beschränkten SCRUM-Teams vor, welches unter allen Umständen ungestört gemeinsam an einem vorab festgelegten Aufgabenbereich arbeiten darf. Den Tagesablauf können die Beteiligten frei bestimmen; vorgegeben sind lediglich zwei Abstimmungsmeetings am Anfang und Ende.

[collapse]

Best Practices – Softwarearchitektur

Architekturentscheidungen dokumentieren

Mit der Aufnahme von Dokumentation in die Definition of Done und der Bestimmung eines Verantwortlichen für Dokumentation kann eine Zunahme von Dokumentation im Projekt erreicht werden. Das gesamte Team erstellt Dokumentation, indem nach einer Konzeptentwicklung die wichtigsten Entscheidungen, Whiteboarddiagramme und einige Stichpunkte als Erklärung festgehalten werden. Abgelegt werden die Informationen bei der jeweiligen Aufgabe in dem Taskmanagement-Werkzeug mit dem das Team ohnehin bereits arbeitet. Optimalerweise wird dies direkt nach der Erarbeitung eines Konzepts, spätestens aber vor dem Iterationsende erledigt.

[collapse]
Architekturlösungen im Team entwickeln

Die Auswahl einer User-Story oder eines Epics zur Bearbeitung, welches ein umfassendes Konzept benötigt oder das Auftreten neuer Anforderungen, deren Lösung noch unklar ist, sind typische Startpunkte für den Einsatz dieser Best Practice. Fragestellungen wie Synchronisation von Offline-Daten, Backup-Strategie oder Sicherstellung von Hochverfügbarkeit sind Beispiele. Die Erarbeitung einer Architekturlösung wird als explizite Aufgabe in der Iteration eingeplant. Dabei übernimmt ein Entwickler die Verantwortung für die Ausarbeitung der Architekturlösung, bezieht aber andere Entwickler oder das gesamte Entwicklungsteam mit ein. Eine Aufgabenstellung wird dabei in Teilaufgaben unterteilt, offene Fragestellungen identifiziert, Aufgaben verteilt und von verschiedenen Entwicklern ausgearbeitet. Der Konzept-Verantwortliche übernimmt die Organisation und Konsolidierung. Das Konzept wird so lange diskutiert und weiterentwickelt, bis es sich zur direkten Umsetzung eignet.

[collapse]
Einfache, aber konsistente Diagramme erstellen und verwenden

Zur Beschreibung grundsätzlicher Aspekte des Systems oder spezifischer Konzepte können Entwickler Diagramme erstellen. Dies ist sowohl während der Erarbeitung von Lösungskonzepten als auch im Nachgang zur weiteren Verwendung während der Umsetzung sinnvoll. Damit Diagramme einen Mehrwert liefern, sollten Sie so gestaltet sein, dass sie den Konsumenten effizientes Arbeiten erlauben. Dafür sollten die Diagramme einen geringen Grad an Komplexität aufweisen und möglichst konsistent sein, das heißt grundsätzliche Prinzipien der Diagrammgestaltung sollten berücksichtigt und einheitliche Diagrammtypen und Notationen verwendet werden.

[collapse]
Feature-Entwicklung und interne Qualitätsarbeiten verzahnen

Die Kernidee dieser Best Practice ist es, nicht den kompletten Entwicklungs-Aufwand in die Realisierung von Features zu stecken, sondern einen gewissen Teil auch zur Bewahrung der internen Produktqualität zu investieren. Die genaue Verteilung muss das Team einmalig festlegen. Während der Entwicklung sammelt das Team Indikatoren für Qualitäts-Defizite, die bei der Realisierung eines Features aufgefallen sind. Bei der Planung der Aufgaben für die nächste Iteration (hier als Iteration n bezeichnet) werden die gefundenen Indikatoren für Qualitäts-Defizite im Team analysiert und der durch das Defizit potentiell entstehende Schaden bewertet. Aus den hoch priorisierten Indikatoren für Qualitäts-Defizite werden Aufgaben abgeleitet, die dazu dienen, Konzepte zu erarbeiten, die diese Defizite beheben. Das können zum einen neue Konzepte sein, die ein Konzept ersetzen, das in einer bestehenden Realisierung verwendet wurde, aber dessen Qualität als nicht mehr ausreichend erachtet wird. Trotz sorgfältiger Arbeit gibt es immer wieder solche Stellen im Produkt, die entweder unter Zeitdruck entstehen mussten, oder die im Lichte neuer Erkenntnisse als nicht mehr geeignet erachtet werden. Weiterhin kann auch die Vereinheitlichung von mehreren ähnlichen Konzepten angestrebt werden. In dieser Iteration n werden im Team diese geplanten Konzeptionierungsaufgaben erledigt. Das Ergebnis daraus ist eine Menge an Realisierungsaufgaben, die der Umsetzung von Lösungsansätzen der gesammelten Qualitäts-Defizite dient. In der nächsten Iteration (hier als Iteration n+1 bezeichnet) liegen damit für die hoch priorisierten Indikatoren für Qualitäts-Defizite sowohl Lösungskonzepte als auch konkrete Aufgaben vor. Während der Planung der nächsten Iteration n+1 wird nun das interne Qualitätsbudget zu einem großen Teil mit der Realisierung dieser Aufgaben belegt, im anderen Teil werden Lösungen für neue Refactoring-Wünsche konzipiert, die dann wieder in Iteration n+2 umgesetzt werden. Die genaue Verteilung muss das Team einmalig festlegen. Somit werden in jeder Iteration sowohl neue Konzepte erstellt als auch umgesetzt. Insgesamt findet somit kontinuierlich eine Investition in die interne Qualität und die Infrastruktur innerhalb der Software statt. Beispielsweise könnte ein Indikator für ein internes Qualitätsproblem sein, dass während der Umsetzung eines neuen Features zwar eine Ähnlichkeit zur Realisierung mehrerer anderer Features erkannt wird, die dabei verwendeten Architektur-Konzepte jedoch voneinander abweichen. Um die Wartbarkeit und Erweiterbarkeit zu erhöhen wird hier ein gemeinsames Architektur-Konzept erarbeitet und umgesetzt, das alle Features konsistent umsetzt und dabei gemeinsame Bestandteile verwendet.

[collapse]
Grob- und Detailplanung bei der Implementierung nutzen

Ziel der Praktik ist es die geplante Architektur so bald als möglich sichtbar machen. Dabei wird eine gemeinsame Sprache verwendet, die im gesamten Team die gleiche Semantik hat, um Missverständnisse zu vermeiden. Generell werden zwei Arten von Architekturdokumentationen benutzt: Eine abstraktere, die langfristige Architekturentscheidungen zueinander in Bezug setzt und zeigt, wie das Produkt die nächsten Blöcke an Anforderungen umsetzen soll. Weiterhin wird ein detailreicherer Ausschnitt dargestellt, der die genauere Ziel-Architektur und damit das Design der aktuellen Iteration dokumentiert. Bei beiden wird zu mehr Details und anderen Artefakten verwiesen. Dies sind beispielsweise Anforderungen, die durch ein Architektur-Konzept umgesetzt werden sollen, oder auch konkrete Entwicklungstasks, die ein Ausschnitt der Architektur realisieren. Hierbei wird von folgender gängiger Praxis ausgegangen: Zu den Anforderungen des Produktes werden durch das Team Entwicklungstasks definiert, die diese Anforderungen umsetzen. Diese Entwicklungstasks werden in Iterationen durch das Team umgesetzt, wobei anhand dieser Aufgaben eine Koordination der Entwicklung stattfindet. Dazu sind Tasks eindeutig bezeichnet und werden während ihrer Bearbeitung eindeutig Personen zugeordnet. Sowohl die Grob-Architektur als auch das Design sollen verständlich für alle Team-Mitglieder dokumentiert werden. Hierbei ist eine immer präsente Dokumentationsform vorzuziehen. Diese kann direkt im Blickfeld des Teams untergebracht werden. Dies kann beispielsweise ein großes Diagramm am Whiteboard oder Flipchart sein, oder ein großformatiger Ausdruck. Dabei sollen diese Diagramme immer auch vom Schreibtisch aus lesbar sein, die Größe soll nicht dazu dienen sehr viele Details unterzubringen.

[collapse]
Kontinuierliche Architekturbewertung durchführen

Die Eignung eines Lösungskonzeptes für die Erfüllung von bestimmten Anforderungen soll geprüft werden. Zusätzlich zu diesen können noch weitere, wichtige Anforderungen ausgewählt werden, deren Erfüllung bei der Realisierung des neuen Konzeptes bewahrt bleiben soll. Ein Teammitglied wird als Assessor ausgewählt, der die Architekturbewertung durchführt. Dieser befragt ausgewählte Mitglieder des Teams über die Lösungen, die die gewählten Anforderungen erfüllen sollen. Dabei versucht er offene Punkte, Inkonsistenzen und Verbesserungspotentiale herauszufinden. Für diese werden Vorschläge für Stories erstellt, die diskutiert und bei Bedarf in das Backlog eingeplant werden.

[collapse]

Best Practices – Usability / User Experience

Produktphilosophie erstellen

Die Best Practice „Produktphilosophie erstellen“ unterstützt die Definition und Bewertung von Faktoren der User Experience einer Softwareanwendung. Sie wird im Rahmen agiler Projekte hauptsächlich zur Entscheidungsunterstützung bzw. Priorisierung durch das Team und als Kommunikationsmedium zwischen involvierten Stakeholdern verwendet. Dabei wird insbesondere der Trade-off zwischen funktionalen Features und User-Experience-Features aufgelöst. Je nach Softwaretyp gibt es verschiedenen Vorlagen (sog. Templates), die verwendet werden können. Abbildung 1 zeigt das Mobile Template der Produktphilosophie, bei dem es vordefinierte Attribute gibt, auf die man sich in den ersten Sprints einigt. Dahinter steckt jeweils eine Erklärung der Bewertung bzw. die Unterstützung durch Beispiele. Die Wertepaare und die Bewertung geben hierbei an, welchen Eindruck die Software vermittelt bzw. vermitteln soll. Beispielsweise besagt die Produktphilosophie in Abbildung 1, dass das zu entwickelnde Produkt einem individuellen Look & Feel folgen soll. Dies bedeutet, dass es bei Entscheidungen hinsichtlich des Interaktionskonzepts und der Benutzeroberfläche eher ein individuelles Look & Feel (z.B. Company CI/Guidelines) verfolgt werden, anstatt Standards der Plattformen zu benutzen. Der Entwickler erhält durch die jeweilige Ausprägung eine Idee, in welchem Maße die genannten Aspekte zu berücksichtigen sind. Darüber hinaus fällt es ihm leichter, Designentscheidungen zu rechtfertigen, da er sich auf die Vorgabe auf der Produktphilosophie beziehen kann. Die Best Practice „Produktphilosophie erstellen“ verbessert die Kommunikation zwischen UI-Verantwortlichen, Vertrieb und Entwicklern. Insbesondere unterstützt sie Entwicklerteams bei kontinuierlicher Anwendung dabei, systematisch eine spezifische User Experience in das fertige Produkt zu „injizieren“. Um dies zu erreichen, können z. B. einzelne User Stories auf die Attribute gemappt werden. Einen besonderen Nutzen erzielen Unternehmen, wenn sie die vorhandenen Templates vor der Verwendung auf ihre konkreten Bedürfnisse anpassen. Verschiedene Templates, die den unterschiedlichen Anwendungsarten (z. B. Mobile, Security, Software Renovation) gerecht werden, stehen zur Auswahl.

[collapse]
Kontextuelles Benutzerinterview durchführen

Beim kontextuellen Benutzerinterview (engl. Contextual inquiry) werden detaillierte Informationen erhoben, auf welche Art der Anwender bestimmte Arbeitsprozesse durchführt und welcher Hilfsmittel er sich hierbei bedient. Das kontextuelle Benutzerinterview verbindet ein halbstrukturiertes Interview mit einer teilnehmenden Beobachtung des Anwenders im natürlichen Anwendungskontext.

[collapse]
Informationsarchitektur erstellen

Die Erstellung der Informationsarchitektur umfasst mehrere Aspekte. Sie befasst sich mit der Benennung, Aufteilung und Strukturierung der Inhalte, der Navigation durch diese und der Suche. Anhand der gegebenen Anforderungen werden die Inhalte strukturiert und benannt. Zur Strukturierung (Kategorisierung/Gruppierung) der Inhalte und festlegen der Navigationswege können beispielsweise Techniken wie Card Sorting verwendet werden. Die Festlegung klarer Navigationswege durch die Software ist ein entscheidender Punkt. Eine schlechte Navigation reduziert die Effizienz mit der eine Software genutzt werden kann. In einem weiteren Schritt werden die Inhalte organisiert, d.h. es wird festgelegt, welche Informationen an welcher Stelle gezeigt werden.

[collapse]
Template-basierte UI Konzeption durchführen

Bei der template-basierten UI-Gestaltung geht es um die Erstellung und Verwendung von Vorlagen zur Gestaltung der Benutzeroberfläche. Diese Vorlagen definieren das Grundgerüst einer Anwendung durch instanziierbare UI-Elemente (z.B. Schaltflächen, Tabellen, Header, Navigationsmenüs), die innerhalb der Anwendung zum Einsatz kommen. Eine hierarchische Struktur dieser Elemente wird dabei festgelegt, um zum einen die Zuordnung einzelner Elemente zu übergeordneten Elementen zu kennen, zum anderen die Einflüsse von Änderungen bestimmter Elemente auf untergeordnete, von ihnen abhängige Elemente von vornherein festzulegen und zu kennen. Weiterhin werden sämtliche Attribute jedes einzelnen Elements spezifiziert, um bei deren Implementierung keine unterspezifizierten oder nichtspezifizierten Aspekte auftreten zu lassen. Einzelne Dialoge der entwickelten Anwendung werden unter (ausschließlicher)Verwendung dieser Vorlagen gestaltet. Ähnlich einem Styleguide werden somit die Elemente für ein einzelnes Projekt, eine Produktlinie oder das gesamte Unternehmen spezifiziert. Durch die Verwendung von gleichen Identifikatoren in UI-Template und Source Code kann zusätzlich zur Erstellung konsistenter Prototypen, auch die Nachverfolgbarkeit von prototypisch instanziierten UI-Elementen zu ausführbarem Code ermöglicht werden.

[collapse]
Usability-Patterns verwenden

Usability-Patterns sind bewährte Lösungsmuster für typische Gestaltungs- bzw. Interaktionsprobleme, die in bestimmten Nutzungskontexten auftreten. Sie können beim Entwurf oder der Entwicklung von Software eingesetzt werden. Usability-Patterns sind in strukturierter, relativ abstrakter Form beschrieben. Sie ermöglichen es, die für ein Produkt relevanten Usability-Merkmale bereits in frühen Phasen der Produktentwicklung und ohne weitere Usability-Expertise systematisch zu betrachten und besser zu berücksichtigen.

[collapse]
Usability-Review durchführen

Beim Usability-Review wird eine Repräsentation der Benutzerschnittstelle (z. B. Designkonzept, Prototyp oder fertige Software) anhand zuvor definierter Szenarios und Usabilityprinzipien untersucht. Hierzu versetzt sich der Gutachter in die Lage des späteren Benutzers, um mögliche Schwierigkeiten bei der Bedienung aufzudecken. Das Usability-Review kombiniert die beiden Inspektionsmethoden Cognitive Walkthrough und Heuristische Evaluierung.

[collapse]
Severity Rating durchführen

Grundlage des Severity Ratings ist ein Usability Walkthrough. Beim Usability Walktrough handelt es sich um eine Expertenevaluation der Gebrauchstauglichkeit, welche an einem fertigen Produkt aber auch schon an Prototypen angewendet werden kann. Grundsätzlich kann die Methode auch ohne die dedizierten Benutzer durchgeführt werden, jedoch kann das Ergebnis verbessert werden, indem repräsentative Benutzer an der Evaluation teilnehmen. Im Allgemeinen ist ein Usability Walkthrough ein angeleitetes Vorgehen, um sich in dedizierte Benutzer hineinzuversetzen oder die Gedanken dieser während der Interaktion mit der Software zu erfassen. Ziel ist es, so viele Usability Issues wie möglich aufzudecken. Unter den Begriff Usability Issue fallen sämtliche Auffälligkeiten der Benutzungsschnittstelle, welche die Usability negativ beeinflussen können. Um so viele Usability Issues wie möglich aufzudecken ist es wichtig, dass die Teilnehmer explorativ die Funktionalität der zu evaluierenden Benutzungsschnittstelle erfahren. Dabei wird die komplette Benutzungsschnittstelle in Betracht gezogen und nicht nur die zur Erfüllung der Aufgabe notwendigen Ausschnitte. Prinzipiell kann ein Usability Walkthrough während des gesamten Software Entwicklungszyklus angewendet werden. Nachdem der Usability Walkthrough durchgeführt wurde, werden die gefundenen Usability Issues von Usability Experten intern reflektiert und je nach Kritikalität bewertet und jeweils eine mögliche Behebung der einzelnen Usability Issues vorgeschlagen.

[collapse]
Usability-Test durchführen

Beim Usability-Test bearbeitet eine Gruppe Testpersonen in einem bestimmten Zeit-raum eine Auswahl typischer Testaufgaben. Hierdurch sollen softwareergonomische Probleme, aber auch positive Aspekte des Produkts aufgedeckt werden. Der Usability-Test ist geeignet für fertige Software, aber auch für Zwischenstände, Prototypen und Designkonzepte.

[collapse]

Best Practices – Testen

Teststrategie festlegen und Teststufen aufeinander abstimmen

Diese Best Practice beschreibt Möglichkeiten, wie der Test ausgerichtet werden kann. Zudem wird der Fokus der einzelnen Teststufen im Testprozess definiert und wie diese Teststufen ineinander greifen, um doppelte Prüfungen zu vermeiden. Zu den Teststufen gehören in der Regel der Entwicklertest (Modultest), der Integrationstest, der Systemtest und der Akzeptanztest. Jede dieser Teststufen hat einen bestimmten Fokus und sollte für bestimmte Zwecke genutzt werden. Die durch eine Teststufe abgedeckten Prüfungen müssen auf anderen Teststufen nicht mehr wiederholt werden. In einer Teststrategie, die für das Projekt erstellt wird, sowie eine Detailplanung für jeden Sprint, sollte das Vorgehen frühzeitig definiert werden, um eine effiziente Testausführung zu gewährleisten.

[collapse]
Fehlermanagement einsetzen

Fehlermeldung sollten in einem einheitlichen Schema geschrieben werden, dass im Idealfall im Team abgesprochen ist. Ziel ist hierbei, die Nachvollziehbarkeit durch die Entwickler und die Reproduzierbarkeit der gemeldeten Fehler zu ermöglichen. Weiterhin sorgt ein Fehlerstatusmodell für einen exakt definierten Ablauf bei der Bearbeitung der Fehlermeldungen. Die Fehlerklassifikation wiederum erlaubt die Priorisierung bestimmter Meldungen je nach der Wichtigkeit / Kritikalität der Meldung.

[collapse]
Reviews von Entwicklungsartefakten durchführen

Nachdem ein Entwicklungsartefakt (z.B. Anforderungen, Design, Code) erstellt wurde, kann es von einem oder mehreren Reviewern überprüft werden. Der bzw. die Reviewer können das entsprechende Dokument basierend auf ihren eigenen Erfahrungen nach Fehlern prüfen, sowie Anmerkungen und Verbesserungsvorschläge dokumentieren (direkt in dem Dokument, in einer Fehlerliste, oder werkzeugunterstützt). Darüber hinaus besteht die Möglichkeit, den Reviewern Leseunterstützung bei der Prüfung zur Verfügung zu stellen, beispielsweise in Form einer Checkliste, die eine Anzahl von Fragen enthält, auf die das Dokument zu prüfen ist. Neben der Möglichkeit, die gleiche Checkliste für alle Reviewer zu nutzen, können auch unterschiedliche Checklisten, die verschiedene Arten von Fehlern bzw. Perspektiven abdecken, genutzt werden. Darüber hinaus können auch Szenarien für ein Review eingesetzt werden, welche den Reviewer aktiv auffordern, eine Aktivität durchzuführen, und dabei die Qualität zu prüfen. Beispielsweise kann ein Testerszenario einen Reviewer auffordern, Testfälle aus einem Anforderungsdokument oder auch User Stories abzuleiten, und dabei zu prüfen, ob alle Informationen vorhanden sind. Im Anschluss an das Review können die Auffälligkeiten dem Autor in einer Gruppensitzung kommuniziert bzw. direkt übergeben werden. Der Autor ist dann schließlich für die Korrekturen verantwortlich. Weitere Detailbeschreibungen sind auch in den Best Practices „Usability-Review durchführen“ sowie „Anforderungen reviewen“ zu finden.

[collapse]
Systematische Testfallableitung und Tests durchführen

Die systematische Testfallableitung sorgt für eine zielgerichtete Erstellung von aufeinander abgestimmten Testfällen. Es wird klar, welche Teile der Software wie gut durch Tests abgedeckt sind. Für unterschiedliche Qualitätsanforderungen können unterschiedliche Testfallableitungsmethoden verwendet werden. Als Basis für die Testfallableitung dient entweder eine Spezifikation, Modelle (für Black Box-Tests) oder der Code selbst (für White Box-Tests). An Black Box-Methoden werden unter anderem die Äquivalenzklassen und Grenzwertanalyse, der zustandsbezogene Test, Ursache-Wirkungs-Graphen und Entscheidungstabellen oder der anwendungsfallbezogene Test empfohlen. Die Wahl der Methodik hängt zum Beispiel ab von den Eigenschaften des Systems, der verfügbaren Testbasis, der Teststrategie, den Testressourcen oder dem Wissen über die Methodiken. An White Box-Tests werden die Anweisungsüberdeckung, die Entscheidungsüberdeckung sowie die Bedingungsüberdeckung empfohlen, wobei die genaue Wahl zum Beispiel von den Qualitätsanforderungen, der Systemstruktur, oder dem zu erreichenden Qualitätslevel abhängt. Die systematisch abgeleiteten Tests werden im Anschluss durchgeführt.

[collapse]
Erfahrungsbasiertes Testen durchführen

Das erfahrungsbasierte Testen beschreibt eine Art des Testens, bei der Testfälle nicht anhand einer Testbasis im Voraus spezifiziert werden, sondern von der testenden Person direkt bei der Ausführung der Applikation / Software entworfen werden. Bei dieser Vorgehensweise wird oft keine Dokumentation der Testfälle vorgenommen, sondern es werden lediglich die zu testenden Bereiche der zu testenden Applikation / Software beschrieben. Neben dem rein explorativen Testen, bei dem ein Tester während des Testens intuitiv durch die Software navigiert, um Probleme zu finden, kann auch eine Checkliste genutzt werden, die beispielsweise gewisse Fehlerbilder enthält, auf die geprüft wird. Eine Testcharta, welche Anweisungen oder Ideen für den erfahrungsbasierten Test enthält, kann genutzt werden, um Bereiche für den erfahrungsbasierten Test festzulegen, und somit diese Art des Testens grob zu steuern.

[collapse]

Best Practices – Unterstützende Praktiken

Checklisten verwenden

Checklisten enthalten in korrekter Reihenfolge die Handlungsanweisungen bzw. Abfrageparameter, die zum Durchführen einer bestimmten Maßnahme erforderlich sind. Sie können als Arbeitshilfe verwendet werden, um sich wiederholende Abläufe zu strukturieren, zu kontrollieren und zu dokumentieren.

[collapse]
Kontrolliertes Vokabular nutzen

Ein kontrolliertes Vokabular ist eine existierende Menge von Begriffen mit definierter Bedeutung, die aus einem Fachbereich, einer Firmenumgebung, einer Software oder einem System stammen kann. Die Methode beschreibt, wie: 1. Ein kontrolliertes Vokabular explizit erfasst werden kann. 2. Definierte Begriffe überall zum Einsatz kommen, und andere Begriffe nur verwendet werden, wenn es keinen definierten Begriff gibt. 3. Ein definierter Begriff nur noch in seinem definierten Bedeutungszusammenhang verwendet wird.

[collapse]
Standardisierte Dokumentstrukturen verwenden

Die Verwendung standardisierter Dokument- und Inhaltsstrukturen vereinfacht die Erstellung vollständiger Dokumente und die Wiederverwendung bestehender Dokumentinhalte. Standardisierte Strukturen helfen dabei, die Qualität der internen und externen Produktdokumentation zu verbessern. Ein konsistenter Aufbau, der über alle Dokumente bzw. Dokumentarten hinweg verwendet wird, sorgt zudem für eine wesentlich einfachere Nutzung der Dokumente.

[collapse]