Advanced Application- System Development

Größe: px
Ab Seite anzeigen:

Download "Advanced Application- System Development"

Transkript

1 Studiengang Master Internet Science and Technology Stichworte zur Vorlesung Advanced Application- System Development Prof. Dr.-Ing. Ulrich Samberg Ausgearbeitet von Daniel Barth WS 2004/2005

2 Inhaltsverzeichnis Inhaltsverzeichnis... 2 Abbildungsverzeichnis Übersicht Entwicklungsrahmen Qualitätssicherung Team Building Application Management Lifecycle - Vorgehensmodell nach ITIL Requirement Phase Design Phase Build Phase Deploy, Operate und Optimise Phase Organisation Projektmanagement (allgemein) Einführung Die 9 Wissensfelder des PM Zielbereiche Erfolgsfaktoren Formale Projektmanagementsysteme Umsetzung ITIL Entwurf Architektur Architektur Grundtypen Beispiel: Microsoft Windows (MFC, alt) Wie entsteht eine Anwendungsarchitektur Exkurs: UML-Modellierung Systementwurf Schritt 1: Use Case Diagramm erstellen Schritt 2: Klassenmodell (fachlich) Schritt 3: Klassenmodell (technisch) Schritt 4: Komponentenmodell Schritt 5: Deployment Diagramm Oberfläche Architektur eines Oberflächenmodells Dialoggestaltung Advanced Application System Development Seite 2

3 4.5 Wiederverwendung Entwurfsmuster Grundlegende Muster nach GoF Beispiel für den Entwurf eines Musters Anwendungstechnologie Frameworks Microsoft.NET Ausblick Konzept CLR, CIL, Garbage-Collection und Reflection Managed und Unmanaged, Interoperabilität Verteilte Programmierung und Web Services Laufzeitumgebung (CLR) NET Framework - Klassenbibliothek (FCL) Typhierarchien Programmausführung (CIL) Assemblies WebServices Grundlagen Vorteile Anwendungsgebiete Erweiterungen Architektur am Beispiel von ASP.NET Aufbau eines WebService Aufruf eines WebService Exkurs: XML, Datenzugriffsschicht der Anwendung Exkurs: Organisation von Zugriffen auf Anwendungs-programme aus eigenem Programmcode Quellenverzeichnis Advanced Application System Development Seite 3

4 Abbildungsverzeichnis Abbildung 1: Übersicht AASD... 5 Abbildung 2: Mind Map Team Building... 6 Abbildung 3: Application Lifecycle... 8 Abbildung 4: Wissenfelder des PM Abbildung 5: ITIL Prozessorganisation Abbildung 6: 1-tier-Architektur Abbildung 7: 2-tier-Architektur Abbildung 8: 3-tier-Architektur Abbildung 9: Windows Anwendung Abbildung 10: Windows Klassenhierarchie (MFC) Abbildung 11: Windows-Anwendung (MFC) Abbildung 12: Ebenenmodell ASP.Net Abbildung 13: SAP Anwendungsarchitektur Abbildung 14: Ausgangssituation UML-Modelleierung Abbildung 15: Objektmodell Abbildung 16: Klassenmodell (Variante 1) Abbildung 17: Klassenmodell (Variante 2) Abbildung 18: Use Case Diagramm Abbildung 19: Fachliches Klassenmodell Abbildung 20: Technisches Klassenmodell Abbildung 21: Komponentenmodell Abbildung 22: Komponenten Abhängigkeiten Abbildung 23: Deployment Diagramm Abbildung 24: Model-View-Controler Architektur Abbildung 25: Model-View-Controler Klassenmodell Abbildung 26: Klassenfabrik Abbildung 27: Framework (allgemein) Abbildung 28: Microsoft.NET Abbildung 29:.NET Dienste Abbildung 30: Laufzeitumgebung und Klassenbibliotheken vor.net Abbildung 31:Laufzeitumgebung und Klassenbibliotheken in.net Abbildung 32: CLR-Aufbau Abbildung 33: Namespace-Hierarchie Abbildung 34: Vererbungshierarchie Abbildung 35: Objektmodell Abbildung 36: Architektur ASP.NET Abbildung 37: Deploymentdiagramm ASP.NET Abbildung 38: WebService Struktur Abbildung 39: Aufrufstruktur WebServices in ASP.NET Advanced Application System Development Seite 4

5 1 Übersicht Abbildung 1: Übersicht AASD Die Inhalte der Vorlesung befassen sich sowohl mit den organisatorischen Aspekten größerer Softwareprojekte wie der Wahl und Umsetzung geeigneter Vorgehensmodelle, als auch mit den technischen Grundlagen moderner Anwendungssystemarchitekturen und deren Implementierung. Die Entwicklung eines Softwareproduktes teilt sich in drei Hauptbereiche auf: 1. Organisation 2. Fachliche Lösung 3. Technologie Advanced Application System Development Seite 5

6 2 Entwicklungsrahmen Der Entwicklungsrahmen legt das Umfeld fest, in dem das Projekt durchgeführt werden soll. Er definiert beispielsweise die Einbindung in einen qualitätssichernden Kontext (Qualitätsmanagement) und legt fest nach welchem Vorgehensmodell die Entwicklung organisiert werden soll. Ferner können im Entwicklungsrahmen unterstützende Funktionen wie z.b. Reporting, Benchmarking, Controlling etc. enthalten sein. 2.1 Qualitätssicherung Qualitätssicherung ist Teil des Qualitätsmanagements. Nach DIN EN ISO 9000:2000, Punkt ist Qualitätssicherung definiert als "Teil des Qualitätsmanagements, der durch das Erzeugen von Vertrauen darauf gerichtet ist, dass Qualitätsanforderungen erfüllt werden". Qualitätssicherung ist der unternehmensinterne Prozess, der sicherstellen soll, dass ein hergestelltes Produkt ein festgelegtes Qualitätsniveau erreicht. Dabei geht es nach ISO 9000 nicht etwa darum, die Qualität eines Produktes zu optimieren, sondern ein vorgegebenes unter Umständen auch extrem niedriges - Niveau zu halten. Das Produkt kann dabei sowohl materiell sein, als auch eine erbrachte Leistung oder eine verwendete Verfahrensweise. Teil der Qualitätssicherung ist die Gleichheit des Produktes mit einem zweiten und jedem weiteren Exemplar des Produktes (Reproduzierbarkeit). Um diese Gleichheit zu erreichen, setzt man Qualitätssicherungsnormen wie beispielsweise internationale Normen nach EN oder ISO, nationale Normen nach DIN oder Önorm, firmeninterne Normen oder andere technische Dokumentationen wie RFCs ein. So fordert z.b. ein Qualitätsmanagement-System nach DIN EN ISO 9001:2000 für Entwicklungsprozesse ein Modell zur Entwicklungsplanung das folgende Forderungen erfüllt: Planung und Lenkung der Entwicklung durch die Organisation Festlegung von Entwicklungsphasen, einer angemessenen Bewertung, Verifizierung und Validierung für jede Phase sowie der Verantwortung und Befugnisse dafür Lenkung der Schnittstellen der an der Entwicklung beteiligten Gruppen, um eine wirksame Kommunikation und eine klare Verantwortungszuordnung zu sichern Aktualisierung der Planung bei Fortschreiten der Entwicklung, soweit angemessen Angewendet auf den Softwareentwicklungsprozess ergibt sich aus dem Qualitätsmanagement als qualitätssichernde Maßnahme die Notwendigkeit des Vorhandenseins und Befolgens eines Vorgehensmodells zur Anwendungsentwicklung. 2.2 Team Building Abbildung 2: Mind Map Team Building Advanced Application System Development Seite 6

7 2.3 Application Management Lifecycle - Vorgehensmodell nach ITIL (nach [5]) Die IT Infrastructure Library, kurz ITIL, ist ein in Großbritannien entwickelter Leitfaden zur Unterteilung der Funktionen und Organisation der Prozesse, die im Rahmen des Betriebs einer IT-Infrastruktur eines Unternehmens entstehen (IT Service Management). Vor allem in England und den Niederlanden ist die Organisation dieser Prozesse nach ITIL ein weit verbreiteter Standard, in Deutschland wächst die Bedeutung ebenfalls stetig. ITIL ist in einer Reihe von Büchern definiert, die vom Office of Government Commerce (OGC), einer Stabstelle der Regierung von Großbritannien herausgegeben werden. Bei ITIL handelt es sich um keine Projektmanagementmethode: ITIL soll nicht die Einführung einer IT-Infrastruktur organisieren, sondern vielmehr deren dauerhaften Betrieb. Sie definiert klare Aufgabenstellungen, die beim Betrieb dieser Infrastruktur anfallen. ITIL beschreibt Umsetzungsmöglichkeiten für die wesentlichen Prozesse, die im Rahmen des IT Service Managements und ICT Infrastructure Managements organisiert werden sollten, einschließlich der nicht oder nicht nur spezifisch IT-originären Prozesse wie Strategiebildung, Planung, Controlling, Personalmanagement etc. ITIL in der Revision 2 besteht aus acht Kernpublikationen: Service Support Service Delivery ICT Infrastructure Management Security Management Application Management Lifecycle Planning to Implement Service Management Software Asset Management The Business Perspective Im Rahmen dieser Vorlesung soll aus ITIL lediglich das Vorgehensmodell, der Application Management Lifecycle betrachtet werden. Im Gegensatz zu klassischen Vorgehensmodellen verfolgt dieses einen integrierten Ansatz über die gesamte Lebensdauer einer Anwendung und endet nicht mit deren Auslieferung, sondern schließt nachgelagerte Problemstellungen der Softwareentwicklung wie Betrieb, Wartung und Pflege bereits in den eigentlichen Entwicklungsprozess mit ein. Der Lebenszyklus einer Anwendung erstreckt sich bis zu dem Punkt, an dem alle Programmdateien von sämtlichen involvierten Systemen der IT-Infrastruktur entfernt wurden und keinen Einfluss mehr auf die IT-Umgebung ausüben können. Es gibt eine Reihe von Perspektiven aus denen der Application Lifecycle betrachtet werden kann, aber die meisten fallen in zwei Kategorien entweder betrachten sie die Anwendungsentwicklung oder das Service Management. Die Entwicklungssicht unterscheidet zwischen globalem und detailliertem Design, Modul- und Systemtests und endet mit einer sehr vagen Phase namens Wartung. Das Service Management beginnt meist erst bei bereits fertig entwickelten Anwendungen, die für den Produktivbetrieb freigegeben wurden. Advanced Application System Development Seite 7

8 Was in beiden Perspektiven übersehen wird ist, dass die Verbindung zwischen Anwendungsentwicklung und Service Management in der Realität sehr viel enger ist als in den entsprechenden Vorgehensmodellen berücksichtigt wird. Der Application Lifecycle nach ITIL definiert sechs Phasen, die jeweils aus beiden Perspektiven betrachtet werden, was eine Abstimmung beider Sichten in jeder einzelnen Phase erforderlich macht. Abbildung 3: Application Lifecycle [5] Requirement Phase Jedes Anwendungssystem beginnt seinen Lebenszyklus in der Requirement Phase. In dieser Phase arbeitet das Entwicklungsteam eng mit den involvierten Fachabteilungen zusammen und sammelt die Anforderungen, die an das System gestellt werden. Die Requirement Phase identifiziert Funktionalitäten und andere Charakteristiken wie Performance, Skalierbarkeit, Sicherheit etc., die die Anwendung erfüllen muss. Die Anforderungen, die in dieser Phase entwickelt werden, dienen als Ausgangspunkt für die weiteren Phasen des Entwicklungsprozesses. ITIL unterscheidet drei verschiedene Anforderungsbereiche: Functional Requirements Non-Functional Requirements Usability Requirements Functional Requirements Funktionale Anforderungen beschreiben die Dinge, die eine Anwendung unterstützen soll und lassen sich als Dienste, Aufgaben oder Funktionen formulieren. Eine Möglichkeit funktionale Anforderungen zu spezifizieren ist z.b. der Einsatz von Use Case Modellen aus der UML, die sich später z.b. auch zu Testfällen erweitern lassen. Da Use Cases die Funktionalität einer Anwendung auf einem Level beschreiben das sowohl für die Business-als auch die IT-Seite verständlich ist, können sie als Vehikel genutzt werden die funktionalen Elemente von Service Level Agreements (SLA s) zu spezifizieren. Advanced Application System Development Seite 8

9 Eine Ebene unterhalb der Use Cases werden je nach Typ der Anwendung weitere Modellierungsschritte durchgeführt, die die statischen / dynamischen Charakteristiken des Anwendungssystems darstellen und ein konzeptionelles Datenmodell definieren (z.b. Sequenz-, Zustandsdiagramme und Komponentenmodell etc. ebenfalls aus der UML). Sie dienen als Basis für die weitere technische Modellierung in der Design Phase Non-Functional Requirements Nicht funktionale Anforderungen werden dazu verwendet Anforderungen und Restriktionen an das Anwendungssystem selbst zu definieren. Diese Anforderungen dienen beispielsweise als Basis zur frühen Bestimmung der benötigten Systembemessung und der damit verbundenen Kosten. Am wichtigsten ist jedoch der Einfluss den sie auf das Design der technischen und operativen Modelle haben. Nicht funktionale Anforderungen bestimmen zu großen Teilen die Entscheidung für eine konkrete Anwendungsarchitektur. Zwei Anwendungssysteme mit identischen Use Cases aber sehr unterschiedlichen nicht funktionalen Anforderungen brauchen sehr unterschiedliche Architekturen. Nicht funktionale Anforderungen sollten den einzelnen Entwickler ebenso dazu ermutigen einen Blick über den Tellerrand zu riskieren und das Projekt und seine Ziele als Ganzes wahrzunehmen. Typische nicht funktionale Anforderungen sind: Verlässlichkeit: o Ausfallsicherheit o Ausfallwirkung Effizienz (z.b. Ressourcenverbrauch) Effektivität (System lernt) Anwendungsintegration (kann es mit anderen Programmen laufen?) Verfügbarkeit (z.b. 24/7/356) Kapazitätsanforderungen (Minimalausstattung) Sicherheitsanforderungen (Checklisten abhaken) Korrigierbarkeit Standartkonfiguration Wartbarkeit Sicherung gegen Störung von außen Advanced Application System Development Seite 9

10 Usability Requirements Der primäre Zweck von Usability Requirements ist es sicherzustellen, dass das Anwendungssystem die Erwartungen der Benutzer an seine unkomplizierte Verwendbarkeit erfüllt. Sie liefern Vorgaben für die Bereiche: User Interface und GUI-Design Performance Standards (z.b. Antwortzeiten) Test Szenarien Change Cases Change Cases sind nicht direkter Teil der Modellierung des zu entwickelnden Anwendungssystems, sondern spezifizieren wahrscheinliche, in zukünftigen Programmversionen zu implementierende Funktionen. Sie dienen dazu die Planung um eine vorausschauende Komponente zu erweitern, um den Aufwand für zukünftige Änderungen zu minimieren Testing Requirements Das Testen der Anforderungen ist eine oft übersehene Möglichkeit die Qualität der zu entwickelnden Anwendung zu verbessern. Die hier zur Verfügung stehenden Möglichkeiten sind beispielsweise: Prototyping, User Interface und GUI Dummies, Screenshot Reviews, Dokumentations Reviews, Präsentationen, etc. Die Herausforderung bei Anforderungstests sind zum einen die anfänglich vielleicht unübersichtliche Anzahl von Anforderungen und zum anderen die unterschiedlichen Erwartungen und Meinungen der Beteiligten was das System wie zu leisten hat. Ziel dieses Schrittes soll sein, vor Beginn der nächsten Phase eventuell vorhandene Missverständnisse in den dokumentierten Anforderungen aufzudecken und zu beseitigen Requirements Management Checklist Bei der Identifizierung der Anforderungen ist es wichtig, dass in der Requirements Phase alle Service Management Funktionen vollständig berücksichtigt und behandelt werden. Dazu gehören: Configuration Unter welcher Systemumgebung soll das System laufen? Change Sind bereits Erweiterungen absehbar (s. Change Cases)? Release Wie soll das System herausgegeben werden; hat es Einfluss auf andere Applikationen die eventuell Updates benötigen? Advanced Application System Development Seite 10

11 Security Welche Sicherheitsanforderungen müssen eingehalten werden (z.b. Verschlüsselung, Zugriff auf die Hardware etc.)? Incidents Wie soll auf Fehler in der Anwendung reagiert werden, wie auf Fehler in der Organisation; Einführung von Unternehmensstandards zur Fehlerbehandlung? Problems Wie sieht die Problembehandlung in der Systemungebung aus (stehen Backup Lösungen bereit etc.)? Capacity Welche Kapazitäten sind verfügbar / werden benötigt? Availability 24/7/365? Service Continuity Wie lange kann der Betrieb ohne das System arbeiten, wie arbeitet er ohne das System? Service Level Welches Service Level wird benötigt (24h Hotline / Vor Ort Service etc.)? Financials Wie beeinflusst das System die Kostenstruktur, wer bezahlt dafür? Organisation des Requirements Teams Das Requirements Team erfordert die Anwesenheit einiger Schlüssel Service Management Bereiche um sicherzustellen, dass die Arbeit umfassend erledigt wird. Dazu werden Rollen definiert, die von ein oder mehreren Personen übernommen werden: Change and Configuration Management Verantwortlich für Change, Release und Configuration Management, welche die Hauptprozesse darstellen, die die Anwendung vom Entwicklungs- in den Produktiveinsatz überführen. Support Verantwortlich für Support, Incident und Problem Management. Operations Verantwortlich für die alltäglichen Wartungsaktivitäten nachdem das System in den Produktiveinsatz überführt wurde. Ziel ist es sicherzustellen, dass Wartung und Pflege des Systems definiert und deren Durchführung kompatibel mit anderen Anwendungen der Organisation ist (z.b. gemeinsame Wartungsfenster, um Downtimes zu reduzieren). Advanced Application System Development Seite 11

12 Security Verantwortlich für das Betreiben eines Risiko Managements. Hauptziele sind die Sicherstellung von: o Daten-Konfidenz: Niemand darf unauthorisierten Zugriff auf Daten haben. o Daten-Integrität: Die Daten müssen korrekt sein. o Daten-Verfügbarkeit: Daten müssen verfügbar sein wann und wo sie gebraucht werden (speziell bei mobilen Applikationen z.b. Aussendienst). Weitere Bereiche sind : o Umfassende Planung zur Erhebung, Aufbewahrung, Klassifizierung und sicheren Vernichtung von Datenbeständen. o Rechtsverbindliche, finanzielle und historische Daten müssen für eine angemessene Zeit, gemäß gesetzlichen, branchen- oder unternehmensverbindlichen Fristen, sicher aufbewahrt werden. o Unnötige Daten sollten gelöscht werden um Kosten und Aufwand zu sparen. o Physische Sicherheit Zugang zu Systemen; sicherer Zugang und Betrieb von Datenverbindungen mit Geschäftspartnern und Unternehmensteilen. ICT Infrastructure Management Verantwortlich für Capacity und Availability Management Design Phase Die Design Phase ist eine der wichtigsten Phasen innerhalb des Application Lifecycles. Sie verarbeitet die Ergebnisse der Requirement Phase und erstellt aus ihnen Spezifikationen und Modelle auf deren Grundlage die Anwendung entwickelt wird. Im Allgemeinen werden in der Design Phase die gleichen Modelle wie in der Requirement Phase erstellt, jedoch werden diese sehr viel detaillierter ausgearbeitet. Neu hinzu kommen Modelle wie Deployment-Diagramme um die physische Aufteilung der Anwendungskomponenten (Komponenten-Diagramm) auf Systeme, Netzwerke und Datenbanken zu planen. Ein weiterer wichtiger Aspekt des Deployment Modells ist das Einfügen der Anwendung in die bestehende Infrastruktur. Welche Systeme können weiterverwendet werden mit was für Auswirkungen? Welche sind zur Unterstützung der neuen Funktionalitäten erforderlich? Sind eventuell bereits notwendige Funktionalitäten vorhanden, die eingebunden werden können? Existieren bereits Lösungen, die verwendet werden können oder müssen sie von Grund auf neu entwickelt werden? All diese Systemcharakteristiken sollten Dokumentiert werden. Die Design Phase bezieht alle Anforderungen in ihre Überlegungen mit ein und erstellt aus ihnen einen ersten Lösungsansatz. Dieser dient den Entwicklern als Basis, um mit der Arbeit zu beginnen. Ebenso können sich aus diesem ersten Ansatz noch Fragen ergeben, die mit dem Advanced Application System Development Seite 12

13 Kunden geklärt werden müssen. Nach Möglichkeit sollte der Einsatz von Frameworks als Ausgangspunkt der Entwicklung dienen. Es ist nicht immer möglichen jeden Aspekt des Lösungsdesigns vorherzusehen. Während der Entwicklung werden sich sehr wahrscheinlich neue Vorgehensweisen und Methoden zur Umsetzung der Anforderungen erlernt oder entwickelt. Das Auftauchen ungeplanter Hindernisse erfordert oft eine Neubewertung des Verständnisses der Kundenanforderungen Design von Non-Functional Requirements / Manageability Das Design nicht funktionaler Anforderungen bedeutet ihnen die selbe Wichtigkeit zuzuordnen wie den funktionalen und sie als erforderlichen nicht zusätzlichen - Teil in die Design Phase einzubinden Risiko gesteuerte Terminierung Risiko gesteuerte Terminierung ordnet risikoreicheren Aufgaben eine höhere Priorität zu und berücksichtigt Risikoprioritäten für die Kundenanforderungen. Das bedeutet, dass die risikoreichsten Aufgaben als erstes abgearbeitet werden, so dass im Falle eines Fehlers oder Fehlplanung mehr Zeit zur Lösung zur Verfügung steht und eine Beeinträchtigung des kritischen Projektablaufs vermieden wird Kompromissentscheidungen Kompromissentscheidungen konzentrieren sich darauf, die Beziehung zwischen Ressourcen, dem Projektplan und den zu implementierenden Funktionalitäten auszubalancieren. Oftmals geschieht dies auf Kosten der nicht funktionalen Anforderungen. Ein Weg dies zu verhindern ist die nicht funktionalen Anforderungen in den anwendungsunabhängigen Design- Richtlinien zu berücksichtigen, beispielsweise durch den Einsatz von Frameworks, die einen Teil der Anforderungen bereits implementieren Anwendungsunabhängige Design-Richtlinien und Frameworks Die Nutzung anwendungsunabhängiger Design-Richtlinien fördert die Manageability innerhalb einer Entwicklung, indem nicht funktionale Anforderungen bereits standardmäßig in den Design-Prozess integriert werden. Der Einsatz von Frameworks ist ein effizienter Weg diese in allen Design-Prozessen zu Standardkomponenten zu machen Organisation des Design Teams Neben den regulären Anwendungsentwicklungsrollen (Datenbank Design, GUI, Architektur etc.) die man im Design Team erwartet, werden auch hier wieder Rollen des Service Managements benötigt, um sicherzustellen, dass die Application Management und Operation Perspektiven in die wichtigen Designentscheidungen eingebunden werden: Advanced Application System Development Seite 13

14 Change and Configuration Management Berät das Entwicklungsteam beim Übergang der Anwendung vom Entwicklungs- /Testbetrieb zum Produktiveinsatz. Änderungsüberwachung, Status- und Versionskontrollen, Softwareverteilung, Lizenzmanagement, Einsatzüberwachung und Außerdienststellung sind weitere Bereiche in denen das Change and Configuration Management konsultiert wird. Eine weitere beratende Funktion besteht in der Integration automatischer Instrumentalisierungsfunktionen (z.b. für CMDB oder DMI) in das Anwendungssystem. Support Berät das Design Team im Hinblick auf die Vereinfachung des Zugriffs auf Support Informationen und die Integrierung von Support Funktionen direkt in die Anwendung. Dazu gehört zum Beispiel das Logging wichtiger Systemparameter oder die Bereitstellung von Speed Recovery oder Selbsthile-Funktionen (z.b. das Anlegen von Wiederherstellungspunkten um das System auf einen früheren, fehlerfreien Stand zurückzusetzen). Operations Stellt sicher, dass die alltäglichen Anforderungen nicht aus den Augen verloren werden. Diese beinhalten die Einbindung der Anwendung in bestehende System Management Systeme, die Einplanung von regelmäßigen Prozessen wie Backups, Archivierung, Überwachung, Output- und Event Kontrolle und die generelle Übereinstimmung mit unternehmensweiten Standards. Security Überwacht die Einhaltung der festgelegten Sicherheitsstandards hinsichtlich ihrer Berücksichtigung im Design der Anwendung, als auch im Entwicklungsteam selbst. Hierzu gehören unter anderem: o Intrusion Detection und Virenschutz, o Denial of Service Prävention, o Festlegung von Standards zum sicheren Umgang und Speicherung von Daten, o Netzwerksicherheit, o Ergreifung von Gegenmaßnahmen im Ernstfall, o Durchsetzen von Benutzer Regeln wie Password Policies, o Physische Sicherheit, Zugriffs-/Zutrittskontrolle, o Sicherung von Kommunikation. ICT Infrastructure Management Achtet darauf, dass die Anwendung im Hinblick auf ihren Ressourcenverbrauch berechenbar bleibt und den Kostenrahmen der dafür bereitgestellten Infrastruktur nicht verlässt, stellt Server Installationen, Images und Installationspakete zusammen und verrechnet den entstandenen Installationsaufwand. Advanced Application System Development Seite 14

15 2.3.3 Build Phase Nachdem die Design Phase abgeschlossen ist beginnt das Entwicklungsteam mit der Umsetzung der Entwürfe und dem Test der Anwendung. Auch in der Build Phase muss die Berücksichtigung der nicht funktionalen Anforderungen sichergestellt sein Konsistente Programmierkonventionen Der Hauptgrund Programmierkonventionen zu verwenden ist die Struktur und Quellcodeformatierung einer Anwendung zu standardisieren, so dass jeder den Entwicklungsprozess ohne Schwierigkeiten lesen, verstehen und managen kann. Gutes Design und Programmierrichtlinien sorgen für einen präzisen, lesbaren und unzweideutigen Quellcode, der mit den Unternehmensstandards übereinstimmt und intuitiv nachvollzogen werden kann. Aus der operativen Perspektiven stellen diese Konventionen sicher, dass die Anwendung über ihren gesamten Lebenszyklus wartbar bleibt. Programmierrichtlinien können eine große Hilfe bei der Verwaltung und Kontrolle von Anwendungen sein, weil sie den Management Tools den Zugriff auf die Anwendung in gewohnter Weise erlauben. Im Allgemeinen ist es vorzuziehen, ein minimales Set an Konventionen zu verwenden an das sich alle halten, als ein übermäßig komplexes aufzustellen das von niemandem mehr vollständig umgesetzt werden kann Anwendungsunabhängige Erstellungsrichtlinien Templates, Code Generierung und Application Frameworks Eine Reihe von Tools bieten eine Vielzahl von Templates zur Erstellung gängiger Anwendungskomponenten. Anstatt alle Teile einer Anwendung von Grund auf neu zu entwickeln können die Entwickler existierende Templates anpassen. Ebenso ist eine Wiederverwendung eigener Komponenten in mehreren Anwendungen möglich. Andere Tools generieren große Abschnitte Quellcode (Skeletons) basierend auf den Design Modellen (z.b. Klassenmodell) und Programmierkonventionen. Der Code enthält Markierungen an denen eigener Code eingefügt werden muss. Application Frameworks können viele der nicht funktionalen Anforderungen abdecken, die dem Standard in ähnlichen Anwendungen entspricht. Templates und Frameworks stellen Werte dar. Diese Werte lenken nicht nur die Entwicklung, sondern enthalten auch das Wissen aus vorangegangenen Entwicklungsanstrengungen. Je mehr dieser Komponenten zur Verfügung stehen, desto schneller und langfristig kostengünstiger läuft die Entwicklung. Eingebettete Anwendungsinstrumentarisierung In der Design Phase wurde das Konzept der Anwendungsinstrumentarisierung eingeführt, in der Build Phase geht es darum diese Komponenten in das Anwendungsgerüst einzufügen. Advanced Application System Development Seite 15

16 Entwickler brauchen ein konsistentes Vorgehen bei der Einbindung von Instrumentarisierungsschnittstellen-Anwendungs-Treibern (z.b. Datenbanktreiber) und Anwendungen, das effizient und einfach zu implementieren ist. Um das Rad nicht mit jeder Anwendung neu erfinden zu müssen, stehen eine Reihe von Methoden und Technologien zur Vereinfachung dieses Prozesses bereit: IBM Application Management Specification (AMS), Distributed Management Task Force (DMTF), Desktop Management Instrumentation (DMI), Microsoft Windows Management Instrumentation (WMI). Jede dieser Technologien bietet ein konsistentes und umfangreiches beschreibendes Modell von Konfiguration, Status und operativen Aspekten von Anwendungen und Systemen. Es wird durch API s zugänglich gemacht, die von den Entwicklern in die Anwendung eingefügt werden (z.b. durch Verwendung von Templates). Es ist wichtig, dass alle Anwendungen so entwickelt werden das sie konform zu einem Instrumentarisierungslevel sind. Wege dies zu erreichen sind: Zugriff auf Management Daten über API Wenn die Anwendung vom System bereitgestellte Managementfunktionen und daten benutzt und diese Daten innerhalb des Instrumentarisierungs-Namespaces verfügbar sind, sollte der Zugriff auf sie über das Instrumentarisierungs-API erfolgen anstatt über native API s. Dies beinhaltet normalerweise unterschiedliche Management Objekte, Performance Monitors und Event-Log-Daten. Das Instrumentarisierungs-API erlaubt eine größere Interoperabilität der Anwendungen und Management Informationen. Ein Beispiel ist Microsofts WMI. WMI ist eine Technologie, die ein Framework bereitstellt um eine Anwendung zu Instrumentarisieren, so dass es möglich ist Funktionen wie beispielsweise Live Performance Monitoring zu nutzen. Bereitstellen von Management Daten für andere Systeme über API Verfügt die Anwendung über Managementfunktionen und daten, die eine Kontrolle oder Überwachung der Anwendung aus anderen Anwendungen heraus erlauben, sollten diese über das Instrumentarisierungs-API zugänglich gemacht werden. Erzeugt die Anwendung Events, sollten auch diese über das Instrumentarisierungs-API an die verarbeitende Management-Anwendung weitergereicht werden. Einhalten der Regeln zur Erweiterung des gemeinsamen Namespace Dies bedeutet, dass die eingebettete Anwendungsinstrumentarisierung in einer Weise beschrieben wird, die nicht nur der Anwendungsentwickler versteht, sondern auch von anderen Entwicklern / Herstellern verwendet wird, damit alle Anwendungen koexistieren können und interoperabel bleiben. Es wäre schwierig für zwei Systeme zusammenzuarbeiten, wenn die selben Objekte unterschiedliche Namen und Methoden hätten, die inkonsistent und untereinander unbekannt sind. Advanced Application System Development Seite 16

17 Bereitstellung von Anwendungs-Event-Handling Ein Anwendungs-Event ist ein Ereignis das normalerweise Folgeaktionen auslöst. Dies kann vom simplen aufzeichnen des Events bis zum alarmieren des Sicherheitsteams reichen, wenn jemand versucht in das System einzubrechen. Die Erzeugung, Behandlung und Meldung von Events sowohl innerhalb als auch außerhalb des Anwendungsrahmens liefern die Schlüsselinformationen um zu verstehen was die Anwendung gerade tut und wie sie arbeitet. Bereitstellung von Diagnosehooks Ein Diagnosehook erlaubt Überwachungs- und Debugging-Tools die Ausführung innerhalb verteilter Systeme zu überwachen und Diagnoseinformationen zu sammeln. Normalerweise stellt er Informationen zu Performance-Daten, Fehlerzuständen und Konfigurationseinstellungen bereit. Sie werden hauptsächlich eingesetzt um die Systemverfügbarkeit und verlässlichkeit zu erhöhen. Fehler können immer auftreten und Diagnosehooks helfen die Downtime zu minimieren. Gute Diagnosehooks helfen bei der Identifizierung der Fehlerursache und stellen Informationen zur Fehlerbehebung bereit. Des weiteren helfen sie die Gesamtqualität der Systeme zu steigern, indem Fehlerursachen aufgezeichnet und analysiert werden. Ein gutes Vorgehen ist, Diagnosehooks zu nutzen, die sich an- und abschalten lassen. So kann im Falle eines Fehlers im Test- oder Produktiveinsatz relativ simpel an die benötigten Informationen gelangt werden, ohne die Performance zu beeinträchtigen. Diagnosehooks können in drei Kategorien aufgeteilt werden: o System Level Information von Betriebssystem und Hardware, o Software Level Information der Systeminfrastrukturen wie Webserver, Datenbanken etc., o Individuelle Informationen der einzelnen Anwendung. Diagnosehooks sind von größtem Wert während der Testphase und wenn Fehler im Betrieb auftreten. Sie stellen die Informationen bereit, die nötig sind um Probleme und Anwendungsfehler zu lösen. Fehler treten selbst in gründlich getesteten Anwendungen auf. Während der Entwicklung ist es für den Entwickler unmöglich an jede einzelne Fehlermöglichkeit zu denken und den Quellcode entsprechend zu gestalten. Jede Anwendung, egal wie auftragskritisch oder gut entwickelt, kann Fehler erleiden. Fehler können durch so einfache Dinge wie geändertes Trafficvolumen oder Benutzungsmuster entstehen. Auch Hardwarefehler eines Server oder der Ausfall von Netzwerkkomponenten können zu Fehlern führen. Nicht zuletzt sind Änderungen innerhalb der Systemumgebung ein häufiger Grund für Fehler. Anscheinend kleine Änderungen können weitreichende Auswirkungen auf laufende Anwendungen haben. Die Änderung von Datenbankschemas zur Unterstüt- Advanced Application System Development Seite 17

18 zung neuer Anwendungen, die Inbetriebnahme neuer Systeme oder Änderung von Sicherheitsrichtlinien sind weitere Fehlermöglichkeiten Produktivtests Während die Anwendung entwickelt wird, muss sie gründlich getestet werden um sicherzustellen, dass sie alle funktionalen und nicht funktionalen Anforderungen erfüllt. Die Herangehensweise an Tests kann zu einem Großteil die Softwarequalität bei Auslieferung bestimmen. Viel zu oft wird das Testen an das Ende der Build Phase - kurz vor die Deployment Phase verschoben und wird dann, vor allem wenn das Projekt schon außerhalb des Zeitplans liegt, beschleunigt oder gekürzt, was der Qualität abträglich ist. Qualität sollte in einem Softwareentwicklungsprojekt von Beginn an berücksichtigt werden und die Arbeitsabläufe des Entwicklungsteams sollten Tests als integrale und obligatorische Tätigkeit in jeder Stufe des Projekts enthalten. Der Test von nicht funktionalen Anforderungen wird oftmals vernachlässigt. Der Testplan sollte eine Sektion enthalten, die jede der nicht funktionalen Anforderungen beschreibt, welches Gebiet sie abdeckt und wie sie getestet werden soll. Ein Beispiel einer solchen Anforderung kann sein, das bei einem Systemausfall ein Ersatzsystem innerhalb von acht Stunden installiert und restauriert werden können muss. Viele Test-Typen sind angemessen, inklusive Tests die vom Entwicklungsteam durchgeführt werden, wie Unit-, System- und Integrationstests und Tests die hauptsächlich von separaten Test-Teams oder den Auftraggebern vorgenommen werden, wie Tests zur funktionalen Akzeptanz, User- und Produktions-Akzeptanz. Um einen qualitativ hochwertigen Übergang in die Deploy Phase zu gewährleisten, sollten Tests eine alles durchdringende Aktivität während der gesamten Build Phase sein. Genau wie die Anforderungen aus der Requirements Phase als Testbasis für die Arbeitsergebnisse der Design Phase genutzt werden können, können auch die Anforderungen der Design Phase als Testbasis für die Build Phase verwendet werden. Basierend auf dem Design der Anwendung kann das Test Team die Testpläne erstellen. Interne Design-Spezifikationen können zu Unit- und System-Tests, externe für Akzeptanz- Tests verwendet werden. Wenn eine Anwendung in mehreren Iterationen in Versionsschritten entwickelt wird, sollte jede dieser Versionen wieder gegen das gesamte Testpaket getestet werden. Diese Regressionstests sind der einzige Weg sicherzustellen, dass sich keine Fehler in bereits entwickelte und getestete Komponenten einschleichen, was immer einmal vorkommen kann. Ein weiterer Weg sicherzugehen das die Testumgebung eine realistische Abbildung der Produktivumgebung darstellt, ist sie unter das gleiche Change und Configuration Management zu stellen als wäre es das Live-System. Advanced Application System Development Seite 18

19 Code-Review bezeichnet ein Peer-Review von Programmcode mit dem Ziel Fehler zu finden und zu beheben, die in der Entwicklungsphase übersehen wurden. Dadurch soll die Gesamtqualität des Programmcodes verbessert werden. Bei Code-Reviews können oft gängige Sicherheitslücken, wie Format String Attacks, Race Conditions oder Buffer-Overflows gefunden und entfernt werden. Online Software Repositories wie CVS erlauben es Gruppen von Individuen gemeinschaftlich Code-Reviews durchzuführen, und damit Sicherheit und Qualtität des Programmcodes zu verbessern. Unit-Tests (auch Komponententests) sind Teil eines Softwareprozess-Vorgehensmodells (z.b. Extreme Programming). Es handelt sich um ausführbare Codefragmente, die das sichtbare Verhalten einer Komponente (z.b. einer Klasse) verifizieren und dem Programmierer eine unmittelbare Rückmeldung darüber gibt, ob die Komponente das geforderte Verhalten aufweist oder nicht. Als Voraussetzung für Refactoring kommt ihnen besondere Bedeutung zu. Nach jeder Änderung sollte durch Ablaufenlassen aller Testfälle die Fehlerfreiheit überprüft werden. Beim testgetriebenen Programmieren, auch TestFirst-Programmieren genannt, werden die Unit-Tests parallel zum eigentlichen Sourcecode erstellt und gepflegt. Dies ermöglicht bei automatisierten, reproduzierbaren Unit-Tests, die Auswirkungen von Änderungen sofort nachzuvollziehen. Der Programmierer entdeckt dadurch sicher ungewollte Seiteneffekte oder Fehler durch seine Änderung Organisation des Build Teams Genau wie in den Phasen zuvor soll auch bei der Organisation in der Build Phase der Gesamtkontext der Anwendung berücksichtigt werden. Change and Configuration Management Berät die Entwickler bei der Einbindung von Diagnosehooks und der Anwendungsinstrumentarisierung, so dass die Anwendung mit den Unternehmensstandards konform ist. Dies beinhaltet Komponenten Identifizierung, Change Control, Status- Reports, Versions-Kontrolle, Softwareverteilung, Lizenzkontrolle, Einsatzüberwachung und Ausserdienststellung, sowie Beratung wie die Übereinstimmung mit obigen Punkten getestet werden kann. Support Hauptaufgabe des Support-Teams ist es, mit den Testern zusammenzuarbeiten, um sicherzustellen das es die Anwendung später supporten kann. Eine Ideale Aufgabe für das Support-Team wäre es, die Anwendung während der Testphase zu betreuen. So kann es den Entwicklern direktes Feedback über die dabei gemachten Erfahrungen liefern, so dass die Supportbarkeit noch vor Inbetriebnahme berücksichtigt werden kann. Der Helpdesk könnte in die User-Akzeptanz-Tests involviert werden. Das hat den Vorteil, dass Endanwender Vorfälle über die gewohnten Kanäle berichten können und der Helpdesk schon vor Inbetriebnahme erste Erfahrungen mit der neuen Anwendung sammeln kann. Zudem kann das hinzufügen einer diagnostischen Sichtweise hilfreich sein. Advanced Application System Development Seite 19

20 Operations Ähnlich wie beim Support sollte das Operations-Team an den Test beteiligt werden und idealerweise die Prozesse und Funktionen durchspielen, die bei der späteren Benutzung auftreten. Security Überwacht die Einhaltung der Sicherheitsstandards, führt Risikoanalysen durch, prüft Quellcode und Dokumentation, ist zuständig für die Sicherheitsaspekte des Testplans und prüft Kompromissentscheidungen auf Sicherheitsprobleme. ICT Infrastructure Management Berät die Entwickler bei der Einbindung von Kapazitäts- und Verfügbarkeitsmanagement Funktionen. Diese Rolle sollte dem Entwicklungsteam auch dabei helfen die Anwendung im Hinblick auf das in der Requirement Phase getroffene Service Level Agreement (SLA) zu entwickeln. Diese Punkte sollten auch in den Testplan aufgenommen werden, um die SLA s auf Realismus zu prüfen und Schwierigkeiten gegebenenfalls mit der Business-Seite besprechen zu können Deploy, Operate und Optimise Phase Die Deploy, Operate und Optimise Phase sollen in diesem Skript nicht weiter beschrieben werden, da sie nicht mehr direkt zum Softwareentwicklungsprozess gehören, sondern diesem nachgelagert sind. Entsprechende Informationen zu diesen Phasen lassen sich den angegebenen Quellen entnehmen. Advanced Application System Development Seite 20

I T I L. ITIL ein systematisches und professionelles Vorgehen für. das Management von IT Dienstleistungen. Andreas Henniger.

I T I L. ITIL ein systematisches und professionelles Vorgehen für. das Management von IT Dienstleistungen. Andreas Henniger. I T I L ITIL ein systematisches und professionelles Vorgehen für das Management von IT Dienstleistungen. 1 ITIL Was ist ITIL? ITIL wurde von der Central Computing and Telecommunications Agency (CCTA) entwickelt,

Mehr

ITIL IT Infrastructure Library

ITIL IT Infrastructure Library ITIL IT Infrastructure Library Einführung in das IT-Service-Management Andreas Linhart - 2009 Agenda IT-Service-Management Der ITIL-Ansatz Lizenzen & Zertifizierungen ITIL-Prozessmodell (v2) Service Support

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITIL in 60 Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re

Mehr

Xpert.press ITIL. Das IT-Servicemanagement Framework. von Peter Köhler. überarbeitet

Xpert.press ITIL. Das IT-Servicemanagement Framework. von Peter Köhler. überarbeitet Xpert.press ITIL Das IT-Servicemanagement Framework von Peter Köhler überarbeitet ITIL Köhler schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Thematische Gliederung: SAP Springer

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITILin60Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re more

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis

Inhaltsverzeichnis. Inhaltsverzeichnis 1 Qualitätssichernde Prozesse 1 1.1 Was war die alte ISO 9000:1994?... 3 1.2 ISO 9000:2000... 4 1.3 ITIL und ISO 9000: 2000... 10 1.4 Six Sigma (6)... 12 1.4.1 Fachbegriffe unter Six Sigma... 17 1.4.2

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Inhaltsverzeichnis. Martin Beims. IT-Service Management mit ITIL. ITIL Edition 2011, ISO 20000:2011 und PRINCE2 in der Praxis ISBN: 978-3-446-43087-7

Inhaltsverzeichnis. Martin Beims. IT-Service Management mit ITIL. ITIL Edition 2011, ISO 20000:2011 und PRINCE2 in der Praxis ISBN: 978-3-446-43087-7 sverzeichnis Martin Beims IT-Service Management mit ITIL ITIL Edition 2011, ISO 20000:2011 und PRINCE2 in der Praxis ISBN: 978-3-446-43087-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-43087-7

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework Einführung MSF MOF Microsoft Solutions Framework Microsoft Operations Framework Daniel Dengler CN7 Agenda Unterschied MSF - MOF Microsoft Solutions Framework Elementare Komponenten grundlegende Richtlinien

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

IT Monitoring: ohne Prozessorientierung ist die Qualität in Gefahr. www.blue-elephant-systems.com

IT Monitoring: ohne Prozessorientierung ist die Qualität in Gefahr. www.blue-elephant-systems.com IT Monitoring: ohne Prozessorientierung ist die Qualität in Gefahr www.blue-elephant-systems.com 1 Prozessorientierung 2 Prozessorientierung Konzentration auf den Gegenstand der Leistung Voraussetzungen

Mehr

ITIL mit SAP R/3. Kundenservice für und mit ZENOS

ITIL mit SAP R/3. Kundenservice für und mit ZENOS ITIL mit SAP R/3 Kundenservice für und mit ZENOS Was ist ITIL? Information Technology Infrastructure Library Ende der 80er Jahre entworfen Herausgeber: Office of Government Commerce (OGC) Sammlung von

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

IT Service Management

IT Service Management IT Service Management Die IT Infrastructure Library (ITIL) Frank Klapper, CIO-IT IT,, Universität t Bielefeld München, 08.03.2006 IT Service Management: Notwendigkeit und Definition Informationen haben

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Modul 2: Geschäftsprozesse, SLA, ITIL und CMDB (Fortsetzung)

Modul 2: Geschäftsprozesse, SLA, ITIL und CMDB (Fortsetzung) Modul 2: Geschäftsprozesse, SLA, ITIL und CMDB (Fortsetzung) M. Leischner Netzmanagement Folie 1 Was haben wir letzte Stunde gelernt? - Wiederholung Erklären Sie folgende Begriffe: Grundidee Netz als Fabrik

Mehr

Modul 3: Service Transition Teil 3

Modul 3: Service Transition Teil 3 Modul 3: Service Transition Teil 3 1. Ziel, Wert und Aufgaben von Service Transition? 2. Prozess: Projektmanagement (Transition Planning and Support) 3. Prozess: Change Management 4. Prozess: Change-Evaluierung

Mehr

Modul 1: Grundbegriffe und Einführung in ITIL

Modul 1: Grundbegriffe und Einführung in ITIL Modul 1: Grundbegriffe und Einführung in ITIL 1. Was ist ein Service? 2. Was ist ein Asset? 3. Was ist Servicemanagement? 4. Was ist eine Rolle? 5. Was ist ein Service Provider? 6. Was ist ein Prozess?

Mehr

Inhaltsverzeichnis. Christian Wischki. ITIL V2, ITIL V3 und ISO/IEC 20000. Gegenüberstellung und Praxisleitfaden für die Einführung oder den Umstieg

Inhaltsverzeichnis. Christian Wischki. ITIL V2, ITIL V3 und ISO/IEC 20000. Gegenüberstellung und Praxisleitfaden für die Einführung oder den Umstieg sverzeichnis Christian Wischki ITIL V2, ITIL V3 und ISO/IEC 20000 Gegenüberstellung und Praxisleitfaden für die Einführung oder den Umstieg ISBN: 978-3-446-41977-3 Weitere Informationen oder Bestellungen

Mehr

ISO & IKS Gemeinsamkeiten. SAQ Swiss Association for Quality. Martin Andenmatten

ISO & IKS Gemeinsamkeiten. SAQ Swiss Association for Quality. Martin Andenmatten ISO & IKS Gemeinsamkeiten SAQ Swiss Association for Quality Martin Andenmatten 13. Inhaltsübersicht IT als strategischer Produktionsfaktor Was ist IT Service Management ISO 20000 im Überblick ISO 27001

Mehr

ITIL V3 zwischen Anspruch und Realität

ITIL V3 zwischen Anspruch und Realität ITIL V3 zwischen Anspruch und Realität Christian Lotz, Dipl.-Inform. Med. certified IT Service Manager & ISO 20000 Consultant 9. März 2009 IT-Service Management ISO 20000, ITIL Best Practices, Service

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

IT Service Management

IT Service Management Strategic Outsourcing IT Service Vorlesung an der FH Wilhelmshaven SS 2007 Klaus Dörner, kdoerner@de.ibm.com ITIL Übersicht ITIL Planning to Implement Service Business The Business Perspective Service

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

SAP Solution Manager zur Implementierung von E-Business- Lösungen im SAP Umfeld

SAP Solution Manager zur Implementierung von E-Business- Lösungen im SAP Umfeld SAP Solution Manager zur Implementierung von E-Business- Lösungen im SAP Umfeld Präsentation Workshop 1 im Rahmen der Lehrveranstaltung Electronic Business Dresden / 27.01.06 0. Agenda 1. SAP Solution

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

1. Verzeichnis der ITIL V3 (2011) Service Strategy Prozesse Dipl.-Ing. Walter Abel Management Consulting

1. Verzeichnis der ITIL V3 (2011) Service Strategy Prozesse Dipl.-Ing. Walter Abel Management Consulting 1. Verzeichnis der ITIL V3 (2011) Service Strategy Prozesse Dipl.-Ing. Walter Abel Consulting Service Strategy Business Relationship der IT Demand Service Portfolio Financial Kundenbeziehungen Strategische

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

>EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements

>EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements >EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements 6. Januar 2014 >Agenda Motivation EasyMain Methoden, Standards und Prozesse bei EasyMain Folie

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13 Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management

Mehr

Die Integration von Requirements Management, Software Configuration Management und Change Management mit der MKS Integrity Suite 2006

Die Integration von Requirements Management, Software Configuration Management und Change Management mit der MKS Integrity Suite 2006 Die Integration von Requirements Management, Software Configuration Management und Change Management mit der MKS Integrity Suite 2006 Oliver Böhm MKS GmbH Agenda Überblick Der Entwicklungsprozess: Requirements

Mehr

Transparenz optimieren durch Managed Services. Dr. Armin Metzger, sepp.med gmbh MID Insight, Nürnberg 2012-11-20

Transparenz optimieren durch Managed Services. Dr. Armin Metzger, sepp.med gmbh MID Insight, Nürnberg 2012-11-20 Transparenz optimieren durch Managed Services Dr. Armin Metzger, sepp.med gmbh MID Insight, Nürnberg 2012-11-20 Inhalt Managed Services was ist das? Motivation und Benefits von Managed Services Parameter

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Teil I Überblick... 25

Teil I Überblick... 25 Inhaltsverzeichnis Vorwort... 17 Motivation und Intention... 18 ITIL ist nicht nur reine Technik... 18 ITIL ist mehr... 19 ITIL ist auch ein Thema für die Organisation... 19 Zurück zum Thema Motivation...

Mehr

IHK Die Weiterbildung. Zertifikatslehrgang. IT Service Management (ITIL)

IHK Die Weiterbildung. Zertifikatslehrgang. IT Service Management (ITIL) Zertifikatslehrgang IT Service Management (ITIL) IHK-Lehrgang IT Service Management (ITIL) Termin: 01.06.2012 bis 16.06.2012 IT12090 Ort: Industrie- und Handelskammer Erfurt Arnstädter Str. 34 99096 Erfurt

Mehr

1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements

1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements 1 1. Methoden, Techniken und Tools: die harte Seite des Projektmanagements Herr Maier wurde von einem Tag auf den anderen Projektleiter: Übernehmen Sie das Projekt Orion, sagte sein Chef. Ohne zu wissen,

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services Wir schützen Ihre Investitionen Qualitätssicherung nach Maß IT Quality Services Sicherheit, die senkt Mit den IT Quality Services schützen Sie Ihre Investitionen Ohne Qualitätssicherung Mit Qualitätssicherung

Mehr

ITIL. fyj Springer. Peter T.Köhler. Das IT-Servicemanagement Framework. Mit 209 Abbildungen

ITIL. fyj Springer. Peter T.Köhler. Das IT-Servicemanagement Framework. Mit 209 Abbildungen Peter T.Köhler 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. ITIL Das IT-Servicemanagement Framework Mit 209 Abbildungen

Mehr

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Erfahrungen aus der industriellen Praxis Fraunhofer IESE Kaiserslautern Inhalt Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Mehr

IT Service Management

IT Service Management IT Service IT Service : Seminarvortrag von Annegret Schnell im Rahmen der Lehrveranstaltung Netzmanagement SS 2003, Prof. Dr. Leischner, FH-Bonn-Rhein-Sieg Annegret Schnell Seminar Netzmanagement 1 Vortrag

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. BEKA: Frankfurt, 25. Oktober 2012 T-Systems Angebot Umsetzung des globalen Telematikprojekts für den ÖPNV im Großherzogtum Luxemburg.

Mehr

WENDIA ITSM EXPERT TALK

WENDIA ITSM EXPERT TALK WENDIA ITSM EXPERT TALK WENDIA ITSM WHITEPAPER IT SERVICE MANAGEMENT BASISWISSEN: IN EINFACHEN SCHRITTEN ZUR CMDB Wer, Wie, Was: Die CMDB als Herzstück eines funktionierenden IT Service Management Die

Mehr

Integration von unterschiedlichen Vorgehensmodellen durch ein Project Management Office auf Basis des PMBoK. Werner Achtert

Integration von unterschiedlichen Vorgehensmodellen durch ein Project Management Office auf Basis des PMBoK. Werner Achtert Integration von unterschiedlichen Vorgehensmodellen durch ein Project Management Office auf Basis des PMBoK Werner Achtert Agenda Projektmanagement in IT-Projekten Einrichtung eines PMO in der BVBS PMBoK

Mehr

DP ITS Vorgehensmodell Build und Microsoft Team Foundation Server

DP ITS Vorgehensmodell Build und Microsoft Team Foundation Server DP ITS Vorgehensmodell Build und Microsoft Team Foundation Server Martin Tappe Düsseldorf, April-08-2009 GIWIVM AGENDA Referent Zum Forschungsprojekt DP ITS Vorgehensmodell Build (VMB) Microsoft Team Foundation

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Testen von Data-Warehouse- und Business-Intelligence-Systemen

Testen von Data-Warehouse- und Business-Intelligence-Systemen Edition TDWI Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte von Herbert Stauffer, Beat Honegger, Hanspeter Gisin 1. Auflage Testen von Data-Warehouse- und

Mehr

2009 Doktor der Wirtschaftswissenschaften, Universitat Pompeu Fabra, Barcelona

2009 Doktor der Wirtschaftswissenschaften, Universitat Pompeu Fabra, Barcelona Personalprofil Dr. Basak Günes Consultant E-Mail: basak.guenes@arcondis.com AUSBILDUNG BERUFLICHE WEITERBILDUNG BESONDERE TÄTIGKEITEN SPRACHEN 2009 Doktor der Wirtschaftswissenschaften, Universitat Pompeu

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik

Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik Entwicklung und Evaluation eines Vorgehensmodells zur Optimierung des IT-Service im Rahmen eines IT-Assessment Framework Oliver

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG CONTINUOUS DELIVERY Entmystifiziert WIE SOFTWARE LIEFERN? 01.07.2014 2 WAS IST CONTINUOUS DELIVERY? Robust Wiederholbar Effektiv 01.07.2014 3 LANDSCHAFTEN Continuous Integration Public / Private Hybrid

Mehr

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL

PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL PRODUKTENTWICKLUNG NACH DEM INGTES- PROZESSMODELL INGTES AG Bahnhofstr. 94 CH 5000 Aarau Tel. +4162 836 30 70 www.ingtes.com PRODUKTENTWICKLUNG NACH DEM INGTES-PROZESSMODELL 2 1 PRODUKT- ENTWICKLUNG Bei

Mehr

Information and Communications Technology Infrastructure Management ICTIM

Information and Communications Technology Infrastructure Management ICTIM Information and Communications Technology Infrastructure Management ICTIM - Eine Einführung - Version: 1.3 Datum: 06.11.03 Agenda Einführung ICTIM Einbettung in ITIL Die 4 Management Bereiche Design &

Mehr

Aktuelle Themen der Informatik IT Infrastructure Library Release Management

Aktuelle Themen der Informatik IT Infrastructure Library Release Management Aktuelle Themen der Informatik IT Infrastructure Library Release Management Oliver Schmid AI 8 Inhalt iii I Inhalt I Inhalt...iii II Abbildungsverzeichnis...iv 1 Einführung...1 2 Release Begriffe...2

Mehr

Einführung des IT-Service-Managements

Einführung des IT-Service-Managements Kassel, ITSMF-Jahreskongress Einführung des IT-Service-s Stadtwerke Düsseldorf Informationsmanagement Realisierung Meilensteine ISO 20000-Pre Assessment, Ausgangsniveau Prozessreife ITIL-Schulungen für

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

1 Die IT Infrastructure Library 1

1 Die IT Infrastructure Library 1 xix 1 Die IT Infrastructure Library 1 1.1 ITIL ein erster Überblick................................. 2 1.2 Service Management Grundlegende Begriffe.................. 5 1.2.1 Dienstleistungen (Services)..........................

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

ITIL und Entwicklungsmodelle: Die zwei Kulturen

ITIL und Entwicklungsmodelle: Die zwei Kulturen Kombination von IT Service Management (ITIL) und Anwendungsentwicklung Kai Witte und Matthias Kaulke, München, den 30.03.2006 Rahmeninformationen Wo sind wir? Unternehmensdarstellung (1) Unabhängiges Beratungsunternehmen

Mehr

Modul 5: Service Transition Teil 1

Modul 5: Service Transition Teil 1 Modul 5: Service Transition Teil 1 1. Ziel, Wert und Aufgaben von Service Transition? 2. Prozess: Projektmanagement (Transition Planning and Support) 3. Prozess: Change Management 4. Prozess: Change-Evaluierung

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

S-ITIL: IT-Infrastructure Library

S-ITIL: IT-Infrastructure Library S-ITIL: IT-Infrastructure Library ITIL bietet eine exzellente Basis zur Ausrichtung der IT an den Geschäftsanforderungen und Kunden sowie für einen effizienten und qualitativ hochwertigen IT-Betrieb. ITIL

Mehr

Das Oracle Release- und Patch- Management unter ITIL in der Praxis

Das Oracle Release- und Patch- Management unter ITIL in der Praxis Das Oracle Release- und Patch- Management unter ITIL in der Praxis Kunde: DOAG Ort: Stuttgart Datum: 03.06.2008 Reiner Wolf, Trivadis AG Reiner.Wolf@trivadis.com Basel Baden Bern Lausanne Zürich Düsseldorf

Mehr

2006-2010 Studium Wirtschaftsinformatik und E-Business an der Hochschule Ravensburg-Weingarten (Bachelor of Sciences)

2006-2010 Studium Wirtschaftsinformatik und E-Business an der Hochschule Ravensburg-Weingarten (Bachelor of Sciences) Personalprofil Thomas Scherzinger Senior Consultant E-Mail: thomas.scherzinger@arcondis.com AUSBILDUNG 2006-2010 Studium Wirtschaftsinformatik und E-Business an der Hochschule Ravensburg-Weingarten (Bachelor

Mehr

DER CONFIGURATION MANAGEMENT PROZESS

DER CONFIGURATION MANAGEMENT PROZESS Mit matrix ist IT einfach! DER CONFIGURATION MANAGEMENT PROZESS als Voraussetzung für aktuelle Daten in der CMDB Christian Stilz, Project Manager PROJEKTERGEBNISSE CMDB? PROJEKTERGEBNISSE CMDB? Daten unvollständig

Mehr

Modul 3: Service Transition

Modul 3: Service Transition Modul 3: Service Transition 1. Ziel, Wert und Aufgaben von Service Transition? 2. Prozess: Projektmanagement (Transition Planning and Support) 3. Prozess: Change Management 4. Prozess: Change-Evaluierung

Mehr

ACT Gruppe. www.actgruppe.de. Effizienz. Innovation. Sicherheit.

ACT Gruppe. www.actgruppe.de. Effizienz. Innovation. Sicherheit. www.actgruppe.de ACT Gruppe Effizienz. Innovation. Sicherheit. ACT Gruppe, Rudolf-Diesel-Straße 18, 53859 Niederkassel Telefon: +49 228 97125-0, Fax: +49 228 97125-40 E-Mail: info@actgruppe.de, Internet:

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

Mehr