Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2.

Ähnliche Präsentationen


Präsentation zum Thema: "Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2."—  Präsentation transkript:

1 Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2

2 Übersicht Projektübersicht Projektziele, Projektaufbau, Projektablauf Projektbeschreibung Darstellung des Projekts iterativ Zwischenstand und Ausblick Vorführung Fragen?

3 Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2 -- Projektübericht --

4 Projektziele Verbesserung des allgemeinen Informationsflusses im Sächsischen Serumwerk Dresden Allgemeine Informationen: mehr oder weniger nicht jobrelevante und eine größere Zielgruppe betreffenden Informationen (…) Lösungsansatz: Einführung eines zentralen Intranetportals

5 Zu erzielende Ergebnisse Die Lösung des Projekts soll die folgenden Ergebnisse beinhalten: Programm (einsetzbar, getestet, installationsfertig) Enduser-Dokumentation (Handbuch, Installationsplan) Projektdokumentation (SSW & BA - SE)

6 Mitarbeiter / Aufgabenverteilung Project ManagerDer Projekt-Manager teilt Betriebsmittel zu, setzt die Prioritäten fest, koordiniert die Interaktionen mit den Kunden/ Benutzern und leitet sein Projektteam durch den gesamten Prozess. Weiterhin stellt er die Vollständigkeit und Qualität der Dokumente und Artefakte sicher. Process EngineerIst verantwortlich für die Projektumgebung und unterstützt das Team während der zu bearbeitenden Prozesse. Sein Aufgabenbereich ist in der Environment Disziplin des RUP beschrieben. System EngineerVerantwortlich für das Business Modelling und die Requirements Disziplin. Software EngineerPrimär verantwortlich für Analyse & Design und die Implementations Disziplin. Test ManagerVerantwortlich für die Verwaltung der Test Disziplin. Deployment ManagerVerantwortlich für die Installationsaktivitäten und die Infrastruktur der Endbenutzer-Umgebung. Rolle Lutz Leonhardt Sächsisches Serumwerk Dresden Zirkusstraße 40 D Dresden ( ) Stephan Henke Sächsisches Serumwerk Dresden Zirkusstraße 40 D Dresden ( ) Projekt Managerx Process Engineerxx Systems Engineerx Software Engineerxx Test Managerx Deployment Managerx

7 Konzeptioneller Projektaufbau Der Projektaufbau muss den Anforderungen an Dokumentationen nach den GlaxoSmithKline (GSK) Kriterien erfüllen. Diese sind durch internationale Vorschriften für pharmazeutische Unternehmen definiert. Der Aufbau entspricht dem Wasserfall-Prinzip und besteht grundsätzlich aus Requirements, Design-Spezifikation, Testplan, Testbericht sowie weiteren optionalen Dokumenten. Jede Phase muss einzeln genehmigt werden. Ergänzung der strikten GSK-Richtlinien durch die Möglichkeiten der Projektplanung des Rational Unified Process (RUP) aus der Vorlesung, die da wären: iteratives Vorgehen, Möglichkeit der nachträglichen Dokumentationsänderung, flexibles Handling des Prozesses, abhängig von Projektfortschritt.

8 Umsetzung des Prozesses PhaseDefinition Inception1. Iteration: Ausarbeitung der Basisinformationen, wie initiale Projektplanung, Requirements, Marktanalyse, Risikountersuchung, etc. Elaboration2. Iteration: Umsetzung der Anforderungen in konkrete Designelemente, Zerlegung des Gesamten in Module 3. Iteration: detaillierte Ausarbeitung der einzelnen Module und Programmierung und Test dieser Construktion4. Iteration: Zusammenfügen der Module 5. Iteration: Test der kompletten Anwendung Transition6. Iteration: Einführung im SSW (Schulungen, Handbücher, Installationsdokumentation) Genaue Prozessbeschreibung entstand step-by-step:

9 Projektdokumentation DokumentInhalt RequirementsBeinhaltet Projektinitialisierung PlanungBeinhaltet Prozess- und Projektplanung Design und Entwicklung Festlegungen zur tatsächlichen Umsetzung der Requirements in Form von Designspezifikationen als Grundlage der Programmierung TestDokumentiert alle Arbeitsschritte, die mit dem Testen des Programms oder Programmteilen zu tun haben GuidelineRegelung zu Abläufen, Formulierungen, Darstellung, etc. TemplatesDiverse Vorlagen für Dokumente und Präsentationen mit fertigen Formatdefinitionen

10 Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2 -- Projektbeschreibung --

11 1. Iteration: Ziele Diese erste Phase des IntraKom-Projekts beinhaltet die Inception Phase des Rational Unified Prozess, initialisiert also unser Projekt. Ziel der Iteration ist es also, die Anforderungen der Stakeholder an das Projekt zu sammeln, untersuchen und analysieren und daraus ein erstes Konzept zu Art und Umfang der Projekts zu erstellen. Der Einsatz von UML-Diagrammen soll Abläufe, Beziehungen, Nutzerklassen und ihr Verhalten und Handeln, etc. Darstellen und klären. Eine Analyse möglicher Risiken soll späteren Problemen vorbeugen. Ein wichtiger Punkt dieser Iteration ist die Gestaltung des Gesamtprojekts, also einen bestimmten Prozess zu definieren, die nötigen Artefakte festzulegen, Rollen und Aufgaben zu verteilen und wichtige Meilensteine ansetzen. Meilenstein der Iteration ist die Präsentation der vorläufigen Projektierung am

12 1. Iteration: Aufgaben (1) AufgabeBeschreibung InitialisierungHauptsächlich ging es in dieser Aufgabe um die Findung eines Projekts und die Auseinandersetzung mit dem zu erwartendem Inhalt und den Problemen. Auch eine Einarbeitung in den RUP fand hier statt. RequirementsSammeln und analysieren der Requierements der Stakeholder BeschreibungErste Beschreibung des Programms als Grundlage für die Marktanalyse und Erweiterung nach Festlegung auf eigene Programmierung MarktanalyseUntersuchung von bereits am Markt vorhandenen Portalen/CMS-Systemen auf Einsetzbarkeit im SSW auf Grundlage der Requirements und Beschreibungen RisikoanalyseSammeln, Analysieren und Einschätzen möglicher Risiken für das Projekt

13 1. Iteration: Aufgaben (2) AufgabeBeschreibung UMLAuseinandersetzung mit UML und erste Darstellung von Requirements ProjektplanungAusarbeitung eines groben Projektplans IterationsplanungTiefergehende Planung dieser Iteration Dokumentations- umplanung Umstrukturierung der Dokumente weg von RUP in Richtung der GSK-Policies WorkflowFestlegen von Guidlines und Erarbeitung von Vorlagen PräsentationPräsentation erster Ergebnisse in SE ReviewReview der ersten Iteration

14 1. Iteration: Ablaufplanung

15 1. Iteration: Zeitplanung

16 1. Iteration: Marktanalyse Das System soll folgende Grundeigenschaften haben: Login-System mit User-/Gruppenverwaltung Zugriffsbeschränkung auf einzelne Teile per User-/Gruppenrichtlinie Oberfläche als HTML-Fontend einfache Administrierung für weniger versierte User (mit CMS) lauffähig auf Windows Servern einfache Informationsbereitstellung Die Marktanalyse war Grundlage für eine eigene Praxisarbeit über den Vergleich diverser CMS-Produkte unter 1500 €. Leider konnten uns keine der getesteten Produkte in Funktionsumfang und Handhabung überzeugen, oder sie waren mit ihren Lizenzmodellen deutlich über den Preis, den die Kalkulation für eine Eigenentwicklung ergeben hat

17 1. Iteration: Kostenabschätzung Während der Software-Entwicklung sind beide Entwickler im SSW beschäftigt und werden mit einem festen Gehalt entlohnt. Die Arbeitszeit liegt im gesamtem Produktionsrahmen über 5 Monate in der Theoriephase, wo beide Entwickler entlohnt werden, aber nicht im SSW arbeiten. Würden sie nicht an Intrakom arbeiten, würden sie trotzdem entlohnt: Von projektbezogenen Kosten kann also keine Rede sein. Während der Praxisphase liegt der Anteil der Projektarbeit an der SSW-Arbeitszeit bei 10%, wenn überhaupt. Die Entwicklungsdauer beträgt 8 Monate, dies bedeutet: [5 (Monate) * 0 (Kosten für SSW an Intrakom während Theorie-Phase) + 3 (Monate) * 0,1 (Anteil der Arbeitszeit in Praxis-Phase im SSW)] * 2 (Entwickler) * 650,00 € (Bruttogehalt) = 390,00 € Für das SSW fallen in der Zeit Personalkosten in Höhe von 390,00 € (zzgl. Arbeitgeberanteil an Sozialleistungen) an, die dem Projekt zu geschrieben werden müssen. Zusätzlich fallen Hardware- und Lizenzkosten an.

18 1. Iteration: Selbst entwickeln! An Hand der Marktanalyse und der Kostenabschätzung für eine Eigenentwicklung wurde entschieden, die Software selbst zu programmieren. Vorteile: Erfüllung aller Anforderungen geringe Kosten Nachteile: langwierige Entwicklung Risiko des Scheiterns

19 1. Iteration: detaillierte Beschreibung Webapplikation als Standard-Website des Firmen-Intranets Authentifizierung per Single Sign On Gruppen- / Benutzerrechte per LDAP gegen Active Directory 3 Rechtklassen (Leser, Manager, Admin) offener und abteilungsinterner Bereich News-System Möglichkeiten zum Datei-Upload einfaches CMS zur Pflege

20 1. Iteration: Rollenverteilung (1)

21 1. Iteration: Rollenverteilung (2)

22 1. Iteration: Risiken für das Projekt Risiken für die Eigenentwicklung: Ranking = 30% Wahrscheinlichkeit + 70% Auswirkung

23 1. Iteration: Requirements Gliederung der Requirements nach logischen Gesichtspunkten: Login Rechteverwaltung Informationsstruktur Design & Bedienbarkeit Sicherheit Funktionalität sonstiges Weitere Requirements betreffen Hardware, Zutritts- und Zugriffssicherheit, Installationspläne, etc. und werden durch GSK vorgegeben und sind nicht Bestandteil des Projekts sondern der SSW internen Umsetzung.

24 1. Iteration: Review Nach anfänglichem schnellem Projektfortschritt verloren wir uns in den unendlichen Weiten des RUP, was zu einer Neustrukturierung des Projekts und der Dokumentation führte und den Prozess (wie Anfangs beschrieben) mehr Richtung Wasserfall-Prozess von GlaxoSmithKline führte. Trotz redundanter Speicherung der Projektdateien auf unterschiedlichen Rechnern und FTP-Server gingen kurz vor Schluss die UML-Diagramme verloren.

25 2. Iteration: Ziele Hauptaufgabe dieser Iteration ist die Umsetzung der Requirements und der ersten Detailbeschreibungen in konkrete Definitionen. Resultat muss eine ausführliche Projektbeschreibung sein. Anschließend soll das Projekt in Module zerlegt werden, um die parallele Abarbeitung zu gewährleisten. Diese Module werden anschließend noch detaillierte definiert, insbesondere Schnittstellen. Diese Definitionen sind Grundlage („Blaupause“) führt die spätere Entwicklung)

26 2. Iteration: Aufgaben AufgabeBeschreibung IterationsplanungPlanung dieser Iteration ProjektplanungDurch die Kenntnisse über Design und Zerlegung in Module kann der Rest des Projektablaufs definiert werden ModularisierungZerlegung in Module WorkflowAusarbeitung von Guidlines zur Programmierung GesamtdesignDetaillierte Beschreibung des System als Ganzes ModuldesignDetaillierte Definition der Module und Schnittstellen ReviewReview zweite Iteration

27 2. Iteration: Ablaufplanung

28 2. Iteration: Zeitplanung

29 2. Iteration: Struktur

30 2. Iteration: Rollen (1) Als Rechte für einen Benutzer stehen folgende Möglichkeiten zur Verfügung. Ein Nutzer kann prinzipiell nur auf die öffentlichen Sites und die der eigenen Abteilung zugreifen. Höhere Rechte beinhalten niedrigere Rechte. ● keine Zugriff ● Leser (gilt für diese Subsite) Ist ein User mit Rechten größer als Leser ausgestattet (für die gerade offene Site) bekommt er im unteren Bereich eine Leiste (Footer) angezeigt, in der er verschiedene Editor-Funktionen auswählen kann: ● als C_Manager (gilt nur für Subsites) bekommt er die Möglichkeit, den Inhalt per CMS zu editieren ● als S_Manager (gilt nur für Subsites) bekommt er zusätzlich die Möglichkeit, die Zugriffsoptionen für diese Site zu bearbeiten, höhere Rechte (SU_Manager und Admin werden angezeigt, können aber nicht editiert werden) ● SU_Manager hat zusätzlich die Möglichkeit, innerhalb der Mainsite neue Subsites anzulegen bzw. vorhandene zu löschen sowie Rechte und Inhalt zu editieren. Er gilt für die gesamte Mainsite inklusive aller Subsites ● Administratoren haben dazu noch die Möglichkeit, weitere Administratoren zu definieren. Er kann alles und überall.

31 2. Iteration: Rollen (2)

32 2. Iteration: Rollen (3)

33 2. Iteration: Rollen (4)

34 2. Iteration: Ablauf Programm

35 2. Iteration: Zerlegung Um eine parallele Bearbeitung eines Produktes zu ermöglichen, ist es üblich, das Programm in logische, aber auch praktisch sinnvolle, Teilprogramme, im weitern Module genannt, zu zerlegen. Bezogen auf die Programmdefinition in Kapitel 4 ergeben sich für das Intrakom-System folgende Module: ● Single Sign On (SSO) ● Access Control und Site Management (AC/SM) ● User Interface (GUI) ● Datenbank (DB) ● Content Management (CM)

36 2.+3. Iteration: Modul SSO Automatische Authentifizierung gegenüber der Domäne Sammlung benutzerspezifischer Daten Grundlage für alle weiteren Module

37 2.+3. Iteration: Modul GUI Entwicklung HTML-Template mit HTML, CSS, JavaScript Verwendung von Platzhaltern Sequentielle Ersetzung der Platzhalter durch PHP

38 2.+3. Iteration: Modul DB Informationen für zentrale Datenhaltung: Benutzer Benutzerrechte Abteilungen Unterseiten

39 2.+3. Iteration: Modul SM/AC Generierung dynamischen Inhalts für Platzhalter, abhängig von SSO DB LDAP Sicherheit

40 2.+3. Iteration: Modul CMS Dieses Modul soll die Veränderung von Inhalten der Seiten von technisch unkundigen Mitarbeitern ermöglichen. Notwendig hiefür ist eine einfache, übersichtliche Bedienung, die möglichst an bekannte Produkte wie Office erinnert. Die Darstellung der Änderungen muss in Echtzeit erfolgen. Mangelnde Vorstellungen einer zeitnahen und anforderungsgetreuen Umsetzung mitteln PHP, HTML, CSS und JavaScript zwingt uns dieses Modul zu einem späteren Zeitpunkt zu entwickeln.

41 2. Iteration: Review Hauptaufgabe dieser zweiten Iteration war die Umsetzung der Anforderungen des Auftraggebers SSW in eine für die Programmierung verwertbare Art und Weise. Dies bedeutete vor allem die Zerlegung des Projekts in Module und die theoretische Entwicklung dieser Module, als Ablaufpläne, Definition von Schnittstellen, usw. Zeitgründe, sowie mangelnde Ideen für die Umsetzung eines Echtzeit- CMS mittels PHP, CSS und JavaScript, welches auch von Laien ohne weiteres verwendet werden kann, nötigten uns zu der Entscheidung, das CMS zu einem späteren Zeitpunkt zu entwickeln. Schließlich muss das Projekt weitergehen und das CMS ist modular einpflegbar.

42 3. Iteration: Ziele Aufgabe ist es, die in Iteration zwo definierten Module (mit Ausnahme des CM-Moduls) umzusetzen und zu testen. Dazu sind die im Design-Dokument definierten Vorgaben zu den Modulen und Schnittstellen einzuhalten oder im Bedarfsfall die Definitionen im Designdokument anzupassen und für alle anderen betroffenen Module zu aktualisieren.

43 3. Iteration: Aufgaben AufgabeBeschreibung IterationsplanungPlanung der Iteration ModuldesignÄnderungen an den Moduldefinitionen während der Programmierung ModulentwicklungProgrammierung der einzelnen Module ModultestIst ein Modul als funktionsfähig eingestuft, muss es einem Einzeltest unterzogen werden, der Funktionaliät sichern soll ArbeitsumgebungEntwerfen und Aufbauen einer Test- und Arbeitsplattform ReviewReview der Iteration

44 3. Iteration: Ablaufplanung

45 3. Iteration: Zeitplanung

46 3. Iteration: Arbeitumfeld Grundlage: Microsoft Windows 2003 Server (ADS) Firefox und IE Client PHP 5 + open_ldap Microsoft Testfeld: IIS 6 MS SQL Server 2005 OpenSource Testfeld Apache 2 + mod_auth_sspi MySQL 4

47 3. Iteration: Testrichtlinien Es sind Testziele zu definieren und aufbauend ein Testplan zu erstellen, der mit geeigneten Testverfahren diese Ziele prüft. Dies ist im Test-Plan zu beschreiben. Bei der Durchführung der Tests, ist zu Dokumentieren, ob ein Test tatsächlich auch den Erwartungen genügt oder ob Abweichungen / Fehler entstanden sind. Dies im im Test-Bericht zu dokumentieren. Abweichungen sind – wenn möglich – zu erklären und zu bewerten: (B)Bedeutende Fehler sind Fehler, die andere Module betreffen oder umfangreiche Änderungen im Programmcode zur Folge haben. In diesem Fall ist die jeweilige Iteration (Design, Entwicklung, Test) erneut zu durchlaufen. (U)Unbedeutende Fehler sind Abweichungen, die keinen geringen Aufwand bedeuten. Sie sind zu erläutern, Programmänderungen zu dokumentieren. Der Test-Manager ist für die Durchführung der Test verantwortlich. Mit seiner Bestätigung garantiert er die Funktionalität des vorliegenden Codes. Nun ist das Programm(-Teil) dem Projekt-Manager vorzuführen, mit seiner Abnahme bestätigt er die Umsetzung der Anforderungen. Er muss Funktionsumfang, Handhabung, Lesbarkeit, etc. Bestätigen. Dieser Schritt dient der Qualitätskontrolle.

48 3. Iteration: Modultest SSO Verwendung unterschiedlicher Browser Verwendung unterschiedlicher Webserver Zugriff von unterschiedlichen Rechnern Zugriff von Rechnern mit ungültigem Account Verwendung unterschiedlicher User

49 3. Iteration: Modultest GUI Füllen des HTML-Templates mit Testdaten Anzeige unterschiedlicher Browser Sicherheitsbedenken JavaScript Unterschiedliche Systemumgebung (graphisch) Behindertenfreundlich

50 3. Iteration: Modultest SM/AC Indirekter Test Modul DB Nutzung des Moduls GUI Bekommen unterschiedliche Nutzer die richtigen Mainsites angezeigt bekommt man für jede Subsite das richtige Recht (und den entsprechenden FOOTER) werden Rechteänderungen übernommen werden Strukturänderungen durch neue Abteilungen übernommen

51 3. Iteration: Review Inhalt dieser Iteration war die Programmierung der Module, d.h. die Umsetzung der Designspezifikationen der zweiten Iteration in funktionierenden Programmcode und das Testen der einzelnen Module. Für die Module SSO, SM/AC ist dieser Vorgang abgeschlossen. Für diese beiden Teiliterationen liegt der Prototyp vor und wurde getestet. Das Modul CM (Content Management) wird zu einem späteren Zeitpunkt entwickelt, es liegt kein Prototyp vor und auch kein Test. Das Modul GUI ist bis auf die graphischen Elemente, die durch das CM-Modul fehlen fertig und liegt getestet vor. Das Modul DB wurde im Zusammenhang mit dem SM/AC-Test getestet (für welchen wiederum das GUI-Modul verwendet wurde)

52 4. Iteration: Ziele, Aufgaben, Review Inhalt dieser vierten Iteration ist der Zusammenschluss der einzelnen Module zu einem gesamten Programm. Dazu müssen noch einige kleine Anpassungen und Optimierungen vorgenommen werden. AufgabeBeschreibung IterationsplanungPlanung der Iteration ZusammenschlußZusammenführen der einzelnen Module, soweit noch nicht geschehen. Optimierung der Abläufe, etc. ReviewReview der Iteration Alle aktuell vorhandenen Module sind zusammengeführt wurden. Es fehlt das CMS mit News-System

53 4. Iteration: Zusammenführung Zentrales Interface: index.php (kleine Datei) Zentrale Haltung der Konfigurationsdaten der Module: config.php Verwendung HTTP: GET, POST Ersetzung der Platzhalter Auswertung der GET-Variablen id

54 5. Iteration: Ziele Aufgabe dieser Iteration ist es einerseits, das in Iteration vier zu einer Einheit geschlossene System in seiner Gesamtheit zu testen. Die andere Aufgabe ist Überarbeitung aller Dokumente bis zum Meilenstein – dem Tag der Projektabgabe. Eine weitere Aufgabe hängt mit dem zweiten Meilenstein dieser Iteration zusammen: Am ist das Projekt mit einer Präsentation vorzustellen und zu verteidigen. Die Präsentation dazu muss natürlich noch erarbeitet werden.

55 5. Iteration: Planung

56 5. Iteration: Review Projektabgabe und Verteidigung (fast) erfolgt. Der finale Test wurde nicht durchgeführt, da vorhergehende Schritte noch nicht abgeschlossen wurden und somit der finale Test nicht vollständig wäre.

57 Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2 -- Zwischenstand & Ausblick --

58 Zwischenstand und Ausblick Das Projekt Intrakom hat die fünfte Iteration absolviert. Für das Programm bedeutet das, dass es alle bisherigen Phasen erfolgreich durchlaufen hat und entwickelt und getestet vorliegt. Eine Ausnahme bildet das Modul Content Management. Es war uns aus Zeitgründen nicht möglich, ein vollwertiges CMS zu erarbeiten, welches ohne weiteres von technisch unkundigen Mitarbeitern genutzt werden kann. Anforderungen wären u.a. Freie Gestaltung in Echtzeit, Möglichkeiten zum Einbinden anderer Quellen, Dateiupload, etc. Es ist zu einem späteren Zeitpunkt ohne Probleme möglich, dieses Modul in die Anwendung einzubauen, die Schnittstellen sind bereits vorhanden. Nachtragungen in der Dokumentation sind selbstverständlich. Mit Vollendung des letzten Moduls kann auch der noch nicht durchgeführte Kompletttest des Programms durchgeführt werden. Die nächste, sechste und letzte Iteration umfasst die Einführung im SSW. Eine Iteration in der auch Dokumente wie Handbücher oder Installationspläne entwickelt werden müssen. Deshalb sind die vorliegenden Handbücher noch in der Entwicklungsphase.

59 Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2 -- Vorführung --

60 Projektvorführung: Umgebung Domäne: GSK.COM Abteilungen: EDV, PA, FE Benutzer: (EDV) Administrator, MitEDV1,MitEDV2,AzubiEDV1 (PA) LeiterPA,MitPA1,MitPA2,AzubiPA1 (FE) LeiterFE,MitFE1,MitFE2,AzubiFE1 Rechte für EDV-Benutzer sind vergeben EDV-Administrator = Administrator „Intrakom“

61 Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2 ??? Fragen ???


Herunterladen ppt "Die Informationsplattform des Sächsischen Serumwerks Dresden -- Projektverteidigung -- Lutz Leonhardt und Stephan Henke BA04IT2."

Ähnliche Präsentationen


Google-Anzeigen