emineo http://blog.emineo.ch We never stop thinking for you Thu, 21 Feb 2013 19:09:58 +0000 de-DE hourly 1 http://wordpress.org/?v=3.5.1 Accessibility – Part 3 http://blog.emineo.ch/2013/02/accessibility-part-3/ http://blog.emineo.ch/2013/02/accessibility-part-3/#comments Thu, 21 Feb 2013 19:09:00 +0000 Schwyn http://blog.emineo.ch/?p=695 In diesem Blog möchte ich noch kurz einen Blick in die Zukunft werden und auf Probleme aufmerksam machen die künftig vor allem mit neueren Frameworks häufiger anzutreffen sein werden.

Web 2.0 Elemente

Mit Web 2.0 werden die Webseiten für sehende immer komfortabler und schöner. Web 2.0 Elemente können jedoch schnell zu Problemen für sehbehinderte Personen führen.

Ich möchte hier insbesondere auf drei Beispiele eingehen die wir mit der sehbehinderten Person etwas genauer angeschaut haben.

Auto-complete Feld

So durften wir miterleben wie bei unserem Workshop ein auto-complete Feld eine gesamte Webseite nahezu unbedienbar gemacht hat. Solche auto-complete Felder erleichtern den sehenden Personen die Bedienung ungemein und helfen eine möglichst komfortable Webseite zu erstellen. Für die Barrierefreiheit war dieses Element leider gar nicht zuträglich.

Durch das auto-complete Listenelement mit den Vorschlägen wurde der Screen Reader überrascht. Die bedienende Person wusste nicht mehr an welcher Stelle auf der Webseite sie sich befindet und was zu tun ist. Konkret konnte die Person nicht feststellen wenn sich der Fokus in der Vorschlags-Liste des auto-complete Feldes befand. Die Person war gefangen und konnte nicht weiterarbeiten.

Overlay-Popup

Auch ein Element, das sich immer grösserer Beliebtheit erfreut ist das Overlay-Popup. Overlay-Popups werden visuell im Vordergrund dargestellt. Das bedeutet für eine sehende Person dass die neue Information direkt im Blickfeld erscheint und die Aufmerksamkeit darauf geleitet wird. Durch ein modales Popup kann sogar eine Aktion des Benutzers erzwungen werden bevor er auf der eigentlichen Seite weiterarbeiten kann.

Wenn man sich den Quellcode einer Seite mit einem angezeigten Overlay Popups anschaut, dann sieht man jedoch dass die Overlay-Informationen im DOM und damit in der Struktur am falschen Ort eingefügt werden. Bei allen Frameworks die ich angeschaut habe konnte ich diese Problematik nachstellen. Meist werden diese Overlay-Elemente zu Beginn, am Schluss oder auf der Stufe unterhalb des <body>-Elementes eingefügt und nicht an die Stelle an der der Benutzer geklickt und damit sich zuletzt befunden hat.

Das heisst eine sehbehinderte Person merkt nicht auf Anhieb, dass eine neue Information eingeblendet wurde und muss 1. Herausfinden dass sich etwas im DOM und damit in der Struktur geändert hat und 2. Die neue Information im DOM suchen.

Mittels eines klaren Tooltips wie „Klicken Sie hier um weitere Informationen anzuzeigen“ kann die sehbehinderte Person darauf aufmerksam gemacht werden, dass neue Informationen angezeigt werden wenn Sie darauf klickt. So weiss die Person schon dass neue Informationen kommen und muss diese im Schlimmsten Falle „nur“ noch suchen.

Kalender-Elemente

Bei Kalender Elementen gelten dieselben Probleme wie bei Overlay-Popups. Meist wird beim Klick in das Input-Feld ein Kalender eingeblendet. Da sicher auch dieser visuell zwar schön platziert, aber meistens in der Struktur am falschen Ort ist, muss die sehbehinderte Person den Kalender zunächst finden um ein Datum auszuwählen.

Fazit

Um solche neue Elemente für sehbehinderte Personen ebenso vorteilhaft einsetzen zu können wie sie für sehende Personen sind, muss der Entwickler sehr viel Aufwand betreiben und viel JavaScript Fachwissen besitzen.

Es geht mir nicht darum solche Web 2.0 Elemente schlecht zu machen, sondern ich möchte viel mehr das Bewusstsein von Designer und Software-Entwickler für diese neuen Herausforderungen stärken. Neue „fancy“ Elemente sind nicht für alle Benutzer von Vorteil. Sie können unter Umständen die Barrierefreiheit einschränken und zu hohen Aufwänden führen um diese wieder herzustellen.

 

]]> http://blog.emineo.ch/2013/02/accessibility-part-3/feed/ 0 Accessibility – Part 2 http://blog.emineo.ch/2013/01/accessibility-part-2/ http://blog.emineo.ch/2013/01/accessibility-part-2/#comments Wed, 02 Jan 2013 11:52:35 +0000 Schwyn http://blog.emineo.ch/?p=688 Nachdem ich im letzten Blog einige theoretische Punkte aufgeführt habe und auch erläutert habe wie es mir bei der Umsetzung gegangen ist, kommen wir nun zum spannenderen Teil – Praxistest mit einer sehbehinderten Person.

Ich habe einige Zeit investiert um möglichst alle Erfolgskriterien zu erfüllen die von den speziellen Rahmenbedingungen möglich waren. Nochmals zur Erinnerung: Die Webseite läuft innerhalb eines SAP Netweaver Portal.

Praxistest

Um abschliessend sagen zu können ob sich die Mühe und der Aufwand gelohnt haben, musste die Webseite einer Prüfung durch eine betroffene Person standhalten. Wir hatten die Chance eine sehbehinderte Person einzuladen und waren sehr froh, dass diese Person unserer Einladung gefolgt ist. An dieser Stelle möchte ich mich nochmal herzlichst für den sehr spannenden und aufschlussreichen Nachmittag bedanken!

Während eines ganzen Nachmittags durften wir dieser Person bei der Bedienung unserer und auch anderer Webseiten sowie einigen Mobile-Apps zuschauen. Natürlich war ich vor allem auf das Fazit zu unserer eigenen Webseite gespannt.

Der Nachmittag brachte für mich einige Überraschungen zu Tage. Zum ersten Mal durfte ich einer sehbehinderten Person bei der Arbeit mit Computern über die Schulter schauen. Überraschend war vor allem die Tatsache dass nicht umgesetzte, aber gemäss WCAG grundlegende und sehr wichtige Erfolgskriterien die Person nicht so stark bei der Arbeit beeinträchtigten als ich das angenommen habe. Im Gegenzug jedoch wurde mir klar, dass einige – gemäss WCAG – weniger wichtige Erfolgskriterien die aber vom Entwickler sehr einfach umgesetzt werden können die Bedienbarkeit enorm erhöhten. Für mich haben sich die folgenden Punkte herauskristallisiert die in der Praxis enormen Einfluss auf die Bedienbarkeit der Webseite haben:

Gut strukturierter Seitenaufbau

Ein gut strukturierter Seitenaufbau erleichtert der Person die Übersicht und die Vorstellung der Seite ungemein. Zu einer guten Struktur beitragen können die folgenden Dinge:

  • Keine Überflüssigen Informationen
    Durch beschränken des Inhaltes auf die wichtigsten Informationen können Webseiten von Sehbehinderten (und meist auch von sehenden) Personen viel besser wahrgenommen und bedient werden.
  • Klare Titel und Titelstrukturen
    Dabei gilt zu beachten, dass jeder Abschnitt einen Titel hat (HTML-Tag h1, h2 etc.). Des Weiteren ist es zentral dass diese Titel einen klaren Aufbau haben und keine Titelstufe ausgelassen wird.
  • Keine nicht-Titel-Tags für Tags verwenden.
    Einige Software-Entwickler wenden CSS an um HTML-Elemente wie <span> visuell als Titel erscheinen zu lassen. Dieses Vorgehen verhindert eine klar strukturierte Webseite.

Die Seitenstruktur kann vom Entwickler einfach überprüft werden indem er das CSS ausschaltet. Ist das CSS ausgeschaltet und die Seite dennoch übersichtlich und klar strukturiert hat er das Ziel erreicht.

  • Aufzählungen immer als Liste
    Je nach Designvorgabe ist es für den Entwickler manchmal einfacher eine Tabelle für Aufzählungen zu verwenden. Für eine sehbehinderte Person stellt dies einige Probleme bei der Interpretation des Inhaltes dar. Listen werden vom Screen Reader speziell angesagt und helfen so der sehbehinderten Person sich auf der Seite und in den Aufzählungen zurechtzufinden.
  • HTML-Tags möglichst vollständig verwenden
    Das bedeutet dass z.B. für Grafiken immer ein Alternativ Text angezeigt wird. Auch die neueren ARIA-Attribute können dem Screen Reader die nötigen Informationen für die Interpretation des Inhaltes geben.

Werden diese relativ wenigen, aber aus meiner Sicht zentralen Verbesserungen umgesetzt, kann sich eine sehbehinderte Person schnell auf der Webseite zurechtfinden und die Webseite schon sehr gut bedienen.

Wie sich während des Nachmittags herausgestellt hat werden die Software Entwickler auch im Bereich der Barrierefreiheit immer neue Probleme antreffen. Im nächsten Blog wage ich einen kleinen Ausblick auf diese Probleme die künftig wohl vermehrt anzutreffen sind.

]]> http://blog.emineo.ch/2013/01/accessibility-part-2/feed/ 0 Accessibility – Part 1 http://blog.emineo.ch/2012/12/accessibility-part-1/ http://blog.emineo.ch/2012/12/accessibility-part-1/#comments Tue, 18 Dec 2012 20:30:48 +0000 Schwyn http://blog.emineo.ch/?p=679 Bei vielen Software Entwicklern von Web-Anwendungen ist das Bewusstsein für Barrierefreiheit eher gering ausgeprägt. Der Grund liegt meiner Meinung darin, dass die Barrierefreiheit zu wenig thematisiert wird.

So war das auch bei mir. In der Ausbildung wurde das Thema gänzlich umschifft und auch während den ersten Jahren meiner Berufstätigkeit wusste ich zwar dass es so etwas wie Barrierefreiheit gibt, aber mehr auch nicht. Seit ungefähr 2 Jahren beschäftigt mich dieses Thema nun etwas mehr.

Wie geht man vor wenn man eine Webseite Barrierefrei machen soll?

Nun, ich habe mich zu Beginn durch sämtliche Richtlinien und Dokumente von W3C gearbeitet und versucht mittels eines Freeware – Screen Readers einen Einblick in diese Welt zu erhalten.

Die W3C Richtlinien können unter http://www.w3.org/WAI nachgelesen werden. Ich werde mich im Folgenden um die Richtlinien für Web Content (WCAG) kümmern und nur auf diesen Bereich eingehen.  Zu WCAG möchte ich nur so viel sagen, dass es 3 verschiedene Conformance-Levels gibt die erreicht werden können. Dabei steht Level „A“ für das niedrigste und Level „AAA“ für die höchste Stufe. Die unterschiedlichen Stufen können erreicht werden indem die der Stufe zugeordneten Erfolgskriterien erfüllt werden.

Detaillierte Informationen zu den einzelnen Levels können hier nachgelesen werden: http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head.

Die Erfolgskriterien und die W3C Richtlinien für Web Content (WCAG) können hier http://www.w3.org/TR/WCAG20 nachgelesen werden.

Tönt alles sehr theoretisch? Ist es auch.

Jedenfalls war es für mich sehr theoretisch. Zwar sind die einzelnen Erfolgskriterien logisch und verständlich, aber ich hatte Mühe damit zu beurteilen, was es heisst wenn ein Erfolgskriterium nicht umgesetzt ist. Ich habe sehr viel gelesen und versucht die einzelnen Kriterien die in den Rahmenbedingungen umsetzbar waren anzugehen.

Zu den Rahmenbedingungen sei gesagt, dass die betreffende Webseite innerhalb des SAP Netweaver Portals läuft und dies die Umsetzung der Erfolgskriterien nicht gerade eben vereinfachte und teilweise sogar die Umsetzung verhinderte.

Zurück zur Umsetzung. Für mich waren die Umsetzungen abstrakt, deshalb weil ich zwar wusste was ich theoretisch machen muss, das Resultat aber nicht interpretieren konnte. Hinzu kommt, dass ich als sehender Mensch die visuelle Darstellung automatisch in den Fokus rückte. Ich hatte die Design-Vorgaben und habe versucht diese möglichst Detailgetreu umzusetzen. Meist ist diese detailgetreue Umsetzung schon schwierig genug und verlangt hohe Konzentration. Dies zusammen mit dem fehlenden Bewusstsein für Barrierefreiheit führte bei mir dazu, dass ich immer wieder merkte, dass ich das Augenmerk auf die Barrierefreiheit verloren habe. Ich musste mich immer wieder zwingen, die Erfolgskriterien wieder in den Fokus aufzunehmen und hin und wieder auch den Screen Reader zu verwenden.

Da die Vorgaben bzw. die Erfolgskriterien klar und verständlich sind, konnte ich ohne wirklich zu wissen wie sich diese Schlussendlich auswirken dennoch die Webseite nach den Erfolgskriterien gestalten und anpassen.

Was ich auf diese Weise im Idealfall erreicht habe ist eine WCAG-konforme Webseite die auch noch schön aussieht. Ob sich der Aufwand für die Barrierefreiheit auch gelohnt hat und ob sich die Webseite von sehbehinderten Personen bedienen lässt und diese vom zusätzlichen Aufwand profitieren können werde ich im nächsten Blog erläutern.

]]> http://blog.emineo.ch/2012/12/accessibility-part-1/feed/ 0 Unterschätzt das Management die Entwickler? http://blog.emineo.ch/2012/08/unterschatzt-das-management-die-entwickler/ http://blog.emineo.ch/2012/08/unterschatzt-das-management-die-entwickler/#comments Sat, 18 Aug 2012 14:10:28 +0000 Grüninger http://blog.emineo.ch/?p=673 An der diesjährigen Jazoon [http://jazoon.com] gab es wieder viele interessante Beiträge. Mich haben dabei vor allem Vorträge zu gutem Software Design interessiert.

So hebt z.B. I. Kellner im Vortrag „How to keep your Architecture in good Shape?!” die Wichtigkeit einer sauberen Softwarearchitektur hervor, mit klareren Abgrenzungen der Komponenten sowohl vertikal (Schichtenmodell) als auch horizontal (Domänen). Dabei sollen etwa 20 Prozent der Projekt-Resourcen für das Refactoring eingeplant werden, um der Erosion der Softwarearchitektur über die Zeit entgegenzuwirken.

Aus eigener Erfahrung weiss ich, dass dieser Aufwand gerne vergessen geht bzw. schwer zu verkaufen ist. Besonders wichtig finde ich, dass bei jeder Anpassung auch das Design im Auge behalten wird und man auch vor grösseren Refactorings zur Verbesserung der Softwarequalität nicht zurückschreckt (man könnte dies auch „Continuous Refactoring“ nennen). Denn desto früher man diese rein technischen Anpassungen durchführt, desto kleiner ist normalerweise der Gesamtaufwand und man kann damit viel zukünftigen Frust vermeiden.

Zur Unterstützung dieses Prozess empfiehlt Herr Kellner den Einsatz von Metriken, wodurch die aktuelle Qualität der Architektur quantifiziert und somit bewusst verbessert werden kann. So kann mittels der „Kopplungs“ Metrik zirkulären Abhängigkeiten der Softwarekomponenten entgegen gewirkt werden.

Im Zusammenhang mit Metriken sind auch die Ausführungen von J. Bächtiger im Vortrag „How to fake metrics – Or how valid are metrics?” sehr interessant. Herr Bächtiger weist auf das Problem hin, dass von oben verordnete Metrik-Ziele die Situation verschlechtern anstatt verbessern können. Dies deshalb, weil der Hauptfokus nicht mehr auf das eigentliche Problem gelegt wird, sondern auf das Optimieren der Metriken. So kann z.B. die verbindliche Vorgabe einer maximalen Anzahl kritischer Probleme (critical and major Issues) dazu führen, dass kritische Probleme von den Entwicklern nicht mehr als solche gekennzeichnet werden, dass kritische Probleme ungelöst geschlossen werden oder dass die Fehler nicht mehr im offiziellen Fehlerverwaltungssystem erfasst werden. All diese Massnahmen verbessern zwar die Metrik, verschlechtern aber die Qualität der Entwicklung.

Weiter muss mit Metriken beachtet werden, dass wirklich das gemessen wird, was gemessen werden soll. In diesem Zusammenhang wurden im Vortrag unter anderem das Simpson-Paradoxon [http://de.wikipedia.org/wiki/Simpson-Paradoxon] und der Hawthorne Effekt [http://de.wikipedia.org/wiki/Hawthorne-Effekt] erwähnt. Die Schlussfolgerung von Herrn Bächtiger war, dass der Einsatz von Metriken höchstens dann erfolgreich sein kann, wenn sie vom Entwicklungsteam für sich selber aufgestellt werden.

Am meisten hat mich aber der Vortrag „From V-Model to Scrum“ von M. Talamona und R. Willimann beeindruckt. Sie entwickelten in ihrer Firma ERP-Lösungen mit 120 Entwicklern nach dem klassischen V-Model [http://en.wikipedia.org/wiki/V-Model_(software_development)]. Die Entwicklung wurde mittels einer komplexen Managementstruktur über vier Ebenen geleitet. Dies führte dazu, dass die Produktivität über die Jahre sank, schlussendlich konnte anstatt der vier geplanten Releases in einem Jahr nur noch eines fertiggestellt werden. Der Leidensdruck war schlussendlich so gross, dass man sich zu einer radikalen Umorganisation entschieden hat. Nach intensiver Vorbereitungszeit wurde der Entwicklungsprozess auf Scrum [http://de.wikipedia.org/wiki/Scrum] umgestellt. Da sich im Scrum-Model die Teams selbst organisieren können und sollen, konnten die zwei untersten Managementebenen komplett gestrichen werden. Die Umstellung lag beim Zeitpunkt des Vortrages etwa ein halbes Jahr zurück, und die Auswirkungen waren bisher als sehr positiv berichtet. So konnten innerhalb dieses halben Jahres schon wieder 4 Releases fertiggestellt werden.

Der Vortrag wurde vom Management gehalten und für mich als Entwickler war es fast befremdlich zu hören, dass man sich sehr überrascht zeigte, dass die Entwicklerteams fähig sind sich selber zu organisieren und Angelegenheiten wie die Sitzordnung selber zu entscheiden.

Wie bei jedem Vortrag fragte ich mich natürlich auch hier, was ich daraus für mich bei meiner täglichen Arbeit mitnehmen kann. Einerseits ist die Situation in der emineo AG alleine schon wegen der Firmen- und Projektgrösse nicht vergleichbar mit der Firma im Vortrag. So können wir in der emineo AG dank kleineren Projektteams und kurzen Entscheidungswegen den Verwaltungsoverhead klein halten und schnell auf die Kundenbedürfnisse reagieren. Andererseits ist gerade bei einer relativen kleinem Unternehmen wie bei uns, wo Entwickler mehr Freiheiten geniessen, wichtig einen strukturierten Entwicklungsprozess anzuwenden und zu pflegen. Nicht stur aber sinnvoll.

Hinweis: Die Handouts der Jazoon Präsentationen sind auf der Webseite [http://jazoon.com] unter dem Punkt „Downloads“ frei zugänglich.

]]> http://blog.emineo.ch/2012/08/unterschatzt-das-management-die-entwickler/feed/ 0 Business Prozessinstanzen in SAP NetWeaver http://blog.emineo.ch/2012/05/business-prozessinstanzen-in-sap-netweaver/ http://blog.emineo.ch/2012/05/business-prozessinstanzen-in-sap-netweaver/#comments Tue, 08 May 2012 09:58:56 +0000 boehm http://blog.emineo.ch/?p=662 Teil 2: Business Prozessinstanzen in SAP NWA beobachten und nachvollziehen

Im ersten Teil dieses Artikels wurde die Ansicht von laufenden Prozessinstanzen beschrieben. In diesem zweiten Teil gehe ich auf die Ansicht abgeschlossener Prozessinstanzen, den log-Viewer und Rollen ein, welche für die Prozessadministration notwendig sind.

Abgeschlossene Prozessinstanzen anzeigen

Manchmal ist es auch hilfreich, nicht nur fehlerhaften Vorgängen nachzuspüren, sondern auch erfolgreiche Prozesse anzuzeigen: wann wurde ein Prozess abgeschlossen, welchen Verlauf nahm der Prozess oder wann fand ein bestimmter Prozessschritt statt? Standardmässig zeigt die Ansicht ‚Prozesse verwalten‘ nur fehlerhafte oder aktuell laufende Prozesse an. Erweitert man die Suchoptionen jedoch mittels des unscheinbaren Links ‚Erweitert‘, so lassen sich auch Prozesse in allen anderen Stati anzeigen. Es stehen dann ebenfalls die im 1.Teil beschriebenen Darstellungsoptionen der Prozesshistorie zur Verfügung. So lässt sich minutiös der Ablauf eines Prozesses nachvollziehen.

Einträge im Log Viewer

Via ‚Problemmanagement‘ -> ‚Protokolle und Traces‘ gelangt man zum Log Viewer. Dieser zeigt sämtliche Logeinträge aller aktivierter Komponenten und vom SAP CE System selbst. Da die Darstellung chronologisch erfolgt, ist sie für die Nachvollziehbarkeit eines Prozessablaufes unübersichtlich. Jedoch kann sie gerade für die Fehlerursachensuche wertvolle Details und Zusammenhänge liefern. Hier werden die programmatischen Logeinträge des SAP-Loggers angezeigt. Der Log-Level einzelner Java-Klassen oder Packages wird in der Protokollkonfiguration gesetzt: ‚Problemmanagement‘ -> ‚Protokolle und Traces‘ -> im Feld ‚Anzeigen:‘ den Wert ‚Trace-Orte‘ auswählen. Anschliessend kann im Hierarchiebaum das gewünschte Package oder die Klasse ausgewählte werden und die Gewichtung (Log-Level) gesetzt werden. Mittels Button ‚Zum Teilbaum kopieren‘ wird die gewählte Gewichtung auf alle darunterliegenden Packages und Klassen kopiert.

Berechtigungen

Nicht nur der Zugang zu den Ansichten im NWA, welche eine Prozessüberwachung ermöglichen, sondern auch die Durchführbarkeit von Funktionalitäten der verschiedenen Ansichten werden über Rollen gesteuert. Hier ein Kurzüberblick über die Rollen und deren Berechtigungen:

  • SAP_BPM_SuperDisplay: berechtigt zur Anzeige aller Administrationsseiten von Prozessen und Aufgaben im NWA
  • SAP_BPM_SuperAdmin: berechtigt zur Anzeige aller Administrationsseiten von Prozessen und Aufgaben im NWA (wie SAP_BPM_SuperDisplay) und ermöglicht das Bearbeiten von Prozessen und Aufgaben und Starten von Prozessen
  • NWA_READONLY: berechtigt zur Anzeige aller Seiten im NWA
  • NWA_SUPERADMIN: berechtigt zur Anzeige (wie NWA_READONLY) und zum Management aller Seiten im NWA (aber nicht zum Starten von Prozessen)
]]> http://blog.emineo.ch/2012/05/business-prozessinstanzen-in-sap-netweaver/feed/ 0 Business Prozessinstanzen in SAP NetWeaver http://blog.emineo.ch/2012/04/business-prozessinstanzen-in-sap-nwa/ http://blog.emineo.ch/2012/04/business-prozessinstanzen-in-sap-nwa/#comments Mon, 30 Apr 2012 09:52:21 +0000 boehm http://blog.emineo.ch/?p=649 Teil 1: Business Prozessinstanzen in SAP NWA beobachten und nachvollziehen 

Gerade während der Entwicklung von Applikationen mit SAP BPM als auch im Betrieb der produktiven Applikation ist es unerlässlich, die Business Prozesse beobachten zu können. Nur so lässt sich ein auftretender Fehler identifizieren, dessen Ursache herausfinden und überhaupt der korrekte Verlauf eines Prozesses feststellen. SAP bietet mit dem NetWeaver Administrator (NWA) ein weit entwickeltes Werkzeug, um die SAP Business Prozesse detailliert beobachten zu können. Dieser Beitrag bezieht sich auf die NWA Version 7.2.

Im hier vorliegenden ersten Teil gehe ich auf die Ansicht von laufenden Prozessinstanzen ein. Im nachfolgenden, zweiten Teil wird die Ansicht abgeschlossener Prozessinstanzen, der log-Viewer und Rollen, welche für die Prozessadministration notwendig sind, beschrieben.

Laufende Prozessinstanzen und Instanzen im Fehlerstatus anzeigen

Um alle Prozessinstanzen eines Prozesses aufzulisten: Entweder ‚Operationsmanagement‘ -> ‚Prozesse und Aufgaben‘ -> ‚Prozesse verwalten‘ oder ‚Konfigurationsmanagement‘ -> ‚Prozesse und Aufgaben‘ -> ‚Prozess-Repository‘: BPM-Komponente auswählen -> unter Fenster ‚Details von Komponente …‘ : ‚Prozesse und Aufgaben‘ den Prozess anklicken. Nun werden alle (aktuell laufende, abgeschlossene, abgebrochene und im Fehlerstatus) Prozessinstanzen aufgelistet. Im Tab ‚Historie‘ (am besten ‚Anzeigen: Mittel‘ selektieren) werden alle durchgeführten Anwendungsschritte gelistet, so dass sich nachvollziehen lässt, welche WebService-Aufrufe durch das BPM und in welcher Reihenfolge diese durchgeführt wurden.

Mittels ‚Anzeigen: Erweitert‘ wird auch angezeigt, ob und wann Veränderungen an welchen Datenobjekten stattgefunden hat. Im Tab ‚Kontextdaten‘ wird der Wert aller Datenobjekte angezeigt. Wurde ein Datenobjekt während des Prozessablaufes (mehrfach) aktualisiert, so wird dieses Datenobjekt entsprechend seiner Anzahl Aktualisierungen mehrfach aufgelistet und chronologisch absteigend sortiert. Wird im Prozess z.B. ein Datenobjekt (Tracer) implementiert, welches bei jedem Prozessschritt aktualisiert wird und lediglich den aktuellen Prozessschritt kennzeichnet, lässt sich hier sehr schnell und einfach feststellen, in welchem aktuellen Prozessschritt der Prozess sich befindet und so kann der durchgeführte Prozessverlauf sehr einfach nachvollzogen werden.

Natürlich lässt sich der Prozessverlauf auch im Tab ‚Historie‘ anhand der durchgeführten Anwendungsschritte erkennen. Ein solches Tracer-Datenobjekt erscheint mir aber einfacher und schneller erkennbar.

Bei Prozessinstanzen, bei denen im Prozessverlauf ein Fehler auftrat und sie sich somit im Fehlerstatus befinden, werden im Tab ‚Fehlerprotokoll‘ die Error-Log Einträge für diese Instanz chronologisch gelistet. Diese Ansicht entspricht zwar den Error-Log Einträgen in der Log-Viewer Ansicht (in ersterer Ansicht ist die Zeilenanzahl begrenzt, die dargestellten Informationen dürften aber in jedem Fall ausreichen), sie werden hier aber übersichtlich in Abhängigkeit ihres Contextes dargestellt. Wenn z.B. ein WebService-Aufruf durch eine Prozessaktivität wegen erfolglosen Verbindungsaufbaus drei Mal durchgeführt wird, so werden alle dazugehörigen Fehlerlogs in diese drei Versuche gegliedert. Es entfällt das mühsame Filtern und Zuordnen der einzelnen Logeinträge zu einem Vorgang wie es in der Log-Viewer-Ansicht notwendig ist. Zwar wird im Fehlerprotokoll kein Datum und Uhrzeit angegeben. Aber diese dürfte immer dem zuletzt erfolgten Ereignis in der Historie der Prozessinstanz entsprechen.

Kann die Ursache eines Prozessfehlers behoben werden, kann ein angehaltener Prozess mittels Button ‚Actions‘ -> ‚Wiederaufnehmen‘ fortgeführt werden. Dabei wird der vormals fehlerhafte Prozessschritt erneut ausgeführt. Ebenso kann hier mittels Aktion ‚Abbrechen‘ ein Prozess abgebrochen werden, dessen Fehlerursache nicht behoben werden kann und der Prozess somit niemals beendet werden kann.

Ist der Tab ‚Historie‘ aktiviert, so wird der Link ‚Protokolle des Geschäftslebenszyklus anzeigen‘ im Tab dargestellt. Dadurch gelangt man auf die Log-Anzeige ‚Geschäftsprotokolle‘, welche detailliertere Angaben zu den Einträgen im Tab ‚Historie‘ darstellt. So kann man hier z.B. die Werte der Aufrufparameter und Rückgabeparameter von WebService-Aufrufen durch das BPM sehen, Werte von eingehenden Nachrichten oder auch den neuen Wert bei Aktualisierung von Datenobjekten. Via der Auswahlliste des anzuzeigenden Zeitraumes sind nur Einträge bis maximal der letzten 7 Tage darstellbar. Allerdings kann mittels des einblendbaren Query-Bereiches ein beliebiger Zeitraum eingegeben werden, nach dem die Einträge nach dem Anlegezeitstempel gefiltert werden können.

Im nachfolgenden, zweiten Teil wird die Ansicht abgeschlossener Prozessinstanzen, der log-Viewer und Rollen, welche für die Prozessadministration notwendig sind, beschrieben.

]]> http://blog.emineo.ch/2012/04/business-prozessinstanzen-in-sap-nwa/feed/ 0 Rapid Application Development mit Spring Roo http://blog.emineo.ch/2012/01/rapid-application-development-mit-spring-roo/ http://blog.emineo.ch/2012/01/rapid-application-development-mit-spring-roo/#comments Sun, 29 Jan 2012 17:15:04 +0000 Nadworny http://blog.emineo.ch/?p=634 Wie oft haben Sie als Software Entwickler die gleichen Schritte während eines neuen Projektes wiederholt? Wie viel Zeit haben Sie für die Konfiguration Ihrer Entwicklungsumgebung aufgewendet? Wie oft mussten Sie die gleichen Bibliotheken herunterladen oder ähnliche Funktionalitäten (wie Reporting, Mailing oder Batchjobs) implementieren, obwohl Sie es schon in einem anderen Projekt umgesetzt haben? Und was ist mit der Validierung der Formulare oder Java-Beans? Automatisierte Tests von Backend oder Frontend? Es gibt viele Java-Standards, die uns bei vielen Aufgaben unterstützen. Um alle vollständig zu kennen, braucht man ein breites Fachwissen, eine grosse Erfahrung und was noch wichtiger ist – Zeit um in eine ständige Forschung zu investieren und zu überprüfen, ob die Standards, die wir aktuell benutzen, nicht bereits veraltet sind.

Gibt es nicht einen einfacheren Weg, um all diese Fragen ohne grossen Aufwand zu beantworten? Wäre es nicht sinnvoll ein Werkzeug zu haben, das die meisten alltäglichen Entwickleraufgaben automatisiert und die allgemein verwendeten Java-Standards integriert? Es scheint, dass im Java-Bereich Spring (www.springsource.org) der erste Kandidat ist, welcher uns eine universelle Lösung anbieten kann. Sie heisst Spring Roo (www.springsource.org/spring-roo) und ich will es ihnen in diesem Blog ausführlich beschreiben.

Spring Roo’s Ziel ist es “grundlegend und nachhaltig die Produktivität der Java-Entwickler zu verbessern ohne die technische Integrität und Flexibilität zu beeinträchtigen” und ermöglicht eine schnelle Entwicklung für Java EE Anwendungen.

Spring Roo ist ein Software-Werkzeug zur Generierung von Java Web Anwedungen mit CRUD-Funktionalität. Dies bedeuet, der Anwender kann die Entitäten erstellen, lesen, finden, auflisten, aktualisieren und entfernen. Spring Roo bietet uns mehrere technologische Optionen, wie:

  • verschiedene Anbieter für die JPA-basierte Persistenz (z.B. Hibernate oder OpenJPA)
  • Spring MVC-Controller
  • Frontend basierend auf JSPs, JSP 2.0, Google Web Toolkit (GWT) oder Flex

Wenn Sie z.B. Ihren Persistenz-Provider wechseln möchten, so können Sie dies ganz einfach machen. Oder wenn Sie z.B. einen JSON-Ausgang zu Ihren Controllern oder eine neue Service-Ebene hinzufügen möchten, so können Sie dies mit einem geringem Aufwand und ein paar wenigen Befehlen erledigen. Alles was von Roo generiert wird, hat eine vernünftige Standard-Konfiguration, so dass nur sehr wenig Konfigurationsaufwand nötig ist. Spring Roo ist stark abhängig von den Spring Kernkomponenten und AspectJ’s Inter-Deklaration Features (welche ich in den nächsten Blog-Beiträgen detaillierter beschreiben werde).

Das Werkzeugset von Spring Roo kann mit sehr wenig Konfiguration-Overhead sowohl den Java-Code generieren als auch eine Menge von Standard-Modulen in einem Java-EE-Projekt integrieren, so dass Sie immer die Wahl haben, alles was Sie brauchen, zu ändern. So können Sie mit ein paar einfachen Befehlen die Technologien wie Mailing, Batchjobs, JSON für REST oder Solr für die Volltextsuche integrieren.

Sie denken, Spring Roo klingt zu schön, um wahr zu sein? Ich möchte Ihnen an einem einfachen Bespiel zeigen, dass es wirklich funktioniert!

Roo selbst ist eine Java-Anwendung und kann ohne zusätzliche Hilfsmittel verwendet werden. Sobald Sie mit Ihrem Roo-Projekt bereit sind, können Sie mit einem Roo-Befehl ein Java-Projekt generieren. Ab diesem Zeitpunkt können Sie das Projekt normal in Ihrer Entwicklungsumgebung (z.B. Eclipse) verwenden. Der bequemere Weg ist jedoch, Roo als ein Eclipse-Plugin zu verwenden oder eine spezielle und konstenlose Eclipse-Version von Spring (STS), welche das Roo-Plugin perfekt integriert, herunterzuladen. Ich selbst würde STS empfehlen und das folgende Beispiel wurde auch mit STS erstellt. Roo benutzt eine Kommandozeile (Shell) Schnittstelle mit leicht zu verstehenden Befehlen. Lassen Sie uns also die Spring Roo Konsole starten. Mit dem Befehl “hint”, erhalten Sie jederzeit Tipps.

Wir haben bereits mit Hilfe von STS ein Projekt erstellt. Normalerweise kann man Roo von der Kommandozeile starten und folgende Befehle ausführen:

roo> project --topLevelPackage ch.emineo.showcase
roo> perform eclipse

An dieser Stelle haben wir ein Eclipse Projekt mit bereits konfiguriertem Maven, welches alle Bibliothek-Abhängigkeiten pflegt. Jetzt werden wir die Java Persistenz mit Hibernate als Provider und MySQL als Datenbank hinzufügen (vergessen Sie nicht, dass Sie TAB oder STRG-SPACE jederzeit drücken können, um die Auto-Vervollständigung zu bekommen):

roo> persistence setup --database MYSQL --provider HIBERNATE

Dieser Befehl erzeugt alle benötigten Konfigurationsdateien (und Abhängigkeiten) und füllt diese mit Standardwerten.

Lassen Sie uns jetzt zwei Entitäten (Unternehmen und Mitarbeiter) mit ein paar Feldern erstellen, die Beziehung zwischen diesen beiden (Unternehmen können mehrere Mitarbeiter haben) definieren, Beans-Validierung hinzufügen und JUnit-Tests generieren. Um dies zu erledigen brauchen wir wirklich ganz wenige Befehle:

roo> entity --class ~.domain.Company –testAutomatically
~.domain.Company roo> field string --fieldName name --notNull --sizeMin 2
~.domain.Company roo> entity --class ~.domain.Employee –testAutomatically
~.domain.Employee roo> field string --fieldName lastname --notNull --sizeMax 40
~.domain.Employee roo> field reference --fieldName company --type Company
~.domain.Employee roo> focus --class ch.emineo.showcase.domain.Company
~.domain.Company roo> field set --fieldName employees --type Employee

Das war’s. Nach der Erstellung des Datenmodells können wir jetzt die Integrations-Tests mit der MySQL-Datenbank durch den Befehl “perform tests” direkt von Roo ausführen lassen.

Die Entitäten, die gerade generiert wurden, bieten eine grundlegende Funktionalität (Erstellen, Suchen, Löschen, etc.). Aber was sollen wir machen, wenn wir einen Mitarbeiter aufgrund seines Nachnamen und für das spezifische Unternehmen suchen möchten? Kein Problem, es steht für uns eine Liste mit bereits generierten “Finders” (die schlussendlich mit Spring Data http://www.springsource.org/spring-data generiert werden) zur Verfügung:

~.domain.Employee roo> finder list --filter lastname
~.domain.Employee roo> finder add --finderName findEmployeesByLastnameLikeAndCompany

Jetzt können wir die neu generierte Methode einfach in unserer Anwendung benutzen:

Employee.findEmployeesByLastnameLikeAndCompany(lastname, company)

Trotz breiter Funktionalität (wie suchen, ändern, löschen, toString, etc.), welche für uns zur Verfügung steht, sieht unsere Mitarbeiter-Klasse immer noch ordentlich und sehr übersichtlich aus (die Zauberei von AspectJ):

@RooJavaBean
@RooToString
@RooEntity(finders = { "findEmployeesByLastnameLikeAndCompany" })
public class Employee {
     @NotNull
    @Size(max = 40)
    private String lastname;
    @ManyToOne
    private Company company;
}

Nun, unser Datenmodell ist fertig und wir wollen eine Web-Ebene (Frontend) zu unserer Anwendung hinzufügen:

~.domain.Company roo> web mvc setup 
~.domain.Company roo> web mvc all --package ~.web

Dieser Befehl scannt unser Projekt nach Entitäten und erstellt automatisch die MVC-Controllers (mit REST-Muster) mit den entsprechenden JSP-Seiten, Tiles, CSS-Dateien, Grafiken und Themes. Von nun an können wir unsere Anwendung durch den Maven-Befehl im Tomcat deployen und danach gleich testen:

~.web roo> perform command --mavenCommand tomcat:run

Unser Frontend sieht jetzt wie folgt aus:

 

 

 

 

Vielleicht möchten wir einige andere Funktionen hinzufügen? Eine Sicherheits-Ebene? Lassen Sie uns die grundlegende Benutzer-Authentifizierung für unser Frontend integrieren:

~.web roo> security setup

Wollen Sie die Frontend-Seiten automatisch testen? Kein Problem, wir können mit Hilfe von Selenium (ein bekanntes Framework für Webanwendungen – http://seleniumhq.org) die Tests mit dem Firefox-Browser ausführen:

~.web roo> selenium test --controller ~.web.CompanyController

Das wäre alles für heute. Wie Sie sehen können, innerhalb weniger Minuten haben wir fast die vollständige Web-Anwendung mit JPA, Hibernate, MySQL, JSP mit Tiles, CSS, Security, Backend und Frontend Tests umgesetzt. Roo bietet aber noch viel mehr Möglichkeiten, welche wir hier gar nicht erwähnt haben. Was noch sehr interresant ist, wir können zum Beispiel den Datenbank-Anbieter in einigen Sekunden mit einem einzigen Befehl wechseln. Das Beste an Roo ist, dass man die Anwendung weiter in seiner Entwicklungsumgebung entwickeln kann, ohne Roo zu verwenden, was dazu führt, dass man (wie von Spring beworben) schneller entwickeln kann, ohne die technische Integrität und Flexibilität zu beeinträchtigen.

Stolperfallen? Wie bei vielen neuen Technologien gibt es wohl Probleme, die am Anfang schwierig werden. Roo ist ein ziemlich neues Werkzeug (2009) und hat noch einige Bugs. Wenn wir Spring Roo intern mehr und mehr benutzen werden, finden wir sicher einige Bugs und wir können Ihnen die Schwierigkeiten des Roo in einem weiteren Blog mitteilen. Spring Roo ist aber bereits zu diesem Zeitpunkt ein wertvolles Tool, welches uns Entwickler sicherlich bei unseren alltäglichen Problemen (die fast bei jedem neuen Projekt auftreten) helfen kann.

Haben Sie Erfahrungen mit anderen RAD Frameworks / Werkzeuge wie Grails oder Ruby on Rails und würden diese gerne mitteilen? Bitte tun Sie dies in den Kommentaren unten!

]]> http://blog.emineo.ch/2012/01/rapid-application-development-mit-spring-roo/feed/ 2 SAP Electronic Medical Record (EMR) http://blog.emineo.ch/2012/01/sap-electronic-medical-record-emr/ http://blog.emineo.ch/2012/01/sap-electronic-medical-record-emr/#comments Mon, 23 Jan 2012 11:45:34 +0000 winkler http://blog.emineo.ch/?p=620 Im letzten Jahr hat SAP das erste Mal ihre mobile Applikation für das Gesundheitswesen angekündigt und auch bereits Prototypen auf dem iPad präsentiert. Die SAP  EMR (Electronic Medical Record), wie die App von der SAP genannt wird, ist auf Ärzte und Pflegepersonal ausgerichtet und erlaubt es jederzeit und von überall auf die Patientendaten über mobile Endgeräte zuzugreifen. Die EMR App bietet Zugriff auf alle relevanten Daten wie sie für die verschiedenen Tätigkeiten im Krankenhaus benötigt werden. Im Standard Lieferumfang enthalten sind Sichten auf Patientendaten, Vitalfunktionen, Laborwerte, Röntgenbilder, klinische Befunde und weitere Dokumente im Zusammenhang mit der Behandlung des Patienten.

An einem EMR Workshop für Partner in Walldorf letzte Woche hat die SAP die Applikation und den aktuellen Stand der Entwicklung näher vorgestellt –  was Anlass dazu gibt dies hier kurz vorzustellen.

Fokussierung auf den Mensch und seine Bedürfnisse und Ansprüche

Die Bedienung der App ist intuitiv und zu 100% auf die Bedürfnisse der Benutzer ausgerichtet. Das ist insbesondere in Bezug auf die Tatsache, dass es sich um eine mobile Anwendung handelt, welche bestehende Daten und Funktionen von SAP Backend Systemen zur Verfügung stellt, keine Selbstverständlichkeit! Entgegen der klassischen Fokussierung auf Systeme und Prozesse, wo es im Wesentlichen darum geht, die bestehenden Funktionen und Daten einfach mobil bereitzustellen, wurde bei der Entwicklung der EMR konsequent auf die Bedürfnisse des Benutzers eingegangen. Die EMR App wurde von Personen designed, welche keine Kenntnisse der bestehenden Funktionen und Systeme hatten, sondern sich ausschliesslich zusammen mit Ärzten und Pflege Personen der Analyse der realen Prozessen und der Aufnahme der Bedürfnisse widmeten. Der zentrale Grundsatz bei der Entwicklung war der Leitsatz „User experience is everything“ und dieser wurde konsequent angewendet was sich im Resultat eindeutig zeigt.

Ausrichtung auf Offenheit und Erweiterbarkeit

Ein weiterer wesentlicher Aspekt der EMR App (und vielleicht auch eher untypisch für eine SAP basierte mobile Lösung) ist die Ausrichtung auf Offenheit und Erweiterbarkeit. Die App kommuniziert ausschliesslich mit einer Middleware, dem SAP EMR Mobile Server. An diesen können Backend Systeme über sog. Konnektoren angebunden werden, welche individuell in die bestehenden Systeme integriert werden. Damit wird die Möglichkeit gegeben, für die mobile EMR Anwendung beliebige Backend Systeme zu nutzen, sowohl SAP wie auch Non-SAP System.

Darüber hinaus wurde die Möglichkeit geschaffen, über sog. „Facetten“ eigene Informations- und Anwendungskomponenten zum Patienten in die App einzubinden. Dadurch können bestehende Applikationen von Drittanbietern einfach eingebunden oder neue Facetten für bestehende Lösungen implementiert werden. Die SAP versteht ihre EMR ganz klar als eine Art „Framework“ für die Implementierung von mobilen Lösungen für das Gesundheitswesen, welches mit vorgefertigten Applikationskomponenten ausgeliefert wird, aber individuell auf die Bedürfnisse und vorhandenen Systeme ausgerichtet werden kann.

Rasche Implementierungszeit, sofern der Standard genutzt wird

Im Zusammenspiel mit dem SAP eigenen KIS System (IS-H*MED) kann die Lösung fast zu 100% „out-of-the-box“ genutzt werden. Einzig für die Darstellung von Röntgenbildern benötigt es eine Integration in ein bestehendes PACS. Für letzteres gibt es vorgefertigte Schnittstellen, welche bei Kunden auch bereits im Einsatz sind. Bei der Charité Berlin, einem grossen Gesundheitsdienstleister in Deutschland bei welchem die EMR im Einsatz ist, erfolgte die initiale Einrichtung der EMR anscheinend innert 5 Tagen. Dies war möglich, da sich die Installation und das anschliessende Customizing sehr einfach gestalten. Es war auch ganz klar das Ziel der SAP, eine Lösung zu bringen, welche rasch und einfach zu implementieren ist und so einen leichten Einstieg in das Thema mobile Lösung ermöglicht. Auf der anderen Seite muss aber auch erwähnt werden, dass ohne ein vorhandenes SAP KIS System die gesamte Integration in Backend Systeme zusätzlich zur Implementation noch erfolgen muss – und dann ist eine Implementierung in so kurzer Zeit kaum mehr möglich.

Integrationsmöglichkeiten sind noch nicht vollständig gegeben

Aus technologischer Sicht kommuniziert die EMR App über oData (Open data Protocol) mit dem SAP EMR Mobile Server. Letzterer ist ein SAP NW Applikationsserver ABAP 7.02 der mit den Komponenten SAP Gateway Server 2.0 und dem EMR Add-on bestückt werden muss. Diese Middleware Schicht übernimmt die Kommunikation mit den Backend Systemen, wobei in der aktuell verfügbaren Ramp-up Version lediglich RFC Schnittstellen zur Verfügung stehen, was eine Einschränkung auf SAP basierte Backend Systeme bedeutet. Dass das nicht genügend ist versteht sich von selbst und auch bei SAP ist das von Beginn weg klar gewesen. Aus diesem Grund wird daran gearbeitet, neben den RFC’s auch SOAP Schnittstellen bereitzustellen, sodass beliebige Integrationen zu beliebigen Systemen möglich gemacht werden können. Diese sollen mit der Verfügbarkeit der EMR App für Endkunden im April 2012 fertiggestellt sein.

Potential für die Schweiz

Als Lösungsanbieter für das Gesundheitswesen in der Schweiz haben wir uns bereits letztes Jahr mit der Positionierung der SAP EMR auseinandergesetzt. Die Herausforderung die sich uns stellt ist die Tatsache, dass das SAP eigene KIS (IS-H*MED) in der Schweiz bei keinem Kunden im Einsatz ist. Es benötigt also in jedem Fall eine Integration in ein anderes Non-SAP KIS System. Und da die Heterogenität in diesem Bereich sehr hoch ist und die verschiedenen KIS Systeme meist keine offenen Schnittstellen anbieten, wird der Aufwand für die Implementierung einer EMR im Bereich der Integration liegen.

Trotz diesem Wermuttropfen bietet die EMR Lösung von SAP aber das Potential, um in einem spezifischen Bereich in ein kleines mobiles Projekt einzusteigen und einige dedizierte und wichtige Funktionen den Benutzern bereitzustellen. Vorab die Offenheit und Erweiterbarkeit, sowie auch die einfache und rasche Implementierung der Lösung auf bestehender SAP Infrastruktur begünstigen einen einfachen Einstieg. Im Anschluss kann die Lösung dann kontinuierlich ausgebaut und optimiert werden.

Wichtig ist auch, dass es sich bei der EMR um eine erste Version handelt, welche noch viel Entwicklungspotential hat. Die SAP hat sehr hohe Erwartung in ihre mobile Lösung und ist auch Willens diese kontinuierlich auszubauen und weiterzuentwickeln. Dazu sind auch Kunden und Nutzer herzlich eingeladen, ihre Ideen und Wünsche mit einzubringen. Im “Idea Place” von SAP, der Community Plattform von SAP auf welcher neue Ideen und Wünsche von jedermann formuliert werden können, hat die EMR bereits einen festen Platz eingenommen.

]]> http://blog.emineo.ch/2012/01/sap-electronic-medical-record-emr/feed/ 0 Der ThermoDock® Test http://blog.emineo.ch/2012/01/der-thermodock-test/ http://blog.emineo.ch/2012/01/der-thermodock-test/#comments Tue, 03 Jan 2012 18:25:49 +0000 zecchino http://blog.emineo.ch/?p=607 Es ist wirklich spannend zu beobachten, wie sich die Technologie rund um die mobilen Geräte entwickelt und wie fast täglich neue Devices, Zusatzgeräte auf den Markt kommen.

Heute haben wir das ThermoDock® erhalten und natürlich sofort ausversucht.

Wie bei allen Devices ist das Einrichten einfach. Die Anwendung runterladen, den Stecker an das iPhone anschliessen und los geht’s.

ThermoDock® ist ein Fieber-Messmodul das mit Infrarot die Temperatur misst.  Das funktioniert einwandfrei und gibt die gleichen Messwerte wie andere Thermometer. Die Messwerte werden auf dem iPhone gespeichert und können bei Bedarf via E-Mail versendet werden. Dabei wird ein Mail an einen zu definierenden Empfänger erstellt welches die Messwerte in verschiedenen Formaten (html, txt, csv) enthält.

Nach ein paar Versuchen mischt sich ein komisches Gefühl in das Erlebnis. Irgend etwas gefällt mir nicht an der grundsätzlich gut gemachten Anwendung.

Datenintegration

Einmal mehr zeigt es sich, dass eigentlich zwingend ein Datenintegrationsstandard definiert werden sollte. Die Daten sind auf dem iPhone in einem beliebigen Format vorhanden und können als E-Mail versendet werden. Es ist meines Erachtens keine Integration in eine Online-Plattform vorgesehen und damit sind die Daten nur isoliert vorhanden. Es besteht keine Möglichkeit, die Daten zum Beispiel in meine Fitbit-Daten (www.fitbit.com) zu integrieren und damit einen Zusammenhang zu meinen weiteren Tätigkeiten (Beispiel: körperliche Aktivitäten) herzustellen oder die Daten anderweitig in einem Zusammenhang mit anderen Daten visualisieren zu können.

Anwendung (Apps)

Die Anwendung stellt die Funktionen für alle Produkte (Messgeräte für Blutdruck, Gewicht, Blutzucker und Fieber) der Firma MEDISANA zur Verfügung und wird mit „Einzigartiges Design“ beworben und ja, das ist es in der Tat – Einzigartig.

IMG_0668 IMG_0670 IMG_0669

Obwohl grundsätzlich hübsch im Design, ist es aus meiner Sicht gewöhnungsbedürftig in der Anwendung. Schwierig zu erklären. Mit ein wenig Geduld kann man sich einfach durch die verschiedenen Funktionen navigieren. Der Grund meiner Irritation liegt darin, dass die Anwendung gesucht hübsch ist. Da hat sich ein Team wirklich Mühe gegeben und versucht eine verspielte Apps zu bauen. Und genau das ist es was mich am Ende stört. Das Apple-Design lebt nicht von Verspieltheit, sondern von einem klaren, simplen Design. Kein rumspielen und herausfinden. Sondern klare Linien und einfache Bedienung.

Zwischenfazit

Ich werde mal damit starten, ThermoDock® über eine längere Zeit zu testen und mal schauen, ob ich mich an die Apps gewöhne.

Die Funktion “Messen der Temperatur” wird auf alle Fälle korrekt bereitgestellt. Die Verpackung und Usability ist auch eine Geschmacksache.

]]> http://blog.emineo.ch/2012/01/der-thermodock-test/feed/ 0 Richtig Testen http://blog.emineo.ch/2011/12/richtig-testen/ http://blog.emineo.ch/2011/12/richtig-testen/#comments Thu, 29 Dec 2011 15:58:13 +0000 Moos http://blog.emineo.ch/?p=601 Im Blog „Qualitätssteigerung mit automatisiertem Testen“ wurden die Vorteile vom automatisierten Testen bereits erläutert. Doch wie wird richtig getestet? Wie kann man Software überhaupt automatisiert testen?

Angenommen ich habe eine Blog-Software und möchte einen Test schreiben, welcher einen Blog-Eintrag veröffentlicht. Hierbei interessiert mich nur gerade das Veröffentlichen des Bloges. Alle restlichen Funktionen und Abläufe z.B. die Registrierung eines Blog-Benutzers interessieren mich jedoch nicht. Der Test wird also wie folgt beschrieben:

  • Name: Blog-Eintrag veröffentlichen
  • Vorbedingungen: Blog-Benutzer existiert und kann Einträge veröffentlichen
  • Testresultat: Der Blog-Eintrag wurde korrekt veröffentlicht
  • Testfall: Der Blog-Benutzer schreibt einen Blog und veröffentlicht diesen auf der Homepage.

Bei der Durchführung dieses Tests habe ich nun das Problem, dass ich die Vorbedingungen sicherstellen muss. Sprich ich muss zuerst einen Blog-Benutzer anlegen, welcher Einträge veröffentlichen kann. Ein kleiner und einfacher Test kann also auf Grund der Vorbedingungen schnell sehr aufwendig werden. Vor allem wenn z.B. Ausnahmefälle (z.B. mit einem gesperrten Blog-Benutzer) getestet werden müssen. Ebenfalls habe ich das Problem, dass die Überprüfung des Testresultates nicht immer einfach ist. Für automatisierte Tests im Java-Umfeld gibt es hierfür ein Zauberwort: „Unitils“.

Unitils ist ein Test-Framework, welches auf JUnit basiert und verschiedene Module zum Testen von Java-Anwendungen beinhaltet. Eines der Module heisst DBUnit. Mit Hilfe dieses Modules kann unser kleines Problem sehr einfach und elegant gelöst werden. Mit DBUnit kann ein definierter Datenzustand in der Datenbank inialisiert werden. Ebenfalls können nach einem Test die Datensätze mit Hilfe von DBUnit überprüft werden. Der Ablauf ist sehr einfach:

  1. Die Datenbank wird mit einem definierten Zustand initialisiert
  2. Der JUnit-Test wird ausgeführt
  3. Die Modifikationen in der Datenbank werden überprüft

Dadurch können auch Spezialfälle sehr schnell und einfach getestet werden.

Datenbank initialisieren

In Schritt 1 wird mit Hilfe einer XML-Datei der Zustand der Datenbank definiert. Die Datenbank wird vor der Ausführung des Tests automatisch durch Unitils initialisiert.

Beispiel XML:

<dataset>
 <TBL_USER ID=”1” LOGINNAME=”testuser” ACTIVE=”1” />
 </dataset>

Hier wird also ein Benutzer „testuser“ in der Datenbank angelegt, welcher aktiviert ist und somit Blog-Einträge erfassen kann.

Datenbank überprüfen

Auch die Testresultate können mit Hilfe einer XML-Datei definiert werden. Unitils überprüft nach der Testdurchführung die Datenbank auf Grund der in der XML-Datei definierten Datensätze.

Beispiel XML:

<dataset>
 <TBL_BLOG ID=”1” USER_ID=”1” BLOG=”Dies ist ein Blog...” />
 </dataset>

Hier wird also überprüft, ob in der Datenbank der Blog-Eintrag korrekt erstellt und mit dem Benutzer verknüpft wurde.

Datensets (XML-Dateien)

Ein Test kann beliebig viele Datensets laden. Ebenfalls können die Datensets (XML-Dateien) von beliebig vielen Tests verwendet werden. Mit Hilfe von Defaultdatensets können so sehr schnell die Vorbedingungen sämtlicher Tests abgedeckt werden. Z.B. könnten wie folgt Defaultdatensets definiert werden:

  • Aktiver Benutzer
  • Gesperrter Benutzer
  • Blog Eintrag für Benutzer
  • etc.

Kennen Sie das Problem mit den Vorbedingungen für einen Test? Welche Lösung haben Sie dafür?

]]> http://blog.emineo.ch/2011/12/richtig-testen/feed/ 0