27. Juli 2018
Martin Maier
0

Testgetriebene Entwicklung (TDD) einer Angular-Anwendung

 

 

Grafische Oberflächen von komplexen Systemen wurden lange Zeit hauptsächlich mit soliden, schwergewichtigen Technologien in sehr hoch entwickelten, objektorientierten Sprachen realisiert. Dabei wurden meist Fat Clients durch WPF oder Swing entwickelt. Eher seltener handelte es sich dabei um Thin Clients in Form von Webanwendungen. HTML und JavaScript wurden in diesen Fällen vorwiegend durch große Frameworks wie ASP oder JSF abstrahiert und serverseitig gerendert. Der Sprachkern von JavaScript entwickelte sich jedoch mit ECMAScript 2015 stark weiter und wurde dadurch auch für komplexere Anwendungen interessant. Basierend auf den Vorschlägen zu ECMAScript 2015 entstand mit TypeScript zusätzlich eine Möglichkeit, Webanwendungen auf sehr hohem sprachlichen Niveau und statisch typisiert zu entwickeln. Durch diese starken sprachlichen Verbesserungen und den starken Support durch Giganten wie Facebook und Google, wurden Webtechnologien zunehmend für komplexere Anwendungen in Form von Singe Page Applications (SPA) interessant.

Leider hat der Quellcode solcher auf Webtechnologien basierender Anwendungen oft noch den Ruf, sich hinsichtlich Lesbarkeit, Design und Testabdeckung auf einem qualitativ sehr niedrigen Level zu befinden. Der Wert qualitativ hochwertigen Code zu entwickeln, um eine Anwendung nachhaltig effizient weiterzuentwickeln und warten zu können, ist jedoch technologieunabhängig und bedarf damit verbundener Prinzipien und Methoden um diesen Wert erhalten.

Testgetriebene Entwicklung (Test Driven Development = TDD) ist eine Methode aus dem Extreme Programming (XP), um qualitativ hochwertigen und gut getesteten Code zu entwickeln.

Dabei wird in kurzen Iterationen stets zuerst in Tests das Verhalten spezifiziert, bevor es implementiert und anschließend die Lesbarkeit und Struktur des Codes verbessert wird. Dies führt nicht nur zu gut testbarem und getestetem Code, sondern auch dazu, dass sich Entwickler bereits sehr früh mit der Struktur bzw. dem Design des Codes auseinandersetzen müssen. Zudem wird durch die vorgelagerte Spezifizierung durch Tests auch effektiv nur Funktionalität entwickelt, die tatsächlich gefordert wird und schützt somit davor prädiktiven und unnötig komplexen Code zu entwickeln.

Mit der Angular CLI erstellte Projekte, enthalten „out of the box“ alle Bordmittel um testgetrieben entwickeln zu können.

Dieses Tutorial soll anhand eines einfachen Szenarios beschreiben, wie Angular Projekte testgetrieben entwickelt werden können.

Das Szenario

Wir wollen den Fokus auf die Methodik legen und wählen deswegen ein sehr einfaches fachliches Szenario. Mit der Anwendung sollen rudimentär Kontakte verwaltet werden können. Sie besteht grundlegend aus nur zwei Funktionalitäten:

  • Kontakte anzuzeigen
  • Neue Kontakte anzulegen

Aufsetzen des Angular Projekts

Ein Angular Projekt ist mittels Angular CLI zügig aufgesetzt.

 

 

Wir möchten die Anwendung von Grund auf entwickeln. Dazu

  • löschen wir Komponente app.component
  • bereinigen die davon betroffenen Abhängigkeiten app.module und index.html
  • löschen die End-to-End Spezifikationen im Verzeichnis e2e/src
  • und überprüfen unsere Änderungen indem wir das Projekt mit ng build bauen

Der „Walking Skeleton“

Unser System ist sehr klein, kommuniziert mit keinem Backend und wird einfachheitshalber auch nicht automatisiert ausgeliefert. Damit handelt es sich bei unserem Skelett ausschließlich um einen Durchstich zur testgetriebenen Entwicklung unserer Anwendung. Dieser sollte einen E2E-Test umfassen, welcher über „Page Objects“ mit der Webanwendung interagiert, und einer ersten kleinen Komponente, welche testgetrieben entwickelt wurde. Eine passende erste kleine Story, um den „Walking Skeleton“ zu erstellen, ist das Anzeigen der Kontakte.

Vorgehen

Wir entwickeln in kurzen TDD-Iterationen. Um dieses Tutorial lesbarer und übersichtlicher zu gestalten, verwende ich ein paar Icons, um den Ablauf darzustellen. Als erstes definieren und sprechen wir darüber, was wir in der nächsten Iteration erreichen möchten. Bestenfalls entwickeln wir das nicht alleine, sondern haben uns mit einem anderen Entwickler „gepaired“. Wir spezifizieren einen entsprechenden Test, starten ihn  und beobachten wie er fehlschlägt  . Daraufhin implementieren wir die Funktionalität und starten den Test erneut  bis dieser erfolgreich ist . Wir überprüfen unseren Code Style, führen Refactorings durch und starten danach mit der nächsten kleinen TDD-Iteration.

Spezifizierung der Story in einem ersten E2E-Test

Wir definieren den Kontext der Story als Kontaktverwaltung und erstellen dementsprechend eine E2E-Spezifikation /e2e/src/contact-management.e2e-spec.ts.

Wir legen fest, dass die Webseite der Kontaktverwaltung initial die beiden Kontakte „Max“ und „Moritz“ auflistet.

Innerhalb der E2E-Spezifikationen wollen wir auf einer sehr hohen Ebene mit der Anwendung interagieren und delegieren den Zugriff auf die HTML-Elemente deswegen in sogenannte „Page Objects“.

In TDD-Manier schreiben wir unseren E2E-Test als würde eine Klasse ContactManagementPage bereits bestehen, um sie so zu definieren, wie sie aus Client-Sicht am sinnvollsten ist.

Wir erstellen uns eine Instanz der ContactManagementPage, navigieren auf deren Ansicht und stellen sicher, dass dort nur die Kontakte „Max“ und „Moritz“ aufgelistet werden.

 

 

Sind wir damit soweit fertig, erstellen wir die Klasse ContactManagementPage unter /e2e/src/pageobjects/contact-management.po.ts, wie im Testfall angenommen.

 Nun kompiliert der Testfall, schlägt aber – wie erwartet – fehl.

Wir beginnen mit der Implementierung des „Page Objects“ bei der Method #navigateTo, welche zur Kontaktverwaltungs-Ansicht navigiert. In unserem Fall ist das aktuell “/”.

Als nächstes benötigen wir die Namen der aufgelisteten Kontakte. An dieser Stelle definieren wir, dass die Ansicht Elemente der Klasse „contact“ darstellen soll, welche wiederrum ein Element der Klasse „name“ beinhalten.

Wir implementieren also #shownNamesOfContacts indem wir alle Namens-Elemente heraussuchen und deren Textinhalte mappen.

Protractor arbeitet asynchron mit eigenen Promises. Wir müssen also unbedingt darauf achten, die richtige Promise-Klasse von Protractor zu importieren.

 

 

   Der Test schlägt nun fehl mit einem Hinweis, dass keine Angular Seite gefunden werden konnte. Der Grund dafür ist, dass aktuell keine Angular Komponente bootstrapped wird.

Um diesen Fehler zu beheben erstellen wir als nächstes eine Angular Komponente “contact-list” mit Hilfe der Angular CLI.

ng generate component contact-list

Sie wird automatisch dem globalen App-Modul zugeordnet und dort deklariert. Das ist für dieses Tutorial soweit in Ordnung, aber wir müssen diese Komponente auch noch in unsere index.html einpflegen und im Modul konfigurieren, dass die Komponente auch gebootstrapped wird.

   Der E2E-Test schlägt weiterhin fehl, diesmal jedoch wie gewünscht, dadurch dass die Erwartungen nicht erfüllt wurden.

Implementierung der Komponente

Zunächst soll die Komponente eine Liste mit einem Eintrag je Kontakt darstellen.

Wir erstellen uns dafür einen Testfall in der von der Angular CLI mitgenerierten contact-list.component.spec wieder unter der Annahme, dass benötigte Abhängigkeiten bereits existieren.

 

 

Der Code kompiliert nicht. Wir benötigen das Daten Objekt „Contact“ und eine Property „contacts“ im Controller contact-list.components.ts der Komponente, welches die Kontakte bereitstellt.

Wir erstellen also die Klasse /model/contact.ts

 

 

und erweitern den Controller um die Property contacts: Contact[].

   Wir starten diesmal die Karma Tests durch ng test und sehen, dass der eben geschriebene Test fehlschlägt, da wir zwei Kontakt-Elemente erwarten, jedoch keiner dargestellt wird.

Wir können Karma im Hintergrund laufen lassen und bekommen dadurch sofortiges Feedback über unsere Änderungen am Code und deren Auswirkungen auf die Testergebnisse.

Wir erweitern die View contact-list.component.html dahingehend, eine Liste mit einem Eintrag je Kontakt darzustellen.

 

 

 Die Tests sind erfolgreich!

So weit so gut. Nun wollen wir die Namen der Kontakte anzeigen.

 

 

   Der Test schlägt – wie erwartet – fehl.

Wir erweitern also den View, der den Namen des Kontakts darstellt.

 

 Erfolgreich! Unsere Komponente zeigt nun die Namen der Kontakte an.

Ist die Story damit fertig implementiert? Wir lassen die E2E-Tests laufen.

   Dieser schlägt weiterhin fehl. Wir erwarten, dass “Max” and “Moritz” initial als Kontakte angezeigt werden.

Als nächstes wollen wir also, dass die Komponente initial die Kontakte „Max“ und „Moritz“ darstellt.

 

   Der Test schlägt fehl.

Wir initialisieren das Property des Controllers mit den entsprechenden Kontakten.

 Alle Komponenten-Tests sind erfolgreich.

 Nun ist auch der E2E-Test grün und die Implementierung der Story damit abgeschlossen.

 

Weiterentwicklung

Da nun unser „Walking Skeleton“ steht, können wir mit der Weiterentwicklung fortfahren.

Mögliche nächste Schritte könnten beispielsweise sein:

  • Refactoring: Auslagern und Delegierung der „contact-list“ spezifischen Inhalte in ein eigenes „Page Object“, um das ContactManagementPage-Object übersichtlich zu halten und die „contact-list“ auch in anderen E2E-Tests wiederverwenden zu können.

  • Story: Anlegen neuer Kontakte
    • Über ein Textfeld soll beim Betätigen der Enter-Taste ein neuer Kontakt angelegt werden.

    • Wurde ein neuer Kontakt angelegt, soll das Textfeld zurückgesetzt werden.

  • Optimierung: Auslagern der Datenhaltung in einen Redux-Store

 

Fazit

Frameworks wie Jasmine, Karma oder Protractor unterstützen die testgetriebene Entwicklung von Webanwendungen sehr gut.

Im Falle von Angular sind Projekte, die mit der Angular CLI erstellt wurden, bereits mit Jasmine, Karma und Protractor vorkonfiguriert und können „out of the box“ testgetrieben entwickelt werden.

TDD ist also auch für die Entwicklung von Webanwendungen eine sehr gute Praxis, um qualitativ hochwertigen und gut getesteten Quellcode zu generieren.

Im Zusammenspiel mit anderen Praktiken wie Pair-Programming und Clean Coding ergeben sich sehr gute Synergieeffekte, wodurch Systeme sehr effektiv und effizient weiterentwickelt und gewartet werden können.

26. Juli 2018
Alexander Casall
0

JavaFX nach 2022 – JavaFX Anwendertreffen

JavaFX nach 2022 – JavaFX Anwendertreffen

 

JavaFX wird ab 2022 von Oracle nur noch über kommerziellen Support durch Bugfixes unterstützt. Gerade für Firmen, welche stark in JavaFX Anwendungen investiert haben, erzeugt dies Unsicherheit.

Am 20.09. wird daher in München ein JavaFX Anwendertreffen stattfinden, dessen Ziel ein Austausch zwischen Anwenderfirmen über ihre JavaFX Projekte und ihre aktuellen Zukunftspläne ist. Zudem werden Vertreter des JavaFX Ökosystems (z.B. Gluon) anwesend sein, um gemeinsam mit den Teilnehmern ein tragfähiges Zukunftsbild von JavaFX zu diskutieren.

Für eine erfolgreiche Weiterentwicklung von JavaFX nach 2022 wird ein starkes Ökosystem benötigt, an dem sich auch Anwenderfirmen beteiligen müssen. Wenn Sie JavaFX aktuell für kritische Geschäftsanwendungen einsetzen, sollten Sie an diesem Tag teilnehmen.

 

Der Tag richtet sich an folgenden Teilnehmerkreis:

  • Vertreter von Firmen, welche JavaFX Anwendungen mit einem Investitionsvolumen > 750k € entwickelt haben
  • Die Vertreter haben das Mandat des Managements der Firma und können daraufhin wirken, dass die Ergebnisse des Tages in der Organisation nachverfolgt werden.

Organisatorische Details:

  • Wann: 20.09.2018, 09:00 – 17:00 Uhr
  • Wo: Carl Zeiss Meditec München, Kistlerhofstraße 75, 81379 München
  • Hotelkontingent im Holiday Inn München Süd bis 20.08. abrufbar (das Oktoberfest findet vom 22.09. bis 07.10.18 statt), kontaktieren Sie dazu unser Team unter feedback@saxsys.de

 

JavaFX after 2022 – JavaFX adopters’ meeting

 

After 2022 Orcale will support JavaFX only by commercial support through bug fixes. Especially for companies that have invested heavily in JavaFX applications, this fact creates uncertainties.

Therefore, we host a JavaFX adopters‘ meeting on the 20th of September, with the goal to create an exchange between attendees about their projects and current future plans. In addition, representatives of the JavaFX ecosystem (e.g. Gluon) will take part to discuss with the attendees a viable future picture of JavaFX.

For a successful further development of JavaFX after 2022, a strong ecosystem is needed, which also makes it necessary for adopter companies to contribute the ecosystem. If you are serious about using JavaFX for your business, you should attend this day!

 

The day is directed to the following audience:

  • Representatives of companies that have developed JavaFX applications with an investment volume > 750k €
  • The representatives have the mandate of the management of the company and can then act to track the results of the day in the organization.

 

Organizational details:

  • When: 20.09.2018 09:00 – 17:00 o’clock
  • Where: Carl Zeiss Meditec Munich, Kistlerhofstraße 75, 81379 Munich
  • Hotel contingent at Holiday Inn Munich South until 20.08. available (the Oktoberfest starts on 22.09.2018), contact feedback@saxsys.de for assistance

 

20. April 2018
Ines Reiche
0

Teamcoaches gesucht

Soziologie oder Kommunikationswissenschaften studieren – und danach ein Praktikum nach dem anderen machen? Psychologie studieren – aber kein Interesse an einer anschließenden Therapeutenausbildung? Erziehungswissenschaften studieren – aber vielleicht doch nicht als Lehrer arbeiten?

Wir kennen eine Alternative! Auch wenn es zunächst gar nicht so scheint – in einigen eher technischen Branchen werden soziale und emotionale Fähigkeiten gebraucht und wir suchen Menschen, die uns diese Lücke füllen – selbst in der IT.

Im agilen Projektvorgehen, was immer mehr zum Standard in Softwareentwicklungsprojekten wird, arbeiten Teams selbstorganisiert und eigenverantwortlich zusammen. Auch wenn Selbstorganisation nach Selbstläufer klingt, handelt es sich um einen anspruchsvollen Prozess, der gelernt sein will. Deshalb gibt es in solchen Projekten einen Teamcoach für jedes Team, der oder die ein Team auf ihrem Weg zur Selbstorganisation unterstützt.

Was zeichnet solche Teamcoaches aus?

Gemeinsam mit ihrem Team übernehmen sie die Verantwortung, das Projektziel zu erreichen. Sie regen durch offene Fragen und konstruktives Feedback ihr Team und das Projektumfeld dazu an, die Prozesse und die Zusammenarbeit ständig zu hinterfragen und zu verbessern. Den Respekt ihres Teams und des Projektumfelds verschaffen sie sich durch ihr methodisches Wissen sowie ihre engagierte und stringente Art. Das, was die Teamcoaches propagieren, leben sie auch vor. Dabei befähigt sie ihre Disziplin dazu, die Interessen aller Beteiligten einschließlich der eigenen zu reflektieren und gemeinsam mit dem Team zu ergründen, was das Team im Prozess am meisten motiviert und voranbringt. Teamcoaches sind außerdem wahre Organisationstalente.

Durch ihre hohe Zuverlässigkeit erfährt ihr Team die notwendige Stabilität während des kontinuierlichen Verbesserungsprozesses und das Vertrauen, um sich in seinem vollen Potential frei zu entfalten. Ihre guten Fähigkeiten im Konfliktmanagement helfen ihnen, bei den natürlichen Reibereien, die auf dem Weg der ständigen Weiterentwicklung entstehen, zu vermitteln. Sie befähigen ihr Team, zwischenmenschliche oder gar strukturelle Konflikte aufzulösen und bieten sich bei Bedarf als Mediator an.

Mit geeigneten Vorschlägen helfen sie dem Team, sich selbst einen Rahmen zu schaffen, um effizient zu arbeiten und die sich selbst auferlegten Regeln einzuhalten. Dabei machen sich Teamcoaches nicht unabdingbar, sondern streben an, dem Team nach und nach selbst die Organisation zu überlassen.

Teamcoaches zeichnen sich besonders durch die folgenden Eigenschaften aus:

  • Verantwortungsvoll, ziel- und prozessorientiert
  • Zuverlässig, engagiert und stringent
  • Analytisch, empathisch und teamorientiert
  • Konstruktiv, problemlösend und vermittelnd

Welche Aufgaben übernehmen Teamcoaches noch?

Neben der Moderation von Meetings stehen sie bei technischen und organisatorischen Problemen zur Seite, z.B. wenn die Tastatur kaputt ist, eine Zugangsberechtigung fehlt oder die Videokonferenz nicht funktioniert. Weiterhin helfen sie dem Team dabei, Hindernisse im Arbeitsprozess zu identifizieren und zu beseitigen. Sie kennen die Hintergründe der verschiedenen Rollen im Team und fungieren als „Übersetzungshilfe“ zwischen der Anforderungsseite (dem Fachbereich) und den Softwareentwicklern. Dies erfordert, dass sie sich in beide Positionen hineinversetzen können und zu einem gewissen Grad verstehen, womit sich diese jeweils beschäftigen.

Wir bei der Saxonia Systems AG arbeiten meist nach dem agilen Regelwerk „Scrum“ zusammen. Hier heißen Teamcoaches Scrum Master. Sie wissen, welche Rollen, Prozesse und Artefakte es gibt(1) und können dem Team die Vorteile, Werte und Vorgehensweisen von Scrum vermitteln.

Häufig arbeiten wir über verschiedene Standorte hinweg. Scrum Master kümmern sich bei uns daher zusätzlich darum, dass die technischen Hilfsmittel für die verteilte Kommunikation wie Videokonferenzanlage, Chat, verteilte Whiteboards etc. zur Verfügung stehen und funktionieren. Ihre Technikaffinität hilft ihnen dabei. Auf der Suche nach den optimalen technischen Rahmenbedingungen für das Team können sie sich stets Rat von anderen Scrum Mastern oder unserer hilfsbereiten IT-Infrastruktur-Abteilung holen.

Zusammengefasst übernehmen die Teamcoaches folgende Aufgaben:

  • Anleitung und Befähigung ihres Teams zur selbstorganisierten Umsetzung des Scrum Frameworks
  • Coaching ihres Teams hinsichtlich zwischenmenschlicher Aspekte der Zusammenarbeit
  • Organisation und Problemlösung für eine optimale Teamzusammenarbeit, häufig über verschiedene Standorte hinweg
  • Erster Ansprechpartner im Team für alle innerhalb und außerhalb des Scrum Teams

Durch das steigende Interesse an agilen Methoden wie Scrum, auch außerhalb der IT, gibt es einen stark wachsenden Bedarf an Scrum Mastern. Nur keine Scheu: Soziale und emotionale Fähigkeiten sind in der IT-Branche immer gefragter! Gerade unterschiedliche fachliche Hintergründe auch außerhalb der Informatik bereichern unsere Arbeit und bringen durch den stetigen Austausch von unterschiedlichen Sichtweisen und Ansätzen einen deutlichen Mehrwert für alle. Wir selbst haben zwei vermeintlich gegensätzliche Hintergründe – den Studiengang Kommunikationspsychologie und Medieninformatik. Doch gerade das Lernen voneinander bereichert uns jeden Tag.

(1): https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf

 

Teamcoaches gesucht!

20. März 2018
Erik Schiller
0

Der Custom Usability Index (CUI) in Action – Usability Tests in der agilen Softwareentwicklung

Ausgangspunkt – Was bisher geschah…

In zwei früheren Blogbeiträgen habe ich einerseits das Konzept des Custom Usability Index vorgestellt, sowie die Vorbereitungsphase genauer erläutert, in welcher Usability-Kategorien individualisiert und gewichtet werden. Mit diesem Blogbeitrag möchte ich tiefer auf die tatsächliche Anwendung eingehen und erklären, welche Schritte notwendig sind, um am Ende eine valide CUI-Bewertung zu erhalten.
Folgender Stand soll als Startpunkt unseres Anwendungsbeispiels dienen. Wir befinden uns in der Entwicklung einer neuen Web-Applikation für einen Business-Kunden. Der verantwortliche Product Owner hatte zu Projektstart die Usability-Kategorien durch einen UX-Experten erklärt bekommen und seine Zielzustände definiert. Diese hat er im Anschluss entsprechend seiner Anforderungen priorisiert und so den Grundstein zur regelmäßigen Messung der zukünftigen Anwendung mit dem CUI gelegt. Nach einiger Entwicklungszeit ist nun ein erster Release Kandidat auf das QA-System deployt worden und steht zum Test bereit.

Der Custom Usability Index (CUI) in Action – Jetzt geht es Ihrer Software an den Kragen!

Wie geht es jetzt weiter? Für den Test der 13 Usability-Kategorien sind mehrere, verschiedene Testmethoden möglich. Die Auswahl der Testmethodik orientiert sich neben der Eignung für die jeweilige Usability-Kategorie auch an zahlreichen weiteren Faktoren. Die Verfügbarkeit der Endnutzer, das Wissen des Usability-Testers sowie zeitliche und monetäre Ressourcen spielen eine wichtige Rolle. Das Wunschszenario, mit mehreren Usability-Testern inklusive Protokollanten zahlreiche Endnutzer einem ausgiebigen und zeitlich intensiven Test zu unterziehen, ist in der Praxis selten der Fall.
Was verlieren wir durch das Eindämmen der Ressourcen? Hauptsächlich Genauigkeit und Unabhängigkeit in der Messung. Jedoch ist dies nicht das primäre Ziel des CUI. Durch die Tests, egal in welchem Ausmaß, sollen hauptsächlich Probleme und Verbesserungspotentiale aufgezeigt werden. Das heißt, selbst wenn das Ergebnis von Test A zu Test B abweicht sind die Schmerzpunkte klar und ermöglichen so Ansätze für eine besser nutzbare Software zu schaffen. Eine ressourcenschonende Variante des Testens ist die heuristische Evaluation. Die heuristische Evaluation ist eine Inspektionsmethode, bei der eine Gruppe von Usability-Experten eine Anwendung auf die Einhaltung von ausgewählten Richtlinien und Heuristiken (in diesem Fall die dem Nutzungskontext angepassten Usability-Kategorien des CUI) untersucht. Nach Nielsen finden ca. 7 Tester 80% der gesamten Usability-Fehler, Folge-Tests sind weniger ergiebig, da kaum noch weitere Fehler gefunden werden.

Nielsen (1995): Anzahl der heuristischen Evaluationen vs. gefundene Usability Probleme https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

In der Praxis von agilen Softwareentwicklungsprojekten ist es jedoch Luxus überhaupt mehrere Usability-Experten für den Test zu bekommen, so dass üblicher Weise 1-2 Experten die Evaluation durchführen. Ein mit der Anwendung vertrauter Usability-Experte sollte je nach Komplexität der Anwendung und dem Dokumentationsumfang in der Lage sein, innerhalb von 1-2 Tagen ein brauchbares Messergebnis zu erzielen. Das heißt Sie können auch schon mit mehreren „kleineren“ Usability-Tests die Qualität Ihrer Software steigern und erste Verbesserungen erzielen.

Ein Beispiel – Die Messung von 13 Kategorien, 31 Kriterien „in a nutshell“.
Starten wir mit der ersten Kategorie Effektivität. Der Product Owner hat für diese Kategorie folgenden Zielzustand definiert: „Der Nutzer hat jederzeit Zugriff auf die zur Aufgabenerledigung notwendigen Funktionalität und erreicht diese in höchstens 2 Schritten. Er wird dabei nur mit den für ihn im Moment notwendigen Informationen belastet (Daten sollen im Vordergrund stehen).“

Zusätzlich wurde Effektivität mit der Fibonacci-Zahl 3 gewichtet.
Die Kategorie Effektivität besteht aus den zwei Kriterien Funktionsumfang und Angemessenheit. Für das Kriterium Funktionsumfang müssen nun die verschiedenen Use-Cases der Webanwendung überprüft und zusätzlich geschaut werden, ob die dazu benötigten Funktionen in höchstens 2 Schritten erreichbar sind.

Der Zielzustand für dieses Kriterium ist für den aktuellen Release Kandidaten vollständig erfüllt und es wird somit die Maximalbewertung von 5 Punkten erteilt.
Weiter geht es mit dem zweiten Kriterium Angemessenheit. Es fordert, dass der Nutzer nur mit den für ihn im Moment notwendigen Informationen belastet wird und die Daten im Vordergrund stehen.

Durch mehrere kleinere Auffälligkeiten gibt es 2 Punkte Abzug und somit eine Bewertung von 3 Punkten. Zusammengerechnet mit der Bewertung des Kriteriums Funktionsumfang bedeutet dies eine durchschnittliche Bewertung von 4 Punkten für die übergeordnete Kategorie Effektivität.
Die Messung der übrigen 12 Kategorien und 29 Kriterien sollte analog zum obigen Beispiel erfolgen. Da die vollständige Dokumentation eines CUI-Tests jedoch den Rahmen dieses Blogbeitrages sprengen würde, springen wir einen Schritt weiter und schauen uns die Endberechnung einmal genauer an.

Beispiel einer fertiggestellten CUI-Berechnung

Der Custom Usability Index (CUI) in Action – Usability Tests in der agilen Softwareentwicklung

Der Custom Usability Index (CUI) in Action – Usability Tests in der agilen Softwareentwicklung

Obige Tabelle zeigt eine vollständig ausgefüllte CUI-Berechnungsmatrix nach Testbeendigung. Der finale CUI-Wert setzt sich wie folgt zusammen:

  • Berechnung des Durchschnittswertes einer Kategorie (Summe der Bewertung / Anzahl der Kriterien)
  • Berechnung der relativen Gewichtung (Gewichtungswert der Kategorie / Summe aller Gewichtungswerte)
  • Berechnung des finalen Kategorienwertes (Durchschnittswert der Kategorie * relative Gewichtung)
  • CUI-Wert = Summe der finalen Kategorienwerte
  • CUI-Erreichungsgrad = ((CUI-Wert – 1) / 4)

Rechnen wir dies einmal anhand unseres Beispiels nach:

  • Bewertung der Kategorie Effektivität (Funktionsumfang 5 Punkte + Angemessenheit 3 Punkte) / 2 Kriterien = 4 Punkte
  • Summe der Gewichtungen aller Kategorien = 24
  • Relative Gewichtung der Kategorie Effektivität = 3/24 = 0,125
  • Einzelwert der Kategorie Effektivität = Bewertung von 4 * relative Gewichtung 0,125 = 0,50

Juhu geschafft – Und nun?

Erst einmal herzlichen Glückwünsch, dass Sie sich um das Wohl Ihrer Nutzer gekümmert haben. Doch nun gilt es weitere Schritte einzuleiten:

  • Entwickeln Sie Lösungsvarianten für die aufgezeigten Probleme in Form von Wireframes und Prototypen
  • Zeigen Sie den Einfluss kommender User Stories in Bezug auf die verschiedenen Usability Kategorien auf
  • Hinterfragen Sie die Anforderungen Ihres Product Owners … Sie sind der Experte!
  • Zeigen Sie aktiv Alternativen auf und setzen Sie die vorgesetzten Anforderungen nicht einfach stillschweigend um
  • Führen Sie in regelmäßigen Abständen einen erneuten CUI-Test durch und tracken Sie so den Einfluss der Verbesserungen bzw. neuer Anforderungen auf die Nutzbarkeit Ihrer Software

Durch den Custom Usability Index ist es möglich mit geringem Ressourcenverbrauch hilfreiche Ergebnisse zu erzielen. Das leichtgewichtige Vorgehen bettet sich nahtlos in den agilen Softwareentwicklungsprozess ein und zeigt Schwachstellen Ihrer Software auf. Durch regelmäßige Tests wird ein langfristiges Tracking möglich und Usability tatsächlich greifbar gemacht. Trauen Sie sich, Ihre Nutzer werden es Ihnen danken!

Ein Einblick in Usability Tests in der agilen Softwareentwicklung!

 

29. Januar 2018
Sven Jänicke
0

Aktuelle Trends und Herausforderungen in der Softwareentwicklung

… das sagten die Teilnehmer der iJS und W-JAX

Dass nicht nur in Sachsen was geht, sondern vor allem auch an unserem Hauptsitz in München, zeigten Ende letzten Jahres die „International JavaScript Conference“ und die „W-JAX“. Beide Konferenzen fanden kurz nacheinander statt und lockten zahlreiche Besucher in die bayrische Landeshauptstadt.

Wie schon die S&S Media Group als Veranstalter der iJS (international JavaScript Conference) feststellt, ist „JavaScript [mittlerweile] überall: kaum ein digitales Business kann heute auf JavaScript und high-level Frameworks, wie Angular, React, oder NodeJS verzichten.“ Da wundert es kaum, dass diesem Thema auf der iJS vom 23.-27.10.2017 im Holiday Inn Munich City Centre eine eigene Konferenz mit zahlreichen Keynotes, Sessions und Power Workshops gewidmet wird. Auch die W-JAX beschäftigt sich zum Teil mit diesen Themenfeldern, bietet aber zusätzlich noch zahlreiche weitere Impulse im Bereich Enterprise-Technologie, Softwarearchitektur, Agilität & Java.

 

Wir nutzten bei beiden Konferenzen die Gelegenheit, uns intensiv mit der Community auszutauschen und hatten deswegen einige Fragen im Gepäck, die wir an die Teilnehmer der Konferenzen richteten. Insgesamt konnten wir fast 100 Umfragen durchführen, die sich in gleichen Teilen auf die beiden Veranstaltungen aufteilten. Wir danken an dieser Stelle noch einmal allen, die sich die Zeit genommen haben, sich an unserer Befragung zu beteiligen. Nur durch einen intensiven Austausch mit Partnern, Kunden und Community kann es gelingen, sich stets zu verbessern. Diesen Ansatz der kontinuierlichen Verbesserung, der auch im agilen Manifest verankert ist, verfolgen wir nicht nur in unseren Projekten, sondern leben wir auch unternehmensweit.

Während unsere Experten Manuel Mauky und Alexander Casall zu Themen wie „Angular-Anwendungen mit Redux“ und „Offlinefähige Desktopanwendungen mit Angular und Electron“ sprachen, wollten wir von unseren Interviewpartnern zuallererst wissen, welche Frameworks und Sprachen sie in ihren aktuellen Hauptprojekten einsetzen. Am häufigsten wurden Angular und JQuery genutzt, dicht gefolgt von JavaEE und Spring. React kam dagegen beispielsweise noch recht selten zum Einsatz. Dabei nutzten 72 von 88 Befragten JavaScript, 69 HTML und 51 Java als Programmiersprache. Ruby, Groovy und Coffeescript dagegen wurden kaum verwendet und bekamen jeweils maximal 5 Stimmen.

 

Natürlich interessierte uns nicht nur, mit welchen Technologien momentan gearbeitet wird, sondern vor allem in welche Richtung sich die Trends der Softwareentwicklung bewegen. Immer mehr Anwender von Geschäftsanwendungen erwarten moderne Webanwendungen anstelle bestehender Desktop-Software. Die Usability von Bestandssoftware trifft in Zeiten von modernen B2C-Applikationen oft nicht mehr die Erwartungshaltung der Nutzer und es werden immer mehr webbasierte Lösungen etabliert, die ihre Nutzer aktiv in der Arbeit unterstützen. Daher ist es auch nicht verwunderlich, dass 70 % der Befragten planen, in nächster Zeit mit Angular, React oder einer anderen reactiven Technologie (z.B. ReactiveX, RxJS, …) zu arbeiten. Vue.JS (14 Stimmen) und JavaFX (3 Stimmen) spielen dagegen bei den Umfrageteilnehmern nur untergeordnete Rollen.

 

Die Hälfte der Befragten konnte sich schon recht genau positionieren und hatte sich auf Angular, React oder zumindest eine reactive Technologie festgelegt. Rund 20 % dagegen waren noch indifferent und konnten sich noch nicht zwischen Angular oder einer reactiven Technologie entscheiden. Hilfestellung könnte hier die von uns evaluierte Entscheidungsmatrix bieten, die mithilfe eines Fragenkatalogs eine persönliche Technologieempfehlung gibt. Diese basiert auf den Erfahrungen unserer Webexperten.

Weiterhin entscheidend bei der Auswahl einer geeigneten Programmiersprache oder eines Frameworks ist selbstverständlich auch der Inhalt des eigentlichen Projektes. Wir fragten daher, was die Umfrageteilnehmer in ihrem Hauptprojekt tun. Der Großteil der Befragten beschäftigte sich hier mit Softwareevolutionsprojekten (61 Stimmen), dicht gefolgt von Neuentwicklungen (56 Stimmen). Rund ein Fünftel der Umfrageteilnehmer beschäftigte sich in ihrem Arbeitsalltag mit DevOps. Je nachdem, ob man eine bestehende Software wartet oder ein „grüne Wiese“-Projekt auf dem Tisch hat, sind die Spielräume bei der Auswahl der Programmiersprachen und verwendeten Tools natürlich sehr unterschiedlich breit.

 

Nachdem wir nun etwas näher herausgefunden hatten, womit die Befragten, bei denen es sich zum Großteil um Softwareentwickler verschiedenster Nationalitäten und aus unterschiedlichsten Branchen und Unternehmensgrößen handelte, wollten wir auch wissen, was sie im aktuellen Projekt am meisten behindert. An dieser Stelle gaben wir bewusst eher offene Antwortmöglichkeiten, wie „schlechter Code“ oder „schlechte Architektur“ vor, die dem Interviewteilnehmer noch Spielraum für Interpretation gaben und somit die Befragten bewusst dazu auffordern sollten, näher auf die Probleme einzugehen und gegebenenfalls einen ersten Dialog zu Problemlösung zu fördern.

Die häufigsten genannten Probleme sind der folgenden Grafik zu entnehmen. Neben den hier auftauchenden Antworten, bei denen sich „unklare Anforderungen“ nach wie vor als eines der Hauptprobleme darstellte, gab es auch einige freie Antworten. Relativ häufig wurde hier „legacy code“, „Warten auf den Auftraggeber / den Kunden“ oder „stark gewachsene und unübersichtliche Softwarearchitektur“ genannt.

 

 

Schlussendlich wandten wir uns noch einigen Fragestellungen aus dem Bereich „Moderne Webentwicklung“ zu, um hier zu prüfen, welche Trends sich tatsächlich von der Community bestätigen lassen oder welche Themen zwar im Netz „gehypt“ werden, aber im tatsächlichen Entwickleralltag noch nicht angekommen sind. Einer dieser Trends in der IT ist beispielsweise GraphQL. Hier stellten wir erst einmal die grundsätzliche Frage, wie die Konferenzbesucher zu der Technologie standen. Lediglich ein Viertel der Befragten plante den Einsatz dieser REST-Alternative für die Zukunft oder hatte GraphQL bereits im Einsatz, während immerhin fast die Hälfte noch nie von der Technologie gehört hatten.

 

Wir wollten hier außerdem noch wissen, ob die Befragten in ihren Projekten Cloud-Technologien einsetzen. Hier war das Verhältnis der Antworten relativ ausgeglichen. 45 % der Umfrageteilnehmer bejahten hier, während die restlichen 55 % nicht, oder zumindest nicht in ihrem Hauptprojekt, mit Cloud-Technologien arbeiteten. Die zweite Frage aus diesem Themenblock war, welche Technologie die Befragten aktuell für das State-Management verwendeten. Zur Auswahl standen React/Angular (ohne Dritt-Framework für das State-Management), Redux oder MobX. Während letzteres lediglich eine Stimme bekam, setzte der Großteil der Umfrageteilnehmer (knapp 50 %) kein Drittframework ein und rund 25 % arbeiteten mit Redux, während wiederum ca. 20 % hier keine Antwort gaben, was das Ergebnis der Umfrage leider etwas verfälscht.

Sie interessieren sich für weitere Umfrageergebnisse? Dann stöbern Sie doch einfach noch ein wenig in unserem Blog, und lesen Sie, welche aktuelle Trends und Herausforderungen in der Softwareentwicklung wir auf der solutions.hamburg 2016, der OOP 2017, der WJAX 2016 oder der DWX 2017 erfragen konnten.

 

30. November 2017
Max Wielsch
0

In Sachsen, da geht was

Ein Bericht vom JUG Saxony Day 2017

Am 29. September 2017 fand im Hotel Radisson Blu Radebeul der nunmehr 4. JUG Saxony Day statt. Über 500 Teilnehmer zählte die Konferenz dieses Jahr und konnte damit ein erneutes Wachstum verzeichnen. Trotz bisher stetig steigender Teilnehmerzahlen konnte dennoch eine familiäre Atmosphäre bewahrt werden. Mit welchen Erwartungen wurde die Konferenz gestartet und wie sollen diese weiterhin erfüllt werden? Diese und weitere spannende Fragen konnte ich in einem Gespräch mit den “Machern der Konferenz” — dem JUG Saxony (e.V.) — klären.

JUG Saxony Day 2017

Copyright JUG Saxony e.V. Quelle: hier.

Der Ursprung der Konferenz sind die regelmäßigen Veranstaltungen des JUG Saxony, die immer an wechselnden Orten stattfinden, um eine Vernetzung von Java-Entwicklern und an der Softwareentwicklung Interessierten zu ermöglichen. Die Treffen in Form der User-Group-Veranstaltungen mit Vorträgen zu Themen rund um Java und Softwareentwicklung stellen ein Angebot für jedermann dar, der an der Lösung von praktischen Problemen in der Softwareentwicklung interessiert ist. Zusätzlich zu den vielen Informatik-Studiengängen in Sachsen, die ein theoretisches und teilweise praktisches Fundament für die Ausbildung von Softwareentwicklern in Sachsen bilden, stellen die Veranstaltungen von User Groups wie dem JUG Saxony ein praktisches Ergänzungsangebot dar.

In Sachsen, da geht was!

Die Veranstaltungen des JUG Saxony kamen gut an und das Feedback aus der Community ergab, dass eine ganztägige Veranstaltung wohl zu einer noch stärkeren Beteiligung und einem noch effizienteren Weg der Wissensvermittlung führen würde. Schließlich wurde 2014 der erste JUG Saxony Day (JSD) an der TU Dresden organisiert. Um einen “Blick über den Tellerrand” zu werfen und sich in der Community auszutauschen, kamen nun Jahr für Jahr mehr Besucher. Es treffen sich Softwareentwickler und Unternehmen aus Sachsen und ganz Deutschland.

Im nun vierten Jahr merkt man, dass alles “wie am Schnürchen“ läuft. Das Radisson Blu als aktueller Veranstaltungsort, aber auch die Organisation der Speaker-Tracks und Themen tragen dabei sehr zur angenehmen Atmosphäre auf dem JSD bei. Ab acht Uhr morgens trifft man die ersten bekannten Gesichter beim JSD. Mal ist es ein ehemaliger Kommilitone aus Studienzeiten. Dann sind es Kollegen, die früher einmal mit in derselben Firma oder sogar im selben Projekt gearbeitet haben. Ein Plausch über den Stand der aktuellen Projekte und das anstehende Programm des JSD sind dann natürlich Pflicht.

Neun Uhr ging der Keynote-Vortrag los: Stefan Zörner gab einen Einblick in die Methoden und Werkzeuge von Architekten und beantwortete die Frage, wie Software-Architektur im Team umgesetzt wird. Thematisch waren viele der Vorträge beim JSD sehr gut einem Teilgebiet der Architektur zuzuordnen. Mit Architektur als Meta-Thema und einem sehr breiten Spektrum an Vorträgen war also für jeden etwas dabei. Zwischen den Vorträgen fand man immer wieder zueinander, um weiter zu diskutieren. Man hatte das Gefühl, das Ambiente führte die Wege der Teilnehmer automatisch zueinander.

Die Größe des JSD ist laut dem JUG Saxony jetzt genau richtig – und laut einer Umfrage des JUG Saxony ist es genau die bereits erwähnte familiäre Atmosphäre, die die Teilnehmer so begeistert und nun schon seit vier Jahren immer wieder anlockt. Statt weiterem Wachstum wird die Erhaltung der Qualität angestrebt. Für die Zukunft hofft man auf eine stärkere Unterstützung von Community getriebenen Veranstaltungen wie dem JSD durch Politik und kommunale Institutionen. Denn mit dieser Konferenz hat die Java Community in Form des JUG Saxony eine Veranstaltung geschaffen, die Leute aus ganz Deutschland und auch dem Ausland anzieht und zeigt, dass in Sachsen in Sachen Softwareentwicklung was geht. Dieses Wertes sollte sich jedermann und insbesondere das Land Sachsen bewusst sein.

Mich persönlich haben dieses Jahr Vorträge zu Themen wie Refactoring von monolithischen Systemen, Überblick zu den Architekturbestandteilen bei Microservice-Umgebungen und auch das Logging in solchen Umgebungen und die Überwachung der Systeme angezogen.

Nächstes Jahr stehen dann gleich zwei Jubiläen an, die es zu feiern gilt: Der JUG Saxony e.V. veranstaltet sein 100. User-Group-Treffen und der JUG Saxony Day feiert seinen 5. Geburtstag. Ich persönlich freue mich schon sehr auf den nächsten JUG Saxony Day und bin sicher, dass ich auch nächstes Jahr bekannte Gesichter treffe und mir neue spannende Themen aus der Praxis von Profis anhören darf.

9. Oktober 2017
Hendrik Loesch
0

DWX 2017 – 100 Leute haben wir gefragt…

Wie schon in den vergangenen Jahren war die Saxonia Systems AG auch dieses Jahr wieder bei der Developer Week (DWX 2017)  in Nürnberg vertreten. So gestalteten wir das Programm aktiv mit Vorträgen und gewährten tiefe Einblicke in unseren Arbeitsalltag, sowie unsere Leistungen.

mehr