famous for integration White Paper SIMULATIONEN in der Software-Entwicklung Einsatzgebiete und Nutzen René Schwarb, Andreas Elsener

famous for integration White Paper SIMULATIONEN in der Software-Entwicklung Einsatzgebiete und Nutzen René Schwarb, Andreas Elsener

2 Simulationen Komponentenbasierte, grosse Systeme Natiaspe llorepr aereium sit et perioss itatur, et pra non conestem que nimoluptatin nis vellate peliquundel inte rem la culliquas autes venist quatent autaepti re denihillanis aborerum re cus, sita demporerum hil il mi, sumqui am, exceati onseque pres rehent verum que od mos evenet unt.

3 Simulationen Inhalt Einleitung 5 Einsatzgebiete 1. Client/Server-Entwicklung 12 2. Komponentenbasierte, grosse Systeme 14 3. Migration oder Einführung von Standardlösungen 16 4. Outsourcing und externe Softwareentwicklung 18 5. B2B und M2M Szenarien 20 6. Integrationsplattformen 22 7. Testdatenmanagement 24 8. Testautomatisierung 26 9. Performancetests (Effizienztests) 28 10. Mobile Apps 30 11. Agile Software-Projekte 31 12. Schulung auf IT-Systemen 32 ipt entwickelt Simulations-Lösungen für Ihr Unternehmen 35 Am Ende des White Papers befindet sich ein Glossar

Einleitung 5 Simulationen

6 Simulationen Zusammenfassung In komplexen Projekten stellt die Verfügbarkeit von Umsystemen eine grosse Herausforderung dar. Ist die Schnittstelle einer Teillösung verspätet, nicht verfügbar oder fehlerhaft, sind die Folgen für das Gesamtprojekt meist Kosten- und Terminüberschreitungen. Das muss heute nicht mehr so sein. Mittels Simulationen werden in der Software-Entwicklung automatisch Software-Objekte generiert, die eine «Konversation» zwischen zwei beliebigen Systemen nachempfinden. Moderne Simulationen können Anfragen «beantworten» und haben ein reales Daten- und Perfomance-Verhalten. Im vorliegenden White Paper werden konkrete Einsatzgebiete für Simulationen über den ganzen Software-Lifecycle beschrieben. Die effektiven Einsatzmöglichkeiten sind allgemein gehalten. Für die konkrete Erhebung des Potenzials von Simulationen erarbeiten wir Ihnen gerne eine individuellen Studie, zugeschnitten auf Ihr Unternehmen (siehe Kapitel «ipt entwickelt Simulations-Lösungen für ihr Unternehmen», S. 35) Mit Simulationen sind Sie besser, schneller und billiger: Bessere Qualität, weil früher eine umfassendere und stabilere Umgebung für die Entwicklung und das Testen zur Verfügung steht. Kürzere Projekt-Laufzeiten, da unter anderem die Abhängigkeit zwischen den Entwicklungsteams, wie auch zwischen den Umsystemen stark reduziert werden. $ Weniger Kosten, da ein erheblicher Teil der Entwicklungs- und Testinfrastruktur eingespart wird, was Beschaffungs- und Betriebskosten für Hard- und Software massiv reduziert.

7 Simulationen Wieso Simulationen? Herausforderung Die meisten Applikationen in grösseren Unternehmen sind mit anderen verbunden. Viele Komponenten, Applikationen und sogar Systeme sind Teil eines grösseren Systems und interagieren mit internen und externen Komponenten. Dieser Verbund von Komponenten und Systemen schafft Abhängigkeiten. Bei der Entwicklung, beim Testen oder bei der Schulung sollen die verbundenen Systeme gemeinsam verfügbar sein und einen sinnvollen Datenzustand aufweisen. Das bedeutet hohe Kosten bezüglich Beschaffung von Hardware, Software und Personal. Aufholbedarf IT-Systeme hinken dem vielfältigen Einsatz von Simulationen in Wirtschaft und Industrie hinterher. Von Software-Entwicklern selbst programmierte Simulationen, sogenannte Mock-ups, die zum Testen von Schnittstellen verwendet werden, skalieren nicht. Neue Softwarewerkzeuge hingegen erzeugen und pflegen automatisiert die Softwaresimulationen. Lösung Simulationen sind eine Art «industrielles Mocking». Dadurch wird eine Umgebung generiert, die ähnlich arbeitet wie das Original. Simulationen sind mehr als eine simple Wiedergabe von aufgezeichneten Anfrage/Antwort-Paaren. Die simulierten Rückgabewerte werden mittels komplexer Algorithmen berechnet und variiert. So wird eine realistische Daten- und Performance- Charakteristik erreicht.

8 Simulationen Wie funktionieren Simulationen Aufzeichnen Um eine Schnittstelle zu simulieren, muss eine Grundlage geschaffen werden. Dafür gibt es folgende Möglichkeiten: Datenverkehr zwischen den Systemen abhören. Log-Dateien einlesen. Simulation ab Spezifikation generieren. Agenten in der Software installieren, die die Interaktionen zwischen Objekten aufzeichnen. Simulation von Grund auf erstellen. Bei der Aufzeichnung können strukturierte Daten automatisch anonymisiert werden. Bei der Aufzeichnung kann es sinnvoll sein, eine spezielle, falsch formatierte Anfrage durchzuführen. Die Simulation wird dann eine Fehlermeldung zurückgeben, wenn eine korrupte Anfrage empfangen wird. Modellieren Die aufgezeichneten Daten können bei Bedarf manuell erweitert werden. Hier können auch Simulationscharakteristiken definiert werden (z.b. für Effizienztests). Simulieren Simulationen werden installiert und mit dem System under Test verbunden. Entwicklungs- oder Testteams können die Servicesimulation verwenden, um Software zu testen und zu debuggen. Pflegen Wenn sich die Schnittstelle verändert, kann die Simulation keine plausible Antwort liefern. In diesem Fall kann der Simulator in einen «Selbstheilungs»-Modus gehen und Anfragen an das echte System weiterleiten, um danach die Simulation zu ergänzen. Alternativ dazu kann die Simulation manuell an das neue Verhalten angepasst werden. Aufzeichnen > Modellieren > Simulieren > Pflegen

9 Simulationen Software-Lifecycle Entwicklung Der Entwicklungsprozess beginnt mit der Anforderungsanalyse. Daraus wird ein Design erstellt und Details wie Schnittstellen spezifiziert. Die Komponenten werden individuell entwickelt. Danach werden sie zu einer einzigen Applikation zusammengeführt und integriert. Dabei geht es nicht nur um eigene Applikationen, sondern auch um Systeme von Partnerunternehmen. Für die Sicherstellung der Qualität werden in allen Subprozessen Tests durchgeführt. Im frühen Stadium sind dies Reviews, nach der Implementierung Komponententests. Während der Integration geht es um Schnittstellentests und zum Schluss werden Systemtests gemacht. Testautomatisierungen, die gezielt die Qualität von Komponenten oder Schnittstellen überwachen, werden immer wichtiger vor allem in Projekten, wo die iterative Vorgehensweise dazu führt, dass gewisse Komponenten mit einer grossen Wiederholungsrate getestet werden müssen. Simulationen erhöhen die Qualität in der Entwicklungsphase. Einführung Bevor ein System in Betrieb genommen wird, muss es noch einmal komplett durchgetestet werden. Bei solchen Abnahmetests wird geprüft, ob das System den Anforderungen für den Produktionsbetrieb genügt. Dazu gehört auch ein Performancetest, der die Leistungsfähigkeit einer Applikation bezüglich Geschwindigkeit, Stabilität und Skalierbarkeit testet. Dank Simulationen können schon Teilsysteme abgenommen werden. Zudem müssen zukünftige Benutzer auf dem neuen System ausgebildet werden. Erst wenn die Abnahme und die Schulungen erfolgreich waren, kann ein System für den Produktionsbetrieb freigegeben werden. Die Schulung auf Simulationen ist sehr kosteneffizient. Betrieb und Wartung Während dem Betrieb soll das System unterbrechungsfrei zur Verfügung stehen. Dennoch müssen Sicherheits-Updates, Optimierungen und Erweiterungen programmiert und getestet werden. Für die Entwicklung und die Tests neuer Systeme müssen weitere Umgebungen oder Systeme aufgebaut werden. Diese Infrastruktur-, Betriebs- und Lizenzkosten können dank Simulationen tief gehalten werden. Firmen mit einer starken Business-to-Business-Ausprägung müssen Schnittstellen für ihre Partner anbieten. Über diese Schnittstellen können auch während dem Produktionsbetrieb neue Partnersysteme entwickelt werden. Simulationen sind hier eine günstige Alternative. Ablösung Gründe für ein neues System sind unterschiedlich: z. B. Ende von Garantieleistungen für Hardware oder Lebenszyklen von Software, fehlende Stabilität oder zu hohe Betriebskosten. Das neue System soll mit identischer Datenlage arbeiten und mindestens dieselben Geschäftsfälle bearbeiten können. Bei der Ablösung von grossen Softwaresystemen sind Simulationen äusserst nützlich.

Einsatzgebiete 11 Simulationen

12 Simulationen Integration von heterogenen Systemen Herausforderung Die Applikationslandschaft einer Unternehmung ist heute in der Regel heterogen und verteilt. Als Architekturstil wird deshalb oft der Service-orientierte Ansatz gewählt. Dabei werden Funktionalitäten und Anwendungen als Services gebündelt und durch eine Middleware entkoppelt (vgl. Abb.). Oftmals muss die Identität des Nutzers mitgeführt werden, damit Zugriffskontrollen durchgeführt werden können und die Nachvollziehbarkeit gewährleistet ist. Involvierte Systeme wurden mit verschiedenen Technologien unterschiedlicher Hersteller gebaut, weshalb ganz unterschiedliche Methoden zur Authentisierung und sicheren Übermittlung digitaler Identitäten unterstützt werden. Sicherheitsanforderungen werden oft durch Applikationsentwickler ausprogrammiert. Die Erfahrung zeigt, dass dies mit einigen Nachteilen verbunden ist, beispielsweise ungenügender oder gar nicht implementierter Zugriffschutz, durch Architektur- oder Programmierfehler entstandene Sicherheitslöcher oder inkonsistent implementierte Sicherheitsrichtlinien. Solcher Code muss getestet und gewartet werden, und Änderungen an Sicherheitsrichtlinien können nur im Rahmen eines Releases eingepflegt werden. Baut man Security direkt in Komponenten ein, besteht die Gefahr von Wildwuchs, Redundanz und fehlender Flexibilität. Das Durchsetzen von unternehmensweiten Richtlinien wie zu verwendende Standards, Authentisierungsmittel oder kryptografische Algorithmen ist stark eingeschränkt. Dies gilt auch für Security Audits. Lösung Die Abbildung zeigt einen möglichen Ansatz einer sicheren Integration von Back-end-Systemen. Dabei wird ein SOA-Mediator (z.b. ein Enterprise Service Bus ESB oder ein Service Gateway) eingesetzt, der externalisierte Security in Form sogenannter Policy Execution resp. Policy Enforcement Points nutzt. Diese erlauben es, Sicherheitsanforderungen ohne Code zu spezifizieren und als Policies auszulagern. Das nennt man auch deklarative Security, die von den meisten unternehmenstauglichen Applikationsservern unterstützt wird. Der SOA-Mediator überbrückt nicht nur unterschiedliche Formate der Nutzlast, sondern vermittelt auch zwischen verschiedenen Security Mechanismen..

13 Simulationen Vorher Nachher

14 Simulationen 2. Komponentenbasierte, grosse Systeme Herausforderungen In grossen Unternehmen sind oft viele Teilsysteme im Verbund im Einsatz. Einzelne Komponenten werden eingekauft, andere intern oder von Partnerfirmen entwickelt. Wenn eine Komponente in einer neuen Version geliefert wird, muss ein gesamter Systemtest durchgeführt werden. Solche Tests sind sehr teuer, weil die ganze Applikationslandschaft zu Verfügung gestellt werden muss (vgl. Abb.). Systeme dieser Art werden oft in zwei bis vier Releases pro Jahr entwickelt. Die verschiedenen Beteiligten implementieren ihre Änderungen auf einen bestimmten Termin. Wenn einzelne Komponenten nicht bereit sind, verzögert sich der gesamte Test, was zu Releaseverschiebungen führen kann. Wegen Fehlern, die erst nach Einführung entdeckt werden, kann ein solches Vorgehen einen zusätzlichen Release nötig machen. Dieser erfordert einen neuen Abnahmetest auf dem Gesamtsystem, was je nach Komplexität mehrere Hunderttausend Franken kosten kann. Lösung Bevor eine veränderte Komponente in den Systemverbund integriert wird, testet man sie zuerst in einem autonomen Testbed. Dabei werden alle angrenzenden Umsysteme simuliert. Mit Simulationen erhalten einzelne Teams sowohl interne wie auch externe Umsysteme mit realistischen und anonymisierten Daten (vgl. Abb.), ohne dass teure Hardware- oder Produktlizenzen benötigt werden. Die Simulationen können jederzeit mit dem realen Verhalten der veränderten Umsysteme automatisiert abgeglichen und auf einfache Weise wieder verteilt werden. Auf einem Simulator können verschiedene Versionen derselben Schnittstelle parallel laufen oder ein Umsystem mit mehreren Varianten von Datenständen. Nutzen Komponenten, die zur Integration abgeliefert werden, haben bereits einen grossen Teil der Integrationstests auf dem Simulator bestanden. Teilweise werden sogar Zertifizierungen gegen Simulationen gemacht. Es gibt weniger Abhängigkeiten zu anderen Entwicklungsteams, was paralleles Arbeiten zulässt. Integrationstests können viel früher begonnen werden. $ Teure Abnahmetests auf dem Gesamtsystem können auf ein Minimum reduziert werden. Applikationslandschaften für die Entwicklung einzelner Komponenten erübrigen sich, was Betriebs-, Wartungs- und Lizenzkosten spart.

15 Simulationen Vorher Nachher

16 Simulationen 3. Migration oder Einführung von Standardlösungen Herausforderung Beim Einsatz grosser Standard-Pakete wie SAP etc. kommt es immer wieder zu grossen Migrationsprojekten. Dafür wird eine neue Umgebung parallel zur bestehenden Entwicklungs- und Testumgebung aufgebaut (vgl. Abb.), da letztere für Wartungsarbeiten am produktiven System be nötigt wird. Für die Migrationsphase werden typischerweise mehrere Instanzen der gesamten Umgebung benötigt. Parallel zu den bestehenden Instanzen (Entwicklung, Test, Integration) braucht es zusätzliche Kopien der Standardlösung. Diese müssen mit den Umsystemen verbunden werden. Um konfliktfrei arbeiten zu können, müssen auch Kopien der Umsysteme erstellt werden in grossen Projekten muss mit bis zu zehn und mehr Kopien der Plattform gerechnet werden. Das ist teuer und aufwändig. Je mehr autonome Plattformen aufgebaut werden müssen, desto grösser wird der Aufwand, diese synchron zu halten. Durch eine Minimierung ihrer Anzahl sollen sichtbare Kosten (Hardware, Software und Betrieb) gesenkt werden oft zu Lasten der versteckten Kosten (viele kleine Mehraufwände bei den Entwicklern). Lösung Die Umgebung jeder einzelnen Instanz kann mit Simulationen nachgebildet werden (vgl. Abb.). Dies entkoppelt die verschiedenen Systeme und erlaubt es jedem Team autonom zu arbeiten. Die Simulationen können auf die spezifischen Anforderungen der Teams eingestellt und jederzeit mit den realen Umsystemen synchronisiert werden. Mit Simulationen können sowohl interne wie auch externe Umsysteme mit demselben Ansatz dargestellt werden. Nutzen 1 In Migrationsprojekten können das abzulösende System und das neuentstehende System gleichzeitig getestet werden. Wenn an den angebundenen Umsystemen ebenfalls Änderungen vorgenommen werden, liefern die Simulationen gleichzeitig den Nutzen, der unter Client/Server-Entwicklung beschrieben ist (vgl. 1.). Ermöglicht paralleles und flexibles Arbeiten der Wartungsteams der aktuellen Systeme sowie der Entwicklungs-, Parametrisierungs- und Test-Teams der neuen Entwicklung. Zusätzliche Instanzen können kurzfristig zur Verfügung gestellt werden, was langwierige Beschaffungsprozesse massiv verkürzt. $ Weil viel weniger Infrastruktur beschafft werden muss, sinken die Projektkosten massiv. Dank Simulationen reduzieren sich die Beschaffungs-, Betriebs- und Wartungskosten für Projektumgebungen drastisch.

17 Simulationen Vorher Nachher

18 Simulationen 4. Externe Software-Entwicklung Herausforderungen Extern entwickelte Lösungen müssen im Verbund mit den angebundenen Systemen getestet werden. Dazu baut man die Systeme beim externen Partner auf und füllt sie mit realen Testdaten oder Externe bekommen einen Zugang auf interne Testsysteme (vgl. Abb.). Für solche Zugriffe muss meist eine extra Umgebung aufgebaut werden, da sich sonst externe und interne Entwickler und Tester in die Quere kommen. Oft sind interne Testdaten Extrakte aus der Produktion. Dadurch wird sichergestellt, dass für alle Tests die relevanten Konstellationen zur Verfügung stehen. Ein externer Zugriff auf solche Systeme ist aber nicht erwünscht oder erlaubt, weshalb Daten verfälscht, anonymisiert oder synthetisch erzeugt werden müssen. Der Aufwand, eine Plattform für externe Partner bereitzustellen, ist erheblich. Lösung Die externen Partner bekommen anstelle einer ganzen Umgebung nur die Simulation der Umgebung (vgl. Abb.) Simulationen werden aus dem Original-System erzeugt. Bei der Generierung werden Daten automatisch desensibilisiert und anonymisiert. Nutzen 1 Die Komponenten können auch bei externen Lieferanten getestet und optimiert werden, sodass bei der Integration oder bei der späteren Werksabnahme kaum mehr Fehler auftreten. Das komplexe Aufbereiten von Testdaten entfällt, weil mit Simulationen direkt anonymisierte Antworten generiert werden können. $ Auf den Aufbau einer extra Umgebung kann verzichtet werden, was Betriebs-, Wartungsund Lizenzkosten spart.

19 Simulationen Vorher Nachher

20 Simulationen 5. B2B- und M2M-Szenarien Herausforderungen Unternehmen, die ihren Partnern eine Lösung zur Verfügung stellen, an die sich Partnersysteme anschliessen können, müssen damit rechnen, dass neue Partnersysteme hinzukommen, bestehende Partnersysteme abgelöst oder Schnittstellen erweitert werden (vgl. Abb.). Projekte sind daher auf ein stabiles Testbed angewiesen. Verschiedene externe Partner sind mit dem zentralen System verbunden. Um eine reibungslose Verarbeitung zu garantieren, müssen die Partnersysteme einwandfreie Meldungen schicken. Für die Tests der externen Partnersysteme muss eine zusätzliche Plattform betrieben werden. So wird sichergestellt, dass neue Systeme die Anforderungen des zentralen Providers erfüllen. Lösung Anstelle einer kompletten Testplattform wird den externen Partnern eine Simulation der Schnittstelle zur Verfügung gestellt, mit der sie sich verbinden müssen. Die Simulation kann generische und partnerspezifische Testfälle enthalten (vgl. Abb.). Nutzen Die Simulation kann auch extern betrieben werden. Simulatoren können auch die Qualität der Partnersysteme beurteilen. Verschiedene Versionen der Schnittstellen sind parallel simulierbar. Partner können jederzeit auf die Simulation zugreifen, was die Koordination und Verzögerungen reduziert. $ Hardware-, Software- und Betriebskosten können gespart werden.

21 Simulationen Vorher Nachher

22 Simulationen 6. Integrationsplattformen Herausforderungen Die Arbeit der Integrationsteams beginnt erst, wenn alle anzuschliessenden Consumer- und Provider-Applikationen fertig sind. Integrationsteams stellen als erste fest, wenn zu integrierende Applikationen fehlerhafte Schnittstellen aufweisen das ist viel zu spät. Für die Qualitätssicherung der Integrationsplattform ist das Team darauf angewiesen, dass Applikations-Entwicklerteams ihre Tests ausführen (vgl. Abb.). Nur so können alle möglichen Interaktionen, die über die Integrationsplattform kommunizieren, getestet werden. Da dieser Ansatz personalintensiv ist, wird aus Kosten- und Zeitgründen oft darauf verzichtet. Umsysteme speziell für das Integrationsteam zu duplizieren ist nicht zielführend, weil die Integrationsteams die fachliche Funktionalität der angeschlossenen Applikationen meist nicht oder nicht genau genug kennen. Simulationen mit konventionellen Mock-ups sind grosse Kostentreiber in IT-Projekten. Die konventionellen Simulatoren bleiben aufgrund des eingeschränkten Fachwissens über die angeschlossenen Applikationen zudem eher einfach und sind über einen längeren Zeitraum betrachtet nicht wartbar. Lösung Simulation von funktionalem und nicht-funktionalem Verhalten von Umsystemen, um eine Integrationsplattform zu testen. Aus der automatischen Analyse und Aufzeichnung der Interaktionen von Systemen mit der Integrationsplattform werden Simulatoren automatisiert erzeugt und regelmässig mit echten Anwendungen synchronisiert. Bediener benötigen kein detailliertes Wissen über die fachliche Bedeutung der Interaktionen. Simulationen werden als autonomes Testbed um die Middleware verwendet (vgl. Abb.). Diese haben nebst der plausiblen Konversation zwischen den Systemen auch eine spezifische Daten- oder Performace- Charakteristik. Nutzen Das Retesting der Integrationsplattform wird massiv vereinfacht, weil die Bedienung der angeschlossenen Systeme wegfällt. Sämtliche nötigen Interaktionen mit der Integrationsplattform werden simuliert. Teilintegrationen können unabhängig und autonom getestet werden. Das Integrationsteam kann früher mit der Arbeit beginnen, weil die virtuellen Schnittstellen früh zur Verfügung stehen Schnittstellenprobleme können dadurch rechtzeitig behoben werden. $ Hardware-, Software- und Betriebskosten können gespart werden, weil keine Integrationsumgebungen dupliziert werden müssen. Der hohe Entwicklungsaufwand für konventionelle Mock-ups fällt weg.

23 Simulationen Vorher Nachher

24 Simulationen 7. Testdatenmanagement Herausforderungen Für jede Art von systematischem Testen werden relevante und stabile Testdaten benötigt, die alle aktuellen und in Zukunft existierenden Geschäftskonstellationen abdecken sollten. Für Last- und Performancetests müssen die Testdaten auch dem realen Datenvolumen der Produktion entsprechen. Es muss möglich sein, Testsysteme innerhalb von Minuten in einen bestimmten Zustand zu bringen. Zudem sollten verschiedene Zustände (Tages- und Monats-Ende, vor und nach bestimmten Verarbeitungen etc.) vorrätig sein. Für externe Projekte müssen Daten zudem synthetisch oder anonymisiert sein und mit statistischen Verfahren nicht wieder in den ursprünglichen Zustand versetzt werden können. Im einfachsten Fall werden periodisch Produktionsdaten auf das Testsystem migriert. Sobald externe Partner mit den Daten arbeiten, werden diese anonymisiert sehr sensitive Daten müssen synthetisch erstellt werden. Grosse Datenmengen zu anonymisieren dauert sehr lange. Beim synthetischen Erstellen der Daten ist es extrem aufwändig, das gewünschte Volumen an Daten zu erreichen. Lösung Wenn Last-Tests gemacht werden, antwortet eine simulierte Datenbank so schnell wie das echte Datenbanksystem mit dem realen Datenvolumen. Mit Simulationen reduziert sich der Bedarf, Systeme immer wieder auf bestimmte Ausgangszustände zu bringen, denn Simulationen sind immer im gewünschten Ausgangszustand. Dabei werden nicht Rohdaten von den Datenbanken gespeichert, sondern Anfragen auf Schnittstellen geben plausible Antworten. Beim Erzeugen der Simulation können die Daten automatisch anonymisiert werden. Da die Rohdaten gar nicht wirklich vorliegen, können diese auch nicht über statistische Verfahren extrahiert werden. Nutzen Dank Simulationen erhält man virtuelle Testdaten, die komplett anonym sind und auch keine Rückschlüsse zulassen. Die Daten können laufend ergänzt werden und brauchen extrem wenig Platz, weil nur ein Bruchteil davon effektiv gespeichert wird. Virtuelle Testdaten können gleichzeitig von mehreren Benutzern verwendet werden, ohne sich gegenseitig zu beeinflussen oder zu stören. Weiter entfällt das aufwändige Zurücksetzen von ganzen Applikationen in vielen Fällen. $ Das einfache Handling der virtuellen Testdaten spart viele manuelle Operationen und damit auch Kosten. Die einfache Art Testdaten zu generieren macht teure Datenbanken für Tests überflüssig.

26 Simulationen 8. Testautomatisierung Herausforderungen Unternehmen mit Anwendungen, die kritisch für den Geschäftserfolg sind, betreiben einen hohen Aufwand für die Sicherstellung der Softwarequalität mit automatisierten Tests. Diese kommen zum Einsatz, wenn sie oft ausgeführt werden müssen oder das manuelle Testen komplex und fehleranfällig ist. Neue Anwendungen werden in kurzen Abständen kompiliert, integriert und getestet. Die Testautomatisierung kann auf verschiedenen Ebenen stattfinden: Komponenten, Schnittstellen oder Benutzeroberfläche. Der Automatisierungsgrad nimmt in der Reihenfolge der Aufzählung ab und die Kosten dafür steigen entsprechend. Für die Automatisierung der funktionalen Tests (Schnittstellen und Benutzeroberfläche) braucht es eine verfügbare Umgebung. Diese muss bezüglich Funktionalität und Datenbestand möglichst stabil sein. Im Idealfall steht sie den Testautomatisierern exklusiv zur Verfügung. Für die Testdurchführung braucht es nebst dem System under Test (SUT) auch entsprechende interne und externe Umsysteme (vgl. Abb.), was aus Kostengründen häufig nicht gewährleistet ist. Testautomatisierung wird deshalb nur unzulänglich betrieben oder erst nach Abschluss der Entwicklung gestartet. Dann helfen sie nur noch dem Wartungsbetrieb und der Mehrwert während der Entwicklung fällt weg. Lösung Dank Simulationen kann mit der Testautomatisierung schon begonnen werden, bevor alle Teilsysteme bereit sind. Dabei wird nicht nur das funktionale, sondern auch das nicht-funktionale Verhalten simuliert. Mit Hilfe der Simulatoren kann auf teure Infrastruktur für Umsysteme verzichtet werden (vgl. Abb.). Mittels Simulatoren können schon bei den Komponententests fachlich hochwertige Testfälle automatisiert durchgeführt werden. Das Antwort-Zeitverhalten der simulierten Umsysteme kann dabei so eingestellt werden, dass es den aktuellen Produktionssystemen entspricht oder gar so, dass es einen geplanten Hardware-Ausbau simuliert. Es ist auch möglich, in einem Simulator nur einen Teil des Datenbankinhaltes zu simulieren und einen anderen Teil real von Datenbanken zu holen. Nutzen Die Qualität der Software aus der Entwicklungsphase steigt massiv, ohne erheblichen Mehraufwand. Die Testautomatisierung kann parallel zur Entwicklung gestartet werden. $ Für jede Art von Testautomatisierung stehen mit Simulatoren von angebundenen Systemen günstige und stabile Plattformen für die Entwicklung von automatisierten Tests zur Verfügung.

27 Simulationen Vorher Nachher

28 Simulationen 9. Performancetests (Effizienztests) Herausforderungen Performancetests überprüfen Geschwindigkeit, Stabilität und Skalierbarkeit. Eine Form davon sind Last-Tests, wo das System mit einer grossen Anzahl von Transaktionen gezielt belastet wird (vgl. Abb.). Die Anforderung an die Wiederholbarkeit solcher Tests ist gross: Tausende oder Zehntausende virtuelle Benutzer müssen über einen Zeitraum von Minuten oder Stunden simuliert werden. Dafür müssen Testdaten in entsprechender Menge verfügbar sein und regelmässig zurückgesetzt werden, da ständig optimiert wird. Um aussagekräftige Last-Tests zu erreichen, benötigt man Umsysteme auf adäquater Hardware mit realen Datenmengen. Das Bereitstellen von Testdaten und -umgebung wird zu einer zeitraubenden Tätigkeit, wenn Zustände auf diesen Systemen verändert werden. Zudem erfordern Last-Tests einen immensen Koordinationsaufwand. Produktionsnahe Last-Tests werden in vielen Firmen aus genannten Gründen nicht gemacht. Wenn doch, dann häufig zusammen mit den Abnahmetests. Grundsätzliche Architekturprobleme werden daher viel zu spät erkannt, deren Korrektur wird teuer. Lösung Mit Simulatoren können komplette Umsysteme dargestellt werden (vgl. 2. Komponentenbasierte, grosse Systeme). Dabei wird auch ein echtes Performanceverhalten geliefert (vgl. Abb.). So können z. B. Time-outs oder ein anderes fehlerhaftes Verhalten einer Komponente simulieren werden. Für die Eingrenzung von Performance-Engpässen werden gewisse Teile der Applikation real und andere nur als Simulation dargestellt. So kann auch eine einzelne Komponente auf ihre Performance überprüft werden. Nutzen Mit Simulatoren können realistischere Tests durchgeführt werden als auf einer speziell aufgebauten Testumgebung. In einem echten Systemverbund sind Szenarien wie Zeitverhalten, Fehlverhalten, Ausfälle etc. schwer zu testen. Teilsysteme können dank Simulationen autonom getestet werden. Fehler, z.b. Designfehler, können früh behoben werden, was komplexe und riskante Korrekturen am Ende des Projekts verhindert. Weniger Vorbereitungsaufwand und Unabhängigkeit von Umsystemen ermöglichen häufi gere Performancetests. Diese können für Teilsysteme sehr früh durchgeführt werden. $ Kosten für Hardware- und Softwarelizenzen werden massiv gesenkt.

29 Simulationen Vorher Nachher

30 Simulationen 10. Mobile Apps Herausforderung Unternehmen setzen auf mobile Enterprise Apps, um Kunden gerecht zu werden und die Effizienz von Mitarbeitern zu steigern. Diese Applikationen sind verteilte Systeme, die normalerweise aus einem Client, der auf einem mobilen Device läuft, und verschiedenen Systemen auf der Serverseite bestehen. In der Entwicklung von mobilen Apps gibt es verschiedene Herausforderungen: die Abhängigkeit zwischen Client- und Serverteil (vgl. 1.) diverse Schnittstellen Integration von bestehenden Back-end-Systemen (vgl. 6.) akzeptable Performance (vgl. 9.) Mobile Apps werden anders genutzt als herkömmliche Desktop-Applikationen: Benutzer können mit mobilen Geräten immer und nahezu von überall auf Applikationen und Back-end-Systeme zugreifen. Das beeinflusst Zugriffszeiten und -intervalle sowie die Anzahl zugreifender Devices pro Benutzer. Dies führt zu bedeutend mehr Last auf Server und Back-end-Systemen als bei konventionellen Applikationen. Die Verbindung zwischen Client und Server ist drahtlos und kann je nach Standort in der Qualität massiv variieren. Das Verhalten von mobilen Apps ist kaum testbar. Lösung Unter 4. Externe Software-Entwicklung und 5. B2B- und M2M-Szenarien sind die Lösungen der meisten Herausforderungen bereits beschrieben. Für die variierende Verbindungsqualität aufgrund von verschiedenen Netzwerkanbindungen wird mit dem Virtual Network Simulator das Verhalten des Web simuliert. Damit lässt sich die Verbindungsqualität zwischen einem Client und dem antwortenden System auf Knopfdruck regeln. So kann das gleiche System einmal unter einer breitbandigen WLAN-Anbindung und das nächste Mal mit einer schwachen EDGE-Verbindung getestet werden. Nutzen Simulationen ermöglichen Aussagen über den Effekt der Verbindungsqualität auf eine mobile Applikation. Dies steigert die Benutzbarkeit von mobilen Applikationen, speziell bei schlechter Verbindung, weil Apps dafür optimiert werden können. Die Entwicklung und Tests können früh gegen reale Schnittstellen inklusive Security getestet werden. $ Durch Lastsimulationen können die erhöhten Performancebedürfnisse mobiler Apps sehr gut abgefangen werden. Damit lässt sich die Serverseite so dimensionieren, dass sie zweckmässig und kosteneffizient ist.

31 Simulationen 11. Agile Software-Projekte Herausforderung Heute werden Software-Projekte vermehrt nach agilen Vorgehensweisen (Scrum, Kanban, XP) entwickelt, was einen Mehrwert bezüglich Effizienz und Planbarkeit verspricht. Scrum: Die Entwicklungsabteilung wird verteilt auf mehrere, kleinere Teams. Häufig gibt es Abhängigkeiten, beispielsweise bei Schnittstellen, die Absprachen erfordern und Missverständnisse mit sich bringen. Agile Projekte werden von Systemen, die nur eine exklusive Benutzung zulassen, stark gebremst: Die Teams können nur nacheinander gegen dieses zentrale System entwickeln oder testen. Dies erfordert Koordination und ergibt entsprechend Wartezeiten. Alternativ können Projekte solche Systeme vervielfachen (d.h. die Umgebung duplizieren), was wiederum grosse Kosten nach sich ziehen kann. Viele agile Projekte arbeiten mit Continuous Integration oder sogar Continuous Delivery. Die Software wird regelmässig kompiliert, integriert und getestet, respektive auch in Produktion gesetzt. Agile Projekte sind von einem hochautomatisierten Testsystem abhängig und scheitern an der unflexiblen Testumgebung. Lösung Die Abhängigkeit von der exklusiven Nutzung eines zentralen Systems kann überwunden werden, indem verschiedenen Teams bedarfsgerecht simulierte Schnittstellen des zentralen Systems zur Ver fügung gestellt werden. Simulationen helfen die Entwicklungsteams zu entkoppeln. Mehrere Teams können gegen Simulationen von Schnittstellen entwickeln und/oder testen (vgl. 1. Client/Server-Entwicklung). Dank Simulationen kann stabil und automatisiert getestet werden Umsysteme müssen nicht mehr real zur Verfügung stehen. Das Testdatenmanagement vereinfacht sich. Nutzen Durch das repräsentative Abbild einer Schnittstelle, gegen das entwickelt werden kann, wird die Qualität gesteigert. Auch gegen zentrale Systeme kann häufiger und zuverlässiger entwickelt respektive getestet werden. Testautomatisierung kann einfacher durchgeführt werden, was die Qualität der gelieferten Software verbessert. Entwicklungsteams können besser zusammenarbeiten, da Abhängigkeiten reduziert werden. Systeme oder Schnittstellen stehen ständig zur Verfügung. Simulationen steigern den Nutzen der Agilität. $ Die kürzeren Wartezeiten führen zu einer höheren Produktivität. Für zentrale Systeme braucht es keine Duplikate für Entwicklungs- und Tests-Systeme. Das spart Bereitstellungs-, Betriebs- und Wartungskosten. Ein erhöhter Automatisierungsgrad im Testing verringert zudem die personellen Aufwände.

32 Simulationen 12. Schulung auf IT-Systemen Herausforderung Bei der Einführung neuer Applikationen müssen Mitarbeiter und Partner geschult werden. Grosse Firmen brauchen deshalb Schulungsumgebungen für all ihre Systeme. Vor jedem Kurs muss auf den Schulungssystemen sichergestellt werden, dass alles funktioniert und die richtigen Releases installiert sowie die entsprechenden Datenzustände bei internen und externen Systemen eingespielt sind (vgl. Abb.). Wenn mehrere Teilnehmer auf demselben System geschult werden, müssen die Daten in unterschiedlichen Variationen vorhanden sein, damit ein Teilnehmer einen ersten Datensatz bearbeiten kann, während ein anderer einen zweiten bearbeitet. Faktisch braucht jeder Teilnehmer sein eigenes System. Entsprechend muss frühzeitig bestimmt werden, für wie viele Teilnehmer ein Kurs oder ein Schulungssystem ausgelegt wird. Werden mehrere Gruppen parallel ausgebildet, muss die Umgebung dupliziert werden. Bestimmte Aktionen müssen zwischen den Gruppen koordiniert werden. Für Systeme, die Daten zu Schulungszwecken verändern, ist es nicht möglich, dass Mitarbeiter unabhängig voneinander im Selbststudium auf dem Schulungssystem arbeiten können. Lösung Mit Simulationen ist es möglich, eine Schulungsumgebung oder Teile davon nachzuahmen. Dabei können zum Beispiel die Stammdaten, die vom Schulungssystem nur gelesen werden, in der echten Datenbank liegen. Gleichzeitig können Transaktionsdaten, die während der Schulung erstellt und manipuliert werden, durch den Simulator verwaltet werden (vgl. Abb.). Nutzen Eine Schulung kann mit beliebig vielen Teilnehmern durchgeführt werden; z.b. eine einzelne Person, die jederzeit unabhängig von anderen Schulungsteilnehmern Ausschnitte aus einem Tutorial durcharbeitet oder mehrere Gruppen, die unabhängig voneinander arbeiten. Das Bereitstellen von speziellen Schulungsdaten entfällt, was Zeit spart. $ Das Duplizieren komplexer Umgebungen für eine Schulung entfällt, was Infrastruktur- und Betriebskosten spart.

33 Simulationen Vorher Nachher

ipt entwickelt Simulations- Lösungen für Ihr Unternehmen 35 Simulationen

36 Simulationen ipt bietet Die Einführung von Simulationen ist ein Change-Thema. Die Entwicklung und das Testen von Software respektive die Schulung von Mitarbeitern werden verändert. Simulationen einzuführen braucht einen Initianten in der Organisation. Business Value Assessment Mit einem gegebenen Fragenkatalog wird zusammen mit einem Simulationsexperten der Nutzen von Simulationen für eine Unternehmung erhoben. Dabei geht es um den betriebswirtschaftlichen Wert von Simulationen (z.b. Return on Investment). Der Fokus liegt auf der Analyse der Ist-Situation, danach wird eine Prognose gemacht, welche Verbesserungen sich durch die Simulationen ergeben. Ansprechpersonen für das Business Value Assessment sind IT-Verantwortliche. Studie Das Potenzial von Simulationen in einer Unternehmung kann durch eine Studie identifiziert werden. Dabei treten Szenarien mit einem grossen wirtschaftlichen Potenzial in verschiedenen Bereichen einer Unternehmung zutage. Zudem kann das Prozess- und Rollenbild mit der Organisation in Einklang gebracht werden. Proof of Concept (PoC) Hier wird die Lösung «Simulationen» in Ihrem Umfeld gezeigt. ipt führt mit Ihnen zusammen einen Proof of Concept durch. Dadurch wird validiert, ob mit der ausgewählten Simulations-Software die erforderlichen Simulationen in Ihrem Umfeld umgesetzt werden können. Der Fokus liegt auf der technischen Machbarkeit. Pilotprojekt (Einführung) ipt begleitet Sie bei der Einführung von Simulationen in Ihrem Unternehmen im Rahmen eines konkreten Projekts. Wir unterstützen Sie dabei konzeptionell und organisatorisch, in der technischen Umsetzung, im Betrieb und der Nutzung von Simulationen. Simulationsspezialisten ipt-berater unterstützen Sie beim Einsatz von Simulationen in Ihrem Betrieb. Wir identifizieren die nutzenbringenden Einsatzgebiete in den Bereichen Software-Entwicklung, Test sowie Schulung und begleiten Ihre Projekte über den gesamten Software-Lifecycle.

37 Simulationen Prozess zur Generierung von Simulationen Subprozesse Anforderungsmanagement (Umgebungsmanager) Eingaben: Softwareprojekt im Frühstadium, Dokumentation, Zugriffsbeschränkungen zu Umsystemen Identifikation von Simulationstargets (Was soll simuliert werden?), Architektursicht Erhebung von Anforderungen an die Schnittstellen f z.b. typische Geschäftsfälle Erhebung der Datenlage (vorhanden, unbekannt, Live-System) Ergebnis: Anforderungen, Geschäftsfälle, Daten Analyse und Design (Umgebungsmanager / Simulationsengineer) Eingaben: Anforderungen, Geschäftsfälle, Dokumentation Analyse der Schnittstellen, Priorisierung Identifikation von Request / Response Paaren Datenanalyse: Qualität, Vollständigkeit, Anonymisierung? Ergebnis: Liste der Simulationen mit Antwortmeldungen zu allen Anfragen Implementation der Simulationen (Simulations-Engineer) Eingaben: Liste der zu simulierenden Schnittstellen Aufbau der Simulationen durch Aufzeichnen, via Schnittstellen-Beschreibung (Spezifikation) oder durch Codierung Daten den Simulationen zuordnen, gegebenenfalls anonymisieren Ergebnis: Installierbare Simulationen Bereitstellung und Betrieb (Umgebungsmanager / Simulations-Engineer) Eingaben: Installierbare Simulationen Installation der Simulationsumgebung Gegebenenfalls Anpassen der Simulationen, falls sich an den Spezifikationen, Umsystemen, Schnittstellen usw. etwas ändert Ergebnis: Simulationen für Entwicklung, Testing und Schulungen

38 Simulationen Kontakt René Schwarb verfügt über eine breite Erfahrung im Bereich der Software-Entwicklung, Test und Schulung sowohl im Mainframe- wie auch im Client-Server-Bereich. Er war als Instruktor in den Bereichen JAVA/JEE und SOA tätig. Seit über zehn Jahren beschäftigt er sich mit Message-basierter Integration, mit Fokus auf Testing. Seit 2007 gehören Simulationen in der Software-Entwicklung zu seinen Kernthemen. René Schwarb ist Partner im ipt-management. Telefon +41 41 727 25 25 Mail rene.schwarb@ipt.ch Dr. Andreas Elsener studierte Rechnergestützte Wissenschaften an der ETH Zürich. Während seiner Dissertation beschäftigte sich Andreas Elsener mit hochkomplexen Simulationen im Umfeld von High-Performance-Computing. Als Lead Consultant bei ipt beschäftigt er sich hauptsächlich mit Simulationen von Umsystemen, Performancetests und Testautomatisierung. Er berät Kunden zu möglichen Einsatzszenarien und über den Business Value von Simulationen und leitet Simulationsprojekte. Andreas Elsener führt intern und extern Schulungen durch, bloggt und hält Vorträge über seine Erkenntnisse. Telefon +41 41 727 25 25 Mail andreas.elsener@ipt.ch

40 Simulationen Glossar Agent: Software, die Interaktionen innerhalb einer Fachanwendung beobachten kann. Applikation: Fachliche Funktionalität, die als Softwarebaustein zur Verfügung steht. B2B (Business-to-Business): Die elektronische Abwicklung von Geschäften zwischen zwei Unternehmen. Back-end: Fachapplikationen, die Funktionalität über Schnittstellen zur Verfügung stellen. Client/Server: Entwicklung von verteilten Systemen, in denen ein Server die Anfragen eines Clients bearbeitet. Front-end: Eine Applikation (Desktop oder Web-Client), die meist mit den Benutzern interagiert und die fachliche Funktionalität von Back-end Applikationen nutzt. Instanz: Kopien der Komponenten und Applikationen, die für Entwicklung, Test, Schulung und Produktion gebraucht werden. Integrationsplattform: Eine Middleware-Infrastruktur im Sinne eines Message-Bus, die für die Integration von Services genutzt wird. Komponente: Bausteine. Eine Komponente kann eine ganze Applikation, ein Infrastrukturbaustein wie eine Datenbank oder Dokumentemanagementsystem sein. Komponenten interagieren über Schnittstellen. Komponentenbasierte Grosssysteme: Lösungen die aus zig Teilsystemen bestehen, die gegenseitig abhängig sind. M2M (Machine-to-Machine): Unternehmen, die Partnerfirmen Daten respektive Schnittstellen zu Daten zur Verfügung stellen. Middleware: Verschiedene Softwarekomponenten interagieren über Schnittstellen miteinander. Dies kann direkt (Punkt zu Punkt) oder via einen Vermittler (Middleware) geschehen. Middleware führt zu mehr Flexibilität und Stabilität bei der Integration der Systeme. Mobile Apps: Applikationen für mobile Geräte wie Mobiltelefone oder Tablets. Mock-up: Simulation von Schnittstellen, die von Entwicklern als Hilfsmittel für die eigene Arbeit manuell erstellt werden. Outsourcing: Software-Entwicklung mit externen Partnerfirmen, die jeweils «inhouse» Software bauen und anschliessend liefern. Partnersystem: Fachapplikation, die bei einem externen Partner läuft über Schnittstellen zu eigenen Systemen. Performancetest: Performance (Geschwindigkeit, Stabiltät und Skalierbarkeit) einer Applikation wird geprüft. Release: Grosse Systeme werden in Versionen entwickelt. Alle 2-4 Monate werden veränderten Komponenten miteinander getestet und eingeführt.

41 Simulationen Remote-Zugriff: Externe Entwicklungspartner brauchen die Umsysteme ihrer Kunden, wenn sie die entwickelte Software vor der Lieferung testen wollen. Dazu betreiben sie die Umsysteme ihrer Kunden bei sich oder haben Zugriff von aussen auf die Umsysteme der Kunden. Schnittstellen: Ort, wo Komponenten und Applikationen miteinander interagieren. Selbstheilungs-Modus: Requests werden durch die Simulation ins Lifesystem geschickt. Die Response wird wiederum durch die Simulation geroutet. Aus dem Unterschied zwischen simulierter und realer Antwort kann die Simulation angepasst werden. Service: Fachliche Bündelung von Funktionen in einer technischen Komponente (Webservice). Simulation: Automatisch generierte Software, die das Verhalten einer Schnittstelle eines realen Softwaresystems funktional und nichtfunktional nachahmt. SOA: Serviceorientierte Architektur. Moderne Softwarearchitektur, in der Komponenten über standardisierte Schnittstellen interagieren. Software-Lifecycle: Der Lebenszyklus von Applikationen, von der fachlichen Anforderungsanalyse über die Nutzung bis zur Ablösung durch neue Applikationen. Standardlösungen: Branchenlösungen die eingekauft werden und mit den Umsystemen integriert werden müssen. Testautomatisierung: Testsets werden automatisch gestartet und durchgeführt. Testbed: Für die Entwicklung und das Testen von Software braucht es ein stabiles Umfeld (Umsysteme) mit einem definierten Datenstand. Ein Testbed kann aus echten Umsystemen oder aus Simulationen bestehen. Testdatenmanagement: Erzeugung, Verwaltung und Bearbeitung von Testdaten. Umsystem: Aus Test- und Entwicklungssicht werden alle Applikationen, die nicht im Fokus der Entwicklung oder des Tests stehen, als Umsysteme bezeichnet. Webservice: Ein Webdienst zur Softwareanwendung in der Maschine-to-Maschine-Interaktion über ein Netzwerk.

43 Simulationen

44 Simulationen White Paper Simulationen Innovation Process Technology AG Poststrasse 14, 6300 CH-Zug T+41 41 727 25 25, www.ipt.ch famous for integration