16.4 Wiederverwendung von COTS-Produkten 16.4 Vorteile bei

Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Wiederverwendung von COTS-Produkten
 COTS = commercial of the shelf
 im Handel erhältliche Software-Produkte
 Anpassung für Kunden ohne Änderung am Quellcode
 Quellcode in der Regel nicht einsehbar (Ausnahme Open Source)
 umfangreiche generische Funktionalität
 einsetzbar in verschiedenen Umgebungen
 eingebaute Konfigurationsmechanismen
 Anpassung an spezielle Kundenbedürfnisse
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.35
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Vorteile bei COTS-Wiederverwendung
 kürzere Entwicklungszeit für ein zuverlässiges System
 nur Konfigurierung, nicht Programmierung
 leichtere Beurteilung der Funktionalität
 Referenzinstallationen
 weniger Ressourcen für IT im Unternehmen nötig
 Konzentration auf das Kerngeschäft
 Updates in Verantwortung des Anbieters
 z.B. bei Weiterentwicklung der Betriebsplattform
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.36
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Probleme bei COTS-Wiederverwendung
 Anpassung der Anforderungen an die Funktionalität
 was nicht vorhanden ist, kann nicht genutzt werden
 Vorgabe von Geschäftsprozessen durch die Software
 Software basiert auf Annahmen über Aktivitäten
 Schwierige Auswahl des passenden COTS-Produkts
 oft nicht ausreichende Dokumentation
 Fehlendes fachliches Wissen vor Ort
 Abhängigkeit von Kundenservice oder externen Beratern
 Abhängigkeit vom COTS-Anbieter
 z.B. Einstellung des Produkts, Übernahme, Konkurs
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.37
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Arten der COTS-Wiederverwendung
`lqpJi∏ëìåÖ
`lqpJfåíÉÖê~íáçå
ÉáåòÉäåÉë=mêçÇìâí=ãáí=îçã=hìåÇÉå=
ÄÉå∏íáÖíÉê=cìåâíáçå~äáí®í
fåíÉÖê~íáçå=ãÉÜêÉêÉê=ÜÉíÉêçÖÉåÉ=
póëíÉãéêçÇìâíÉ=òìê=bêêÉáÅÜìåÖ=ÇÉê=
ÄÉå∏íáÖíÉå=cìåâíáçå~äáí®í
Ä~ëáÉêÉåÇ=~ìÑ=ÖÉåÉêáëÅÜÉê=i∏ëìåÖ=ìåÇ=
ëí~åÇ~êÇáëáÉêíÉå=mêçòÉëëÉå
ÑäÉñáÄäÉ=i∏ëìåÖÉå=ÑΩê=hìåÇÉåéêçòÉëëÉ
båíïáÅâäìåÖ=Ü~ìéíë®ÅÜäáÅÜ=hçåÑáÖìê~íáçå
båíïáÅâäìåÖ=Ü~ìéíë®ÅÜäáÅÜ=fåíÉÖê~íáçå
póëíÉã~åÄáÉíÉê=îÉê~åíïçêíäáÅÜ=ÑΩê=ÇáÉ=
t~êíìåÖ
póëíÉãÄÉëáíòÉê=îÉê~åíïçêíäáÅÜ=ÑΩê=ÇáÉ=
t~êíìåÖ
póëíÉã~åÄáÉíÉê=äáÉÑÉêí=ÇáÉ=mä~ííÑçêã=ÑΩê=
Ç~ë=póëíÉã
póëíÉãÄÉëáíòÉê=äáÉÑÉêí=ÇáÉ=mä~ííÑçêã=ÑΩê=
Ç~ë=póëíÉã
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.38
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
COTS-Lösungen
 Generische Anwendungssysteme zur Unterstützung von
 Geschäftsaktivität
 Geschäftstyp
 Geschäftsunternehmen
• -> ERP
 Fachbereichsspezifische Funktionalität
 Nutzung durch möglichst viele potentielle Benutzer
 Annahmen über Arbeitsweise
 Konfiguration
 Einstellungen statt Programmierung
 schwierig zu testen
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.39
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
ERP-Systeme
 Enterprise Resource Planning Systeme
 große integrierte Systeme
 generische Unterstützung für Geschäftsaktivitäten
• Auftragserteilung
• Rechnungswesen
• Lagerhaltung
• Produktionsplanung
 wohl häufigste Form der Software-Wiederverwendung
 Anpassung an Kundenbedürfnisse
 Auswahl benötigter Module
 Konfiguration der Module
 Definition von Geschäftsprozessen und –regeln
 Struktur der Systemdatenbank
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.40
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Architektur eines ERP-Systems
Logistik
Lieferkette
Einkauf
Kundenpflege
Prozesse
Prozesse
Prozesse
Prozesse
Geschäftsregeln
Systemdatenbank
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.41
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Architekturmerkmale von ERP-Systemen
 Module zur Unterstützung von Geschäftsfunktionen
 große Module für komplette Geschäftsbereiche
 Festgelegter Satz von Geschäftsprozessen
 für jedes Modul Festlegung der Aktivitäten und Rollen
 Gemeinsame Datenbank
 Daten für alle Geschäftsfunktionen ohne Replizierung
 Festgelegte Menge von Geschäftsregeln
 Validierung und Konsistenz der Datenbank
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.42
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4







Konfiguration von ERP-Systemen
Auswahl der erforderlichen Funktionalität
Erstellung des Datenmodells der Systemdatenbank
Definition von Geschäftsregeln für die Daten
Definition der Interaktionen zu externen Systemen
Entwurf der Eingabe- und Berichtsformulare
Entwurf neuer passender Geschäftsprozesse
Festlegung der Parameter für die Einsatzplattform
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.43
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
COTS-Integration
 Anwendungen aus
zwei oder mehr COTS-Produkten oder Altanwendungen
 wenn kein einzelnes COTS-System alle Anforderungen erfüllt
 wenn neue Funktionalität in vorhandene Umgebung
integriert werden soll
 Integration über
 Dienstschnittstellen oder APIs
 Verbindung von Ausgabe zu Eingabe
 Aktualisierungen der jeweiligen Datenbanken
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.44
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
COTS-Integration: Entwurfsentscheidungen
 Welche COTS-Produkte eignen sich am besten?
 Funktionalität in mehreren Produkten
 häufig mehrere Kombinationsmöglichkeiten
 Wie werden Daten ausgetauscht?
 oft proprietäre Datenstrukturen und –formate
 Adapter zur Umwandlung erforderlich
 Welche Funktionen werden tatsächlich verwendet?
 häufig mehr Funktionalität als nötig
 oft gleiche Funktionalität redundant in mehreren Produkten
 nicht benötigte Funktionen als mögliche Fehlerquellen
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.45
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Szenario zur COTS-Integration
 Beschaffungen in einem Unternehmen
 Stand
 zentraler Einkauf nach Anforderung aus der Abteilung
 Nutzung eines Bestell- und Fakturiersystems
 Ziel
 Abwicklung der Bestellungen vor Ort
 dezentral über das Web
 Vorgehen
 Anbindung eines E-Commerce-Systems via Adapter
 Anbindung eines E-Mail-Systems via Adapter
 Client mit Browser und Mail als COTS-System
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.46
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Szenario zur COTS-Integration
Client
Webbrowser
E-Mail-System
Server
E-CommerceSystem
Adapter
Bestell- und
Fakturiersystem
E-Mail-System
Adapter
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.47
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Serviceorientierte COTS Integration
 Einfachere Integration durch Dienstschittstellen
 Standarddienstschnittstelle für Funktionalität
 jeweils ein Dienst für jede Funktionalitätseinheit
 Implementation einer Dienstschnittstelle
 Wrapper verbirgt Anwendung und stellt Dienste bereit
 insbesondere bei Altsystemen sinnvoll
Dienste-Wrapper
Dienst
Dienst
Dienst
Anwendungssystem
Dienst
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Dienst
Dienst
Stand: 08.04.13
Folie 16.48
Wissen. Was praktisch zählt.
Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik
16.4
Probleme der COTS-Integration
 Mangel an Kontrolle über Funktionalität und Leistung
 Diskrepanz zwischen Beschreibung und Programmierung
 Probleme mit der Interoperabilität von COTS-Systemen
 unterschiedliche Modelle, fehlende Standards
 Keine Kontrolle über die Evolution des Systems
 neue Versionen nicht immer kompatibel
 Unsichere Unterstützung durch die Anbieter
 Einstellung oder Übernahme des Produkts
© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.
Stand: 08.04.13
Folie 16.49