Software mit Verantwortung: Wie wir den digitalen Wandel nachhaltiger gestalten!

Im Interview mit Hendrik Lösch, Softwarearchitekt bei ZEISS Digital Innovation

Nachhaltigkeit bedeutet, heute schon an Morgen zu denken – das betrifft nicht nur die Gesellschaft, sondern auch Unternehmen und nicht zuletzt die Industrie. Die Digitalisierung nimmt dabei eine Doppelrolle ein, denn sie birgt sowohl Chancen als auch Herausforderungen für eine nachhaltige Zukunft. Einerseits ermöglicht sie effizientere Prozesse, Ressourcenschonung und den Zugang zu neuen Technologien. Andererseits bringt sie auch ökologische Belastungen durch den steigenden Energieverbrauch und die zunehmende Nachfrage nach digitalen Infrastrukturen mit sich. 

Hendrik Lösch, Softwarearchitekt bei ZEISS Digital Innovation

Im nachfolgenden Interview sprechen wir mit Hendrik Lösch, Softwarearchitekt bei ZEISS Digital Innovation. Er ist Experte auf dem Gebiet und beschäftigt sich bereits seit einigen Jahren mit ressourceneffizienter Softwareentwicklung. Jüngst hat er als Autor am Leitfaden des Bitkom „Ressourceneffizienz im Software Lifecycle“ mitgewirkt. 

Im Gespräch werden wir erfahren, welche Auswirkungen der Softwareentwicklungsprozess auf die Nachhaltigkeitsziele von Unternehmen haben kann und wie wichtig es ist, Nachhaltigkeit von Beginn an in die digitale Planung zu integrieren. 

Hendrik, du verwendest lieber den Begriff Ressourceneffizienz statt Nachhaltigkeit, warum? 

Ressourceneffizienz ist konkreter und messbarer als der breite Begriff der Nachhaltigkeit. Nachhaltigkeit beinhaltet ein umfassendes Konzept mit ökologischen, sozialen und wirtschaftlichen Dimensionen. Ressourceneffizienz hingegen beschäftigt sich mit dem gezielten Einsatz von Ressourcen und ist daher praxisorientierter. Es lassen sich daraus klarere Handlungsschritte ableiten, die sowohl ökologische als auch wirtschaftliche Vorteile bringen, ohne mit der Komplexität des gesamten Nachhaltigkeitsbegriffs zu überfordern.

Welche konkreten Ressourcen umfasst das Thema in der Softwareentwicklung und wo überall können Ressourcen eingespart werden?  

Die hauptsächlich betrachteten Ressourcen sind die eingesetzte Energie und Hardware. Alle anderen lassen sich darauf reduzieren bzw. lassen sie sich aus ihnen ableiten. Tauschen wir bspw. Hardware vorzeitig aus, schlägt sich dies sowohl finanziell als auch ökologisch nieder. Finanziell lässt sich dies leicht über die notwendigen Investitionskosten quantifizieren, ökologisch ist es etwas schwieriger, da hierfür das eingesetzte CO2-Äquivalent berücksichtigt werden muss, welches in der bestehenden und neu angeschafften Hardware gebunden ist.

Ähnlich verhält es sich mit den übertragenen und verarbeiteten Daten. Je mehr Daten wir verarbeiten, desto mehr Energie und Hardware benötigen wir. Wobei diese Aussage etwas missverständlich ist: Denn die Betrachtungen zielen nicht nur auf die schiere Menge an übertragenen Daten und die dafür benötigte Rechenleistung ab. Im Rahmen der ressourceneffizienten Softwareentwicklung geht es insbesondere darum, Wege aufzuzeigen, wo im Lebenszyklus von Software angesetzt werden kann, um schlankere und effizientere Lösungen auf den Weg zu bringen. Sei es in der Entwicklung selbst, im Softwaretest aber auch im Betrieb und in der Wartung.

Warum lohnt es sich frühzeitig mit Nachhaltigkeitsaspekten auseinanderzusetzen und Maßnahmen zu ergreifen?

Der Entwicklungsprozess einer digitalen Lösung lässt sich vereinfacht in folgende Aufgabenbereiche unterteilen: Auftragsklärung, Konzeptarbeit sowie Entwicklung und Betrieb. Im ersten Schritt, der Auftragsklärung, ermöglicht die dort eingenommene übergeordnete Perspektive die Grundsatzfrage nach dem Ressourcenverbrauch unmittelbar in die Vision zu integrieren.

In der Praxis kommt dies zu kurz, wenn man sich nur die Frage stellt, was eine Software leisten muss, aber nicht, wie sie diese Leistung erbringen soll. So beobachte ich immer wieder, dass Projekte in Auftrag gegeben werden, die vorrangig niedrige Entwicklungskosten im Blick haben und welche anschließend aufgrund ineffizienter Ressourcennutzung unnötig hohe Betriebskosten aufweisen. Betrachtet man also bereits bei der Auftragsklärung die zu erwartenden Gestehungskosten, beeinflusst dies die Konzeptarbeit und führt automatisch zu einer effizienteren Umsetzung und einem günstigeren Betrieb. Ein niedriger CO2-Fußabdruck ist in diesem Fall dann eher ein erfreulicher Nebeneffekt, der sich automatisch einstellt.

Du hast an einem Leitfaden des Bitkom mitgewirkt. Was möchtest du damit erreichen, was ist deine Motivation? 

Wie zuvor erwähnt, teilt sich der Entstehungsprozess der Software in verschiedene Aufgabenbereiche auf. In der Realität sind diese nicht selten mit unterschiedlichen Denkmustern und Arbeitsrealitäten der jeweiligen Beteiligten verbunden. Man könnte salopp sagen: Sales verkauft, Architekten entwerfen, Entwickler bauen, Tester testen und die IT betreibt. Die Frage nach der Nachhaltigkeit einer Software wird somit für jeden dieser Bereiche anders beantwortet, wobei sich die Antworten verstärkend aufeinander auswirken.

Wird in der Auftragsklärung nicht einmal über Nachhaltigkeitsaspekte gesprochen, können diese beim Entwurf nur bedingt berücksichtig werden und somit auch nicht zu nachhaltigen Lösungen führen. Die Kosten dieser Verschwendung treten dann aber verstärkt im Betrieb auf, wo sie als gegeben akzeptiert werden.

Die drei Teile des Leitfadens sollen genau diesen Weg darstellen und zeigen, wie vielschichtig und komplex die Zusammenhänge sind. Es gibt unzählige Ansatzpunkte, um Ressourcen und damit Kosten einzusparen, langfristig stabil und somit in sich selbst nachhaltig wird das Vorgehen aber erst, wenn man es interdisziplinär umsetzt. Wir haben daher absichtlich die jeweiligen Zielgruppen in eigenen Leitfäden adressiert, um in ihrer Sprache und ihren Problemfeldern, allgemeine Maßnahmen zu skizzieren, die bei der Schaffung ressourceneffizienter Lösungen helfen sollen.

Der Leitfaden spricht von interdisziplinärer Zusammenarbeit als Schlüssel. Wen braucht es, um ressourceneffiziente digitale Lösungen zu entwickeln?

Zunächst müssen natürlich alle Beteiligten für das Thema sensibilisiert sein. Requirements Engineers, Product Owner und Softwarearchitekten haben aber den entscheidendsten Einfluss. Requirements Engineers und Product Owner sind maßgeblich an der Auftragsklärung beteiligt und arbeiten eng mit den Stakeholdern zusammen, um die Anforderungen zu ermitteln und eine klare Produktvision zu formulieren. Sie müssen kontinuierlich die Auswirkungen der geäußerten Anforderungen hinterfragen und verstehen, wie diese Anforderungen miteinander interagieren.

Softwarearchitekten hingegen sind dafür verantwortlich, Lösungen basierend auf diesen Anforderungen zu entwerfen. Sie müssen den Auftraggebern auch Rückmeldungen zu den Anforderungen geben und das Bewusstsein für deren Auswirkungen über die rein funktionale Ebene hinaus schärfen. Ihre Verantwortung endet nicht mit dem Entwurf; sie unterstützen die Entwickler bei der Umsetzung und müssen die technische Vision des Produkts vor schädlichen Einflüssen schützen. Dazu gehört auch die enge Zusammenarbeit mit Testern und dem Betrieb, um das tatsächliche Verhalten der digitalen Lösung zu überprüfen und zu ermitteln, wie sich der Ressourcenverbrauch in der Praxis darstellt.

Welche Herausforderungen siehst du bei der Umsetzung nachhaltiger Praktiken in der Softwareentwicklung? 

Gerade die Bewegung der „Sustainable Software“ bzw. „Green Software“ zielte in der Vergangenheit eher auf die Reduktion des CO2-Fußabdrucks von Software ab. Dies ist ein immens wichtiges Thema, hat aber auch das Problem, dass CO2-Einsparung für kaum ein Unternehmen ein aktiver Business Driver ist. Allerdings verändert sich diese Situation allmählich durch die steigenden Stromkosten und die CO2-Bepreisung. Letztere ermöglicht es, ökologische Kosten in ökonomische umzuwandeln und sie somit in einen primären Treiber zu überführen. Diese Bepreisung ist politisch bedingt und stark umstritten, was zu einer Investitionsunsicherheit führt. Daher fällt es Unternehmen oft schwer, entsprechende Einsparmaßnahmen zu ergreifen.

Hinzu kommt, dass viele Technologien, die wir einsetzen, extra dafür entwickelt wurden, Komplexität zu verbergen. Gerade das Cloud Computing ist hier ein sehr gutes Beispiel. Mit wenigen Klicks können Sie eine Lösung aufbauen, die weltweit skaliert. Fehlendes Bewusstsein bzgl. des realen Ressourceneinsatzes führt dann dazu, dass Lösungen komplexer gebaut werden, als sie es möglicherweise sein müssten. Die ökologischen Auswirkungen lagert man dann zwar an den Cloud-Anbieter aus, bezahlt sie aber mit, über wiederum gesteigerte Wartungsaufwände und Betriebskosten. Da diese Zusammenhänge sehr abstrakt sind und die Betrachtungen der Betriebskosten oft nachträglich geschehen, werden diese schnell als gegeben angesehen und dann auch in kommenden Projekten nicht ausreichend berücksichtigt, wodurch eine Kostenkaskade entstehen kann.

Wo muss deiner Meinung nach noch ein Umdenken geschehen, um das Bewusstsein zu schärfen und die Herausforderungen zu überwinden?  

Aus der Perspektive nachhaltiger Softwareentwicklung ist es entscheidend, sowohl die Ökologie als auch die Ökonomie im Auge zu behalten, um langfristig stabile und kosteneffiziente Lösungen zu entwickeln.  Dieses Zusammenspiel ist jedoch oft sehr abstrakt, weshalb es schwer zu vermitteln ist und die tatsächlichen Kostentreiber schwer zu ermitteln sind. So wollte ich mit meinen vorangegangenen Aussagen bspw. nicht den Eindruck erwecken, dass die Cloud etwas Schlechtes sei. Sie ist ein hervorragendes Werkzeug, dass aufgrund seiner Flexibilität und des eingebauten Monitorings viele Möglichkeiten bietet, nur die Ressourcen zu verbrauchen, die auch wirklich gebraucht werden. Man muss sich aber dieser Möglichkeiten und des eigenen Bedarfs bewusst sein, um wirklich nachhaltig zu arbeiten.

Unternehmen können dieser Problematik begegnen, indem sie sich in allen Phasen des Softwareentwicklungsprozesses an der ISO 25000 orientieren und allen Beteiligten klar kommunizieren, unter welchen Bedingungen die betrachteten Systeme funktionieren sollen. Nur so können Programmierer Lösungen entwickeln, die in einem angemessenen Rahmen Ressourcen verbrauchen und somit unnötige Kosten, unabhängig von ihrer Art, vermeiden. Statt also nach völlig neuen Theorien zu suchen, reicht es oft schon, bestehenden Theorien korrekt zu folgen und langfristig orientiertes Handeln, statt kurzfristiger Einsparungen zu belohnen.

Wie siehst du die Zukunft der Softwareentwicklung in Bezug auf Nachhaltigkeit? Welche Trends werden in den nächsten Jahren entscheidend sein? 

Die Einsparung von CO2-Äquivalenten ist nach wie vor ein sehr wichtiges Thema, wird aber aufgrund der veränderten Weltlage überschattet und zunehmend durch weitere Themen angereichert. Hierzu zählt die Einbeziehung ökonomischer Aspekte und Betrachtungen zur Resilienz sowie Souveränität.

Resilienz wird aufgrund steigender Cyberkriminalität und vermehrt auftretender digitaler Störaktion immer wichtiger, da deren Auswirkungen für Unternehmen existenzbedrohend werden können. Souveränität ist wiederum bedeutend, da sie die Unabhängigkeit von digitalisierten Lösungen und den mit ihnen verbundenen Entscheidungsprozessen beeinflusst. Nicht zuletzt aufgrund der politischen Entwicklung in den USA sorgen sich europäische Unternehmen wieder vermehrt darum, inwieweit sie selbst oder ihre externen Dienstleister die eigentliche Hoheit über die entstehenden digitalen Systeme und damit verbundenen Daten haben.

Ganz deutlich sehe ich dies zum Beispiel daran, dass unsere Kunden sich vermehrt darauf konzentrieren ihre bestehenden Systeme zu optimieren, statt Neuentwicklungen zu starten.

Inwiefern spielt die Ressourceneffizienz bei diesen Trends eine Rolle?

Sie wirkt verstärkend auf die Bestrebungen und gibt vielfältige Hinweise zu möglichen Lösungsansätzen. Nehmen wir beispielsweise die Datensparsamkeit. Dies ist ein Konzept, welches sowohl im Kontext der Ressourceneffizienz als auch Souveränität und Sicherheit von Softwaresystemen eine Rolle spielt. Im Grundgedanken sollten wir möglichst nur die Daten erfassen, die wir auch effektiv verarbeiten können und die einen nachweislichen Mehrwert für unsere Kernprozesse darstellen. Je weniger Daten wir erfassen, desto weniger Aufwand haben wir, sie zu speichern, verwalten und abzusichern. Dies führt nicht nur zu einer Reduzierung des Energieverbrauchs, sondern minimiert auch potenzielle Sicherheitsrisiken und erleichtert die Einhaltung von Datenschutzbestimmungen.

Welche praktischen Tipps würdest du Unternehmen geben, die ihre Softwareentwicklung und den daran anknüpfenden Betrieb nachhaltiger gestalten möchten? 

Ressourceneffizienz ist kein neuer Begriff und auch kein kurzfristiger Trend. Es geht vielmehr darum, die richtigen Dinge auf die richtige Weise zu tun. Dazu ist es wichtig, sich darüber im Klaren zu sein, was diese „richtigen Dinge“ sind und wie man sie effektiv umsetzt.

Eine der einfachsten Möglichkeiten, dies zu erreichen, besteht darin, bei Neuentwicklungen verstärkt auf Qualitätsmerkmale der Software zu achten, die über die reine Funktionalität hinausgehen. Zudem ist es entscheidend, mögliche Betriebskosten bereits detailliert in der Auftragsklärung und im Entwurf zu berücksichtigen, um die Lösungen an den tatsächlichen Bedarf anzupassen.

Diese Überlegungen lassen sich auch auf bestehende Systeme anwenden, wobei Änderungen hier oft aufwändiger und schwerer zu rechtfertigen sind. Es sei denn, es sind signifikante Einsparungen zu erwarten. Diese Einsparungen müssen schließlich den Aufwand für die erforderlichen Änderungen ausgleichen. Angesichts der typischen Lebensdauer von Business-Software sind aber zumindest die Kosten für eine solche Analyse überschaubar. Dem zuvor erwähnten Leitfäden kann man einige der Aspekte entnehmen, auf die man achten sollte.

Interview zur Aktionswoche „SCHAU REIN!“

Auch in diesem Jahr holten sich Sachsens Schülerinnen und Schüler in der Aktionswoche „SCHAU REIN!“  in sächsischen Unternehmen Anregungen für ihren späteren Berufswunsch. Nach der großen Resonanz im Vorjahr war ZEISS Digital Innovation Dresden wieder mit zwei verschiedenen Workshops dabei. Die 18 Plätze waren im Handumdrehen ausgebucht. Offenbar hatten die Themen der Workshops die Neugier geweckt, und auch das Feedback der Teilnehmer war durchweg positiv. Denn sie haben sich in den Workshops mit Legobausteinen und Black Stories beschäftigt und so den Prozess der Softwareentwicklung ganz spielerisch kennengelernt. Wir sprachen mit Maria Petzold und Sabrina Paffe und aus dem Team der ZEISS Digital Innovation, die die Workshops in der „SCHAU REIN!“ Aktionswoche erneut geleitet hatten:

Was hat der Prozess der Software-Entwicklung mit Lego bzw. mit Black Stories zu tun?

Sabrina: Ob bei der Entwicklung einer Software-Architektur oder beim Bau einer Stadt aus Lego – wenn viele Menschen sich die Arbeit teilen, muss man planen und kommunizieren. Wir haben die Schüler in zwei Gruppen aufgeteilt und sie in aufeinander folgenden Schritten beauftragt, ganz konkrete Bauwerke von der Feuerwehr bis zum Zoo zu errichten. Es gab Zeitlimits, eine regelmäßige Auswertung und Nachjustierung, und ganz ähnlich funktionieren die Abläufe in den Software-Entwicklerteams. 

Maria: Um die Aufgaben von Black Stories zu lösen, ist nicht nur Teamarbeit gefragt, sondern auch ein Blick über den Tellerrand. Das ist vergleichbar mit der Software-Entwicklung, und wir nennen dieses Herangehen „Out-of-the-box-Thinking“.  Auch dort geht es darum, dem anderen im Team gut zuzuhören, die richtigen Fragen zu stellen, nach unkonventionellen Lösungen zu suchen und die Ergebnisse immer wieder zu reflektieren.

Was konnten die Schüler nach dem „SCHAU REIN!“- Projekttag für sich mitnehmen?

Sabrina: Ich denke, sie haben vor allem gelernt, dass Softwareentwicklung oft im Team abläuft  und dass das Klischee vom einsamen Programmierer völlig veraltet ist. Klare Arbeitsteilung und die Kommunikation sind sehr wichtig und typisch für Berufe in unserer Branche.

Maria: Vielleicht haben sie auch die Erkenntnis mitgenommen, dass nicht nur das Fachwissen entscheidend ist, sondern auch Faktoren wie Teamfähigkeit und die Bereitschaft zu kommunizieren. Da gibt es viele Parallelen zur Schule, wo die Schüler ja auch immer mal zusammen an Vorträgen oder Projekten arbeiten. Dort kann man sich super ausprobieren.

Was würdet Ihr jungen Menschen raten, wenn sie noch unschlüssig sind, ob die IT oder generell die Tech Branche für sie das Richtige ist?

Maria: Sie sollten jede Möglichkeit nutzen, um Unternehmen kennenzulernen, Praktika machen, die Lange Nacht der Wissenschaften besuchen.

Sabrina: Bei ZEISS Digital Innovation ist der Girls Day am 3.4. die nächste Gelegenheit, da gibt es meines Wissens in Görlitz noch freie Plätze.

Was ist Eure Rolle bei der ZEISS Digital Innovation?

Maria: Ich bin seit 2010 im Unternehmen und momentan als Teamleiterin Qualitätssicherung bzw. Testmanagerin für neue Software tätig.

Sabrina: Ich arbeite als Scrum-Masterin in Software-Entwicklerteams und bin quasi die „Wächterin“ über die Arbeitsorganisation im Team. Bei der ZEISS Digital Innovation bin ich seit 2,5 Jahren.

Wie habt Ihr eigentlich zu einem Beruf in der IT gefunden?

Maria: Bei mir fing alles mit der Installation eines Computerspiels an. Das hört sich heutzutage banal an, allerdings spreche ich von der Zeit als Speicherplatz sehr begrenzt war, und mit Floppy-Disc und DOS-System gearbeitet wurde. Damit begann das Interesse für Computer, Software und Lösungsfindungen, weswegen ich auch zu Hause wegen „Computerproblemen“ sehr gefragt bin. Während meiner schulischen Laufbahn habe ich dann das Beruflichen Gymnasium für Wirtschaft besucht und auch Informatik belegt. Dies führte dazu, dass ich mich entschlossen habe an der Berufsakademie Glauchau Wirtschaftsinformatik zu studieren.

Sabrina: Ich habe gerne Mathe gemacht und mich für ein Studium der Wirtschaftsmathematik entschieden. Dort hat mich eher das Fach Informatik begeistert und ich bin in eine Ausbildung zur Fachinformatikerin gewechselt. Mein Vater war auch in der IT-Branche, hatte aber vor allem mit Hardware zu tun. Das hatte mich nicht so interessiert, allerdings war mir damals nicht klar, dass es in der IT so viele verschiedene Jobs gibt.

ZEISS Digital Innovation Goes Green: Unsere strategische Nachhaltigkeitsinitiative

Um unsere strategischen Ziele zu erreichen, arbeiten wir kontinuierlich an sogenannten Strategischen Initiativen (SI), die den Fokus auf ein bestimmtes Thema entlang unserer Unternehmensziele legen. Im Oktober 2023 wurde die SI Sustainability gestartet, um uns im Bereich Nachhaltigkeit stärker zu positionieren. Nachhaltigkeit und Ressourceneffizienz beziehen in allen Bereichen des Lebens und der Gesellschaft einen immer höheren Stellenwert und sind auch für uns bei ZEISS Digital Innovation (ZDI) enorm wichtig. Gerade für künftige und heranwachsende Generationen werden diese Themen auch bei der Wahl des Arbeitgebers von Bedeutung sein. Ebenso kann unser Handeln für unsere Partnerunternehmen sowie Kundinnen und Kunden entscheidend sein und positive Effekte erzielen. 

Was sind die Ziele der SI? 

Die SI Sustainability ist in zwei Teams aufgeteilt. Das erste Team konzentriert sich auf den Aspekt des täglichen Arbeitens (Business Operations), während sich das zweite mit nachhaltiger Softwareentwicklung befasst (Sustainable Software).  

Das Business Operations Team entwickelt ein Dashboard für unsere Mitarbeitenden, um aktuelle Informationen zum ökologischen Fußabdruck von ZDI für die Belegschaft zugänglich zu machen. Darüber hinaus werden die CO2-Emissionen von ZDI im Geschäftsbetrieb analysiert, um Verbesserungsmöglichkeiten zu identifizieren.  

Das Sustainable Software Team hat es sich zum Ziel gesetzt die Nachhaltigkeit in unserem Kerngeschäft, der Softwareentwicklung, zu verbessern. Erste Schritte sind zunächst eine Ist-Analyse zum Stand der Technologien sowie eine datengetriebene Analyse unserer eigenen Software-Emissionen und die Ableitung eines Konzepts, wie wir dies verbessern können. Es sollen mehrere Kommunikationsinitiativen an alle Mitarbeitenden entwickelt werden, sowie ein Austausch mit anderen ZEISS-Einheiten erfolgen, um das Konzept der nachhaltigen Softwareentwicklung zu diskutieren. 

Was wurde bisher unternommen? 

Im folgenden Abschnitt möchten wir den aktuellen Stand der angestrebten Arbeitspakete betrachten. 

Im Team Business Operations haben wir uns im Sprint 0 zunächst auf die verschiedenen Kennzahlen der Nachhaltigkeitsberichterstattung konzentriert. Als Grundlage für die weiteren Betrachtungen diente der Greenhouse Gas Standard (THG) und seine drei Anwendungsbereiche. Scope 1 (Burn) sind alle Emissionen, die direkt durch ZDI verursacht werden und kontrolliert werden können, wie z.B. Kraftstoff für Firmenwagen oder Heiz- und Kühlsysteme. Scope 2 (Buy) umfasst alle Emissionen, die von ZDI „gekauft“ werden, wie z.B. Strom. Scope 3 (Beyond) umfasst alle Emissionen, auf die ZDI keine direkte Kontrolle hat, wie Geschäftsreisen oder das Pendeln von Mitarbeitenden. 

Im nächsten Schritt haben wir uns mit dem strategischen Key-group-Program (KGP) Nachhaltigkeit bei ZEISS in Verbindung gesetzt. In mehreren Meetings haben wir diskutiert, was bei ZEISS bereits getan wird, was in Zukunft passieren könnte und ob wir einen Beitrag dazu leisten können. Gleichzeitig haben wir uns angeschaut, was bereits bei ZDI geleistet wird. 

Im Rahmen von Sprint 0 des Workstreams Sustainable Software haben wir das Konzept der Nachhaltigkeit und Ressourceneffizienz in der Softwareentwicklung umfassend erforscht. Es wurde festgestellt, dass es derzeit keine standardisierten Richtlinien oder „Goldstandards“ in diesem Bereich gibt. Der Kontakt zum ZEISS Geschäftsbereich Industrial Quality & Research (IQR) zur nachhaltigen Entwicklung setzte den Impuls zur Analyse der Emissionen eines Softwareprojektes.  

In Sprint 1 begannen wir mit der Analyse unserer eigenen Software auf Basis der Berechnungstabelle von IQR. Darüber hinaus haben wir gemeinsam mit dem Co-Innovationszentrum Smart Systems Hub einen dreitägigen Hackathon (Thin[gk]athon) mit verschiedenen Partnern aus Industrie und Hochschulen vorbereitet, um tief in die Idee von Verbesserungspotenzialen für eine nachhaltige und ressourceneffiziente Entwicklung einzutauchen. 

Bild 1: Co-Innovation für nachhaltige Softwareentwicklung
Bild 2: Teilnehmende des Thin[gk]athons 2024

Was sind die nächsten Schritte? 

Als Teil von Sprint 2 hatte unsere SI ein wichtiges Ziel vor Augen: einen Thin[gk]athon durchzuführen. Diese Veranstaltung fand im Juni mit bemerkenswertem Erfolg im Impact Hub in Dresden statt. Die teilnehmenden Teams hatten drei Tage Zeit, um innovative Lösungen zur Minimierung der CO2-Emissionen bei der Entwicklung digitaler Lösungen zu entwickeln. Die Ergebnisse waren beeindruckend und wir danken allen drei Teams für ihre hervorragende Leistung: „Carbon Cutter“, „Cooler Climate Coders“ und „Proekspert AS“.  

Derzeit analysiert und bewertet die Workstream Sustainable Software die Ergebnisse des Thin[gk]athons. 

Gleichzeitig arbeiten unsere Kollegen im Workstream Business Operations an neuen Richtlinien für Geschäftsreisen. Um die Emissionen aus Heizung, Klimaanlage und Stromverbrauch transparent zu machen, soll ein Power-BI Dashboard erstellt werden. Darüber hinaus haben wir ein Projekt zur Berechnung der Emissionen ausgewählt. Mit unseren Kolleginnen und Kollegen im Marketing erstellen wir Inhalte, die unsere Bemühungen im Kontext der Nachhaltigkeit unterstreichen. Wir werden das Thema weiterverfolgen und arbeiten kontinuierlich daran, unseren Beitrag für eine nachhaltige Zukunft zu leisten. 

Im letzten Schritt der SI sehen wir uns an, wie das Thema Nachhaltigkeit umgesetzt werden kann. Wir wollen das Thema in unsere Kundenkommunikation integrieren und nachhaltige und ressourceneffiziente Softwareentwicklungspraktiken in unseren aktuellen Workflow integrieren. Unser Ziel ist es, die Nachhaltigkeit in der Softwareentwicklung weiter mitzugestalten und uns an zukünftige Entwicklungen in diesem Bereich anzupassen. 

Kann agile Softwareentwicklung in einem regulierten Umfeld wie der Medizintechnikindustrie funktionieren?

Was sind Vorteile, Herausforderungen und kritische Erfolgsfaktoren bei der Umsetzung?

Business Kontext

Studien haben gezeigt, dass die digitale Transformation in der Gesundheitsbranche in den letzten fünf Jahren enorm beschleunigt wurde. Ein katalysierender Aspekt war die COVID-19-Pandemie, die zu Veränderungen in den Interaktionen zwischen Patient:innen und medizinischem Fachpersonal führte. Im Zuge dieses Prozesses wurden neue Technologien entwickelt, die es ermöglicht haben, viele Aufgaben remote durchzuführen. Medizintechnik- und Life-Science-Unternehmen müssen nun zeitnah reagieren, um auf diese veränderten Bedingungen einzugehen. Aufgrund der zunehmenden digitalen Lösungen wurden die Kundenerwartungen dahingehend erhöht, dass Kund:innen in ihrer täglichen Arbeit in derselben Weise und Qualität von digitalen Lösungen unterstützt werden wie dies in anderen Branchen (z.B. Unterhaltung oder Reiseorganisation) bereits möglich ist.

In diesen Industrien haben R&D-Organisationen agile Entwicklungsmethoden erfolgreich verwendet, um dieses Niveau an Digitalisierung zu erreichen. Medizintechnik- und Life-Science-Unternehmen hingegen haben aufgrund der regulatorischen Anforderungen strenge Vorschriften und interne Prozesse einzuhalten, die agile Bestreben einschränken. Können die agilen Entwicklungsframeworks auf diese speziellen Rahmenbedingungen angepasst werden, um bei der Bewältigung dieser Herausforderungen zu helfen und damit den Softwareentwicklungsprozess zu beschleunigen sowie durch mehrfache Iterationen flexibel und nutzerzentriert zu gestalten?

Die Durchführung von Software-R&D-Projekten mit agiler Methodik kann die Effizienz auf verschiedene Weisen verbessern:

Time-to-Market: Durch die agile Methodik werden einsatzfähige Softwareinkremente in jedem Entwicklungsschritt (Sprints) geliefert, was den Teams dabei helfen kann, sich auf die wesentlichen Anwendungsfälle des Produkts zu konzentrieren und dieses schneller auf den Markt zu bringen.

Ressourcennutzung: Durch die Schätzung der Kosten für jedes Produktinkrement und die enge Überwachung des Fortschritts können Teams die Ressourcennutzung optimieren und Verschwendung reduzieren.

Kontinuierliche Verbesserung: Die agile Methodik inkludiert kontinuierliche Verbesserung und Feedback. Teams werden regelmäßig dazu ermutigt, ihre Prozesse zu verbessern und effizienter zu werden.

Reduzierter Nachbearbeitungsaufwand: Durch die frühzeitige Identifizierung von Problemen oder neuen Anforderungen im Projektverlauf und deren rasche Behebung bzw. Umsetzung können Teams das Risiko teurer Nacharbeiten reduzieren und sicherstellen, dass das Projekt den Kunden- und Nutzerwünschen entspricht.

Welche Herausforderungen bestehen bei Einführung von agilen Methodologien in einer regulierten Umgebung?

Einhaltung von Vorschriften: Medizintechnikunternehmen müssen eine Vielzahl von Vorschriften und Standards einhalten, wie z. B. MDR oder FDA-Vorschriften. Jede neue Methodik muss daher mit den Vorschriften konform sein und sicherstellen, dass alle erforderlichen Prozessschritte zur Zertifizierung sowie die zugehörigen Dokumentationen rechtzeitig abgeschlossen sind, damit eine Softwarelösung erfolgreich zugelassen werden kann.

Risikomanagement: Medizintechnikunternehmen müssen eine Vielzahl von Risiken managen, wie z. B. Patientensicherheit, Datenschutz und Cybersicherheit. Eine angemessene Identifizierung, Bewältigung und Überwachung dieser Risiken ist für den Projekterfolg entscheidend und muss auch bei agiler Softwareentwicklung umgesetzt werden.

Dokumentation: Medizintechnikunternehmen sind verpflichtet, detaillierte Dokumentationen über ihre Softwareentwicklungsprozesse und deren Ergebnisse zu führen.  Das Problem ist, dass bei einer Software, die als Medizinprodukt eingestuft ist, für jeden neuen Softwarerelease eine komplette technische Akte für die Zulassung erzeugt werden muss. Damit entsteht ein zusätzlicher Dokumentationsaufwand.

Einbeziehung der Interessengruppen: Im Gesundheitswesen sind viele Interessengruppen an Produkt- und Softwareentwicklungsprojekten beteiligt, darunter Patient:innen, Ärzt:innen, Regulierungsbehörden und IT-Mitarbeitende. Es ist wichtig sicherzustellen, dass die Stimmen aller Interessengruppen gehört und ihre jeweiligen Bedürfnisse berücksichtigt werden.

Wie können die Vorteile beider Ansätze kombiniert werden?

1. Erstellen Sie einen detaillierten Projektplan

Agil zu arbeiten bedeutet nicht, ohne Plan zu arbeiten. Beim Einsatz agiler Methoden in einer regulierten Umgebung sollte ein detaillierter Projektplan den Projektumfang, die Ziele, den Zeitplan, die erforderlichen Ressourcen und die zu bewältigenden Risiken umreißen und dokumentieren.

2. Erstellen Sie Dokumente durch automatisierte Prozesse

In einer regulierten Umgebung ist eine detaillierte Dokumentation erforderlich, um die Einhaltung von Standards und Vorschriften nachzuweisen. Gemäß dem Wasserfallmodell werden Design-Eingabe- und Ausgabedokumente für einen bestimmten Projektsynchronisationspunkt erstellt, in denen die Risiken, Geschäftsanforderungen, Architektur, Tests und betrieblichen Aspekte des zu erstellenden Produkts detailliert beschrieben werden. Die agilen Methodologien können angepasst werden, um die Anforderungen an die Dokumentation in den detaillierten Produkt-Backlog-Elementen zu berücksichtigen.

Die Dokumente können vor Beginn eines Entwicklungssprints oder eines Produktinkrements erstellt werden, um den regulatorischen Anforderungen gerecht zu werden und die Verfügbarkeit der Design-Eingaben sicherzustellen. Sie können einen engen Umfang beschreiben, der für den bevorstehenden Entwicklungszeitraum relevant ist. Durch Automatisierung in diesem Bereich kann der Zeitaufwand für die Erstellung, Aktualisierung und Genehmigungszyklen von Dokumenten erheblich reduziert werden. Anforderungen, Softwareentwürfe und Tests können nahe am Entwicklungsumfeld erstellt werden und mit Hilfe validierter Tools später in umfassende und konsistente Dokumente überführt werden kann, die den Anforderungen des Qualitätsmanagementsystems entsprechen.

3. Ausbau der Testautomatisierung

Es gibt mehrere Gründe, warum Investitionen in Testautomatisierung ein Projekt effizienter machen können. Wenn Änderungen an einer Software in einer regulierten Umgebung vorgenommen werden, besteht stets die Herausforderung, nachzuweisen, dass keine negativen Auswirkungen auf die Patientensicherheit und die allgemeine Wirksamkeit bestehen.

Oder wenn ein Produkt von einer Implementierungsphase zu einer Verifikations- und Validierungsphase übergeht, sind viele notwendige, aber zeitaufwändige Testaktivitäten erforderlich. In funktionsübergreifenden agilen Teams können Verifikationsaufgaben für bestimmte Funktionen der Softwarelösung Teil der Entwicklungssprints sein. Die Zeit, um Feedback zum tatsächlichen Zustand des Produkts zu erhalten, verringert sich erheblich bei hohem Automatisierungsgrad.

So reduziert sich auch das Risiko der Einführung unbeabsichtigter Nebenwirkungen bei Änderungen an einem bestehenden Code. Mit der richtigen Testdokumentation und Codequalität können automatisierte Tests die Geschäftsanforderungen formell abdecken und für Verifikationsaktivitäten verwendet werden, wodurch die benötigte Zeit für einen Testzyklus reduziert wird.

4. Risiken kontinuierlich managen

Gesundheitsorganisationen müssen eine Vielzahl von Risiken managen, wie z. B. Patientensicherheit, Datenschutz und IT-Sicherheit. Agile Methodologien können angepasst werden, um Risikomanagementpraktiken wie Risikoerkennung, Risikobewertung und Risikominderung in wiederholten verkürzten Zyklen einzuschließen, unterstützt durch den automatisierten Dokumentenerstellungsprozess und automatisierte Tests gegen die definierten Risikominderungen.

5. Einbeziehung der Interessengruppen

Durch regelmäßige Sprint- und Produktinkrement-Demonstrationssitzungen können die Teams allen wichtigen Interessengruppen zeigen, in welche Richtung sich die Digitallösung entwickelt. Da die Entwicklungszyklen verkürzt werden, können Patient:innen, Ärzt:innen und IT-Mitarbeitende regelmäßig Beitrag leisten, um Änderungswünsche einzubringen, denen die agilen Teams folgen können. Regelmäßig sollten zudem auch Kund:innen, Meinungsführer:innen und Partner:innen ihre Meinung darüber äußern können, wie die Lösung gestaltet werden soll. Dies können Medizintechnikunternehmen zum Beispiel durch gemeinsame Workshops oder Pilotphasen auf Grundlage von Zwischenproduktversionen ermöglichen.

Fazit

Die Einführung von neuen Prozessen, insbesondere in einer regulierten Umgebung, ist mit zusätzlichen Schwierigkeiten und Verzögerungen verbunden. Die Integration agiler Prinzipien, unterstützt von einem Team aus Branchenexperten und hochgradig automatisierten Prozessen, ermöglicht einer Organisation jedoch eine schnelle Reaktion und Antwort auf neue Herausforderungen, die sich aus den wandelnden Anforderungen der Medizintechnikbranche mit einer stark regulierten Umgebung ergeben.

➡️ Kontaktieren Sie uns, um sich über Ihre Ideen auszutauschen und wie wir helfen können. Besuchen Sie auch unsere Website, um mehr über uns und unsere Dienstleistungen zu erfahren.

➡️ Weitere Blogartikel zum Thema Health Solutions finden Sie hier.

Änderungen an der ISO 25010 stehen bevor

Die ursprünglich aus der ISO 9000 hervorgegangene ISO 25000 beschreibt die Qualität innerhalb der Softwareentwicklung. Hierbei ist für Softwareentwicklerinnen und Softwareentwickler insbesondere die ISO 25010 von Interesse, welche typische Qualitätsmerkmale von Softwareprodukten abbildet. Innerhalb der ZEISS Digital Innovation ist dieser Standard von besonderem Interesse, da er sich nicht nur auf die Produkte unserer Kunden, sondern auch auf unsere internen Abläufe auswirkt. Gerade in Verbindung mit den regelmäßig durchgeführten Health Checks stellt der Standard eine wichtige Richtschnur dar, weil er definiert auf welche Eigenschaften von Software besonderes Augenmerk gelegt werden sollte. Nach über zehn Jahren ist es nun so weit, dass dieser so wichtige Standard überarbeitet wird. Dieser Artikel behandelt die zu erwartenden Änderungen.

Die ISO 25010

Der Standard ISO 25010 wurde im Jahr 2011 abgesegnet und ersetzte damit den bis zu diesem Zeitpunkt geltenden Standard 9126. Er definiert acht Haupteigenschaften von Software, die sich in weitere Untereigenschaften aufteilen.

Quality criteria for software
Abbildung 1: Qualitätskriterien für Software – definiert in der ISO 25010

Eine weithin bekannte Eigenschaft ist zum Beispiel die Usability, zu Deutsch auch Benutzbarkeit. Mit ihr wird beschrieben, inwiefern die Software ihre Nutzer bei der Umsetzung von deren Arbeitsabläufen unterstützt. Wichtige Unterkategorien sind dabei zum einen, wie leicht die Software zu erlernen ist, zum anderen aber auch inwiefern sie die Nutzer vor Eingabefehlern schützt. Außerdem relevant ist der Umgang der Software mit möglichen Bedienungseinschränkungen, im Sinne von Seh- und Hörbeeinträchtigungen der Nutzer.

Description of the usability guidelines in detail
Abbildung 2: Untermerkmale für das Qualitätskriterium Usability

Dank der detaillierten Beschreibung des Standards ist es damit unterschiedlichen Projektbeteiligten wie Softwarearchitekten, Softwaretestern oder Produkt Ownern möglich, entsprechende Qualitätseigenschaften zu priorisieren sowie diese mit entsprechenden Anforderungsbeschreibungen zu versehen.

Änderungen am Standard?

ISO-Standards unterliegen einem Reviewprozess, durch den sie aller fünf Jahre auf ihre Aktualität geprüft werden. Für die ISO 25010 geschah dies in den Jahren 2016 und 2021. Bei der letzten Prüfung wurden verschiedene Änderungspotentiale offensichtlich. Beispielsweise findet sich bisher die Eigenschaft der Skalierbarkeit nicht im Standard, obwohl sie ausschlaggebend dafür ist, ob eine Applikation tatsächlich in der Cloud oder On-Premise umgesetzt werden sollte. Auch die Frage, ob die Software als Monolith oder in Form von Micro-Services umgesetzt werden sollte, ist maßgeblich von der notwendigen Skalierbarkeit abhängig.

Änderungswünsche wie diese konnten von den Standardisierungseinheiten bis zum 15. November 2022 vorgeschlagen werden, wodurch nun ein Vorschlag vorliegt, über den in den nächsten drei Monaten abgestimmt wird. Folgt die 2. Edition auch weiterhin dem üblichen Prozess, ist damit zu rechnen, dass die neue Edition etwa Mitte 2023 als bindend gilt und breitflächig veröffentlicht wird. Aber welche Änderungen sind konkret zu erwarten?

Mögliche ISO 25010 – 2. Edition

Bezogen auf die Usability ergeben sich einige Änderungen, so haben sich Astethics und Accessbility in User Engagement, User Assistance und Self-Descriptiveness gewandelt. Damit wurden die zuvor vorhandenen Beschreibungen im Grunde nur näher erläutert bzw. deutlicher getrennt.

Description of the usability guidelines in detail
Abbildung 3: Untermerkmale der Usability – 1. Edition
Changes in the quality characteristics for usability
Abbildung 4: Untermerkmale der Usability – 2. Edition

Eine weitere Änderung ergibt sich für die Portabilität. Sie wandelt sich in Flexibilität, was ihrem eigentlichen Charakter auch viel näherkommt und sie deutlicher von der Kompatibilität unterscheidet. Unter der Flexibilität findet sich dann auch die schon länger vermisste Skalierbarkeit.

Description of the poratbility guidelines in detail
Abbildung 5: Aspekte der Portability – 1. Edition
Changes in the quality characteristics for portability
Abbildung 6: Aspekte der Portability – 2. Edition

Die größte Änderung betrifft eine neue Eigenschaft, die bisher noch gar nicht betrachtet wurde. Hierbei handelt es sich um Safety. Mit Safety ist dabei die Betriebssicherheit gemeint. Ihre Einführung als wichtiges Qualitätsmerkmal spiegelt daher auch die deutliche Verbreitung von Software im Kontext der Hardware wider. Denn nicht zuletzt steuert Software in vielen Fällen auch Hardware und kann daher auch in der realen Welt zu Schäden an Mensch und Material führen.

New quality characteristic safety
Abbildung 7: Neues Qualitätsmerkmal – Safety

Fazit

Änderungen an Standards sind zu einem gewissen Teil auch immer etwas kritisch, da der Standard damit etwas weniger gut zu verstehen ist. So ist beispielsweise damit zu rechnen, dass in der Übergangszeit, durch die Namensgleichheit der verschiedenen Editionen, zunächst etwas Verwirrung entlang der verschiedenen Begriffe herrschen wird. Andererseits sind die Änderungen nachvollziehbar und sinnvoll. Inwiefern es überhaupt zu den Änderungen kommt, steht darüber hinaus auch noch nicht ganz fest, da die Abstimmung über jene Änderungen aktuell noch nicht abgeschlossen ist.

Tester-Tea-Time (Teil 2): Rechtschreibung in Anwendungen – mehr als nur Kleinlichkeit

Die „Tester-Tea-Time“ ist ein Beitragsformat auf diesem Blog, in dem Themen aufgegriffen werden, die Testerinnen und Tester tagtäglich beschäftigen. Gewisse Problemstellungen oder Themen kehren immer wieder, daher soll hier eine Basis geschaffen werden, solche Phänomene zu erläutern und Lösungen dafür zu finden. Zudem sollen Diskussionen und neue Denkweisen angeregt werden. Im Testing können wir viel voneinander lernen, indem wir unseren Alltag beobachten!

Moderator: Willkommen zur Tester-Tea-Time! Im Interview mit Testerinnen und Testern der ZEISS Digital Innovation (ZDI) werden wir erneut spannende Themen diskutieren.

Widmen wir uns nun dem heutigen Thema. Dazu sprechen wir mit Sandra Wolf (SW), Testerin bei ZDI. Warum beschäftigen wir uns dieses Mal mit dem Thema „Rechtschreibung“ und wo siehst du den Zusammenhang mit der Softwareentwicklung?

SW: Der Alltag eines Testers hält viele Herausforderungen bereit. Gerade während des Testprozesses ist große Konzentration gefragt, wenn jedes Detail auf Qualität überprüft werden muss. Eines dieser Details ist die Rechtschreibung und Grammatik. Oft wird es unterschätzt, wie wichtig die korrekte Orthografie sein kann.
Im Arbeitsalltag passiert es oft, dass Rechtschreibfehler in der Software gefunden werden. Doch wenn diese zur Behebung an die Entwicklung gemeldet werden, kommt es nicht selten vor, dass der Tester dafür belächelt wird. Die vorherrschende Meinung ist, dass das nur sehr kleine und unwichtige Fehler wären. Im heutigen Gespräch soll mit dieser Meinung aufgeräumt werden. Rechtschreibung und Zeichensetzung sind nicht gerade die beliebtesten Themen und werden häufig als sehr trocken empfunden. Dabei sind gerade diese Regeln, die wir seit der Schulzeit lernen, eine Orientierungshilfe für uns und unser Gehirn. Ein Wort, das richtig geschrieben wird, wird auch leichter gelesen, im Satz zu einer Aussage kombiniert und somit im Gehirn verarbeitet. Aufmerksame Leser – oder im Fall der Softwareentwicklung – Nutzer werden zwangsläufig über falsche Rechtschreibung in der Software stolpern. Es wurde sogar nachgewiesen, dass bestimmte Persönlichkeitstypen unterschiedlich emotional auf falsche Orthografie reagieren (vgl. Weiß, 2016). Somit können Fehler in diesem Bereich im Gegensatz zu ihrem trockenen Ruf Emotionen auslösen, die dann als Konsequenz den Umgang mit der Software beeinflussen.

Zwei Kollegen zum Interview über Videokonferenz verbunden
Abbildung: Stanislaw Traktovenko und Sandra Wolf in der virtuellen Tester-Tea-Time im Gespräch.

Moderator: Von welcher Art der Beeinflussung sprechen wir in diesem Fall?

SW: Korrekte Rechtschreibung strahlt zum Beispiel Seriosität aus. In Bewerbungen und amtlichen Anträgen wird eine fehlerfreie Rechtschreibung vorausgesetzt. Es ist sogar in Studien belegt worden, dass beispielsweise die Chancen auf Bewilligung eines Kreditantrags durch sprachliche Fehler vermindert werden (vgl. Weiß, 2016). Übertragen wir das nun auf die Software, die wir entwickeln, ist nur ein möglicher Schluss zu ziehen: Rechtschreibung ist essenziell für eine adäquate Nutzung und die Außenwirkung der Software beim Kunden. Und somit sollte dieses Thema innerhalb des Entwicklungsprozesses eindeutig ernster genommen werden und mehr Aufmerksamkeit bekommen als bisher.
Schauen wir uns den Alltag von Testern und Entwicklern an, dann wissen wir, dass die Funktionalität der Software im Mittelpunkt steht. Natürlich ist nachvollziehbar, dass ein kosmetisch wirkendes Thema wie die Rechtschreibung hinter aufwendig programmierten Anwendungsteilen zurücktritt. Das sollte alle Beteiligten des Prozesses allerdings nicht über die Wichtigkeit hinwegtäuschen. Denn ganz klar ist, dass der Erfolg eines Produktes und somit auch einer Anwendung von der sprachlichen Qualität beeinflusst werden kann. Der erste Eindruck beim Lesen eines Textes oder beim Nutzen einer Software lässt uns automatisch auch auf den Bildungsgrad der Schöpfer schließen (vgl. Frost, 2020). Somit kann durch eine fehlerhafte Rechtschreibung ein schlechtes Licht auf eine gute Software geworfen werden.

Moderator: Wie muss ich mir dieses “schlechte Licht”, in dem die Software dann steht, im Detail vorstellen?

SW: Durch eine schlechte Rechtschreibung kann das Vertrauen in die Qualität der Software verloren gehen und die Akzeptanz für die Anwendung sinken. Der Nutzer könnte davon ausgehen, dass generell wenig Wert auf Qualität gelegt wird, wenn schon mit der Rechtschreibung nachlässig umgegangen wird. Schließlich drückt eine korrekte Orthografie nicht nur Professionalität, sondern auch einen gewissen Respekt gegenüber dem Leser/Nutzer aus. Es konnte sogar festgestellt werden, dass eine Textqualität beeinflusst, ob jemand vom Interessenten zum Käufer wird. Wird das auf die Softwareentwicklung bezogen, kann es auf jeden Fall Budget einsparen, wenn von Anfang an auf die Rechtschreibung geachtet wird und die Meldung solcher Fehler ernst genommen wird (vgl. Frost, 2020).
Letztendlich präsentieren wir in unseren Projekten auch unser Unternehmen, weshalb das Thema der Orthografie weitreichendere Auswirkungen haben kann, als wir zunächst denken. Im besten Fall kann durch eine gute Rechtschreibung der Ruf unserer Softwareentwicklung verbessert werden bzw. erhalten bleiben. Dadurch können wiederum mehr Kunden und höhere Umsätze erzielt werden, weil die gleichbleibende Qualität unserer Softwareprodukte ein Argument für eine Zusammenarbeit mit der ZDI sein kann.

Moderator: Hier möchte ich gern anknüpfen und Stanislaw Traktovenko (ST) aus unserem Usability-Team zu Wort kommen lassen. Welche Bedeutung nimmt das Thema der Rechtschreibung aus deiner Sicht ein? Siehst du ebenfalls die Auswirkungen in dem von Sandra Wolf beschriebenen Maße?

ST: Aus meiner Sicht hat die Rechtschreibung einen Einfluss auf die Lesbarkeit und dadurch auf die Wahrnehmung der Informationen in der Anwendung. Wir ordnen das den Usability-Prinzipien Konsistenz und Sprache zu. Rechtschreibfehler haben also potenziell eine direkte Auswirkung auf die Usability einer Anwendung. Eine inkorrekte Orthografie stört zum Beispiel den Lesefluss und somit die Wahrnehmung der Software durch den Nutzer. Es entsteht ein negatives Gefühl und der Nutzer beschäftigt sich nicht mehr mit der Aufgabe, die er mit der Software eigentlich verfolgt hatte. Er wird durch eine falsche Rechtschreibung abgelenkt und das beeinflusst seine Effektivität und Effizienz. Auch wenn Rechtschreibung nur ein kleiner Bruchteil der Usability ist, kann sie somit größere Auswirkungen haben als gedacht, so wie Sandra bereits vorher erläutert hat.

Moderator: Vielen Dank, Sandra und Stanislaw für diese interessanten Einblicke. Die Auswirkungen sind tatsächlich weitreichender als erwartet, das ist sehr erstaunlich. Wir können somit zusammenfassen, dass das trocken wirkende Thema der Rechtschreibung in allen Softwareprojekten ernst genommen werden muss, um eine möglichst hohe Qualität zu liefern und sowohl die Produkte als auch uns als Unternehmen adäquat zu präsentieren. Das Thema der Rechtschreibung wirkt im ersten Moment vielleicht banal, hat aber im Endeffekt eine große Wirkung und somit Wichtigkeit für uns alle. Das Thema sollte daher unbedingt die Aufmerksamkeit bekommen, die es verdient hat.

In den folgenden Beiträgen werden wir weitere Problemstellungen aus dem Alltag von Testerinnen und Testern aufgreifen und besprechen, welche möglichen Lösungsansätze es dafür gibt.

Security und Compliance in Softwareprojekten – Dependencies unter Kontrolle bringen

Symbolbild: Weiße Tastatur mit Schloss und Schlüssel

Dieser Blogbeitrag befasst sich mit den hohen Ansprüchen an Security und Compliance, die wir an jedes Softwareprojekt stellen. Dafür verantwortlich ist in jedem Projekt ein ausgebildeter Security Engineer. Dabei stellen ihn insbesondere die unzähligen Dependencies in Softwareprojekten, welche in ihrer Vielzahl von Versionen unter Kontrolle gebracht werden müssen, vor große Herausforderungen.

Abbildung 1: Ein Ausschnitt aus dem Abhängigkeits-Graph eines npm Paketes, aus npmgraph.js.org/?q=mocha

Herausforderungen in Softwareprojekten

Große Softwareprojekte bestehen schon seit langer Zeit aus kleineren Teilen, die für ihr jeweiliges Gebiet wiederverwendet werden können. Komponenten, bei denen es nicht um geheime Funktionalität geht, werden zunehmend als „FOSS (Free and Open Source Software)“ veröffentlicht. Das bedeutet „quelloffen“ (Open Source) und mit einer freien Lizenz zur Weiterverwendung.

Dabei ist es für die Einschätzung und Prävention von Sicherheitslücken äußerst wichtig, eine vollständige Übersicht über alle eingebundenen Drittbibliotheken zu haben. Denn jedes unserer importierten Module kann ebenfalls mit mehreren Abhängigkeiten verbunden sein. Schnell steigt dann die Anzahl an zu beobachtenden Abhängigkeiten in die Tausende und es ist nicht einfach, zwischen allen Versionen den Überblick über Lizenzen und Sicherheitslücken zu behalten.

Die Auswirkung der Problematik wird z. B. klar, wenn man Fälle von „Supply chain attacks“ und „Dependency Hijacking“ der letzten Jahre liest. Eine interessante Meta-Analyse ist „What Constitutes a Software Supply Chain Attack? “ von Ax Sharma (https://blog.sonatype.com/what-constitutes-a-software-supply-chain-attack). Den Umgang mit diesen Komponenten in großen wie kleinen Softwareprojekten aus Sicht eines Security Engineers möchten wir weiter erläutern.

Lösungsmöglichkeiten mittels FOSS Scanner

Über die Zeit haben sich einige Projekte dem Problem der Kenntlichmachung von FOSS-Komponenten gewidmet. Es gibt Programme zum Erstellen von Bill of Material (BOM) und Übersichten zu Sicherheitsrisiken, welche wir verprobt haben.

Weiter gibt es große Kataloge wie den „Node Paketmanager“ (npm), die selbst ausführliche Informationen zu den jeweils angebotenen Komponenten geben.

Auch wenn es diese freien und quelloffenen Komponenten gratis gibt, so sind sie nicht ohne Aufwand, besonders in langlebigen und wichtigen Softwareprojekten.

Wir haben für die Evaluierung den OWASP-Dependency Check (DC) und das OSS Review Toolkit als kombinierte Lösung für das Auffinden von Sicherheitsproblemen mit DC und Überprüfung der Einhaltung der Lizenzbestimmungen eingesetzt. Im Vergleich zu kommerziellen Lösungen wie BlackDuck bieten diese frei und kostenlos die Möglichkeit einer Übersicht über die FOSS-Komponenten in Projekten und die Bewertung von Risiken.

Das war aber unserer Erfahrung nach mit Mehraufwand sowohl in der Konfiguration als auch bei der kontinuierlichen Überprüfung, d. h. neuen Scans auf neue Sicherheitsprobleme, verbunden.

Verantwortung als Software Engineer

Unsere Richtlinien für sichere Entwicklung und den Einsatz von Open Source geben die notwendigen Prozesse und Ziele vor, an dem sich unsere Security Engineers in Vertretung der Projekte orientieren. Der vielleicht wichtigste Ausschnitt daraus wird im folgenden Abschnitt aufgeführt:

It is our responsibility that the following so called Essential FOSS Requirements are fulfilled:

  • All included FOSS components have been identified and the fitness for purpose has been confirmed.
  • All licenses of the included FOSS have been identified, reviewed and compatibility to the final product/service offering has been verified. Any FOSS without a (valid) license has been removed.
  • All license obligations have been fulfilled.
  • All FOSS are continuously – before and after release – monitored for security vulnerabilities. Any relevant vulnerability is mitigated during the whole lifecycle.
  • The FOSS Disclosure Statement is available to the user.
  • The Bill of Material is available internally.

For that it must be ensured that

  • the relevant FOSS roles are determined and nominated.
  • the executing development and procurement staff is properly trained and staffed.

Anhand dieser Richtlinien werden verpflichtende Trainings, Wissensträger und Qualitätskontrollen gebildet.

Vorstellung der Abläufe

  • Untersuchen vor Einbindung (Lizenzen, Operational Risk wie Update-Häufigkeit)
  • Überwachen von Updates (Operational Risks)

Irgendwann soll eine neue Funktion zu einem Softwareprojekt hinzugefügt werden. Oft kennen Entwickler bereits mögliche FOSS Software, die bei der Funktionalität hilft.

Ein wichtiger Aspekt ist, dass möglichst jeder Entwickler den Umgang mit Paketmanagern und mögliche Implikationen kennt, um Ergebnisse aus den Tools oder Analysen richtig einordnen zu können. Es ist z. B. sehr wichtig, sich zu veranschaulichen, aus wie vielen Teilen eine Top-Level-Abhängigkeit besteht – oder verschiedene Abhängigkeiten gleicher Funktionalität im Hinblick auf zukünftige sichere Entwicklung (Operationelle Risiken) zu bewerten. Immer öfter sehen wir das Ziel, die Zahl an Abhängigkeiten klein zu halten. Das sollte bei der Auswahl von Komponenten berücksichtigt werden, um möglichst nur das wirklich notwendige an Funktionalität von zusätzlichen Abhängigkeiten zu erhalten.

Bereits vor dem Einbinden sind durch den Security Engineer potenzielle Imports auf ihre kompatible Lizenz und bestehende Sicherheitslücken zu überprüfen. Ebenso wichtig ist aber auch der Blick auf das, was unter operationale Risiken fällt wie z. B.:

  • Aktualität
  • Lebendige Community oder aktive Instandhaltung
  • Update-Zyklus ausreichend agil, um auftretende Sicherheitslücken zu beseitigen
  • Wird Wert auf den sicheren Umgang mit Abhängigkeiten gelegt?
  • Ist die Anzahl an weiteren Abhängigkeiten sinnvoll und wird wenn möglich reduziert?

Im laufenden Entwicklungsprozess und später im Betrieb muss das Projektteam auch informiert werden, wenn neue Sicherheitslücken entdeckt oder geschlossen werden. Dafür können periodische Scans oder eine Datenbank mit Alerts für Sicherheitslücken eingesetzt werden. Für periodische Scans spricht die größere Unabhängigkeit von der einen Datenbank – dafür müssen Hardware und Alerts selbst bereitgestellt werden. Diese wiederum sind einer der Mehrwerte einer Software-Composition-Analysis-Lösung wie BlackDuck.

Da der Anteil an gut gekennzeichneter FOSS steigt, wird bei neuen Versionen der Zeitaufwand für manuelle Kuration vergleichsweise geringer. Dazu zählen das Deklarieren einer Lizenz – und leicht auffindbare und formatierte Copyright-Angaben in den Komponenten, was in älteren Komponenten oft sehr individuell formatiert oder ganz weggelassen wurde. Ist keine Lizenz angegeben, so darf dies nicht fälschlicherweise als „Freibrief“ verstanden werden. Ohne eine Lizenz darf eine Komponente nicht ohne Einverständnis der Autoren benutzt werden!

Beispiel einer Sicherheitslücke

Ein Beispiel für eine komplizierte Sicherheitslücke ist unter dem CVE-2021-32796 veröffentlicht worden. Eingebunden wird das problematische Modul xmldom indirekt über zwei weitere Abhängigkeiten in unserem Beispielprojekt.

BlackDuck zeigt uns zu dem Modul folgende Sicherheitswarnung:

Abbildung 2: BlackDuck: Beispiel Zusammenfassung einer Schwachstelle  

Damit kann der Security Engineer bereits eine grobe Einschätzung zur Tragweite der Sicherheitslücke vornehmen. Auch ist ein Hinweis auf dem Patch in Version 0.7.0 angegeben.

Wichtigkeit von Vorlauf für Updates/Austausch von Kompetenzen

Wir haben in der Zeit bis zu der „frischen Veröffentlichung“ unter @xmldom/xmldom bereits überprüfen können, welchen Aufwand es bedeuten würde, ohne diese Abhängigkeit auszukommen.

Um diese Zeit zu haben, ist es sehr nützlich, bereits im Entwicklungsprozess – und mit genügend Vorlauf zu einer Produktveröffentlichung – eine Übersicht über mögliche Probleme zu bekommen.

Das erleichtert den Entwicklern das Evaluieren von Ausweichlösungen für problematische Software-Bibliotheken, sei es wegen Sicherheitslücken, inkompatiblen Lizenzen oder anderer operativer Risiken.

Fazit

Dieser Beitrag hat einen Überblick über unsere Arbeit mit der großen Vielfalt an Open Source in unseren Projekten und die Aufgaben als Security Engineer im Umgang mit Open Source gegeben. Damit bringen wir mittels moderner Werkzeuge die Vielfalt an Abhängigkeiten unter Kontrolle und schaffen die notwendige Transparenz und Sicherheit. Bereits vor Einbinden von Abhängigkeiten sollte eine Evaluierung dieser von einem geschulten Team durchgeführt werden, und danach während des ganzen Software-Lebenszyklus überwacht und auf Probleme reagiert werden.

Softwareentwicklung in Zeiten von Corona – „Business as usual?“

In Zeiten des Social Distancing treten gelegentliche Videokonferenzrunden im Freundeskreis an die Stelle des gemeinsamen Kneipenbesuchs. Hier kam schnell die Diskussion auf, wie stark Corona den Arbeitsalltag beeinflusst.

Die allgemeine Meinung war, dass die Arbeitsfähigkeit stark beeinträchtigt und bei einigen sogar fast gar nicht mehr vorhanden sei. Die Arbeitgeber waren schlicht nicht bzw. nur stark eingeschränkt in der Lage, die notwendige Infrastruktur für die Arbeitsfähigkeit bereitzustellen. Und wenn dann die Infrastruktur endlich stand, wurde allen klar, was jeder weiß, der schon einmal verteilt gearbeitet hat: Es ist kompliziert! Wer darf sprechen? Kamera an oder aus? Da schreit ein Kind im Hintergrund, bitte das Mikrophon muten! Du möchtest etwas sagen? Bitte dein Mikrophon un-muten! Die Verbindung ist schlecht, ich verstehe nur jedes zweite Wort… die Liste lässt sich endlos weiterführen.

Viele sind es einfach nicht gewohnt, so zu arbeiten. Nicht zuletzt, da Kommunikation mehr ist als der bloße Austausch von Worten. Die Deutung bspw. von Körperhaltung, Mimik und Gestik der Gesprächspartner ist bei Telefon- und auch Videokonferenzen ungleich schwieriger. Das ist eine neue Situation, die viel Disziplin und Anpassungen aller Beteiligten erfordert!

Die Diskussionen mit meinen Freunden ziehen dann so vor sich hin und Erfahrungsberichte über Video-Tool-Anbieter wechseln sich mit Klagen über die eigentliche „Unmöglichkeit“ des Arbeitens in dieser Situation ab. Währenddessen suche ich in meinem Kopf verzweifelt nach eigenen Wortbeiträgen für diese Diskussion. Und ich finde auf die Frage „Was hat sich für dich seit Corona in deiner Arbeit geändert?“ nur die Antwort: „Eigentlich nichts!“

Das ist – zugegeben – eine leichte Übertreibung! Die Fahrt ins Büro, das gemeinsame Mittagessen mit Kollegen, der Schwatz an der Kaffeemaschine – all das fällt nun erst einmal weg und bedeutet einen herben Einschnitt und Verlust. Wenn, wie in meiner Situation, das Home-Office nicht nur Büro sondern auch noch Kita ist und beide Elternteile Vollzeit arbeiten, wird verteiltes Arbeiten auch für Menschen, die damit eigentlich Erfahrung haben, zu einer Herausforderung.

Aber auch hier gilt: Die Ausgangssituation ist für die meisten Menschen gleich. Insofern hilft es nur, sie entsprechend anzunehmen und das Beste daraus zu machen. Und genau da zeigt sich einmal mehr, wie wichtig es ist, bereits Erfahrungen im verteilten Arbeiten gesammelt zu haben.

Die ZEISS Digital Innovation (vormals Saxonia Systems AG) verfolgt seit vielen Jahren das Grundprinzip des Arbeitens in verteilten Teams. Nicht zuletzt, um die Work-Life-Balance der Mitarbeiterinnen und Mitarbeiter zu erhalten, ist es dem Unternehmen wichtig, dass die Leistungen für einen Kunden theoretisch überall erbracht werden können. Dadurch werden zum einen Reisekosten gespart und zum anderen wird sichergestellt, dass die notwendige Infrastruktur für die Arbeit vorhanden ist und nicht ggf. noch extra vom Kunden beschafft werden muss.

Person sitzt vor Laptop und mehreren Monitoren während einer Videokonferenz und nutzt das Tool ETEOboard für verteilte Zusammenarbeit
Abbildung 1: Verteilte Projektarbeit im Home-Office

Ich persönlich habe in meiner fünfjährigen Betriebszugehörigkeit erst ein Projekt erlebt, bei dem das Entwicklungsteam ständig an einem Standort versammelt war. In meinem aktuellen Projekt, gestartet im September 2019, liegt eine extreme Verteilung vor: Die sechs Projektmitglieder der ZEISS Digital Innovation sitzen an fünf unterschiedlichen Standorten, die Projekt-Stakeholder des Kunden an zwei Standorten. Insofern haben wir nicht erst seit Corona die Herausforderung des verteilten Arbeitens zu meistern, sondern diese Verteilung bereits zu Projektstart als Risiko identifiziert, dem wir uns stellen mussten.

Gelungen ist uns das meiner Meinung nach mit einem simpel anmutenden Mittel: Direkte Kommunikation!

Das Entwicklungsteam hat oft die Technik des PairProgramming eingesetzt, um einerseits den Know-how-Transfer innerhalb des Teams zu fördern, aber auch, um den individuellen Stil des jeweils anderen kennenzulernen. Daneben gehören bei uns Code Reviews zum Standardvorgehen. Diese dienen einerseits der Qualitätssicherung, andererseits fördern Code Reviews auch den Wissensaustausch innerhalb des Teams. Neben dem Daily-Meeting für alle Teammitglieder haben wir ein eigenes „DEV-Daily“ etabliert, in dem sich das Entwicklungsteam in kleinerer Runde über insbesondere technische Fragestellungen austauschen kann.

In regelmäßigen Refinement-Meetings werden fachliche Anforderungen mit technischen Lösungsansätzen gemappt. Ideen werden gesammelt, geprüft, angepasst, verworfen und neu entwickelt und das ohne Denkverbote und -schranken. Dadurch ist ein Raum der Kreativität und freien Entfaltung entstanden, in dem jedes Teammitglied seine Ideen einbringen kann und sich dadurch wertgeschätzt und mitgenommen fühlt: Trotz der Verteilung ist ein echter Teamspirit entstanden!

Die Etablierung dieser offenen Kommunikationskultur führt dazu, dass wir innerhalb des Teams intensiver und häufiger kommunizieren, sei es im Vier-Augen-Gespräch oder in der Gruppe. Dabei ist immer zu beachten, dass den individuellen Präferenzen der Teammitglieder hinsichtlich der Kommunikation Rechnung getragen wird: Manche Menschen sind Frühaufsteher. Sie sind um 8 Uhr morgens bereits voll in ihrem Flow und platzen fast, ihre neuen Ideen den Kolleginnen und Kollegen mitzuteilen, während andere um diese Uhrzeit noch kaum die Augen aufkriegen. Einige möchten gerne im Vorfeld einen Termin bekommen, um Dinge zu besprechen, damit sie planen und sich vorbereiten können. Andere springen ganz leicht zwischen Themen hin und her und man kann sie einfach ad hoc mit einem Anruf überfallen.

Um effizientes Arbeiten auch in einem verteilten Team zu ermöglichen, ist es zugegebenermaßen vermutlich nicht ausreichend, einfach „mehr zu kommunizieren“. Vielmehr ist ein durchdachtes Konzept, das alle Aspekte und Herausforderungen von verteiltem Arbeiten berücksichtigt, unabdingbar. Das gilt insbesondere für Teams mit wenig Erfahrung im verteilten Arbeiten.

Die ZEISS Digital Innovation hat bereits vor einigen Jahren mit dem ETEO-Konzept Aufmerksamkeit erregt. ETEO („Ein Team Ein Office“) ist ein Framework zur verteilten Arbeit von Projektteams. Es gibt Projektteams einen Leitfaden an die Hand, wie verteilte Arbeit erfolgreich gestaltet werden kann. Eine permanente Videoverbindung zwischen den Standorten und die Nutzung eines digitalen Workboards für die Organisation von Aufgaben ermöglichen es den Teams, standortübergreifend zusammenzuarbeiten, quasi als wären sie an einem Standort versammelt. Die Videoverbindung ist dabei kein Muss, sondern lediglich ein Element aus dem Baukasten des bei ZEISS Digital Innovation gebräuchlichen Tool-Kits für verteiltes Arbeiten. Im Unternehmen gibt es speziell geschulte Mitarbeiter (ETEO-Coaches), welche die Teams in der Ramp-up-Phase eines Projektes und während des weiteren Projektverlaufs dediziert in Techniken für verteilte Zusammenarbeit schulen und hinsichtlich einzusetzender Tools beraten. Bei unseren Kunden führt dies oft zu „Aha-Effekten“, dass verteilte Zusammenarbeit durchaus möglich ist – und zwar ohne Performance-Einbußen befürchten zu müssen.

Grafik eines Hauses "Ein Team Ein Office" auf vier Säulen und auf der Basis von Werten für verteilte Scrum-Teams
Abbildung 2: ETEO – unser Zusammenarbeitsmodell

Generell gilt aber auch für das verteilte Arbeiten: Das Werkzeug ist nichts, wenn man es nicht einzusetzen weiß! Damit meine ich, dass verteiltes Arbeiten ohne die entsprechende Disziplin und das passende Mindset der Beteiligten nicht gelingen kann. An dieser Stelle bleibt zu sagen: Man muss sich darauf ohne Vorbehalte einlassen sowie Tools und Techniken einfach mal ausprobieren. Und natürlich: Übung macht den Meister! Je länger ein Team verteilt zusammenarbeitet, desto stärker bilden sich die Best Practices für die verteilte Arbeit in der individuellen Teamkonstellation heraus. Man darf nicht außer Acht lassen, dass es das ultimative Konzept für verteiltes Arbeiten nicht gibt. Denn in Projekten kommunizieren keine Rollen oder Verantwortlichkeiten miteinander, sondern immer Menschen und die sind bekanntlich unterschiedlich.

Jedes Projekt ist anders und damit auch die Anforderungen an die verteilte Arbeit. Aber die Grundprinzipien sind überwiegend gleich. Das ist vergleichbar mit dem Bau eines Hauses: Ein Haus kann 1, 2, 3 oder 20 Stockwerke haben, ein Spitz- oder ein Flachdach, Doppelfenster oder einfache Fenster, aber jedes Haus hat ein Fundament, auf dem es steht.

Und die Fundamente der verteilten Arbeit sind bei ZEISS Digital Innovation sehr stabil!

Personas – wenn der Nutzer nicht gerade nebenan sitzt…

Personas in a nutshell – Was sind Personas und wozu brauche ich diese?

Im Umfeld der agilen, verteilten Softwareentwicklung kommt es gerade im B2B-Kontext häufig zu dem Szenario, dass der Auftraggeber der einzige Ansprechpartner für den Entwicklungsdienstleister ist. Oft begründet sich dies durch die mangelnde Verfügbarkeit der Endnutzer, welche entweder örtlich vom Entwicklungsteam getrennt sind oder keine Zeit haben. Wenn der Nutzer nicht gerade nebenan sitzt, können Personas Abhilfe schaffen und den fehlenden Nutzerkontakt kompensieren.

Personas stellen prototypische Benutzer in Vertretung einer Benutzergruppe dar und verkörpern deren wichtige Eigenschaften und Bedürfnisse in Hinblick auf das geplante Produkt. Sie verdichten die Ergebnisse aus der Kontextanalyse, ersetzen jedoch die Nutzerforschung nicht. Die Ausgestaltung erfolgt in Poster-Form, möglichst „lebendig“ und realistisch, denn sonst ist die Persona nicht brauchbar. Generell entstehen Personas in frühen Projektphasen (Analyse und Planung) und werden dann über den gesamten Entwicklungszyklus hinweg als Soll-Ist-Vergleich verwendet. So wird es dem Design- und Entwicklungsteam ermöglicht, sich auf Nutzerbedürfnisse zu fokussieren. Bei Diskussionen dienen sie als Entscheidungsreferenz und stellen mit einer Frage wie „Würde Person x das verstehen?“ den Nutzer in den Vordergrund. Vor allem dem Product Owner helfen Personas bei der Bewertung von Ideen für neue Features.

Oft braucht es nicht nur eine Persona, sondern mehrere Personas, um die potentiellen Benutzer der Software abzudecken. Falls zu viele, eventuell auch im Widerspruch zueinander stehende Personas existieren, ist es hilfreich, diese in primäre und sekundäre Personas zu unterteilen. Das hilft, den Fokus auf die Zielnutzergruppe zu behalten und Entscheidungsalternativen zu gewichten.

Und welche Bestandteile werden nun für eine gute Persona benötigt?

  • Name: Ein realistischer Name, anhand dessen man die Persona identifizieren kann
  • Alter: Lässt Rückschlüsse auf die Einstellung der Persona zu
  • Bild: Ein Bild, egal ob fotografiert oder gezeichnet, damit die Persona realistischer wird
  • Persönliche Informationen: Alter, Geschlecht, fachliche Ausbildung, Wissen und Fähigkeiten, Familienstand, Kinder, …
  • Persona-Typ: Die zugehörige Nutzergruppe / der Archetyp (z. B. Teenager, Hausfrau, Rentner)
  • Beruf: Funktion, Verantwortlichkeiten und Aufgaben
  • Technische Expertise: Allgemeine Computerkenntnisse, Technikaffinität, Kenntnisse über verwandte Produkte, Vorgängersysteme oder Konkurrenzprodukte
  • Charakter: Die persönlichen Einstellungen und Werte der Persona – Ist sie z. B. aufgeschlossen gegenüber Neuem?
  • Verhaltensmuster und Vorgehensweisen: Werte, Ängste, Sehnsüchte und Vorlieben
  • Ziele: Die wesentlichen Aufgaben, welche mit der neuen Anwendung zu bearbeiten sind
  • Bedürfnisse & Erwartungen: Anforderungen an den Umgang mit dem Produkt
  • Frustration: Typische Ärgernisse an Produkten generell, was also unbedingt zu vermeiden ist

Persona Template

Das Usability Team der Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation) hat auf Basis der Best Practices und eigener Erfahrungen ein Template zur Erstellung einer Persona entwickelt. Das Template ist kostenlos als PDF erhältlich: DOWNLOAD

Template Personas
Template zur Erstellung einer Persona

Mit dem Persona Template haben Sie die Möglichkeit, Ihre Software noch besser an Ihre potentiellen Nutzer anzupassen und verlieren nie den Blick auf das Wichtigste … denn wir wissen ja alle: „The user is always right.“

In Sachsen, da geht was – JUG Saxony Day 2017

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.

Gefüllter Vortragssaal beim JUG Saxony Day 2017
© 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.