Wartung von Applikationsystemen: Modelle und Erfahrungen Helmut Thoma

Größe: px
Ab Seite anzeigen:

Download "Wartung von Applikationsystemen: Modelle und Erfahrungen Helmut Thoma"

Transkript

1 Wartung von Applikationsystemen: Modelle und Erfahrungen Helmut Thoma SPIQ SW Process Improvement and Quality 2008, Freiburg i. Br.

2 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 2

3 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 3

4 IBM Global Services Method Custom Application Development Beispiel für ein Wachstumsmodell 4

5 Deployment, Solution Close Und was kommt danach? Übergabe an eine Organisation für den Betrieb des Informationssystems? Wartung des Applikationssystems? Das IT Service Management? Gemäss IT Infrastructure Library (ITIL)? Und was war davor? 5

6 Beispiel eines Informationssystems: Corporate Safety and Ecological Data (1) green phone COSED Multidiv. Werk Prod. User Prod. Owner MSDS 6 Prod. User

7 Beispiel eines Informationssystems: Corporate Safety and Ecological Data (2) Corporate Safety and Ecological Data Entwicklung Personen in IT, 3 Personen vom Benutzer ca. 4 Mio. CHF Entwicklungskosten, seit 1999 im produktiven Einsatz beim Kunden ca Benutzer weltweit im Web definiert 7

8 Beispiel eines Informationssystems: Corporate Safety and Ecological Data (3) Seit 1999 Begleitung der Produktion / Maintenance 1 Person aus Entwicklungsteam, 1 Person beim Kunden fliessender Übergang in die Unterstützung ca. 0.5 Mio., abnehmend bis ca. 0.3 Mio. p.a. fest vereinbart für Basis Support sowie kleine Änderungen & Erweiterungen pro Jahr mehrere geplante Anforderungen des Kunden für Anpassungen an Veränderungen im Einsatzgebiet oder betriebliche Umstellungen Aufgaben der operativen ITIL-Prozesse (Support-Prozesse) wie Incident Management mit Service Desk, wie Problem Management etc. auf Verrechnungsbasis mit einer Kundensupport- und Ticket-Software 8

9 ITIL V2 Prozesse Quelle: Internet commsys Informatik Gmbh, Thomas M. Genkinger 9

10 ITIL V3 - Service Life Cycle Quelle: 10

11 ITIL V3 - Service Life Cycle ITIL V3 Service Lifecycle Basis: Service Lebensphasen-Zyklus Service Design, Service Transition und Service Operation: Progressive Phasen für die Änderung, den Change und deren Umsetzung Service Strategy repräsentiert die Richtlinien und Ziele Continual Service Improvement: Kontinuierliches Lernen und Verbessern Service Strategies: Achse, um die sich der Lebenszyklus dreht. Service Design, Service Transition und Service Operation setzen die Strategie um. Continual Service Improvement hilft Verbesserungsprogramme und -Projekte auf der Basis der strategischen Ziele zu platzieren und zu priorisieren. Quelle: 11

12 ITIL V3 alle Prozesse in der Übersicht Quelle Wikipedia Autor Bernd F. Dollinger,

13 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 13

14 Service Level Management (SLM) Ein Prozess der Service Delivery Prozesse in ITIL V2 Ein Prozess der Service Design Prozesse in ITIL V3 SLM ist eigentlich die Basis für alle anderen Prozesse und steht im Anfangsstadium von Services Erfüllung der Kundenanforderungen mit preiswerten, quantifizierbaren IT-Services in vereinbarter Qualität SLM implementiert einen beständigen Zyklus von Planung, Vereinbarung und Überwachung von Service-Leistungen SLM erstellt Katalog von Services, die von der IT-Organisation erbracht werden können SLM vereinbart Service Level Agreements (SLAs) mit den Kunden und sichert diese über interne Vereinbarungen (Operational Level Agreements) und Verträge mit Lieferanten ab SLM stellt die einzige Kommunikationsschnittstelle zwischen Kunde und IT-Organisation auf taktischer Ebene dar 14

15 Situation eines Beispiels aus der Praxis zur Diskussion Service Level Management n n+1 Jahr Bestehende IT Plattform und Applikationen Migration auf neue Plattform und zu Appl. K(neu) Parallelbetrieb Appl. k und k(neu) Entwicklung der neuen Applikation k(neu) Transition-Phase Migration HW / SW, Entwickl. neues Portal Application Maintenance & Support 15

16 Aufgaben in der Transition-Phase Beispiel aus der Praxis Sicherstellung der Ressourcen bzw. des Knowhow Übergang vom Implementierungsprojekt in ein Wartungsprojekt Einführung des Service Supports (operative Wartungsprozesse) Aufsetzen der Wartungsorganisation Etablierung des Reportings Einführung des Service Delivery (strategische Wartungsprozesse) z.b. Service Level Management, Continuity Management, Capacity Management Einführung des Service Managements Übernahme von Projektpendenzen gemäss separatem Übergabeprotokoll Durchführung einer formellen Übergabe vom Implementierungsprojekt ins Wartungsprojekt 16

17 Service Overview Beispiel aus der Praxis Beschreibung des Umfangs der Services (1) Helpdesk (Single Point of Contact, SPOC) und Supportstruktur - Wer ist für SPOC verantwortlich: Applikations-Anwender (= Kunde) oder externer Service Provider? - Beschreibung der Zuständigkeiten von Kunde und Service-Provider Im Beispiel wurde folgendes vereinbart: 1st Level Support (SPOC) beim Applikations-Anwender (= Kunde) - Registrieren und Problemverfolgung (Eintrag in das zentrale Problem Management System) - Beheben von kleinen Störungen mit dem Login, Fragen zur Benutzung von Office-Systemen, zur Konfiguration etc. - Weitergabe an den 2nd Level Support (falls nötig) 17

18 Service Overview Beispiel aus der Praxis Beschreibung des Umfangs der Services (2) 2nd und 3rd Level Support beim externen Service Provider Aufgaben 2nd Level Support - Problem-Analyse, Behebung kleiner Codierungs- oder Parametrisierungs-Probleme Weiterleiten von Problemen an 3rd Level Support oder Produktion Tests von Fehlerkorrekturen des 3rd Level Supports Aufgaben 3rd Level Support 18 Bestimmung von Problem-Ursachen Koordination mit Sub-Contractors Fehler beheben oder Umgehungslösungen erstellen Tests in der Entwicklungsumgebung durchführen Lieferung des reparierten Produkts und Nachführen der Dokumentation

19 Service Overview Beispiel aus der Praxis Beschreibung des Umfangs der Services (3) Verfügbarkeiten von Mitarbeitern - 1st Level Support während 7 x 24 Stunden - 2nd und 3rd Level Support zwischen 8:00 und 17:00, Mo - Fr - Erweiterungen der Support-Level beeinflussen Aufwand und Anzahl Mitarbeiter Systems Management und Operations-Services Beschreibung des Management der Services: - Service Level Agreements - Availability Management: Koordination von Skills, Information, Verfügbarkeit von HW- / SW-Komponenten - Behandlung von Extrem-Situationen auf einer 7 x 24 Stunden-Basis - Problem Management, Change Management, Measurements & Reports 19

20 Service Overview Beispiel aus der Praxis Beschreibung des Umfangs der Services (4) Server Management inklusiv - Systems Operation (Health Checks, ) - Production Control (Kontrolle der Batch-Produktion, ) - Performance und Capacity Management Storage Management Security Management Service Modell für Application Maintenance & Support 20

21 Service Modell (des Service Provider) für Application Maintenance & Support (1) Ressourcen fest zugeordnet Major Enhancements / Neue Applikationen Minor Changes and Enhancements *) Basic Support Services *) Bis zu einem Betrag von max. xx Stunden p. a. 21 Priorität durch den Kunden festgelegt Ressourcen auf Anforderung (projektbezogen) Ressourcen Beispiel aus der Praxis Zeit

22 Service Modell (Service Provider) für Application Maintenance & Support (2) Beispiel aus der Praxis Fehlerklassen Class 1: Funktionsfehler, der weiteres Arbeiten verhindert, z. B. - Abbruch einer Routine oder täglich benötigten Funktion - Datenverlust oder Zerstörung von Daten - Abbruch eines Programms oder Modules Class 2: Programm / Module stimmt nicht mit der Spezifikation überein - entspricht nicht der bereitgestellten Spezifikation - keine Spezifikation vorhanden oder Programm arbeitet nicht gemäss den Erwartungen des Kunden - und geschätzter Aufwand zur Problembeseitigung ist kleiner als ein festgelegter, vereinbarter Aufwand 22

23 Service Modell (Service Provider) für Application Maintenance & Support (3) Beispiel aus der Praxis Fehlerklassen (2) Class 3: Programm arbeitet mit fehlerbehafteten Spezifikationen oder es sind keine Spezifikationen vorhanden - Ausnahmebedingung von Class 2 (grösserer Aufwand) Class 4: Es werden neue Spezifikation definiert 23

24 Service Modell (Service Provider) für Application Maintenance & Support (4) Beispiel aus der Praxis Drei Service-Kategorien (1) Basic Support Services - Externer Service Provider wird seine Ressourcen hauptsächlich für diese Aufgaben einsetzen, basierend auf einem vereinbarten, festen Preis p. a. - bei geringerem Aufwand als geschätzt werden die Ressourcen für Changes verwendet - laufende Arbeiten, um eine stabile und zuverlässige Basis für den Betrieb zu sichern (inkl. Monitoring, präventiver SW-Maintenance etc.) - Problemanalyse und Problem lösen oder Umgehungslösung initialisieren für die Fehlerklassen Class 1 und Class 2 - Probleme verfolgen für Fehlerklassen Class 1 bis Class 4 - Interface zum 3rd Level Support (Sub-Contractors) 24

25 Service Modell (Service Provider) für Application Maintenance & Support (5) Beispiel aus der Praxis Drei Service-Kategorien (2) Minor Changes and Enhancements - Externer Service Provider arbeitet auf vereinbarter, geplanter Basis p. a. - Zusätzliche Anforderungen werden mit Ressourcen / Skills abgedeckt, die verfügbar sind Definition von Changes : - Problemanalyse und eingeplante Fehlerkorrekturen für Fehlerklassen Class 3 und 4 - Änderungen existierender Funktionen - Bewertung von Anträgen für Änderungen und Erweiterungen - Technische Wartung und Pflege, die vereinbarten Aufwand nicht überschreitet: Zusätzliche Funktionalität, Modifikationen aufgrund neuer SW-Versionen (System- und Applikations-SW) - Design von Lösungen und Erstellen von Angeboten für Änderungs- und Erweiterungs-Anträge, die vereinbarten Umfang überschreiten 25

26 Service Modell (Service Provider) für Application Maintenance & Support (6) Beispiel aus der Praxis Drei Service-Kategorien (3) Major Enhancements / New Applications Major Enhancements: - Entwicklung neuer, Änderungen des Konzepts oder Ersetzen von Applikations-Modulen - Technische Wartung und Pflege, die den für Minor Changes and Enhancements vereinbarten Aufwand überschreitet Entwicklung neuer Applikationen: - diese Kategorie von Services deckt alle Arbeiten für den Design und Entwicklung neuer Applikationen ab Service Level Agreement - Service Levels (z. B. Reaktionszeit bei Problemen) sind während der Transition Phase der neuen Applikationen und InfrastrukturKomponenten noch zwischen Kunden und Service Provider zu vereinbaren 26

27 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 27

28 Service Level Agreements Severity und Priority Levels Severity Level eines Problems wird durch die Auswirkung bestimmt, die das betreffende Problem auf den Geschäftsbetrieb der betroffenen Gesellschaft / des Sectors hat Priority Level eines Problems wird durch die Auswirkung bestimmt, die das Problem auf die Arbeit der Benutzer einer Applikation hat 28

29 Service Level Agreements Severity Levels (1) Beispiel aus der Praxis für ein Pikett-Konzept Severity Level 1: Schwerwiegender Einfluss auf den Geschäftsbetrieb - Entscheidender Kunden-Service ist nicht verfügbar oder sehr stark beeinträchtigt - die Verpflichtungen für den Service können nicht erfüllt werden oder sind ernsthaft gefährdet - der Ausfall eines Service beeinträchtigt mehr als 500 Benutzer - die Kunden haben keine einfache Alternative, die normale Arbeit fortzuführen Severity Level 2: Bedeutender Einfluss auf den Geschäftsbetrieb - Entscheidender Kunden-Service ist durch das Problem beeinträchtigt - Verpflichtungen für den Service sind gefährdet - Schwerwiegende Leistungsverminderung oder Beeinträchtigung von mehr als 50 Benutzern durch den Ausfall eines Service - die Kunden haben keine einfache Alternative, die normale Arbeit fortzuführen 29

30 Service Level Agreements Severity Levels (2) Beispiel aus der Praxis für ein Pikett-Konzept Severity Level 3: Geringfügiger Einfluss auf den Geschäftsbetrieb - Unkritischer Kunden-Service ist nicht verfügbar - Verpflichtungen für den Service sind geringfügig beeinträchtigt - Kunden haben Schwierigkeiten, die normale Arbeit fortzuführen oder können andere Arbeiten ausführen, während das Problem behoben wird Severity Level 4: Minimaler Einfluss auf den Geschäftsbetrieb - Unkritischer Kunden-Service ist durch das Problem beeinträchtigt - Kunden werden durch das Problem belästigt - Kunden haben leicht verfügbare Alternativen zu arbeiten 30

31 Service Level Agreements Severity Levels (3) Beispiel aus der Praxis für ein Pikett-Konzept 31

32 Service Level Agreements Severity Levels - Reaktionszeiten (4) Beispiel aus der Praxis für ein Pikett-Konzept 32

33 Service Level Agreements Priority Levels Definitionen Beispiel aus der Praxis für ein Pikett-Konzept Zur Erinnerung: Problem hat Auswirkung auf die Arbeit der Benutzer einer Applikation Priority Level 1: - Endbenutzer kann mit der Workstation keine sinnvolle Arbeit erledigen und benötigt dringende Unterstützung Priority Level 2: - Die Arbeit des Endbenutzers mit der Workstation ist beeinträchtigt, aber der Endbenutzer kann mit der Workstation arbeiten Priority Level 3: - Endbenutzer erkennt und berichtet, dass ein Problem eingetreten ist, aber er ist in der Lage, weiterhin mit der Workstation zu arbeiten 33

34 Service Level Agreements Priority Levels Definitionen von Zeiten, Service Windows Beispiel aus der Praxis Zeit für die Problemlösung (Resolution Time) Reaktionszeit (Reaction Time) Problem-Ticket eröffnet Beginn Bearbeitung des Problems Wiederherstellung der Funktionalität (Umgehungslösung möglich) Service Window 1 Mo Fr, 7:00-18:00 Help Desk vorhanden Service Window 2 Mo Fr, 18:00-7:00 Sa, So, Feiertag Mo Fr, 18:00-7:00 Sa, So, Feiertag Help Desk nicht vorhanden, Pikett verfügbar Service Window 3 34 Help Desk nicht vorhanden, kein Pikett vorgesehen

35 Service Level Agreements Priority Levels Zeiten für die Problemlösung Beispiel aus der Praxis Service Window 1 Resolution Time Service Window 2 Resolution Time Service Window 3 Resolution Time Priority 1 1 Tag - Nächstes Service Window Tag Priority 2 2 Tage - Nächstes Service Window Tage Priority 3 Wird von Fall zu Fall mit dem Kunden vereinbart - Wird von Fall zu Fall mit dem Kunden vereinbart 35

36 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 36

37 Reporting Auszüge aus einem Monats-Report der Praxis 37

38 Reporting Auszüge aus einem Monats-Report der Praxis 38

39 Reporting Auszüge aus einem Monats-Report der Praxis 39

40 Reporting Auszüge aus einem Monats-Report der Praxis 40

41 Reporting Auszüge aus einem Monats-Report der Praxis 41

42 Reporting Auszüge aus einem Monats-Report der Praxis 42

43 Reporting Auszüge aus einem Monats-Report der Praxis 43

44 Reporting Auszüge aus einem Monats-Report der Praxis 44

45 Reporting Auszüge aus einem Monats-Report der Praxis 45

46 Reporting Auszüge aus einem Monats-Report der Praxis 46

47 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 47

48 Zur Erinnerung: Service Support Prozesse von ITIL V2 Incident Management und Service Desk - Minimierung der Auswirkungen von Störungen (oder Anfragen nach einer Dienstleistung) auf Geschäftsprozesse - durch Wiederherstellung beeinträchtigter IT-Services innerhalb eines vereinbarten Zeitraums und in definierter Qualität - kann auch eine Umgehungslösung sein, die sehr schnell zum Erfolg führt - Schaffen einer hohen Anwenderzufriedenheit - in den Beispielen besprochen Problem Management - Langfristige Stabilisierung der IT-Infrastruktur und IT-Servicefähigkeit - durch nachhaltige Beseitigung der Ursachen von Störungen an den zu erbringenden IT-Services - in den Beispielen besprochen 48

49 Zur Erinnerung: Service Support Prozesse von ITIL V2 Configuration Management - Bereitstellung aktueller und vollständiger Informationen über die IT-Infrastruktur für den IT-Service - Configuration Management Data Base (CMDB) für alle Configuration Items, die am IT Service Management beteiligt sind - Hardware, Software, Netzwerk, Dokumentation, ServiceInformationen, Notfallplan, Verfahrensanweisungen, - Aufbau einer CMDB ist sehr viel Arbeit, deshalb bei den wichtigsten Services beginnen (z.b. Mail-Service) 49

50 Zur Erinnerung: Service Support Prozesse von ITIL V2 Change Management (CM) - wichtiger Prozess zur Qualitätssicherung - Sicherstellen, dass Änderungen am IT-Betrieb effizient und mit möglichst geringen negativen Auswirkungen auf die Qualität des Service umgesetzt werden - Change Management wird immer durch einen Request for Change (RFC) initiiert: RFC ist Änderungsantrag für Configuration Items - Auswirkungen von Changes in Kategorien eingeteilt: - Kategorie 0 pre-authorized Changes; genau beschriebene und immer wiederkehrende Changes, ohne Durchlauf des CM (ca. 80%) - Kategorie 1 geringfügig (minor); Change Manager kann selbst den Change autorisieren - Kategorie 2 beträchtlich (significant) - Kategorie 3 gravierend (major) - Change Management gilt als ineffizient, wenn nicht 90% der Changes in Kategorie 0 oder 1 liegen - Kategorien 2 und 3 sollten durch Change Advisory Board (CAB) für das Change Management beraten und empfohlen werden 50

51 Zur Erinnerung: Service Support Prozesse von ITIL V2 Release Management - Schutz der Produktivumgebung durch Einsatz funktional korrekter und zuverlässiger Hard-und Softwarekomponenten - definiert verbindliche Richtlinien für die eingesetzte Hard- und Software (Release Policy); - pflegt Definitive Software Library und Definitive Hardware Store - Release-Planung, Release-Freigabe, Rollout-Planung, - Configuration, Change und Release Management sollten idealerweise in derselben Verantwortung liegen Configuration, Change und Release Management sind auch in den Process Areas von CMMI für die Systementwicklung beschrieben - Category Support: Configuration Management etc. - Category Engineering - Category Project Management 51

52 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 52

53 Wartungsfreundliche Konstrukte von SoftwareEntwicklungs-Prozessen Kein Wasserfallmodell Iterationen sollten möglich sein dies gilt auch für Requirements notwendige Unterscheidung von Requirements Development und Requirements Management intensive Zusammenarbeit von Applikationsbenutzern mit Entwicklern der Applikationen wirkungsvolles Engineering durch fachkundiges Projektmanagement unterstützt Die Entwicklung umfangreicher neuer Releases ist wie die Entwicklung neuer Applikationen zu behandeln organisationsweites Arbeiten mit geeigneten Prozess-Frameworks unterstützen neutrale Reviews sollen ab einer definierten Projektgrösse die Qualität der Projekt-Ergebnisse sichern Configuration Management auch bei der Entwicklung der Applikationen 53

54 Spiralmodell Quelle: Prof. M. Glinz 54

55 Rational Unified Process Beispiel für ein Spiralmodell 55

56 Extreme Programming XP - one of several lightweight methodologies Agile Software Development Methods Weitere Informationen: 56

57 Wachstumsmodelle Quelle: Prof. M. Glinz 57

58 Application Maintenance & Support Weiterentwicklung der Infrastruktur und Applikation Ressourcen mit neuen Releases über mehrere Jahre Rel. (X+1).2 Rel. X.2 Major Enhancements / Neue Releases Rel. (X+2).1 Rel. (X+1).1 Rel. X.1 Minor Changes and Enhancements Rel. (X+2).1 Basic Support Services n n+1 n+2 n+3 Jahre Oder ist das die Entwicklung neuer Applikationen? 58

59 en t l e ck en i tw on n e ati l sa plik i a pr Ap p -A s s e I M g ro M C hr s a r se d ür s fü f te ase k oje ele r e P ue R l l A ne

60 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 60

61 Bedeutung von CMMI für die Wartung von Applikationssystemen Software Engineering Institute Capability Maturity Model Integration The Software Engineering Institute (SEI) is a federally funded research and development center at the Carnegie Mellon University, Pittsburgh 61

62 Bedeutung von CMMI für die Wartung von Applikationssystemen Process Areas von CMMI, die bei der Wartung von Applikationssystemen für die Entwicklung von Releases bedeutend sind CATEGORY PROCESS MANAGEMENT PROCESS AREA Organizational Process Focus (OPF) CATEGORY PROJECT MANAGEMENT Organizational Process Definition (OPD) Risk Management (RSKM) Quantitative Project Management (QPM) Organizational Innovation and Deployment (OID) ENGINEERING Requirements Management (REQM) Project Monitoring and Control (PMC) Integrated Project Management (IPM) Organizational Process Performance (OPP) PROCESS AREA Project Planning (PP) Supplier Agreement Management (SAM) Organizational Training (OT) CATEGORY PROCESS AREA CATEGORY SUPPORT PROCESS AREA Configuration Management (CM) Requirements Development (RD) Process and Product Quality Assurance (PPQA) Technical Solution (TS) Measurement and Analysis (MA) Product Integration (PI) Decision Analysis and Resolution (DAR) Verification (VER) Causal Analysis and Resolution (CAR) Validation (VAL) CMMI-SW, V1.1 62

63 Bedeutung von CMMI für die Wartung von Applikationssystemen CMMI staged representation - The CMMI Maturity Levels Maturity Level 2 CATEGORY PROCESS MANAGEMENT Maturity Level 3 PROCESS AREA Organizational Process Focus (OPF) Maturity Level 4 CATEGORY PROJECT MANAGEMENT Organizational Process Definition (OPD) Requirements Management (REQM) Project Monitoring and Control (PMC) Risk Management (RSKM) Quantitative Project Management (QPM) Organizational Innovation and Deployment (OID) ENGINEERING Project Planning (PP) Integrated Project Management (IPM) Organizational Process Performance (OPP) PROCESS AREA PROCESS AREA Supplier Agreement Management (SAM) Organizational Training (OT) CATEGORY Maturity Level 5 CATEGORY SUPPORT PROCESS AREA Configuration Management (CM) Requirements Development (RD) Process and Product Quality Assurance (PPQA) Technical Solution (TS) Measurement and Analysis (MA) Product Integration (PI) Decision Analysis and Resolution (DAR) Verification (VER) Causal Analysis and Resolution (CAR) Validation (VAL) CMMI-SW, V1.1 63

64 Bedeutung von CMMI für die Wartung von Applikationssystemen CMMI Categories of Process Areas Proj. Mgmt. Project Mgmt. 64 Engineering Process Mgmt. Support

65 Bedeutung von CMMI für die Wartung von Applikationssystemen Project Management Process Areas 65 Project Planning Risk Mgmt. Project Monitoring and Control Integrated Project Mgmt. Supplier Agreement Mgmt. Quantitative Project Mgmt.

66 Bedeutung von CMMI für die Wartung von Applikationssystemen CMMI Categories of Process Areas Engineering Project Mgmt. 66 Engineering Process Mgmt. Support

67 Bedeutung von CMMI für die Wartung von Applikationssystemen Building the right product Engineering Process Areas Validation Building the product right: peer reviews and tests Product Integration Design Technical Solution Requirements Mgmt. 67 Verification Requirements Development Integration of components and delivery From customer needs to system and component requirements

68 Bedeutung von CMMI für die Wartung von Applikationssystemen Requirements Development SG 1 Develop Customer Requirements SP 1.1 Elicit Needs SP 1.2 Develop the Customer Requirements SG 2 Develop Product Requirements SP 2.1 Establish Product and Product-Component Requirements SP 2.2 Allocate Product-Component Requirements SP 2.3 Identify Interface Requirements SG 3 Analyze and Validate Requirements SP 3.1 Establish Operational Concepts and Scenarios SP 3.2 Establish a Definition of Required Functionality SP 3.3 Analyze Requirements SP 3.4 Analyze Requirements to Achieve Balance SP 3.5 Validate Requirements with Comprehensive Methods 68

69 Bedeutung von Systems Engineering & Architecture für die Wartung von Applikationssystemen Stakeholder Requirements Define Concept / Context Diagram Use Case Scenarios Input / Output Requirements Qual. Funct. Deploym. System Objectives / Non-Functional Requ. System Requirements 69

70 Bedeutung von CMMI für die Wartung von Applikationssystemen Requirements Management SG 1 Manage Requirements SP 1.1 Obtain an Understanding of Requirements SP 1.2 Obtain Commitment to Requirements SP 1.3 Manage Requirements Changes SP 1.4 Maintain Bidirectional Traceability of Requirements SP 1.5 Identify Inconsistencies between Project Work and Requirements 70

71 Bedeutung von CMMI für die Wartung von Applikationssystemen RTVM (extract) Requirements Traceability/Verification Matrix - <Project> Requirements Traceability Matrix Customer R1 System. Requirements Verification Matrix FVT. Test Method. Affected Elements Design Documents Requirements Build Components This is a customer requirement S1 S1.1 This is a System requirement Test Type / Test Method Component C1.1 C1.2 R2 S2 S2.1 C This is a component requirement Customer Acceptance Criteria.

72 Full Lifecycle Testing Concepts Master Test Plan The Testing Process Operability testing Plan for the tests User acceptance testing Prepare for tests Systems integration testing Execute the tests Report the results System testing Integration testing Unit testing 72 Quelle: IBM Full Lifecycle Testing Concepts

73 Bedeutung von CMMI für die Wartung von Applikationssystemen CMMI Categories of Process Areas Support Project Mgmt. 73 Engineering Process Mgmt. Support

74 Bedeutung von CMMI für die Wartung von Applikationssystemen Configuration Management SG 1 Establish Baselines SP 1.1 Identify Configuration Items SP 1.2 Establish a Configuration Management System SP 1.3 Create or Release Baselines SG 2 Track and Control Changes SP 2.1 Track Change Requests SP 2.2 Control Configuration Items SG 3 Establish Integrity SP 3.1 Establish Configuration Management Records SP 3.2 Perform Configuration Audits 74

75 Bedeutung von CMMI für die Wartung von Applikationssystemen CMMI Categories of Process Areas Proc. Mgmt. Project Mgmt. 75 Engineering Process Mgmt. Support

76 Bedeutung von CMMI für die Wartung von Applikationssystemen More or less the organizational culture before CMMI ML 5 We have experience and we know our We have experience customer and we know our We have experience customer and we know our We have experience customer and we know our We have experience customer and we know our customer 76

77 Projektmanagement und Engineering Process Areas erschweren derartige Verhältnisse Quelle: Universität Zürich 77

78 Bedeutung von CMMI für die Wartung von Applikationssystemen Target Organizational Culture We have experience and we know our We have experience customer and we know our We have experience customer and we know our We have experience customer and we know our We have experience customer and we know our customer Goals Independence from individual heroes Predictability Productivity Knowledge We share our experience and improve our processes 78

79 CMMI ist nur ein Framework 79 CMMI muss ergänzt werden durch ein SWEntwicklungs-Prozessmodell Es sind gegebenenfalls weitere Hilfen (ArbeitsLayouts etc.) und Anweisungen einzuführen, die von den Mitarbeitern der betreffenden Entwicklungsorganisation zu benutzen sind

80 Bedeutung von CMMI für die Wartung von Applikationssystemen Mapping process to show evidence of the CMMI conformity for the appraisal projects via organizational process assets Standard CMMI Model What to do Organization Organizational Process Assets How to do Tailoring to projects needs Project Project activities and work products 80 Do it!

81 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 81

82 Systems Engineering and Architecture Systems Engineering is the: "...translation of a need/deficiency into a system architecture through the iterative process of functional analysis, allocation, implementation, optimization, test, and evaluation;...incorporation of all technical parameters to assure compatibility between physical & functional interfaces, hardware & software interfaces, in a manner that optimizes system definition and design; and...integration of performance, manufacturing, reliability, maintainability, supportability, global flexibility, scaleability, upgradeability and other specialties into the overall engineering effort" Capability Maturity Model Integrated (CMMI) Stevens Institute of Technology IBM Global Services 2001 IBM Corporation 82 System Engineering and Architecture Process Release /06/ IBM Corporation

83 Systems Engineering and Architecture Important Steps / Roles of the SE&A Process SE&A project initiation System Engineering Management Plan (SEMP): Defines the process the Systems Engineering team will follow for the project Work Breakdown Structure (WBS): Defines projects SE&A deliverables and SE&A reviews Systems Engineering Board SE Board members are required for SE&A reviews Ensure that projects are following the SE&A process Systems Engineer Conducts Systems Engineering Reviews (SRR, PDR, CDR) Updates Scorecards in review template 83 System Engineering and Architecture Process Release /06/ IBM Corporation

84 Systems Engineering and Architecture Important Deliverables of the SE&A Process Business Requirements Specifications (optional) Business Requirements Review System Requirements Specifications System Requirements Review Component / Application Requirements Specification Preliminary Design Review Component Design, Component Test Plan Critical Design Review All reviews led by the Systems Engineer Test Readiness Review led by the Test Team Production Readiness Review led by the Project Manager SE&A Scorecards for all reviews 84 System Engineering and Architecture Process Release /06/ IBM Corporation

85 Systems Engineering and Architecture The IBM AMS Systems Engineering Process defines deliverables and a series of Reviews (Part I) Conceptual System Specification Need / Opportunity Identification Customer Baseline System Baseline Systems Req me nt Specs RTVM Customer Provided 85 System Level Architec t. Componen t Req ment Specs Componen t Level Architectu re Design Baseline Preliminary Design Review (PDR) Critical Design Review CDR) Compone nt RTVM Test Architectu re Systems Engineering Provided WMA INCOSE Presentation Detailed Design Architecture/Component Baseline Systems Requirements Review (SRR) Business Requirements Review (BRR) Business Require. Specs. Component Architecture Compone Compone nt nt Test Design Plan Component Developer Provided 2003 IBM Corporation

86 Systems Engineering and Architecture The IBM AMS Systems Engineering Process defines deliverables and a series of Reviews (Part II) Detail Design Development Design Baseline Test and Production System Update Test Baseline System Test Strategy Comp. Design Comp. Test Plan Production Baseline Test Readiness Review (TRR) CDR System Test Data System Test Plan / Test Test Cases Traceabili ty Matrix. New Production System Releas e Conten t Move to Prod. Plan Production Readiness Review (PRR) Deployme nt Plan Data Migration Plan Customer Component Developer Provided Systems Engineering Provided Provided Service Delivery / Managed Ops Provided System Test Provided 86 WMA INCOSE Presentation 2003 IBM Corporation

87 Bedeutung von Systems Engineering & Architecture für die Wartung von Applikationssystemen Stakeholder Requirements Define Concept / Context Diagram Use Case Scenarios Input / Output Requirements Quality Funct. Deployment System Objectives / Non-Functional Requ. System Requirements 87

88 Bedeutung von Systems Engineering & Architecture für die Wartung von Applikationssystemen System Requirements Stakeholder Requirements Quelle: 88

89 Bedeutung von Systems Engineering & Architecture für die Wartung von Applikationssystemen Requirements Traceability and Verification Matrix Provide tracability of customer and system requirements through the life cycle P Provide a verification matrix that shows how each requirement will be tested when each requirement will be tested the test acceptance criteria for each requirement 89

90 Bedeutung von CMMI für die Wartung von Applikationssystemen RTVM (extract) Requirements Traceability/Verification Matrix - <Project> Requirements Traceability Matrix Customer R1 System. Requirements Verification Matrix FVT. Test Method. Affected Elements Design Documents Requirements Build Components This is a customer requirement S1 S1.1 This is a System requirement Test Type / Test Method Component C1.1 C1.2 R2 S2 S2.1 C This is a component requirement Customer Acceptance Criteria.

91 Bedeutung von Systems Engineering & Architecture für die Wartung von Applikationssystemen Stakeholder / System Requirements (Examples) Maximal flexibility and extendability for structured sports data Structured database for sports data should be dynamically extendable for new kinds of sports Multi-dimensional data base structures Online data input from integrated sporting grounds, with autom. generated output for TV Teletext and SMS Automatically generated output, released via ready-tosend button, program controlled (TV Teletext, SMS) Delay time after ready-to-send 3 sec 91

92 Bedeutung von Systems Engineering & Architecture für die Wartung von Applikationssystemen Formal Review Objectives (TRR, PRR) Test Readiness Review - TRR Establish the test baseline Verify Test plans against system requirements Verify that test entrance criteria has been met Verify the test readiness and the environment Review and approve test types and test methods Review test plan risks and mitigation plans Production Readiness Review - PRR Establish production baseline Review test results and release content Review move-to-production plans and readiness 92

93 Bedeutung von Systems Engineering & Architecture für die Wartung von Applikationssystemen Areas to be evaluated in Scorecards for TRR and PRR Test Readiness Review (TRR) Test Strategy Test Requirements Verification Matrix Application Readiness Verification (Test Entrance Criteria Met) Test Environment Readiness Verification (Includes Test Data) Test Team Readiness Verification Production Readiness Review (PRR) Release Content Test Results Expected Availability / Performance / Response Times Move to Production Plan Data Migration Plan Deployment Plan 93

94 Agenda Einführung Beispiel zum Service Level Management Service Level Agreements: Severity und Priority Levels Reporting: Auszüge aus einem Monats-Report der Praxis Zur Erinnerung: Service Support Prozesse von ITIL V2 Bedeutung von Software-Entwicklungs-Prozessen für die Wartung Bedeutung von System-Entwicklungs-Standards für die Wartung Bedeutung von formalen Reviews für die Wartung Schlussbemerkung 94

95 Schlussbemerkung Organisationen für die Applikationsentwicklung sollten daran denken, dass Wartung ein Teil des Lebens ihrer Applikation ist und sie die Wartung beeinflussen dass die Beschreibung von Requirements, Design, Strukturierung, Tests, wartungsfreundlich und die Dokumentation nachvollziehbar und die Wartung unterstützend sein sollten dass Applikationen auch eines Tages abgelöst werden: Keine komplizierten und schlecht dokumentierten Abhängigkeiten Organisationen für die Wartung von Systemen sollten sich auch mit Standards und Prozessen für die Entwicklung von Systemen befassen Wartung kann bald einmal in eine Entwicklungsaufgabe münden 95

96 Versionen, die der Diskussion hier zugrunde liegen ITIL Version 2 CMMI Release 1.1 SE & A Release

97 Helmut Thoma Software Engineering & IT-Consulting Helmut Thoma Selbständiger SW-Ingenieur Dittingerstr. 17 Postfach 255 CH-4008 Basel Tel./Fax Mobile Lehre als Elektroniker (Abschluss 1964) Studium der Nachrichtentechnik, FH Karlsruhe (Abschluss 1967) Studium der Informatik, Universität Karlsruhe (Abschluss 1977)

ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006

ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006 ITIL meets CMMI: Optimierung der IT-Prozesse durch das Zusammenspiel von ITIL und CMMI SQM 2006 Dr. Ralf Kneuper Dr. Ralf Kneuper Beratung Jan Stender ITIL Berater Überblick Motivation Überblick CMMI Überblick

Mehr

Requirements Engineering in Prozessmodellen CMMI, V-Modell XT und andere

Requirements Engineering in Prozessmodellen CMMI, V-Modell XT und andere Engineering in Prozessmodellen CMMI, V-Modell XT und andere Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 2012-03-07 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD

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

Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007

Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007 Vorgehensmodelle und Reifegradmodelle Ergänzung oder Konkurrenz? Dr. Ralf Kneuper 27.09.2007 2007-09-27 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD Computing Science, Univ. of Manchester 1989-1995:

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

Mehr

Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ)

Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ) Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ) Dr. Ralf Kneuper GI-Workshop Vorgehensmodelle 2009 2009-04-09 1 Ralf Kneuper Dipl.-Mathematiker,

Mehr

Werkzeug-gestützte Nachverfolgbarkeit von Anforderungen nach CMMI

Werkzeug-gestützte Nachverfolgbarkeit von Anforderungen nach CMMI IBM Software Group Werkzeug-gestützte Nachverfolgbarkeit von Anforderungen nach CMMI Hubert Biskup, IBM, IT-Specialist Ralf Kneuper, Berater und SEI-autorisierter CMMI Lead Appraiser Agenda IBM Software

Mehr

AnyWeb AG 2008 www.anyweb.ch

AnyWeb AG 2008 www.anyweb.ch Agenda - BTO IT heute Was nützt IT dem Business? Die Lösung: HP Software BTO Q&A IT heute Kommunikation zum Business funktioniert schlecht IT denkt und arbeitet in Silos und ist auch so organisiert Kaum

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

CMMI for Embedded Systems Development

CMMI for Embedded Systems Development CMMI for Embedded Systems Development O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software Engineering Gruppe Leiter des Fachbereichs Informatik cs.uni-salzburg.at Inhalt Projekt-Kontext CMMI FIT-IT-Projekt

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

CMMI und Verwandte ein Überblick Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung

CMMI und Verwandte ein Überblick Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung CMMI und Verwandte ein Überblick Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 2012-03-21 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD Computer Science, Univ. of

Mehr

SPiCE und Test: Was hat das denn miteinander zu tun?

SPiCE und Test: Was hat das denn miteinander zu tun? SPiCE und Test: Was hat das denn miteinander zu tun? TAV Düsseldorf 15./16.2.2007 Arbeitskreis Test eingebetteter Systeme Dr. Uwe Hehn Uwe.Hehn@methodpark.de Gliederung Reifegradmodelle Übersicht über

Mehr

Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung. FHH meets economy 2008-01-17

Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung. FHH meets economy 2008-01-17 ITIL meets CMMI Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 1 Überblick Motivation Überblick CMMI CMMI und ITIL im Lebenszyklus einer Anwendung Best Practices Zusammenfassung

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

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

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

ITIL Foundation Prüfung

ITIL Foundation Prüfung ITIL Foundation Prüfung Musterprüfung A, Version 5.1 Multiple Choice Anweisungen 1. Alle 40 Fragen sollten beantwortet werden. 2. Alle Antworten müssen in einer echten Prüfungssituation auf dem beiliegenden

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

ISO/IEC 20000 & ITIL Unterschiede im Fokus gemeinsame Zukunft? Markus Schiemer, ISO 20000 Auditor, CIS Wien

ISO/IEC 20000 & ITIL Unterschiede im Fokus gemeinsame Zukunft? Markus Schiemer, ISO 20000 Auditor, CIS Wien ISO/IEC 20000 & ITIL Unterschiede im Fokus gemeinsame Zukunft? Markus Schiemer, ISO 20000 Auditor, CIS Wien Der heilige Gral des Service Management Was ist ein Standard? Was ist Best / Good Practice? Standard

Mehr

IT-Service Management

IT-Service Management IT-Service Management Der IT-Service wird im IT-Haus erbracht Dipl. Ing. Dr.Dr. Manfred Stallinger, MBA manfred.stallinger@calpana.com calpana business consulting gmbh Das IT-Haus ein Service-Punkt mit

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

Service Strategie und Sourcing Governance als Werkzeuge zur Durchsetzung der Sourcing Ziele auf Kundenseite

Service Strategie und Sourcing Governance als Werkzeuge zur Durchsetzung der Sourcing Ziele auf Kundenseite 1 itsmf Deutschland e.v. Service Strategie und Sourcing Governance als Werkzeuge zur Durchsetzung der Sourcing Ziele auf Kundenseite Ben Martin, Glenfis AG Zürich 26.09.2012 Service Strategie und Sourcing

Mehr

SERVICE SUPPORT nach ITIL

SERVICE SUPPORT nach ITIL SERVICE SUPPORT nach ITIL Seminar: Professor: Student: Aktuelle Themen der Informatik Prof. Dr. Friedbert Kaspar Koblavi Adjamah, CN7 1. Einleitung... 3 2. Service Desk... 4 3. Incident Management... 5

Mehr

Capability Maturity Model Integration (CMMI) aus Sicht des IT-Servicemanagements

Capability Maturity Model Integration (CMMI) aus Sicht des IT-Servicemanagements Capability Maturity Model Integration (CMMI) aus Sicht des IT-Servicemanagements Dr. Ralf Kneuper Beratung für Softwarequalitätsmanagement und Prozessverbesserung 1 Agenda CMMI: Capability Maturity Model

Mehr

ITIL-V3 Neu, oder alter Wein in neuen Schläuchen. Peter Lehmann - Freier Berater -

ITIL-V3 Neu, oder alter Wein in neuen Schläuchen. Peter Lehmann - Freier Berater - ITIL-V3 Neu, oder alter Wein in neuen Schläuchen Peter Lehmann - Freier Berater - IT Es ist sinnlos zu sagen: Wir tun unser Bestes. Es muss dir gelingen, das zu tun, was erforderlich ist Winston Churchill

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

Christian Lotz, Dipl.-Inform. Med. certified IT Service Manager (ITIL) & ISO 20000 Consultant. 13. Januar 2011

Christian Lotz, Dipl.-Inform. Med. certified IT Service Manager (ITIL) & ISO 20000 Consultant. 13. Januar 2011 ITIL V3 zwischen Anspruch und Realität Christian Lotz, Dipl.-Inform. Med. certified IT Service Manager (ITIL) & ISO 20000 Consultant 13. Januar 2011 IT Service Management ISO 20000, ITIL, Process Modelling,

Mehr

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen.

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. Stefan Topp Honeywell International SARL 16. Februar 2012 Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. 1 Agenda Hintergruende Der Auswahlprozess Ausrollen von

Mehr

CMMI im Kontext von Agilität

CMMI im Kontext von Agilität CMMI im Kontext von Agilität PMA, 10.05.2012, Zug by mimacom ag Zur Person David Krebs COO, Mitglied der Geschäftsleitung mimacom ag Software Engineer EMBA GM 10.05.2012 2 mimacom ag facts and figures

Mehr

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

Befähigen Beherrschen Bestätigen

Befähigen Beherrschen Bestätigen ISO 20000-1:2011 Befähigen Beherrschen Bestätigen ISO/IEC 20000-1:2011 - Der Standard für IT Service Management ISO/IEC 20000-1:2011 ist ein Service Management System (SMS) Standard. Er spezifiziert die

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

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

Empfehlungen von ITIL zu ITSM Einführung. Jacqueline Batt, 12. Juni 2012

Empfehlungen von ITIL zu ITSM Einführung. Jacqueline Batt, 12. Juni 2012 Empfehlungen von ITIL zu ITSM Einführung Jacqueline Batt, 12. Juni 2012 Wo ist das WIE in ITIL?! Service Strategy! Service Design! Service Transition! Service Operation! C. Service Improvement Kapitel

Mehr

Wie agil kann Business Analyse sein?

Wie agil kann Business Analyse sein? Wie agil kann Business Analyse sein? Chapter Meeting Michael Leber 2012-01-24 ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

ITIL V3 - Security Management

ITIL V3 - Security Management ITIL V3 - Security Management Richard Friedl richard.friedl@itsm-partner.com ITIL is a Registered Trade Mark, and Registered Community Trade Mark of the Office of Government Commerce, and is Registered

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

CMMI - Unterschiede und Gemeinsamkeiten zu CMM. 10/16/03 CMMI - Unterschiede und Gemeinsamkeiten zu CMM

CMMI - Unterschiede und Gemeinsamkeiten zu CMM. 10/16/03 CMMI - Unterschiede und Gemeinsamkeiten zu CMM CMMI - Unterschiede und Gemeinsamkeiten zu CMM Universität Tübingen Arbeitsbereich: Informatik und Gesellschaft Thomas Grosser email: tgrosser@informatik.uni-tuebingen.de im Juli 2003 1 Gliederung Einleitung,

Mehr

Cloud Architektur Workshop

Cloud Architektur Workshop Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell

Mehr

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box?

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? 04. November 2008 ITC GmbH 2008 Agenda Was bringt der HP Service Manager 7? Überblick SM7 Module Neue / zusätzliche

Mehr

Requirements-Engineering Requirements-Engineering

Requirements-Engineering Requirements-Engineering -Engineering Copyright Chr. Schaffer, Fachhochschule Hagenberg, MTD 1 Was ist ein Requirement? IEEE-Standard (IEEE-726 83) A condition or capability needed by a user to solve a problem or achieve an objective.

Mehr

TFS als ALM Software. Erfahrungsbericht aus der MedTec Ecke. Lukas Müller

TFS als ALM Software. Erfahrungsbericht aus der MedTec Ecke. Lukas Müller TFS als ALM Software Erfahrungsbericht aus der MedTec Ecke Lukas Müller Agenda Tecan Umfeld und Prozesse Einsatzgebiet TFS Tecan Erweiterungen von TFS Erfahrungsaustausch Head Office in der Schweiz, >1100

Mehr

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Martin Glinz, Samuel Fricker Software-Qualität Ausgewählte Kapitel Kapitel 7 Prozessqualität 2007-2010 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Modul 3: Service Transition Teil 4

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

Mehr

Process Management Office Process Management as a Service

Process Management Office Process Management as a Service Process Management Office Process Management as a Service Unsere Kunden bringen ihre Prozesse mit Hilfe von ProcMO so zur Wirkung, dass ihre IT- Services die Business-Anforderungen schnell, qualitativ

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

Titelbild1 ANSYS. Customer Portal LogIn

Titelbild1 ANSYS. Customer Portal LogIn Titelbild1 ANSYS Customer Portal LogIn 1 Neuanmeldung Neuanmeldung: Bitte Not yet a member anklicken Adressen-Check Adressdaten eintragen Customer No. ist hier bereits erforderlich HERE - Button Hier nochmal

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

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

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Institut für Informatik! Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 7 Prozessqualität" 2007-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen,

Mehr

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis Der Vortrag zeigt anhand von Fallbeispielen auf, wie sich SOA durch die Kombination

Mehr

Projektrisikomanagement im Corporate Risk Management

Projektrisikomanagement im Corporate Risk Management VERTRAULICH Projektrisikomanagement im Corporate Risk Management Stefan Friesenecker 24. März 2009 Inhaltsverzeichnis Risikokategorien Projekt-Klassifizierung Gestaltungsdimensionen des Projektrisikomanagementes

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

Mehr

CMMI for Services V 1.2 (CMMI-SVC) Überblick

CMMI for Services V 1.2 (CMMI-SVC) Überblick CMMI for Services V 1.2 (CMMI-SVC) Überblick Prof. Dr. Urs Andelfinger Hochschule Darmstadt, FB Informatik Was Sie heute mitnehmen können Was ist CMMI for Services (CMMI-SVC) und was nutzt es? Was unterscheidet

Mehr

A central repository for gridded data in the MeteoSwiss Data Warehouse

A central repository for gridded data in the MeteoSwiss Data Warehouse A central repository for gridded data in the MeteoSwiss Data Warehouse, Zürich M2: Data Rescue management, quality and homogenization September 16th, 2010 Data Coordination, MeteoSwiss 1 Agenda Short introduction

Mehr

ITIL V3 Basis-Zertifizierung

ITIL V3 Basis-Zertifizierung Nadin Ebel ITIL V3 Basis-Zertifizierung Grundlagenwissen und Zertifizierungsvorbereitung für die ITIL Foundation-Prüfung ^- ADDISON-WESLEY An imprint of Pearson Education München Boston San Francisco Harlow,

Mehr

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20.

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. Februar 2008 Presenter: Neno Loje, MVP für Team System www.teamsystempro.de

Mehr

TOGAF The Open Group Architecture Framework

TOGAF The Open Group Architecture Framework TOGAF The Open Group Architecture Ein Überblick Gesellschaft für Informatik, Regionalgruppe München Dr. Michael Bulenda München, 7.12.2009 Vorstellung Dr. M. Bulenda Seit 2001 bei Cirquent IT Management

Mehr

BPM Solution Day 2010 T-Systems Multimedia Solutions GmbH 28.09.2010 1

BPM Solution Day 2010 T-Systems Multimedia Solutions GmbH 28.09.2010 1 T-Systems Multimedia Solutions GmbH 28.09.2010 1 Qualitätssteigerung im Servicemanagement durch Verbesserung der IT-Prozesse der Bundesagentur für Arbeit durch optimiertes IT-Servicemanagement. T-Systems

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

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

Service Orientierung organisiertes IT Service Management in der BWI IT auf Basis ITIL

Service Orientierung organisiertes IT Service Management in der BWI IT auf Basis ITIL Orientierung organisiertes IT Management in der BWI IT auf Basis ITIL 97. AFCEA-Fachveranstaltung Diensteorientierung aber mit Management Heiko Maneth, BWI IT Delivery, Leitung Prozessarchitektur und -management

Mehr

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008 Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE Heinrich Dreier Elmshorn 17.04.2008 Einleitung Softwareprozesse verbessern Einleitung Softwareprozesse verbessern SPI Software

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

1 von 119 Eine Einführung in das Project Management/1 Einführung/Seiten/Startseite

1 von 119 Eine Einführung in das Project Management/1 Einführung/Seiten/Startseite 1 von 119 Eine Einführung in das Project Management/1 Einführung/Seiten/Startseite 2 von 119 Eine Einführung in das Project Management/1 Einführung/Seiten/Einführung 3 von 119 Eine Einführung in das Project

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

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

Service Design. Dirk Hemmerden - Appseleration GmbH. Mittwoch, 18. September 13

Service Design. Dirk Hemmerden - Appseleration GmbH. Mittwoch, 18. September 13 Service Design Dirk Hemmerden - Appseleration GmbH An increasing number of customers is tied in a mobile eco-system Hardware Advertising Software Devices Operating System Apps and App Stores Payment and

Mehr

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master,

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master, TFS Customzing in der Praxis Thomas Gugler ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com Thomas Gugler seit 2005 bei

Mehr

AnyWeb AG 2006 www.anyweb.ch

AnyWeb AG 2006 www.anyweb.ch AnyWeb AG 2006 www.anyweb.ch ITSM PracticeCircle September 2007 IT Service LifeCycle Management nach ITIL Version 3 Tom Waldis AnyWeb AG 2006 www.anyweb.ch ITIL V3: The Big Picture ITIL V2 V3 from 9 to

Mehr

Integriertes Service Management

Integriertes Service Management Servicebestellung bis zur Abrechnung PPPvorlage_sxUKMvo-05.00.potx santix AG Mies-van-der-Rohe-Straße 4 80807 München www.santix.de santix AG Themen Ziel-Workflow Service Catalog Change Configuration und

Mehr

Product Lifecycle Manager

Product Lifecycle Manager Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM is powerful, economical and based on standard technologies. Directory

Mehr

Managed Infrastructure Service (MIS) Schweiz

Managed Infrastructure Service (MIS) Schweiz Pascal Wolf Manager of MIS & BCRS Managed Infrastructure Service (MIS) Schweiz 2011 Corporation Ein lokaler Partner in einem global integrierten Netzwerk Gründung im Jahr 2002 mit dem ersten full-outtasking

Mehr

Inhaltsverzeichnis. Christian Wischki, Lutz Fröhlich. ITIL & ISO/IEC 20000 für Oracle Datenbanken. Praxisleitfaden für die Einführung und den Betrieb

Inhaltsverzeichnis. Christian Wischki, Lutz Fröhlich. ITIL & ISO/IEC 20000 für Oracle Datenbanken. Praxisleitfaden für die Einführung und den Betrieb sverzeichnis Christian Wischki, Lutz Fröhlich ITIL & ISO/IEC 20000 für Oracle Datenbanken Praxisleitfaden für die Einführung und den Betrieb ISBN: 978-3-446-41978-0 Weitere Informationen oder Bestellungen

Mehr

Company Presentation

Company Presentation Glenfis AG Company Presentation IT Service Management Vom Kennen. Zum Können. Zum Tun. Mit Glenfis vom Kennen, zum Können, zum Tun. Als unabhängiger Berater und akkreditiertes Schulungsunternehmen sind

Mehr

Maturity Assesment for Processes in IT

Maturity Assesment for Processes in IT Maturity Assesment for Processes in IT Was ist MAPIT? Maturity Assessment for Processes in IT Werkzeug zur Reifegradbestimmung von IT Service Management Prozessen hinsichtlich ihrer Performance und Qualität

Mehr

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank SwissICT 2011 am Fallbeispiel einer Schweizer Bank Fritz Kleiner, fritz.kleiner@futureways.ch future ways Agenda Begriffsklärung Funktionen und Aspekte eines IT-Servicekataloges Fallbeispiel eines IT-Servicekataloges

Mehr

Medical SPICE Von der Regulierung zur Praxis

Medical SPICE Von der Regulierung zur Praxis Medical SPICE Von der Regulierung zur Praxis Thomas Wunderlich, Manager, Vector Consulting Services GmbH Markus Manleitner, SW Quality Assurance Officer, Dräger medical GmbH MedConf 2013, 17.10.2013 2013.

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

Assetwise. Asset Lifecycle Information Management. Ulrich Siegelin. 2010 Bentley Systems, Incorporated

Assetwise. Asset Lifecycle Information Management. Ulrich Siegelin. 2010 Bentley Systems, Incorporated Assetwise Asset Lifecycle Information Ulrich Siegelin Agenda Was bedeutet Asset Lifecycle Information? AssetWise Technischer Überblick Positionierung von Bentley s AssetWise Einsatz und Arbeitsweise von

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

4... SAP Solution Manager als Plattform für den End-to-End-Anwendungsbetrieb... 63

4... SAP Solution Manager als Plattform für den End-to-End-Anwendungsbetrieb... 63 ... Geleitwort... 15... Vorwort... 17... Einführung... 23 1... Was ist Run SAP?... 25 1.1... Motivation der Run SAP-Methodik... 27 1.2... Roadmap... 29 1.3... Run SAP-Phasen... 32 1.3.1... Assessment &

Mehr

BIM Forum Serviceorientierung ein wichtiger Faktor für ein erfolgreiches IT Service Management

BIM Forum Serviceorientierung ein wichtiger Faktor für ein erfolgreiches IT Service Management - ein Kooperationspartner von BIM www.futureways.ch SwissICT 2011 BIM Forum Serviceorientierung ein wichtiger Faktor für ein erfolgreiches IT Service Management Fritz Kleiner, fritz.kleiner@futureways.ch

Mehr

ITSM (BOX & CONSULTING) Christian Hager, MSc

ITSM (BOX & CONSULTING) Christian Hager, MSc ITSM (BOX & CONSULTING) Christian Hager, MSc INHALT Ausgangssituation ITSM Consulting ITSM Box Zentrales Anforderungsmanagement Beispielhafter Zeitplan Nutzen von ITSM Projekten mit R-IT Zusammenfassung

Mehr

Clause 3 Requirements for a Management System Clause 4 Service Management System general Requirements Neue Bezeichnung SMS

Clause 3 Requirements for a Management System Clause 4 Service Management System general Requirements Neue Bezeichnung SMS Clause 3 Requirements for a Management System Clause 4 Service Management System general Requirements Neue Bezeichnung SMS Clause 3.1 Management Responsibility Clause 4.1 Management Responsibility Clause

Mehr

Peter Hake, Microsoft Technologieberater

Peter Hake, Microsoft Technologieberater Peter Hake, Microsoft Technologieberater Risiken / Sicherheit Autos Verfügbarkeit Richtlinien Service Points Veränderungen Brücken Straßen Bahn Menschen Messe Airport Konsumenten Kennt die IT-Objekte,

Mehr

SLA Einführung bei der Stuttgarter Volksbank AG - Ein Praxisbericht -

SLA Einführung bei der Stuttgarter Volksbank AG - Ein Praxisbericht - SLA Einführung bei der Stuttgarter Volksbank AG - Ein Praxisbericht - Christina Dreller Christina.Dreller@stuttgarter-volksbank.de Übersicht I. Theoretische Grundlagen II. ITIL bei der Stuttgarter Volksbank

Mehr

on Software Development Design

on Software Development Design Werner Mellis A Systematic on Software Development Design Folie 1 von 22 How to describe software development? dimensions of software development organizational division of labor coordination process formalization

Mehr

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7 xv 1 Einleitung 1 2 Einführung und Grundlagen 7 2.1 Die neue Rolle der IT...................................... 7 2.2 Trends und Treiber........................................ 8 2.2.1 Wertbeitrag von

Mehr

Management von Anforderungen im Rational Unified Process (RUP)

Management von Anforderungen im Rational Unified Process (RUP) Management von Anforderungen im Rational Unified Process (RUP) Peter Fröhlich ABB DECRC 69115 Heidelberg Fröhlich-8/98-1 Themen: Was ist RUP? RM im RUP Core Workflows Dokumente Tools Erfahrungen RUP Objectory

Mehr

Reifegradmodelle. Skiseminar Software Engineering. Robin Schultz

Reifegradmodelle. Skiseminar Software Engineering. Robin Schultz Reifegradmodelle Skiseminar Software Engineering Robin Schultz Agenda Grundlagen Die IT Infrastructure Library Entwicklung Aufbau Kritik Kombination mit anderen Modellen Praktischer Einsatz Fazit und Ausblick

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

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

SPICE in der medizinischen Software-Entwicklung

SPICE in der medizinischen Software-Entwicklung SPICE in der medizinischen Software-Entwicklung MedConf 2012 Matthias Hölzer-Klüpfel Medical SPICE Medizinische Software Regulatorische Grundlagen Referenzmodell Medical SPICE Beispiele 1968: Software-Krise

Mehr

etom enhanced Telecom Operations Map

etom enhanced Telecom Operations Map etom enhanced Telecom Operations Map Eigentümer: Telemanagement-Forum Adressaten: Telekommunikationsunternehmen Ziel: Industrieeigenes Prozessrahmenwerk Verfügbarkeit: gegen Bezahlung, neueste Version

Mehr