Sie sind auf Seite 1von 40

1. Vorstudie....................................................................... 2 3.2.2.5 Executive Information System (EIS).....................................

20
3.2.2.6 Grundarchitektur .................................................................. 20
1.1 Ziele................................................................................... 2 3.2.2.6 Data Mart .............................................................................. 20
1.2 Anforderungskatalog .................................................... 2 3.2.2.8 Analysemethoden ................................................................ 20
1.2.1 Funktionale Anforderungen .............................................2 3.2.3 Applikationsarchitektur................................................... 21
1.2.2 Nicht Funktionale Anforderungen ...................................2 3.2.4 Nezwerkplan .................................................................... 21
1.2.4 Anforderungskatalog ........................................................2 3.3 Objektorientierter Ansatz (S.87 in UML).....................21
1.3 Evaluation (S. 34 in Comp. Eval).................................. 3 3.3.1 Systemidee ....................................................................... 23
1.3.1 Beschaffungsgründe .........................................................3 3.3.2 Stakeholder ...................................................................... 23
1.3.2 Vorbereitungen ..................................................................3 3.3.3 Business-Use-Case ........................................................... 23
1.3.3 Pflichtenheft erstellen ........................................................3 3.3.4 Anwendungsfälle essenziell beschreiben.................... 23
1.3.4 Bewertungsdokumente (S. 54) .........................................4 3.3.5 Use- Case.......................................................................... 24
1.3.5 Grobevaluation durchführen (S. 62) ...............................4 3.3.6 Klassendiagramm............................................................ 25
1.3.6 Detailevaluation durchführen (S. 63) ..............................4 3.3.7 Fachliches Glossar anlegen........................................... 26
1.3.7 Entscheidung treffen (S.71)...............................................4 3.3.8 Aktivitätsdiagramm......................................................... 27
1.3.8 Vertrag abschliessen (S. 73)..............................................5 3.3.9 Zustandsdiagramm ......................................................... 27
1.3.9 Weitere Erhebungstechniken ...........................................5 3.3.10 Sequenzdiagramm ....................................................... 27
1.4 Arbeits- und Zeitplan ..................................................... 6 3.3.11 Kollaborationsdiagramm ............................................. 28
1.4.1 Strukturplan .........................................................................6 3.4 Strukturierter Ansatz (S.76 in Comp. Struk.)...............28
1.4.1.1 Aufwandschätztechniken ..................................................... 6 3.4.1 Systemanalyse ................................................................. 29
1.4.2 Tätigkeitsliste........................................................................6 3.4.2 Ereignistabelle.................................................................. 29
1.4.3 Kostenplanung ...................................................................6 3.4.3 Kontextdiagramm ........................................................... 29
1.4.4 Balkendiagramm................................................................6 3.4.4 Datenflussdiagramm ...................................................... 30
1.5 Lösungsvarianten ........................................................... 6 3.4.5 Mini Spezifikation ............................................................. 30
1.5.1 Benötigte Betriebsmittel ....................................................6 3.4.6 Data Dictionary ............................................................... 30
1.5.2 Beschaffendes Material ....................................................6 3.4.7 Entity-Relationship-Modell (ERM) .................................. 30
1.5.3 Risiken...................................................................................6 3.4.8 Funktions-Hierarchie-Diagramm.................................... 30
1.5.4 Zeitaufwand........................................................................6 3.4.9 Aktivitätsdiagramm......................................................... 31
1.5.5 Kostenplanung ...................................................................6 3.4.10 CRUD-Matrix ................................................................... 31
1.6 Projektauftrag ................................................................. 7 3.4.11 Strukturdiagramm.......................................................... 31
2. Hauptstudie ................................................................. 7 3.4.12 Zustandsdiagramm ....................................................... 32
2.1 Personaleinsatz ............................................................... 7 4. Realisierung ................................................................ 32
2.1.1 Rollenverteilung..................................................................7 4.1 Testen (S. 81 in Comp. Testen) ...................................32
2.1.2 Brutto-Personalaufwand ...................................................7 4.1.1 Testprinzipen..................................................................... 32
2.1.3 Personalressourceplan ......................................................8 4.1.2 V-Modell............................................................................ 32
2.2 Arbeitspaket.................................................................... 8 4.1.3 Testprozess ........................................................................ 32
4.1.3.1 Testmanagement ................................................................. 32
2.3 Sicherheit ......................................................................... 8 4.1.3.2 Testplanung ........................................................................... 32
2.3.1 Höhere Gewalt ...................................................................8 4.1.3.3 Testspezifikation..................................................................... 33
2.3.2 Menschliches Versagen ....................................................9 4.1.3.4 Testdurchführung ................................................................. 33
2.3.3 Kriminelle Handlung ...........................................................9 4.1.3.5 Testaufzeichnung.................................................................. 33
2.3.4 Organisatorische Mängel .................................................9 4.1.3.6 Testauswertung ..................................................................... 33
2.4 Risikoanalyse ................................................................... 9 4.1.4 Testmethoden.................................................................. 33
2.4.1 Systemabgrenzung ............................................................9 4.1.4.1 Ereignistabelle ....................................................................... 33
2.4.2 Definition des Datenbestandes .......................................9 4.1.5 Review und Audit ............................................................ 33
2.4.3 Definition der Verletzbarkeit .............................................9 5. Einführung................................................................... 34
2.4.4 Definition der Bedrohung..................................................9 5.1 Einführungsformen .......................................................34
2.4.5 Risikoanalyse .......................................................................9 5.1.1 Schlagartige Einführung ................................................. 34
2.4.6 Schadensausmas und Eintrittwahrscheinlichkeit...........9 5.1.2 Schrittweise Einführung................................................... 34
2.4.7 Massnahmen ....................................................................10 5.1.3 Parallel Einführung........................................................... 34
2.4.7.1 Hardware ............................................................................... 10 5.2 Abnahmekriterien ........................................................34
2.4.7.2 Daten- und programmierbare Massnahmen ................... 10
2.4.7.3 Verbesserung der Verfügbarkeit ........................................ 10
5.3 Service Level Agreement............................................34
2.4.7.4 Bauliche / Physische Sicherheit........................................... 10 5.4 Schulung ........................................................................35
2.4.7.5 Manipulation von Eingabe.................................................. 10 5.4.1 Gruppenschulung / Seminar ......................................... 35
2.4.7.6 Gegen Manipulation............................................................ 10 5.4.2 Einzelschulung.................................................................. 35
2.4.7.7 Hacking und Spionage ........................................................ 10 5.4.3 Externe Schulung............................................................. 35
2.4.7.8 Organisatorische Massnahmen .......................................... 10 5.4.4 System – Unterstützende Schulung............................... 36
2.4.7.9 Technische Massnahmen .................................................... 10
5.4.5 Learning by doing ........................................................... 36
2.5 Authentisierung ............................................................ 11 5.4.6 Aufbau der Schulung...................................................... 36
2.6 Datenschutz / Strafrecht............................................. 11 5.4.7 Lernerfolg Messbarkeit.................................................... 36
2.6.1 Grundschutz (S. 48 in Comp. Grundschutz) .................12 5.4.8 Kosten................................................................................ 36
2.6.1.1 Netzplanerhebung ............................................................... 13
2.6.1.2 Gruppengliederung ............................................................. 13
5.5 Administration ...............................................................36
2.6.1.3 Erhebung Komponenten ..................................................... 13 5.5.1 Projektabschlussbericht.................................................. 36
2.6.1.4 Erhebung Applikationen...................................................... 13 5.5.2 Erfahrungssicherung........................................................ 36
2.6.1.5 Erhebung Systeme pro Applikation.................................... 13 5.5.3 Einführungsnacharbeitung ............................................ 36
2.6.1.6 Schutzbedarfskategorien definieren.................................. 13 5.5.4 Projektauflösung .............................................................. 36
2.6.1.7 Schutzbedarfsfeststellung .................................................... 13
2.6.1.8 Modellierung der Massnahmen.......................................... 14
6. Wartung / Betrieb ..................................................... 36
2.6.1.9 Basis-Sicherheirscheck (Soll-/Ist-Vergleich)........................ 14 6.1 Service Desk (S. 119 in ITIL) ..........................................36
2.6.1.10 Priorisierung der Massnahmen .......................................... 14 6.2 Störungs- Management(S. 45 in ITIL) .........................37
2.6.1.11 Umsetungskostenplan /Realisierungsplan ....................... 14 6.3 Problem Management(S. 59 in ITIL)...........................37
3. Detailstudie ................................................................ 14 6.4 Config Management (S. 71 in Comp. Config) .......38
3.1 Detailkonzept................................................................ 14 6.4.1 Identifikation..................................................................... 38
3.2 Modellierung (S.42 in Comp. Mapping)................... 15 6.4.2 Kontrolle ............................................................................ 38
3.2.1 ERM /ERD ...........................................................................16 6.4.3 Statusüberwachung ....................................................... 38
3.2.1.1 Attributsliste............................................................................ 18 6.4.4 Plausibilisierung ................................................................ 38
3.2.2 Datawarehouse ...............................................................19 6.5 Release Management(S. 107 in ITIL) .........................38
3.2.2.1 Qualität der erhobenen Daten .......................................... 19
3.2.2.2 Probleme bei der Informationserhebung .......................... 19
6.6 Change Management(S. 91 in ITIL) ..........................39
3.2.2.3 Management Information System (MIS)............................ 19 6.6.2 Klassifizierung.................................................................... 39
3.2.2.4 Decision Support System (DSS)............................................ 19 6.6. 3 Planung der Auswirkung und Ressourcen .................. 39

Mirco Holtkamp Seite 1 10.03.2009


1. Vorstudie
Ziele
- Bedürfnis - Kosten
- Bereiche - Länge
- Ziele
Aufgaben
- Analyse Projektauftrag - Erstellung Projektauftrag
- Situationsanalyse - Grobe Lösungsvarianten
- Ziele definieren - Lösungsvarianten analysieren
- Risiken erkennen - Kosten-/Nutzenbetrachtung pro Variante
- Kosten-/Nutzenbetrachtung - Bewertungsdokumente erstellen
- Erstellung Phasenplan - Weiteres Vorgehen vorbereiten
1.1 Ziele
Nachdem der Projektantrag freigegeben wurde, müssen die Projektziele definiert werden.
Kriterien
- Lösungsneutral - Erreichbar
- Messbar - Nicht konkurrierend
Formulierung
Leistungsziele
- Das System ist zu 99.9% verfügbar von Mo bis Sa von 07.00 – 19:00 Uhr
Qualitätsziele
- Die Redundanzen werden um 80% reduziert
Soziale Ziele
- Alle Mitarbeiter werden über die Einführung des neuen Systems informiert
Betriebswirtschaftliche Ziele
- Die Produktivität erhöht sich um 50%

1.2 Anforderungskatalog
Anforderungen sind um einiges detaillierter und definieren im Gegensatz zu den Zielen auch einen Weg.
Adäquatheit Verständlichkeit
Beschreibung der nötigen Anforderungen an In einer verständlichen Form für alle Beteiligten
das System Eindeutigkeit
Vollständigkeit Fehlinterpretionen werden vermieden
Alle Anforderungen sind enthalten Prüfbarkeit
Widerspruchsfreiheit Anforderungen werden so definiert das diese
Gegenseitiges Widersprechen der Prüfbar sind
Anforderungen ist eliminiert
Formulierung
Funktionalität
- Jedes Formular und jeder Bericht muss via Druckbutton ausgedruckt werden können.
Zugriffsbeschränkung
- Der Zugriff auf das Programm erfolgt mittels eines 6stelligen Passworts.
Archivierung
- Die Benutzung der Archive ist mittels Logfile nachvollziehbar
Benutzerfreundlichkeit
- Das System ist mehrsprachig und unterstützt neben deutsch auch englisch, französisch usw.
Schnittstellen
- Das System verfügt über eine Exportschnittstelle in Text-Format.
1.2.1 Funktionale Anforderungen 1.2.2 Nicht Funktionale Anforderungen
Die funktionalen Anforderungen erklären Bei den nicht funktionalen
was das System machen muss. Anforderungen wird die Leistung des
Das Ticketsystem verfügt über eine Ein- und Produkts beschrieben.
Ausgabemaske, die sich per Knopfdruck ausdrucken Ein Ticket am Service Desk lässt sich innerhalb von 30
lässt. Sekunden erstellen und weiterleiten.
1.2.4 Anforderungskatalog
Titel Inhalt
Zielbestimmung
Muss-Anforderungen Unverzichtbar
Wunsch-Anforderungen Sollte Angestrebt werden
Abgrenzungskriterien Bewusst ausgelassen
Anwendungsbereiche Geplante Produktionseinsatz
Zielgruppen
Betriebsbedingungen physikalische Umgebung des
Systems
Betriebszeit
Notwendige Überwachung

Mirco Holtkamp Seite 2 10.03.2009


Software Software des Zielsystems
Hardware Hardware des Zielsystems
Orgware Organisatorische
Anforderungen
Produkt-Schnittstellen
Produkt-Funktionen Im Vordergrund steht was das
System erledigen soll
Produkt-Daten Langfristig zu speichernde
Daten
Produkt-Leistung Qualitätsbezogen
Benutzeroberfläche
Qualitäts-Zielbestimmung
Globale Testszenarien Für Abnahmetest
Ergänzungen Beispiel räumliche
Gegebenheiten

1.3 Evaluation (S. 34 in Comp. Eval)


Die Evaluation ist wie die Vorstudie oder die Realisierungsphase einer Projektphase und hat als Ziel die „beste“
Lösung zu finden.

1.3.1 Beschaffungsgründe
- Neue Einsatzgebiete - Geänderte Geschäftsaufgabe
- Erhöhte Kapazitätsanforderung - Ablösung von Systemen
- Neue Organisationsformen - Ersatz und Neuanschaffung
1.3.2 Vorbereitungen
Bevor Sie mit der Evaluation beginnen, müssen Sie einige Vorbereitungsarbeiten durchführen.
Verschaffen Sie sich insbesondere möglichst vollständige Klarheit über den Inhalt des Auftrags. Folgende
Punkte sind dabei schriftlich festzuhalten:
- Projektnummer: Die Projektnummer dient als eindeutige Identifikation des Projekts.
- Grundlagen: In der Regel werden unter diesem Punkt die Beschaffungsgründe aufgeführt.
- Grobziele: Hier werden zwei bis drei übergeordnete Ziele definiert.
- Aufgabenstellung: Die Aufgabenstellung ist meistens einfach umrissen. Die zu beschaffenden
Komponenten werden grob skizziert.
- Gestaltungsbereich: Der Gestaltungsbereich gibt Auskunft über die Systemgrenzen, Schnittstellen und
die beteiligten Bereiche.
- Rahmenbedingungen: Bei einer Evaluation können durchaus die Kosten, die für die zu evaluierende
Lösung anfallen dürfen, unter diesem Punkt erscheinen.
- Projektorganisation: Unter diesem Punkt werden die personelle Besetzung und die einzelnen Rollen der
Projektbeteiligten beschrieben.
- Termine: Die Terminplanung gibt Auskunft über die zu erwarteten Aufwände der Projektmitglieder,
Zeitpunkte der Meilensteinsitzungen und die zu erwartenden Durchlaufzeiten. Die Meilensteine
sichern die erarbeiteten Ergebnisse und dadurch den kontinuierlichen Projektfortschritt.
- Budgetbeschränkung/ Evaluation: Bei der Evaluation fallen, neben den internen Arbeitsstunden, wenn
überhaupt, nur geringe Beträge, wie z.B. externes Beratungshonorar oder Miete für Sitzungs- oder
Schulungsräume an.
- Auskunft/ Informationspflicht: Unter diesem Punkt werden Periodizität, Form und Inhalt der von der
Projektleitung an den Lenkungsausschuss zu liefernden Projektberichte festgelegt.

1.3.3 Pflichtenheft erstellen


Hauptkapitel Inhalte
Ausgangslage - Angaben zum Unternehmen
- Organisation der Informatik
- Beschaffungsgrund
- Projektorganisation (Rollen)
Ist-Zustand - Aufbauorganisation
- Ablauforganisation
- Applikationsportfolio
- Systemplattform
- Übrige technische Infrastruktur
Ziele - Nutzenrelevante Ziele

Mirco Holtkamp Seite 3 10.03.2009


- Systemziele
- Vorgehensziele
Anforderungen - Applikationssoftware
- Systemplattform
- Anbieterbezogene Leistungen
Mengen und Häufigkeiten - Datenbewegungen
- Datenbestände
- Anzahl Benutzer
Aufbau und Inhalt der Offerte - Angaben zum Offertsteller
- Management Summary
- Applikationsbezogene Angaben
- Angaben zur Systemplattform
- Anbieterbezogene Angaben
- Kosten
Administratives - Vertraulichkeit
- Evaluationsschwerpunkte
- Rückfragen zum Pflichtenheft
- Termine
- Abgabe der Offerte und weiteres Vorgehen
Fragenkatalog - Fragen über die Firma
- Fragen zum Produkt

1.3.4 Bewertungsdokumente (S. 54)


Dienen zum vergleichen der verschiedenen Lösungsvarianten.
Die Bewertungsdokumente beinhalten die Kriterienliste, die Liste der gewichteten Anforderungen und die
KO-Kriterien.
Die Kriterienliste lehnt sich an die Struktur der Anforderungen aus dem Pflichtenheft an. Zur Gewichtung
der Kriterien werden jeweils 100 Punkte innerhalb derselben Hierarchiegruppe vergeben. Anschliessend
wird über die gesamte Kriterienstruktur hinweg das absolute Gewicht ermittelt. Die Summe aller absoluten
Gewichtungen auf der untersten Hierarchieebene muss wieder 100 betragen.
Für die einzelnen Anforderungen werden z.B. Gewichtungswerte von 3, 6 und 9 vergeben. Diese werden
mit der vereinbarten Maximalnote multipliziert, was die maximal erreichbare Punktzahl ergibt. Diese
wiederum bildet die Basis für die Berechnung des maximalen Nutzwerts.
Die KO-Kriterien dienen zu ersten Grobevaluation. Angebote, welche die KO-Kriterien nicht erfüllen,
werden nicht mehr weiter bearbeitet, sondern rasch ausgesondert. Auf diese Weise wird die Anzahl der
Angebote, die in die engere Auswahl kommen, auf ein vernünftiges Mass reduziert und die Effizienz des
Evaluationsprozesses erhöht.
Kriterienaufteilung
- Musskriterium (KO-Kriterium) - Kannkriterium
Gewichtung
Ein Total von 100 Punkten (oder Prozent) wird nun auf die Kannkriterien verteilt.
Entscheidungstechniken
- Einfache Gewichtung

- Entscheidungsbaum

Präferenzmatrix Formel= Punkte pro Kriterium * 100 / Total Anzahl Punkte = Prozentsatz

1.3.5 Grobevaluation durchführen (S. 62)


Bei der Grobevaluation findet eine Selektion nach den KO-Kriterien, Vollständigkeit der Offerte und einer
ersten Kostenüberprüfung statt.

1.3.6 Detailevaluation durchführen (S. 63)


Die Detailevaluation besteht aus einer Benotung und Bewertung der einzelnen Anforderungen und
Kosten verschiedener Angebote. Dabei wird u.a. die Technik der Kostenwirksamkeitsanalyse eingesetzt.

1.3.7 Entscheidung treffen (S.71)


Die Entscheidungsträger werden aufgrund eines Antrages die Entscheidung für eine Lösung fällen. Dafür
stützen sie sich hauptsächlich auf folgende Informationen:
- Kostenaufstellung - Risikoanalyse
- Nutzwertanalyse - Stärken- und Schwächenanalyse

Mirco Holtkamp Seite 4 10.03.2009


Nach der Entscheidung wird mit dem ausgewählten Lösungsanbieter ein Vertrag über die Erstellung eines
Detailkonzepts abgeschlossen. Dieses beschreibt detailliert den Einsatz der Lösung.

1.3.8 Vertrag abschliessen (S. 73)


Make
Vorteile Nachteile
- Flexibilität - Mehraufwand, Personalressourcen
- Schnellere Anpassung, Umstellung - Sicherheit
- Know-how im Hause - Mitarbeiterrisiko
- Unabhängigkeit
- Entspricht exakt den Anforderungen
Buy
Vorteile Nachteile
- Konzentration auf Kerngeschäft - Abhängigkeit
- Verringerung der Personalkosten - Weniger Individuell
- Kosten kalkulierbar - Umstellungskosten
- Arbeit wird mit viel Know-how extern erledigt - Verlust von Schlüsselpersonen
- Technik (Entwicklungstool müssen nicht beschafft - Gezwungener Update
werden)
- SLA bringt gute Absicherung
- Dokumentation bereits vorhanden

1.3.9 Weitere Erhebungstechniken


- Dokumentenstudium: Das Dokumentenstudium eignet sich vor allem für den Beginn einer Analyse, um
sich einen Überblick über den zu bearbeitenden Bereich zu verschaffen. Durch diese Technik
erhalten Sie einen guten Eindruck, wie die Aufbau- und Ablaufstrukturen angelegt sind. Der Vorteil
dieser Technik liegt in der Einfachheit der Durchführung. Der Nachteil ist eher bei der mangelnden
Aktualität und Vollständigkeit zu sehen.
- Laufzettelverfahren: Das Laufzettelverfahren ist eine ablaufbezogene Untersuchung. Sie ermittelt den
Weg, den ein Dokument oder ein Produkt nimmt, mit Hilfe eines Laufzettels.
Der Laufzettel sollte mit Feldern für folgende Eintragungen versehen werden:
Eingangsdatum, Bearbeitungsdatum, Ausgangsdatum, Bearbeiter, Art der Bearbeitung, Dauer des
Bearbeitungsvorganges
- Interview: Interviews werden vorrangig bei der Erhebung von Ist- und Soll-Zuständen eingesetzt. Die
Durchführung von Interview ist vor allem bei organisatorisch-analytischen
Problemstellungenangebracht. Es braucht eine sehr gute Vorbereitung durch den Interviewer. Die
Auswertung ist eher als aufwändig zu bezeichnen. KROKUS ist das Schlüsselwort (Kurze Fragen,
Redundante Fragen vermeiden, Offene Fragen, Konkrete Fragen, Unterfragen vermeiden,
Suggestivfragen verboten)
- Selbstaufschreibung: Sie wird hauptsächlich bei der Aufgabenanalyse eingesetzt und eignet sich für
grössere Personengruppen.
- Fragebogen: Mit dem Einsatz der Fragebogentechnik werden die Erhebungsaktivitäten hauptsächlich
in die Fachabteilung verlagert. Die durch die Fragen angesprochenen Mitarbeiter müssen die Fragen
schriftlich beantworten. Fragebögen sind in allen Lebensbereichen vertreten.
Weitere Darstellungstechniken
- Kosten-Nutzen-Profil - Nutzenprofil
- Risikoprofil - Kostendarstellung
- Stärken-Schwächen-Analyse (SWOT)
- Kiviatdiagramm

Mirco Holtkamp Seite 5 10.03.2009


1.4 Arbeits- und Zeitplan
Dauer und Kosten des Projekts.

1.4.1 Strukturplan

Objektorientiert

Funktionsorientiert
1.4.1.1 Aufwandschätztechniken
- Delphi Verfahren -> Befragung von mindestens zwei Fachexperten
- Beta-Methode -> Projektmitarbeiter schätzen die Dauer (optimistisch, häufigste, pessimistischste
Dauer)
Formel = ((Opt. Dauer + 4)*Häufig. Dauer)+Pessim. Dauer / 6 = Mittlere Dauer
- Kennzahlenmethode -> Vorherige Projekte werden verglichen

1.4.2 Tätigkeitsliste
Die Tätigkeiten aus dem Strukturplan werden nun in eine Tätigkeitsliste übertragen.
- Identifizierungs-Nr. - Vorgangsdauer -> inkl. Wartezeiten
- Arbeitspaketbezeichnung - Aufwand -> Nettoarbeitsaufwand
1.4.3 Kostenplanung
1.4.4 Balkendiagramm
Visualisierung der Ablaufstruktur der Pakete und Vorgänge

1.5 Lösungsvarianten
Folgende Punkte müssen bei Lösungsvarianten geklärt werden:
1.5.1 Benötigte Betriebsmittel
1.5.2 Beschaffendes Material
1.5.3 Risiken
1.5.4 Zeitaufwand
1.5.5 Kostenplanung
- Arbeitsaufwand - Beschaffende Produkte
- Betriebsmittel

Mirco Holtkamp Seite 6 10.03.2009


1.6 Projektauftrag
In der Vorstudie werden viele Informationen zusammen getragen. Es wurden:
- Ziele festgelegt - Zeit und Kostenplan erstellt
- Struktur und Ablauf geplant - Verschiedene Varianten geprüft

Der Projektauftrag enthält:


- Ausgangslage - Systembezogenen
- Umfang/Abgrenzung Restriktionen/Abhängigkeiten
- Kurzbeschreibung des Ist-Systems - Termine
- Ursache des Auftrages (Motivation) - Budget
- Ziele - Dokumentation
- Lösungsvorschlag - Informationsverfahren
- Stärken/Schwächen der neuen Lösung
2. Hauptstudie
Ziele
- Wer arbeitet im Projekt? - Welche Aufgaben werden verteilt?
- In welcher Organisationsform wird gearbeitet?
Aufgaben
- Rollen verteilen - Konfiguration definieren
- Personalressourceplanung - Schnittstellen definieren
- Arbeitspakete erstellen - Anforderungen an Datensicherheit festlegen
- Geschäftsereignisanalyse durchführen - Anforderungen an Datenschutz festlegen
- Datenanalyse - Kosten/Nutzen Rechnung erstellen
2.1 Personaleinsatz
2.1.1 Rollenverteilung
Aus der Tätigkeitsliste lässt sich erkennen wie viel Aufwand das Projekt verursacht. Folgende Kriterien sind
wichtig für die Zuteilung:
- Zeit (Verfügbar) - Einstellung (Motivation)
- Know-how (notwendige Fachwissen) - Team (passt er ins Team)
2.1.2 Brutto-Personalaufwand
Mitarbeiter = 52 Wochen zu 5 Tagen à 8 Stunden. Theoretisch 2080 h pro Jahr
Ausfallzeiten
- Krankheit, Schwangerschaft - -Weiterbildung, Sitzungen
- Ferien - Ferien
- Militär
Leistungskürzende Situationen
- Neueinstellung - Versetzung
(Einarbeitungszeit) - Teilzeitarbeit
- Kündigung (Know-how Verlust) - Pensionierung
- Probezeit

Mirco Holtkamp Seite 7 10.03.2009


2.1.3 Personalressourceplan
Nachdem die Mitarbeiter definiert wurden, werden die Tätigkeiten mit den Einsatzmöglichkeiten der
Mitarbeiter verglichen um Engpässe zu erkennen.

1. Arbeitsaufwand 3. Vergleich

4. Bereinigung
Formel = Aufwand / Vorgangsdauer = Aufwand pro
Person in Prozent

2. Personalkapazität

2.2 Arbeitspaket

2.3 Sicherheit
2.3.1 Höhere Gewalt
- Defekte der Hardware, - Fehler im Betriebs- oder
Stromversorgung, Klimaanlage Kommunikationssystem

Mirco Holtkamp Seite 8 10.03.2009


- Feuer, Explosion im Rechenzentrum - Streik, Weggang von Schlüsselpersonen
- Natürliche Naturkatastrophen
2.3.2 Menschliches Versagen
- Programmabsturz aufgrund eines - Fehlerhafte Produktion
Programmfehlers - Verlust der Vertraulichkeit durch
- Bedienungsfehler herumliegende Daten
2.3.3 Kriminelle Handlung
- Manipulation von Geräten - Hacking
- Missbrauch vertraulicher Daten - Industriespionage
- Diebstahl oder Kidnapping von - Vandalismus
Geräten, Programmen oder Daten - Sabotage
- Einbringen von bösartiger Software
(Viren)
2.3.4 Organisatorische Mängel
2.4 Risikoanalyse
2.4.1 Systemabgrenzung
Alle ICT-Systeme werden aufgelistet und in Bereiche unterteilt (Komplexitätsreduktion)

2.4.2 Definition des Datenbestandes


Innerhalb der Bereiche, werden nun die Datenbestände erhoben.
Applikation 1:
- -Mitarbeiterdaten - -Lohndaten
2.4.3 Definition der Verletzbarkeit
Die Datenbestände werden den Grundbedrohungen der IT gegenübergestellt.

2.4.4 Definition der Bedrohung


Nun werden die möglichen Bedrohungen notiert.
- Hacker - etc
- Wasserschaden
2.4.5 Risikoanalyse
Jetzt folgt die eigentliche Risikoanalyse.

2.4.6 Schadensausmas und Eintrittwahrscheinlichkeit

Mirco Holtkamp Seite 9 10.03.2009


2.4.7 Massnahmen
2.4.7.1 Hardware
- USV - RAID Systeme
- Notstromaggregate - Sicher für Harddisk und andere
- Kontrolle / Wartung Hardware, Massenspeicher
Performacemessung
2.4.7.2 Daten- und programmierbare Massnahmen
- Datenbanksicherungstechnike - Automatischer Neustart
n - Operationelle Datensicherung
- Replikation, Synchronisation (Abfangen von Benutzerfehler)
redundanter Bestände - Zugriffsbeschränkung
- Wiederanlaufpunkt in ein
Programm einbauen
2.4.7.3 Verbesserung der Verfügbarkeit
- Redundanzschaffung - Stellvertretung und Schulung
- Dokumentation (ermöglicht - Störungsüberwachung,
schnellere und geplante Monitoring
Reaktionen)
2.4.7.4 Bauliche / Physische Sicherheit
- Einbruchsschutz - Sicherheitsschleusen
- Brandschutz - Druckerstation abschliessen
- USV (Einsatz in sensible Daten)
- Sicherheit bei der Verkabelung - Zugang zu Gebäude
- Sicherheit bei auswärtigen kontrollieren
Geräteeinsatz (Notebook)
2.4.7.5 Manipulation von Eingabe
- Funktionstrennung respektive - Periodische Überprüfung von
Vieraugenprinzip Stammdaten
- Zugriffsschutzsysteme mit - Protokollierung wesentlicher
restriktiver Vergabe von Transaktionen
Rechten - Interne Kontrollstelle
2.4.7.6 Gegen Manipulation
- Abnahmetest durch - Restriktiver direkter Zugriff auf
Fachbereiche produktive Programme
- Einsatz von Prüfsummen über - Restriktiver Einsatz von
produktive Programme Dienstprogrammen
2.4.7.7 Hacking und Spionage
- Logon mit starker - Einmalpassworte löschen
Authentisierung - Gezwungener
- Gut administrierte Passwortwechsel
Zugriffschutzsysteme, - Gezielter Einsatz / Kombination
insbesondere an den mehrerer
Netzeingängen Authentifizierungsmittel
- Verschlüsselung von - Firewall
gespeicherten Daten - Callback
- Permanente Realtime-
Überwachung der Netzwerke
2.4.7.8 Organisatorische Massnahmen
- Daten klassifizieren in Geheim, - Aufteilung in Sicherheitszonen
Vertraulich, Normal - Einschliessen von Datenträgern
- Benutzerbeschränkung - Verhaltensregeln, Weisungen
- Clean Desk - Schulungen
2.4.7.9 Technische Massnahmen
- Zugriffsicherheit - Verschlüsselung der Daten
(Benutzeridentifikation, - Zentrale Verteilung von
Passwort) Software
- Schutz gegen aussen, - Berechtigung auf
Callback, Firewall Betriebsystemebene
- Schutz der eigenen
Datenbestände (RAID,
Backup)

Mirco Holtkamp Seite 10 10.03.2009


2.5 Authentisierung
Logische Merkmale - Karte mit Personen spezifischen
- Passwort Zusatzpasswort (Magnetkarte)
- Einmalpasswort - Standalone Token (Kombination mit
- Abfragen von Spezialwissen Passwort
- Anwendung von Indirekte Verfahren
Codierungsalgorithmen - Callback
Physische Merkmale - Standorterkennung
- Schlüssel - Leitungsverschlüsselung
- Ausweis Sicherheit
- Automatisch lesbare Karten Die gesetzten Sicherheitsbestimmungen
- Standalone Token – Generator, müssen voll unterstützt werden.
Streichliste Kosten- / Nutzen
Biometrische Merkmale Die Kosten müssen mit dem Nutzen
- Fingerabdruck übereinstimmen.
- Handgeometrie Einfachheit
- Netzhautmuster Einfach zu erlernen.
- Spracherkennung Erfassungsaufwand, Geschwindigkeit
- Bildererkennung Die Geschwindigkeit muss in einem
- Gewicht guten Verhältnis zur Sicherheitsstufe
- Schriftenerkennung stehen.
- Eingaberhytmus Benutzerakzeptanz
- Genetische Muster (DNA) Wichtiger Aspekt ist die Akzeptanz der
Kombinierte Verfahren User.
- Personalausweis
2.6 Datenschutz / Strafrecht
Der Grundgedanke des Datenschutzes liegt im Schutz des Persönlichkeitsrechts.
Sicherheit = Prinzipiell: „Zustand ohne Gefahren“
Kurze Massnahmenübersicht:
- Zugangskontrolle - Speicherkontrolle
- Datenträgerkontrolle (Berechtigungen) - Benutzerkontrolle
- Transportkontrolle (Transfer) - Zugriffskontrolle
- Bekanntgabekontrolle - Eingabekontrolle
Bestimmungen aus dem Strafrecht
Strafbestand Artikel Inhalt
Urkundenfälschung StGB 251
Unbefugte Datenbeschaffung / StGB 143 Datendiebstahl, Datenspionage

Mirco Holtkamp Seite 11 10.03.2009


Datenspionage
Unbefugtes Eindringen in ein StGB 143bis Hacking
Datenverarbeitungssystem
Datenbeschädigung StGB 144bis Sachbeschädigung, Viren
Betrügerischer Missbrauch einer StGB 147 Computerbetrug,
Datenverarbeitungsanlage Computermanipulation
Erschleichen einer Leistung StGB 150 Unerlaubte Nutzung eines DV-Systems
für eigene Zwecke
Grundbedrohungen
Grundbedrohungen Artikel
Schutz vor Verlust der Integrität StGB 251
StGB 144 bis, StGB 147
(DSG)
Schutz vor Verlust der Vertraulichkeit StGB 143
Schutz vor Verlust der Verfügbarkeit StGB 143bisStGB 150
StGB 147

2.6.1 Grundschutz (S. 48 in Comp. Grundschutz)

Ziel
Ziel des IT-Grundschutzes ist es, durch standardisierte Sicherheitsmassnahmen ein standardisiertes
Sicherheitsniveau für IT-Systeme aufzubauen, das für sensible Bereiche weiter ausbaufähig ist.
Vorgehensweise
1.IT-Strukturanalyse
2.Feststellung des Schutzbedarfs
3.Modellierung des Grundschutzes
4.Basis-Sicherheitscheck
5.Ergänzende Sicherheitsanalyse
6.Realisierung von IT-Sicherheitsmassnahmen
Merkmale
- Vertraulichkeit (Confidentiality) - Integrität (Integrity)
- Verfügbarkeit (Availability) - Verbindlichkeit (Non-repudiation)
Bedrohung
- Menschliches Versagen - Höhere Gewalt
- Vorsätzliche Handlung - Organisatorische Mängel
- Technisches Versagen

Mirco Holtkamp Seite 12 10.03.2009


2.6.1.1 Netzplanerhebung

2.6.1.2 Gruppengliederung 2.6.1.4 Erhebung Applikationen


Der nächste Schritt besteht darin,
den Netzplan um die Information
zu bereinigen, die für die
nachfolgenden Aufgaben nicht
erforderlich sind. Hierzu sollten
jeweils gleichartige Komponenten
zu einer Gruppe zusammengefasst 2.6.1.5 Erhebung Systeme pro
werden, die im Netzplan durch ein Applikation
einzelnes Objekt dargestellt wird.
2.6.1.3 Erhebung Komponenten

2.6.1.6 Schutzbedarfskategorien definieren


Kategorie Schadensauswirkung
Niedrig bis mittel begrenzt und überschaubar
Hoch beträchtlich
Sehr hoch existenziell bedrohlich, katastrophales Ausmass
2.6.1.7 Schutzbedarfsfeststellung
Schutzbedarfsfeststellung für
Applikationen

Schutzbedarfsfeststellung für
Kommunikationen

Schutzbedarfsfeststellung für
Systeme
Schutzbedarfsfeststellung für
Räume

Mirco Holtkamp Seite 13 10.03.2009


2.6.1.8 Modellierung der
Massnahmen
2.6.1.9 Basis-Sicherheirscheck (Soll-
/Ist-Vergleich)
Um herauszufinden, was
unternommen werden muss, um
die gesteckten Sicherheitsziele zu
erreichen, wird ein Basis-
Sicherheitscheck durchgeführt.

Der Basis-Sicherheitscheck
überprüft die IT-Komponenten in
Bezug auf die bereits vorhandenen
Sicherheitsmassnahmen (Soll/Ist-
Vergleich). Die Abweichung
gegenüber den empfohlenen
Massnahmen werden im
Realisierungplan festgehalten.
2.6.1.10 Priorisierung der Massnahmen
Kategorie Bedeutung
Entbehrlich Die Umsetzung ist nicht notwenig, da bereits andere,
gleichwertige Massnahmen im Einsatz sind.
Ja Die empfohlene Massnahme ist vollständig und wirksam
umgesetzt.
Teilweise Noch nicht umgesetzt
Nein kaum oder gar nicht umgesetzt
2.6.1.11 Umsetungskostenplan /Realisierungsplan
Zielobjekt Massnahme Prio Initial Kosten Wiederkehrende
Kosten
Gesamte Regelung des 1 CHF 0.- (2 CHF 0.-
Organisation Passwortgebrauchs Arbeitstage)
Serverraum Vermeidung von 3 CHF 20'000.- (12 CHF 0.-
wasserführenden Arbeitstage)
Leitungen
Server S4 USV 1 CHF 1'000.- (1 CHF 100.-
Arbeitstag)

3. Detailstudie
Ziele
- Sind die Erkenntnisse aus der Vorstudie bzw. Hauptstudie noch aktuell?
- Wer muss in welcher Form über die Änderungen informieren werden?
- Wie muss das zu beschaffende System sein, damit es den Ansprüchen entspricht?
Aufgaben
- Anpassung Phasenplanung - Datendesign fertig stellen
- Festlegung von Details über Ablauf und Produkte - Online Dialog spezifizieren (Menüstruktur, etc)
- Vertragsabschluss vornehmen (falls Externe - Ablauffolge der logischen Transaktionen
beteiligt) festlegen
- Testdrehbuch vorbereiten - Testdrehbuch erstellen
- Schulung vorbereiten - Weiteres Vorgehen vorbereiten
3.1 Detailkonzept
In der Detailphase wird der PL nicht mehr so stark beansprucht.
Hauptsächlich sind jetzt die Spezialisten bzw. Projektmitarbeiter im Einsatz.
Der Projektleiter hat jetzt die Kontrollfunktion über das gesamte Projekt.

Mirco Holtkamp Seite 14 10.03.2009


3.2 Modellierung (S.42 in Comp. Mapping)
1. Analyse der Realität
Festhalten der Tatsachen der
Realität (Interviews,
Dokumentenstudium usw.)
Resultat = ERM, ERD
Methodische Ansätze:
- Top-down
- Bottom-up
- Inside-out
2. Entitätstypen bilden
Kunde, Kredit, Mitarbeiter
3. Beziehungen zwischen
Entitätstypen (-mengen)
festlegen

4. Identifikationsschlüssel für
jeden Entitätstyp definieren
- Kunden-Nummer: Kunden-#
- Kredit-Nummer: Kredit-#
- Mitarbeiter-Nummer:
Mitarbeiter-#
5. Komplexe Beziehungen
auflösen

6. Attribute für die Entitätstypen


festlegen
- Kundenname
- Alter
- Usw.
7. Normalisieren
Redundanzen sind durch
Normalisierung über drei Stufen zu
eliminieren, um
Mutationsanomalien zu
vermeiden. Dies ist ein technischer
Schritt, der die Semantik des
Modells nicht verändert.
8. Logisches Datenbankdesign
Erstellen des Datenbankschemas
(Tabellen + Zugriffspfad-Matrix +
Integritätsbedingungen).
9. Physikalisches
Datenbankdesign
Berücksichtigung von Hardware,
Eigenschaften des verwendeten
DBMS
10. Am Ziel
Implementiert

Mirco Holtkamp Seite 15 10.03.2009


3.2.1 ERM /ERD

Mirco Holtkamp Seite 16 10.03.2009


Superentität

Faktum
Ein Faktum ist eine Behauptung, der zufolge eine Entität für eine Eigenschaft einen bestimmten
Eigenschaftswert aufweist.
Generalisierung und Spezialisierung
Das Definieren einer Superentität wird als Generalisierung bezeichnet und die in einer Generalisierung
auftretenden Subentitäten lassen sich als Spezialisierung auffassen.
Kernentitätsmenge
Eine Entitätsmenge ist dann eine Kernentitätsmenge, wenn es möglich ist, Entitäten hinzuzufügen, ohne
dass auf andere Entitäten geachtet werden muss, d.h. die Entität darf kein Fremdschlüsselattribut
enthalten.
Assoziationen
Eine Assoziation (Zuordnung) dient der genauen Bestimmung der Beziehung zwischen zwei
Entitätsmengen/Entitätstypen. Eine Assoziation legt fest, wie viele Entitäten der einen Entitätsmenge mit
wie vielen der anderen Entitätsmenge in Beziehung stehen bzw. stehen müssen.
Kardinalität
Die Mengenangaben der beteiligten Entitäten erfolgen über die Kardinalität. Es können grundsätzlich
vier Arten von Assoziationen unterschieden werden:
- Einfache (Min. 1, ;Max. 1)
- Konditionelle (Min. 0, Max. 1)
- Komplexe (Min 1, Max n)
- Konditionell komplexe (Min 0, Max n)

Mirco Holtkamp Seite 17 10.03.2009


3.2.1.1 Attributsliste
Kunde
Feldname Feldtyp Beschreibung
K# AutoWert AutoWert = Zahl
PLZ Zahl -
KA# Zahl -
Name Text -
Vorname Text -
Adresse Text -
Passwort Text -
Lieferant
Feldname Feldtyp Beschreibung
L# AutoWert AutoWert = Zahl
PLZ Zahl -
Lieferant Text -
Adresse Text -
Wein
Feldname Feldtyp Beschreibung
Erste Ziffer: Weisswein 1,
W# Zahl Rotwein 2, Champagener 3
L# Zahl -
Bezeichnung Text -
Inhalt Zahl -
Preis Währung -
Jahrgang Zahl -
Bestellung
Feldname Feldtyp Beschreibung
B# Zahl -
K# Zahl -
W# Zahl -
Menge Zahl -
PreisTot Währung -
Datum Datum -
Ort
Feldname Feldtyp Beschreibung
PLZ Zahl -
Ort Text -
Kundenart
Feldname Feldtyp Beschreibung
KA# AutoWert AutoWert = Zahl
Bezeichnung Text -

Mirco Holtkamp Seite 18 10.03.2009


3.2.2 Datawarehouse

Typische Fragenstellung
- Welchen Deckungsgrad hat das Produkt im letzten Quartal in der Region Innerschweiz im
Privatkundensegment erzielt?
- Welche Kunden reagieren auf ein bestimmtes Produktangebot mit einer Wahrscheinlichkeit von 95%
positiv?
Data Mining
Prozess der mit Hilfe von speziellen Tools grosse Datenmengen analysiert werden
3.2.2.1 Qualität der erhobenen Daten
Korrektheit
Möglichst detailgetreue Nachbildung der Realität
Vollständigkeit
Alle relevanten Daten
Aktualität
Möglichst schnell und wirtschaftliche Aktualisierung
Aufgabenadäquanz
Der Aufgabe entsprechend
Konsistenz
Keine Widersprüche
Exaktheit
Verwendungszweck angemessen
Relevanz
Daten die benötigt werden
Glaubwürdigkeit
Daten für den Empfänger nachvollziehbar
Verständlichkeit
Angepasste Form für Empfänger
3.2.2.2 Probleme bei der Informationserhebung
Mögliche Probleme
- Der richtige Informationsträger - Widerstände bei Befragung
ist nicht auffindbar - Rahmenbedingungen ändern
- Informationen unvollständig sich
- Datenmenge falsch - Betriebsblindheit
eingeschätzt
3.2.2.3 Management Information System (MIS)
System, das ermöglicht detaillierte und verdichtete Informationen zu extrahieren.
Benutzergerecht und Aufgabengerecht
3.2.2.4 Decision Support System (DSS)
Unterstützung von taktischen und strategischen Unternehmungs-
entscheidungen.
In aggregierter Form

Mirco Holtkamp Seite 19 10.03.2009


3.2.2.5 Executive Information System (EIS)
Spezielle Anwendung für das Top-Management.
- Einfache Benutzerführung und grafische Präsentation
- Hochaggregierte und summierte Daten
3.2.2.6 Grundarchitektur
Unternehmensweites Data Warehouse

3.2.2.6 Data Mart Mehrschichtiges Data Warehouse


Autonomer Data Mart
Unter einem Data Mart versteht man ein
bereichspezifisches oder funktionales Data
Warehouse.

Verteiltes Data Mart

3.2.2.8 Analysemethoden
Endbenutzer kategorisieren
- Explorer (Power-User, technisch versiert)
- Farmer (eingeschränkter Zugriff)
- Tourist (vorgegebene Reports und Auswertungen)
Access-Tool
- Zugang zu Daten
- Sorgfältige Auswahl nötig
Query-Tool
- Möglichkeit zur Auswertungen und Abfragen
- intuitiv nutzbare, grafische Oberfläche
- Abfragen einfach und schnell
- vordefinierte Funktionen
- Sicherheitsfunktionen
OLAP Tool (Online Analytical Processing)
- Der Benutzer ist direkt (online) zu Analysezwecken verbunden
- Würfelprinzip (vordefinierte Dimensionen)

Mirco Holtkamp Seite 20 10.03.2009


3.2.3 Applikationsarchitektur 3.2.4 Nezwerkplan

3.3 Objektorientierter Ansatz (S.87 in UML)

Vorteile / Nachteile der Objektorientierte Entwicklung


Vorteile Nachteile
- liegt im Trend - fehlendes Know-how (Erfahrung)
- für hoch interaktive, Ereignisgesteuerte
Systeme
- für flexible und komfortable Bearbeitung
hochkomplexer Objekte
- bei hohen Anforderungen an
Änderbarkeit und Erweiterbarkeit
- bei Einsatz und Wiederverwendung
verfügbarer Klassenbibliotheken,
Frameworks und Komponenten.
- bei iterativem Projektvorgehen
- Wiederverwendbarkeit
- Kundennähe
- geringer Aufwand bei
Zusatzimplementierung
Begriffe
Delegation
Delegation ist ein Mechanismus, bei dem ein Objekt eine Nachricht nicht vollständig selbst interpretiert,
sondern an ein anderes Objekt weiterleitet und damit unter anderem eine Alternative zur Vererbung.

Abstrakte Klassen
Sind Klassen von denen keine konkreten Exemplare erzeugt werden können. Zum Beispiel eine Abstrakte
Klasse ist „Geometrische Figur“ die Konkreten Klassen heissen dann „Rechteck“, „Kreis“ usw.
Assoziation
Eine Assoziation repräsentiert die Beziehung zwischen verschiedenen Objekten einer oder mehrerer
Klassen.

Aggregation
Hierbei handelt es sich ebenfalls um eine Beziehung zwischen zwei Klassen, jedoch mit der Besonderheit,
dass die Klassen zueinander in Beziehung stehen, wie ein Ganzes zu seinen Teilen.

Mirco Holtkamp Seite 21 10.03.2009


Komposition
Eine besondere Form der Aggregation liegt vor, wenn die Einzelteile vom Aggregat (dem Ganzen)
existenzabhängig sind; dieser Fall wird Komposition genannt.

Polymorphie (Viele Formen)


Polymorphie heisst, dass eine Operation sich (in unterschiedlichen Klassen) unterschiedlich verhalten
kann. Es gibt zwei Arten der Polymorphie: statische Polymorphie (Überladung) und dynamische
Polymorphie.
Statische Polymorphie
Im Programmcode werden die verschiedenen Operationen deklariert und je nach Parameterangabe
wird ausgewählt welche Operation benutzt wird. Dies passiert aber bei der Erzeugung (compilieren) des
Programms.
Dynamische Polymorphie
Die genaue Auswahl der Operation wird dynamisch bei der Laufzeit des Programms ausgewählt.
Persistenz
Persitenz ist das Speichern von Objekten auf einem nicht flüchtigen Medium.
Hinweis: Es gibt keine 1:1-Abbildung auf relationale Datenbanken.

Klassifizierung von Klassen


Klassen sind nicht gleich Klassen; es ist sinnvoll, verschiedene Arten zu unterscheiden.
Entitätsklasse „entity“
Repräsentieren gewöhnlich einen Sachverhalt oder Realwelt-Gegenstand.
- Meistens viele Attribute
- Viele Primitive Operationen
Steuerungsklasse „control“
Repräsentieren einen Ablauf, Steuerungs- oder Berechnungsvorgang.
- Meistens wenige oder keine Attribute
- Häufig kurze Lebensdauer
Wenn Operationen inhaltlich mehrere Klassen betreffen und etwas Übergeordnetes darstellen, ist dies ein
deutlicher Indikator zur Erfindung einer Steuerungsklasse.
Schnittstellenklasse „interface“
Schnittstellenklassen sind abstrakte Definitionen rein funktionaler Schnittstellen.
- Definieren gewöhnlich keine Attribute
- Haben keine Instanzen
- Definieren eine Menge abstrakter Operationen
- Definieren für diese Operationen häufig Vor- und Nachbedingungen
Schnittstellenobjekt „boundary“
Spezielle konkrete Objekte, die eine spezielle Sicht auf eine Menge anderer Objekte liefern. (z.B.
Kundensicht)
Typ „type“
Definieren eine Menge von Operationen und Attributen
Primitive Klasse „primitive“
Repräsentieren elementare Klasse der verwendeten Programmiersprache, z.B. integer, string etc.
Datentyp, Datenstruktur „data-type“
Sind Klassen mit gewöhnlich mehreren einfach Attributen, deren Typen wiederum primitive Klassen oder
andere Datenstrukturen sind.
Aufzählung „enumeration“
Aufzählbare Wertemengen, wie beispielsweise Familienstand = {ledig, verheiratet, geschieden,
verwitwet}
Komponenten
Komponenten (Person) und Komponenteninstanzen (Gabi) sind zu unterscheiden.
Komponenten sind im Gegensatz zu Klassen prinzipiell ohne weitere Eingriffe austauschbar.

Mirco Holtkamp Seite 22 10.03.2009


Strukturdiagramm Verhaltensdiagramm Architekturdiagramm
Klassendiagramm Interaktionsdiagramm Kompositionsdiagramm
Sequenzdiagramm Verteilungsdiagramm
Kollaborationsdiagramm
Aktivitätsdiagramm
Zustandsdiagramm
Use-Case-Dialog

3.3.1 Systemidee
- Entwickle die Systemidee zusammen mit Auftraggeber, Produktempfänger, Benutzer und Entwickler
unter aktiver Klärung von Interessenskonflikten und Widersprüchen.
- Formuliere die Systemidee kurz und knapp aber unbedingt schriftlich mit etwa 5- 20 Sätzen.
Berücksichtige die wichtigsten Eigenschaften, Leistungsmerkmale, Rahmenbedingungen,
Voraussetzungen und expliziten Leistungsausschlüsse.
- Sorge dafür, dass Arbeitgeber, Produktempfänger, Benutzer und Entwickler die Systemidee kennen und
vorbehaltlos unterstützen.

3.3.2 Stakeholder
- Identifiziere die Interessenhalter (Stakeholder).
- Bewerte die Wichtigkeit der Interessenhalter anhand von Relevanz und Risiko.
- Identifiziere die Projekt-Ansprechpartner
- Unterscheide die Ansprechpartner in Fachexperten, Anforderungsverantwortlichkeiten und
Systembetroffene.
- Beschreibe die Ziele und Interessen der einzelnen Stakeholder.
- Identifiziere bestehende Probleme und Schwachstellen aus Sicht der Stakeholder.
- Beschreibe die wichtigen geforderten Systemeigenschaften aus Sicht der Stakeholder

3.3.3 Business-Use-Case
- Entscheide, ob Geschäftsanwendungsfälle identifiziert werden sollen.
- Identifiziere die Geschäftsanwendungsfälle
- Identifiziere Anfang und Ende der Anwendungsfälle mit Hilfe von Auslösern und Ergebnissen
- Identifiziere die auszuführenden Geschäftsanwendungsfälle

Für jeden Geschäftsfall sollte notiert werden:


- Name
- Kurzbeschreibung (1-20 Zeilen)
- Akteur(e)
- Auslöser
- Ergebnis(se)

3.3.4 Anwendungsfälle essenziell beschreiben


- Identifiziere und beschreibe zu allen Geschäftsanwendungsfällen die geschäftliche Essenz, d.h. abstrakt
und technologieunabhängig die eigentlichen geschäftlichen Intentionen.

Mirco Holtkamp Seite 23 10.03.2009


- Unterscheide die wahrscheinlich stabilen von den wahrscheinlich sich ändernden Anforderungen.
- Definiere für jeden Geschäftsanwendungsfall die Auslöser, Vorbedingungen und eingehenden
Informationen.
- Definiere für jeden Geschäftsanwendungsfall die Ereignisse, Nachbedingungen und ausgehenden
Informationen.
- Beschreibe mit jedem Anwendungsfall nur genau einen kohärenten fachlichen Sachverhalt, d.h. teile
sie ggf. auf und benutze ggf. Enthält-Beziehungen („include“), um sie zu entkoppeln.
Essenzielle Schritte (Beispiel)
- Kunden identifizieren
- Reservierungswunsch aufnehmen
- Reservierungsmöglichkeit prüfen
- Kfz reservieren
- Reservierung bestätigen

3.3.5 Use- Case


- Identifiziere die konkreten Systemanwendungsfälle. Falls Geschäftsanwendungsfälle identifiziert wurden:
Entscheide, welche Geschäftsanwendungsfälle ganz oder teilweise systematisch umgesetzt werden
sollen.
- Zerlege die systemtechnisch umzusetzenden Geschäftsanwendungsfälle in zeitlich kohärente
Systemanwendungsfälle.
- Ergänze ggf. weitere Informationen wie Ansprechpartner, Risiko, Wichtigkeit, geschätzter Aufwand,
Stabilität etc.
Beschreibung
Ein Anwendungsfalldiagramm beschreibt die Zusammenhänge zwischen verschiedenen
Anwendungsfällen untereinander und zwischen Anwendungsfällen und den beteiligten Akteuren. Es zeigt
die Struktur und Zusammenhänge von verschiedenen Geschäftsvorfällen und wie mit ihnen verfahren
wird.

Akteur (Actor)
Ein Akteur ist ein ausserhalb des Systems agierender Beteiligter, der an der in einem Use Case
beschriebenen Interaktion beteiligt ist. Akteure nehmen in der Interaktion gewöhnlich eine definierte
Rolle ein. Ein Akteur kann ein physischer Anwender eines Systems oder ein anderes Systems sein, das die
Dienste eines Systems nutzt. Ein System hat eine spezifizierte Schnittstelle, die ein Akteur aufrufen kann.
Diese Schnittstelle kann mit einem Use-Case-Diagramm modelliert werden.
Extend
Eine Beziehung zwischen Use Cases mit dem Stereotyp «extend»:
Eine Extend-Beziehung zwischen Use Cases besagt, dass ein Use Case unter bestimmten Umständen bzw.
an einer bestimmten Stelle (dem sog. "Extension point") durch einen anderen erweitert wird. Diese andere
Use Case (der kein vollständiger Use Case ist) wird verwendet, wenn der ursprüngliche Use Case an den
”Extension point” gekommen ist.
Include
Eine Beziehung zwischen Use Cases mit dem Stereotyp «include»:
Eine Include-Beziehung zwischen Use Cases besagt, dass innerhalb eines Use Case ein anderer
vorkommt.
Dieses Konstrukt dient dazu, Abschnitte, die in mehreren Use Cases gleichermaßen vorkommen, zu
extrahieren, um so Redundanz zu vermeiden.
Der Use Case, der inkludiert wird, ist an sich ein vollständiger Use Case, der für sich selbst oder zusammen
mit anderen Use Cases ausgeführt werden kann.
Realize
Realisiert einen Geschäftsanwendungsfall in Form mehrerer Systemanwendungsfällen.

Mirco Holtkamp Seite 24 10.03.2009


Beschreibungsbeispiel eines Use-Case:

3.3.6 Klassendiagramm
- Identifiziere die wichtigsten fachlichen Gegenstände, die vom zu entwickelnden System repräsentiert
werden sollen, betrachte sie als Klassen und modelliere ihre strukturellen Zusammenhänge in einem
Klassendiagramm.
- Gib den Klassen sprechende Namen, benenne ihre Assoziationen und Assoziatonsrollen und
beschreibe soweit möglich ihre Multiplizitäten.
- Beschreibe geschäftliche Konstanten, Standardwerte und Aufzählungsmengen in Form von Klassen.

Mirco Holtkamp Seite 25 10.03.2009


Spezialitäten
Zusammenfassung von Klassen (Packete)
Um die Übersichtlichkeit in einem Klassendiagramm zu gewährleisten könne Klassen zu Paketen
zusammengefasst werden.

Interfaces
Interfaces (Schnittstellen) können wie folgt in einem Klassendiagramm dargestellt werden. Interfaces
werden meist mit einem „I“ als solches gekennzeichnet.

Komponenten
Wenn eine Klasse aus verschiedenen auswechselbaren Komponenten (Modulen) besteht, kann dies mit
kleinen Rechtecken an der Seite der Klasse dargestellt werden.

3.3.7 Fachliches Glossar anlegen


- Lege ein fachliches Glossar an und definiere dort alle wichtigen fachlichen Begriffe.
- Definiere Klassen und Assoziationsrollen des Klassenmodells, wichtige fachliche Gegenstände,
Konzepte und Zustände dieser Gegenstände als Begriff im Glossar.
- Definiere auch wichtige allgemeine und fachliche Prozesswörter im Glossar.
- Überprüfe alle Definitionen im Glossar.
Struktur des Glossar
- Begriff - Eventuelle ähnliche Begriffe oder
- Mögliche Synonyme Definitionen
- Definition (1-2 Sätze) - Einschränkungen auf bestimmte
Anwendungsbereiche

Mirco Holtkamp Seite 26 10.03.2009


- Verantwortlicher - Änderungshistorie
- Status
3.3.8 Aktivitätsdiagramm
- Zerlege jeden Anwendungsfallschritt aus der Anwendungsfallbeschreibung in eine oder mehrere
elementare Schritte und modelliere den Ablauf eines jeden Anwendungsfalls mit einem
Aktivitätsdiagramm.
- Modelliere für jeden Schritt alle vorgesehenen Ausnahmen und Verzweigungsmöglichkeiten.
- Leite aus dem vollständigen Ablauf die notwendigen Testfälle ab und realisiere sie ggf. sofort
Aktivitätsdiagramm = Ablaufdiagramm = FAD

3.3.9 Zustandsdiagramm
Ein Zustandsdiagramm beschreibt verschiedene Zustände einer Entität bzw. eines Objekts, das heisst
einen möglichen Lebenszyklus, sowie die Ereignisse, Bedingungen und Aktionen welche die Übergänge
(Transaktionen) zwischen diesen Zuständen verursachen.

Tipps / Regeln für Datenflussdiagramm


- Ein Zustand gehört genau zu einer Klasse

3.3.10 Sequenzdiagramm
Ein Sequenzdiagramm zeigt eine Menge von Interaktionen zwischen einer Menge ausgewählter Objekte
in einer bestimmten begrenzten Situation (Kontext) unter Betonung der zeitlichen Abfolge. Ähnlich dem
Kollaborationsdiagramm. Sequenzdiagramme können in generischer Form existieren (Beschreibung aller
möglichen Szenarien) oder in Instanzform (Beschreibung eines speziellen Szenarios).

Mirco Holtkamp Seite 27 10.03.2009


Tipps / Regeln für Sequenzdiagramm
- Zu jedem Anwendungsfall (Use-Case) besteht ein Sequenzdiagramm, das die möglichen Abläufe des
Anwendungsfalles beschreibt.
- Beim Sequenzdiagramm steht der zeitliche Aspekt im Vordergrund.

3.3.11 Kollaborationsdiagramm
Gemeinschaft von Rollen und anderen Elementen, die zusammenwirken, um ein kooperatives Verhalten
zu zeigen, das mehr ist als die Summe seiner Teile. Eine Kollaboration spezifiziert, wie ein Element, z.B.
einen Anwendungsfall oder eine Operation, die durch eine Menge von Klassifizierungen und
Assoziationen realisiert werden, die bestimmte Rollen spielen und in bestimmter Weise benutzt werden.
Das Kollaborationsdiagramm unterscheidet sich vom Sequenzdiagramm dadurch, dass die Betonung auf
den Beziehungen zwischen den Objekten und ihrer Topologie liegt; beim Sequenzdiagramm steht der
zeitliche Aspekt im Vordergrund.

3.4 Strukturierter Ansatz (S.76 in Comp. Struk.)


Umgebungsmodell Verhaltensmodell

Datenfluss-
Ereignistabelle
diagramm
Seite 35
Seite 38

Kontext- Mini
diagramm Strukturierte Spezifikation
Seite 36 Analyse Seite 43

System-
Data Dictionary
bezeichnung
Seite 42
Seite 37

ERM /ERD
Seite 53

Vorteile / Nachteile der Strukturierte Entwicklung


Vorteile Nachteile
- meist langjährige Erfahrung - Methodenbruch
- für prozedurale Aufgaben (Step by Step, - Redundanzen (Methoden)
Batch) - hoher Aufwand bei
- für Massendatenverarbeitung mit relativ Zusatzimplementierung
einfachen Datenstrukturen
- bei relativ stabilen Anforderungen

Mirco Holtkamp Seite 28 10.03.2009


- bei extremen Performance-Ansprüchen
(real Time Systeme)
- bei sequentiellem Projektvorgehen

3.4.1 Systemanalyse
Aktivitäten
- Anforderung ermitteln - Anforderungen simulieren und
- Anforderung festlegen und ausführen (exploratives Prototyping)
beschreiben - Anforderung verabschieden
- Anforderung analysieren
Qualitätsziele
- Vollständigkeit - Durchführbarkeit
- Konsistent - Abnahmetest geeignet
- Eindeutigkeit
3.4.2 Ereignistabelle
Eine Ereignistabelle beschreibt diejenige Ereignisse, die im System eine Funktion auslösen und eine oder
mehrere Antworten bzw. Reaktionen. Man unterscheidet zwischen externen und zeitlichen Ereignissen.

Tipps / Regeln für Ereignistabelle


- Es werden nur Ereignisse in die Liste aufgenommen, die eine Reaktion im System auslösen
- Die Ereignisliste ist als Vorarbeit für die eigentliche Modellierung gedacht
- Die Ergebnisse werden danach grafisch im Kontextdiagramm dargestellt.

3.4.3 Kontextdiagramm
Im Kontextdiagramm werden die Schnittstellen und deren Datenflüsse untersucht. Das Innenleben des
Systems wird dabei nicht untersucht → zeigt das System als Blackbox

Mirco Holtkamp Seite 29 10.03.2009


Systemkurzbeschreibung
Das Kontextdiagramm wird durch eine Kurzbeschreibung des Systems in Textform ergänzt.

3.4.4 Datenflussdiagramm
Mit dem Datenflussdiagramm soll das System in einer leicht verständlichen Form dargestellt werden. Ziel
ist es eine gemeinsame Kommunikationsbasis für alle im Entwicklungsprozess beteiligten Personen zu
erhalten.

Tipps / Regeln für Datenflussdiagramm


- konsistente Bezeichnung der Symbole verwenden
- In der Regel alle Pfeile beschriften
- Kreuzungen vermeiden
- Zur besseren Verständlichkeit können Externe Agenten redundant geführt werden
- Ein Datenflussdiagramm sollte nicht mehr als sieben (plus/minus zwei) Prozesse enthalten
- Eine Prozessbeschreibung sollte auf eine Seite passen

3.4.5 Mini Spezifikation


Eine Mini-Spezifikation (auch: MiniSpec, Prozessbeschreibung) ist eine inhaltliche Beschreibung eines
Prozesses.
Form
- Normale Text-Form - Pseudo-Code
3.4.6 Data Dictionary
Das Data Dictionary entsteht in der Definitionsphase und wird in der Entwurfs- und Realisierungsphase
weiter verwendet, ergänzt und verfeinert. Die erste Zielsetzung des Data Dictionary ist es, die in den
Datenflussdiagrammen verwendeten Bezeichnungen der Datenflüsse und Datenspeicher zu definieren.

Tipps / Regeln für Data Dictionary


- Grob definierte Daten werden im Data Dictionary detailliert
- Funktionsfähigkeit des Datenflussdiagrammes wird mit dem Data Dictionary geprüft
- Die Verfeinerung wird beendet wenn die Daten nicht weiter zerlegt werden können
- Jeder Datenflussname ist im Data Dictionary definiert
- Jeder Speicher trägt einen Namen
- Jeder Speichername ist im Data Dictionary definiert

3.4.7 Entity-Relationship-Modell (ERM)


Siehe Datenmodellierung

3.4.8 Funktions-Hierarchie-Diagramm
Das Funktions-Hierarchie-Diagramm zeigt die stufenweise Zerlegung von Funktionen. Die Anordnung der
Funktionen ist rein hierarchisch, d.h. es werden keine Angaben über Sequenz, Selektion und Iteration
gemacht; dennoch erleichtert eine „logische“ Reihenfolge der Funktionen das Verstehen des
Sachverhalts.

Mirco Holtkamp Seite 30 10.03.2009


3.4.9 Aktivitätsdiagramm
Siehe Objektorientiert

3.4.10 CRUD-Matrix

3.4.11 Strukturdiagramm
Strukturdiagramme (engl. Structure charts) werden zur grafischen Darstellung funktionaler Module
verwendet, um die Aufrufstruktur und den Datenfluss zwischen den Modulen deutlich zu machen.
Strukturdiagramme bestehen aus Rechtecken, welche die Aufrufhierarchie festlegen. Durch Datenpfeile
wird die Kommunikation zwischen Modulen beschrieben.

Notation
- Ein Pfeil mit weissem Kreis beschreibt eine Datenkommunikation, d.h. Daten, die verarbeitet werden,
werden übergeben.
- Ein Pfeil mit schwarzem Kreis beschreibt eine Status-Information (flag). Ein solche Information wird nicht
wirklich verarbeitet, sonder stellt Informationen über Daten bzw. die Verarbeitung bereit

Mirco Holtkamp Seite 31 10.03.2009


3.4.12 Zustandsdiagramm
Siehe Objektorientiert

4. Realisierung
Ziele
Das Ziel der Realisierung besteht darin, das neue System zu erstellen.
Aufgaben
- Realisierung des neuen Systems - Räumliche Anpassungen planen
- Organisation und Ablauf anpassen - Netzwerke anpassen
- Infrastruktur anpassen (Hardware/Netzwerk) - Hardware anpassen
- Aufbau Supportstelle - Datenmigration durchführen
- Testen - Aufbau Supportstelle
- Einführung planen
4.1 Testen (S. 81 in Comp. Testen)
4.1.1 Testprinzipen
- Zu jedem Testfall gehört das erwartete Ergebnis
- Ein Programmierer sollte nie sein eigenes Programm testen
- Das Ergebnis jedes Tests muss sorgfältig untersucht werden
- Testfälle sowohl für ungültige und unerwartete, als auch für erwartete Eingaben müssen erstellt werden
- Testfälle müssen reproduzierbar sein
- Testfälle müssen definiert und messbar sein
- Testen beweist nur die Anwesenheit von Fehlern, nicht aber deren Abwesenheit
- Testen ist keine Aufgabe für am Ende des Projekts, sondern sollte konstant während der Realisierung
durchgeführt werden.

4.1.2 V-Modell

4.1.3 Testprozess

4.1.3.1 Testmanagement 4.1.3.2 Testplanung


Planung, Steuerung und Kontrolle Organisatorischen und zeitlichen
des kompletten Testprozesses. Ablauf der Tests.

Mirco Holtkamp Seite 32 10.03.2009


4.1.3.3 Testspezifikation 4.1.3.6 Testauswertung
Zusammenfassung aller Tests mit
Fazit. Ergebnis -> Testbericht

4.1.3.4 Testdurchführung
Durchführung gemäss Testplan
4.1.3.5 Testaufzeichnung
Fehlermeldungen protokolliert und
priorisiert.

4.1.4 Testmethoden

4.1.4.1 Ereignistabelle

Entscheidungstabelle:
Tabellenbezeichnung R1 R2 R3 R4 R5 R6 R7 R8
Bedingungen
Bedingung 1 j j j j n n n n
Bedingung 2 j j n n j j n n
Bedingung 3 j n j n j n j n
Aktionen
Aktion 1 x x x
Aktion 2 x x
Aktion 3 x x x x x
Aktion 4 x x x
Aktion 5 x
Die Spalten R1 bis R8 bezeichnen die jeweiligen Regeln. Am
Beispiel der Regel 7 sei erläutert, wie die Regeln zu lesen sind: Wenn
die Bedingung 3 erfüllt ist, die Bedingungen 1 und 2 hingegen
nicht, dann sind die Aktionen 1 und 4 auszuführen.

4.1.5 Review und Audit


Review
Mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem
Projektergebnisse einem Team von Gutachtern (Gremium) präsentiert und von diesem kommentiert und
genehmigt werden.
Audit
Beim Audit wird die Vorgehensweise auf deren Angemessenheit, Einhaltung, Wirksamkeit überprüft.

Mirco Holtkamp Seite 33 10.03.2009


5. Einführung
Ziele
Das Ziel der Einführung besteht darin, das neue System dem Auftraggeber abzugeben und das Projekt formell
abzuschliessen.
Tätigkeiten
- Einführung - Erfahrungssicherung
- Schulung - Einführungsnachbearbeitung
- Abnahme - Projektauflösung
- Projektabschlussbericht
Aufgaben
- Einführung des neuen Systems - Übergabe der Projekt- und Systemdokumentation
- Schulung der Mitarbeiter - Erstellen des Projektauflösungsprotokoll
- Beim Auftraggeber den Antrag auf Projektschluss - Projektabschlusssitzung
stellen - Auflösen aller projekteigenen Ressourcen

5.1 Einführungsformen
5.1.1 Schlagartige Einführung
Vorteile Nachteile
- Einmalige, einfache Datenübernahme - Nach Einführung oftmals kein Weg zurück
- Keine Doppelbelastung für Benutzer - Hohes Einführungsrisiko

5.1.2 Schrittweise Einführung

Vorteile Nachteile
- Benutzer kann sich langsam an das neue System - Hohe Belastung für den Benutzer, da konstante
gewöhnen Veränderungen anfallen
- Erfahrungen können stufenweise gesammelt - Grosser Aufwand für die Erstellung von
werden temporären Schnittstellen

5.1.3 Parallel Einführung

Vorteile Nachteile
- Benutzer kann sich langsam in das neue - Sehr hoher IT Ressourcenbedarf,
System einarbeiten Netzauslastung
- Kleines Einführungsrisiko - Doppeleingabe der Daten oder Abgleich
5.2 Abnahmekriterien
- Die nötigen Prozesse sind definiert und etabliert
- Technische Administration ist geklärt
- Anwendungsbetreuung ist geklärt
- Know-how Transfer zwischen Entwicklern und Mitarbeitern ist vollzogen
- Dokumentationen liegen vor
- Technische Infrastruktur ist auf die Anforderungen angepasst
- System ist abgenommen
- Kommunikationswege sind definiert
- Wartungsvertrag ist abgeschlossen

5.3 Service Level Agreement


Ziele
- Erhöhung der Kundenzufriedenheit - Unterstützung des Kundenerfolgs

Mirco Holtkamp Seite 34 10.03.2009


- Erhöhung der Kostentransparenz - Ermitteln von Kostenverursachern
- Kostenkontrolle der vereinbarten - Vereinfachte Budgetierung von ICT
Dienstleistung Leistungen
- Transparenz der Leistungen und der - Qualität und Image verbessern
Verrechnung schaffen
Voraussetzungen
- SLA muss in der Leistungsbeschreibung - Feedbacksysteme über die
messbar sein Kundenzufriedenheit
- Klare Definition von Verantwortlichkeiten - Klare Definition der Servicegeber und
Servicenehmer

Vorteile Nachteile
- Gesicherter Grundstock für Qualität - Aufwendig
- Effiziente Kommunikation zwischen Kunden und - Geschäftsbeziehungen können unter Druck
ICT geraten
- Objektiv messbare Grössen für die - Leistungsdruck für Mitarbeiter steigt
Kostenverrechnung - Mitarbeiter haben das Gefühl überwacht zu
- Zuständigkeit ist klar definiert werden

5.4 Schulung
5.4.1 Gruppenschulung / Seminar
Vorteile Nachteile
- Breite Wissensvermittlung - Produktionsausfall Mitarbeiter
- Kostengünstig (Lehrpersonal) - Fehlende Anonymität, Angst in der Gruppe Fehler
- Gruppenzwang zu machen
- Konkurrenzverhalten steigert Effizienz - Oberflächlichkeit, Einstellung der Teilnehmer
- Feste Termine - Einzelbedürfnisse werden vernachlässigt
- Isolierter Raum
- Klares Themengebiet
- Vorbereitetes Lehrpersonal

5.4.2 Einzelschulung
Vorteile Nachteile
- Schulung 100% auf Bedürfnisse angepasst - Zeitaufwand
- Individuelle Betreuung, Stärken/Schwächen - Kosten
können optimal berücksichtigt werden - Störungsanfälligkeit
- Gute Lernkontrolle

5.4.3 Externe Schulung


Vorteile Nachteile
- Infrastruktur vorhanden - Reisespesen

Mirco Holtkamp Seite 35 10.03.2009


- Ablenkung vom Job - Reisezeit
- Keine Störungen - Abweichung der Schulinstallation von der
- Lehrpersonal kann in eigenen Räumen effizienter Businessinstallation
agieren

5.4.4 System – Unterstützende Schulung


Vorteile Nachteile
- Freie Zeitwahl für die Teilnehmer - Grosser Aufwand für Herstellung
- Keine Reisen - Setzt Eigeninitiative voraus

5.4.5 Learning by doing


Vorteile Nachteile
- Keine Schulungskosten - Überlastung des Help Desk
- Unzufriedenheit und Angst

5.4.6 Aufbau der Schulung


Aufgaben Beschreibung
Lernziele setzen Was müssen Sie nach der Schulung können.
Auswahl und Gliederung des Stoffes Welche Themengebiete sind zur Erfüllung der Lernziele
nötig.
Aufbau der Schulungseinheiten Phasengerechte Gliederung des Stoffes
Schulungsmethode Auswahl der Schulungsmethode
Ausarbeiten der Schulungsunterlagen Geeignete Form und Detaillierung der Unterlagen
ausarbeiten.
Hilfsmittel bereitstellen z.B. Beamer, Pinwand usw.

5.4.7 Lernerfolg Messbarkeit


- Prüfung (Diplom) - Effizienz / Durchlaufzeit
- Fehlerquote (Vorher/Nachher)
5.4.8 Kosten
Personalkosten
- Dozent - Spesen
- Arbeitsausfall - Organisation
Sachmittel
- Kursraum - Papier, Ordner, Schreibzeug
- Infrastruktur - Bücher, Lehrmittel
5.5 Administration
5.5.1 Projektabschlussbericht
- Beurteilung des gesamten Projektteams - Auflisten der Aufgaben
- Positive und Negative Erfahrungen - Begründung für Abweichung
- Aussagen über geplante und effektive
Kosten
5.5.2 Erfahrungssicherung
5.5.3 Einführungsnacharbeitung
5.5.4 Projektauflösung
- Beim Auftraggeber den Antrag auf - Offizielle Abschlusssitzung
Projektabschluss stellen
- Übergabe aller Dokumentationen
6. Wartung / Betrieb
6.1 Service Desk (S. 119 in ITIL)
Im Gegensatz zu den anderen Kapiteln wird hier kein eigentlicher IV-Service-Management-Prozess
beschrieben. Der Service-Desk ist eine Funktion, die mehrere Prozessen unterstützt.
Zielsetzung
Ziel des Service Desk ist die Unterstützung der vereinbarten Services.

Mirco Holtkamp Seite 36 10.03.2009


6.2 Störungs- Management(S. 45 in ITIL)
Das Incident Management nimmt alle Störungen, Anfragen und Aufträge der Anwender entgegen. Sein
primäres Ziel ist es, Störungen schnellstmöglich zu beheben. Der wichtigste Parameter für diesen Prozess ist eine
hohe Sofortlösungsrate.
Grundbegriffe
Service Requests -> Anfrage eines Anwenders zur Unterstützung
Problem -> Die Ursache für einen oder mehrere Incidents wird Problem genannt.
Known Error -> Ist die Ursache für ein Problem bekannt, so spricht man von „Known Error“.
Workaround -> Übergangslösung

6.3 Problem Management(S. 59 in ITIL)


Das Problem Management untersucht die Infrastruktur, um die Ursachen für (potenzielle) Störungen innerhalb
des IT-Service zu bestimmen.
Zielsetzung
Das Ziel des Problem Management besteht in der Vermeidung von Störungen. Um dieses Ziel zu erreichen, führt
das Problem Management sowohl proaktive als auch reaktive Aktivitäten aus.

Mirco Holtkamp Seite 37 10.03.2009


6.4 Config Management (S. 71 in Comp. Config)

6.4.1 Identifikation
Nachdem der Detaillierungsgrad festgelegt ist,
müssen alle Konfigurationseinheiten identifiziert und bezeichnet werden. Dazu werden Attribute erfasst.
Auf diese Weise wird eine eindeutige Erkennung der Konfigurationseinheit sichergestellt.

6.4.2 Kontrolle
Die Einträge in der CMDB werden von autorisierten Personen vorgenommen und gepflegt.

6.4.3 Statusüberwachung
Der Lebenszyklus einer Komponente muss genau verfolgt werden können, z.B. geplant, bestellt, geliefert,
getestet, installiert, entsorgt.

6.4.4 Plausibilisierung
Die CMDB muss jederzeit über aktuelle und integre (fehlerfreie und vollständige) Daten verfügen.

6.5 Release Management(S. 107 in ITIL)


Um die verschiedenen Versionen der Konfigurationseinheiten korrekt zu erstellen, muss ein effizientes Versions
und Release Management aufgebaut werden.

Nummern und Namenskonventionen


Softwareentwickler oder Systembetreuer verwenden Versionsbezeichnungen wie zum Beispiel: Version
10.2627.2625. Diese dreiteilige Versionsnummer setzt sich wie folgt zusammen:
Major Release
bezeichnet eine komplett neue, überarbeitete Version (z.B. Sprung von Word 2000 auf Word XP)
Architectural Release
Beinhaltet kleinere Funktionserweiterungen bzw. –Änderungen (z.B. zusätzliche Treiber oder Funktionen, die
beim Vorgängerrelease noch nicht implementiert bzw. nicht freigegeben waren, da sie noch nicht zuverlässig
funktionierten.)
Internal Release
Dieser wird erstellt wenn z.B. Fehler behoben werden sollen (z.B. Fixpack)

Baseline
Die Basis für alle weiteren Entwicklungen, d.h. die erste, „eingefrorene“ Version wird als Baseline bezeichnet.

Mirco Holtkamp Seite 38 10.03.2009


6.6 Change Management(S. 91 in ITIL)

Zunächst muss jeder Änderungsantrag registriert und mit einer eindeutigen Änderungsnummer versehen
werden.
Nach der Registrierung muss ein Änderungsantrag von einem zu definierenden Gremium
(Änderungsausschuss oder „Change Advisory Board“ autorisiert werden.

6.6.2 Klassifizierung
Nach der Registrierung und Autorisierung gilt es, die gewünschten Änderungen zu klassifizieren, d.h. einer
festgelegten Kategorie und Priorität zuzuordnen. Dieses „Priorisieren“ ermöglicht eine bessere
Überprüfung der Termine und eine effizientere Zuweisung der vorhandenen Ressourcen.

6.6. 3 Planung der Auswirkung und Ressourcen


Vor der Umsetzung eines autorisierten und klassifizierten Änderungsantrags müssen verschiedene Aspekte
berücksichtigt werden.
- Auswirkung auf die IT-Infrastruktur

Mirco Holtkamp Seite 39 10.03.2009


- Auswirkungen auf den Benutzerservice
- Auswirkungen auf den übrigen Service
- Auswirkungen bei Nichtdurchführung der Änderung
- Notwendige Ressourcen für die Durchführung
Koordination
Grundsätzlich müssen die geplanten Änderungen mit allen Beteiligten koordiniert und allen Betroffenen
rechtzeitig bekannt gegeben werden. Software-Änderungen sollten in einem Release zusammengefasst
werden. Die Zusammenfassung in einem Release bedeutet einerseits, dass mehrere Änderungen an
verschiedenen Orten gleichzeitig durchgeführt werden müssen. Andererseits können die Änderungen bei
eventuellem Fehlverhalten der Software in der Produktion mit einem Fall-Back-Verfahren geordnet
rückgängig gemacht werden.

Mirco Holtkamp Seite 40 10.03.2009