Download - FA Kochbuch IAD
Mirco Holtkamp Seite 1 10.03.2009
1. Vorstudie....................................................................... 2
1.1 Ziele................................................................................... 2
1.2 Anforderungskatalog .................................................... 2
1.2.1 Funktionale Anforderungen .............................................2
1.2.2 Nicht Funktionale Anforderungen ...................................2
1.2.4 Anforderungskatalog ........................................................2
1.3 Evaluation (S. 34 in Comp. Eval).................................. 3
1.3.1 Beschaffungsgründe .........................................................3
1.3.2 Vorbereitungen ..................................................................3
1.3.3 Pflichtenheft erstellen ........................................................3
1.3.4 Bewertungsdokumente (S. 54) .........................................4
1.3.5 Grobevaluation durchführen (S. 62) ...............................4
1.3.6 Detailevaluation durchführen (S. 63) ..............................4
1.3.7 Entscheidung treffen (S.71)...............................................4
1.3.8 Vertrag abschliessen (S. 73)..............................................5
1.3.9 Weitere Erhebungstechniken...........................................5
1.4 Arbeits- und Zeitplan ..................................................... 6
1.4.1 Strukturplan .........................................................................6
1.4.1.1 Aufwandschätztechniken ..................................................... 6 1.4.2 Tätigkeitsliste........................................................................6
1.4.3 Kostenplanung ...................................................................6
1.4.4 Balkendiagramm................................................................6
1.5 Lösungsvarianten ........................................................... 6
1.5.1 Benötigte Betriebsmittel ....................................................6
1.5.2 Beschaffendes Material ....................................................6
1.5.3 Risiken...................................................................................6
1.5.4 Zeitaufwand........................................................................6
1.5.5 Kostenplanung ...................................................................6
1.6 Projektauftrag................................................................. 7
2. Hauptstudie ................................................................. 7
2.1 Personaleinsatz ............................................................... 7
2.1.1 Rollenverteilung..................................................................7
2.1.2 Brutto-Personalaufwand ...................................................7
2.1.3 Personalressourceplan ......................................................8
2.2 Arbeitspaket.................................................................... 8
2.3 Sicherheit ......................................................................... 8
2.3.1 Höhere Gewalt ...................................................................8
2.3.2 Menschliches Versagen....................................................9
2.3.3 Kriminelle Handlung...........................................................9
2.3.4 Organisatorische Mängel .................................................9
2.4 Risikoanalyse ................................................................... 9
2.4.1 Systemabgrenzung ............................................................9
2.4.2 Definition des Datenbestandes .......................................9
2.4.3 Definition der Verletzbarkeit .............................................9
2.4.4 Definition der Bedrohung..................................................9
2.4.5 Risikoanalyse .......................................................................9
2.4.6 Schadensausmas und Eintrittwahrscheinlichkeit...........9
2.4.7 Massnahmen ....................................................................10
2.4.7.1 Hardware............................................................................... 10 2.4.7.2 Daten- und programmierbare Massnahmen ................... 10 2.4.7.3 Verbesserung der Verfügbarkeit ........................................ 10 2.4.7.4 Bauliche / Physische Sicherheit........................................... 10 2.4.7.5 Manipulation von Eingabe.................................................. 10 2.4.7.6 Gegen Manipulation............................................................ 10 2.4.7.7 Hacking und Spionage ........................................................ 10 2.4.7.8 Organisatorische Massnahmen.......................................... 10 2.4.7.9 Technische Massnahmen .................................................... 10
2.5 Authentisierung ............................................................ 11
2.6 Datenschutz / Strafrecht............................................. 11
2.6.1 Grundschutz (S. 48 in Comp. Grundschutz) .................12
2.6.1.1 Netzplanerhebung ............................................................... 13 2.6.1.2 Gruppengliederung ............................................................. 13 2.6.1.3 Erhebung Komponenten ..................................................... 13 2.6.1.4 Erhebung Applikationen...................................................... 13 2.6.1.5 Erhebung Systeme pro Applikation.................................... 13 2.6.1.6 Schutzbedarfskategorien definieren.................................. 13 2.6.1.7 Schutzbedarfsfeststellung .................................................... 13 2.6.1.8 Modellierung der Massnahmen.......................................... 14 2.6.1.9 Basis-Sicherheirscheck (Soll-/Ist-Vergleich)........................ 14 2.6.1.10 Priorisierung der Massnahmen .......................................... 14 2.6.1.11 Umsetungskostenplan /Realisierungsplan....................... 14
3. Detailstudie ................................................................ 14
3.1 Detailkonzept................................................................ 14
3.2 Modellierung (S.42 in Comp. Mapping)................... 15
3.2.1 ERM /ERD ...........................................................................16
3.2.1.1 Attributsliste............................................................................ 18 3.2.2 Datawarehouse ...............................................................19
3.2.2.1 Qualität der erhobenen Daten .......................................... 19 3.2.2.2 Probleme bei der Informationserhebung.......................... 19 3.2.2.3 Management Information System (MIS)............................ 19 3.2.2.4 Decision Support System (DSS)............................................ 19
3.2.2.5 Executive Information System (EIS)..................................... 20 3.2.2.6 Grundarchitektur .................................................................. 20 3.2.2.6 Data Mart .............................................................................. 20 3.2.2.8 Analysemethoden................................................................ 20
3.2.3 Applikationsarchitektur................................................... 21
3.2.4 Nezwerkplan .................................................................... 21
3.3 Objektorientierter Ansatz (S.87 in UML).....................21
3.3.1 Systemidee ....................................................................... 23
3.3.2 Stakeholder ...................................................................... 23
3.3.3 Business-Use-Case ........................................................... 23
3.3.4 Anwendungsfälle essenziell beschreiben.................... 23
3.3.5 Use- Case.......................................................................... 24
3.3.6 Klassendiagramm............................................................ 25
3.3.7 Fachliches Glossar anlegen........................................... 26
3.3.8 Aktivitätsdiagramm......................................................... 27
3.3.9 Zustandsdiagramm ......................................................... 27
3.3.10 Sequenzdiagramm ....................................................... 27
3.3.11 Kollaborationsdiagramm ............................................. 28
3.4 Strukturierter Ansatz (S.76 in Comp. Struk.)...............28
3.4.1 Systemanalyse ................................................................. 29
3.4.2 Ereignistabelle.................................................................. 29
3.4.3 Kontextdiagramm ........................................................... 29
3.4.4 Datenflussdiagramm ...................................................... 30
3.4.5 Mini Spezifikation ............................................................. 30
3.4.6 Data Dictionary ............................................................... 30
3.4.7 Entity-Relationship-Modell (ERM) .................................. 30
3.4.8 Funktions-Hierarchie-Diagramm.................................... 30
3.4.9 Aktivitätsdiagramm......................................................... 31
3.4.10 CRUD-Matrix ................................................................... 31
3.4.11 Strukturdiagramm.......................................................... 31
3.4.12 Zustandsdiagramm ....................................................... 32
4. Realisierung ................................................................ 32
4.1 Testen (S. 81 in Comp. Testen) ...................................32
4.1.1 Testprinzipen..................................................................... 32
4.1.2 V-Modell............................................................................ 32
4.1.3 Testprozess ........................................................................ 32
4.1.3.1 Testmanagement ................................................................. 32 4.1.3.2 Testplanung ........................................................................... 32 4.1.3.3 Testspezifikation..................................................................... 33 4.1.3.4 Testdurchführung ................................................................. 33 4.1.3.5 Testaufzeichnung.................................................................. 33 4.1.3.6 Testauswertung ..................................................................... 33
4.1.4 Testmethoden.................................................................. 33
4.1.4.1 Ereignistabelle ....................................................................... 33 4.1.5 Review und Audit ............................................................ 33
5. Einführung................................................................... 34
5.1 Einführungsformen .......................................................34
5.1.1 Schlagartige Einführung................................................. 34
5.1.2 Schrittweise Einführung................................................... 34
5.1.3 Parallel Einführung........................................................... 34
5.2 Abnahmekriterien ........................................................34
5.3 Service Level Agreement............................................34
5.4 Schulung ........................................................................35
5.4.1 Gruppenschulung / Seminar ......................................... 35
5.4.2 Einzelschulung.................................................................. 35
5.4.3 Externe Schulung............................................................. 35
5.4.4 System – Unterstützende Schulung............................... 36
5.4.5 Learning by doing ........................................................... 36
5.4.6 Aufbau der Schulung...................................................... 36
5.4.7 Lernerfolg Messbarkeit.................................................... 36
5.4.8 Kosten................................................................................ 36
5.5 Administration ...............................................................36
5.5.1 Projektabschlussbericht.................................................. 36
5.5.2 Erfahrungssicherung........................................................ 36
5.5.3 Einführungsnacharbeitung ............................................ 36
5.5.4 Projektauflösung.............................................................. 36
6. Wartung / Betrieb ..................................................... 36
6.1 Service Desk (S. 119 in ITIL) ..........................................36
6.2 Störungs- Management(S. 45 in ITIL) .........................37
6.3 Problem Management(S. 59 in ITIL)...........................37
6.4 Config Management (S. 71 in Comp. Config) .......38
6.4.1 Identifikation..................................................................... 38
6.4.2 Kontrolle ............................................................................ 38
6.4.3 Statusüberwachung ....................................................... 38
6.4.4 Plausibilisierung ................................................................ 38
6.5 Release Management(S. 107 in ITIL) .........................38
6.6 Change Management(S. 91 in ITIL) ..........................39
6.6.2 Klassifizierung.................................................................... 39
6.6. 3 Planung der Auswirkung und Ressourcen.................. 39
Mirco Holtkamp Seite 2 10.03.2009
1. Vorstudie
Ziele - Bedürfnis - Bereiche - Ziele
- Kosten - Länge
Aufgaben - Analyse Projektauftrag - Situationsanalyse - Ziele definieren - Risiken erkennen - Kosten-/Nutzenbetrachtung - Erstellung Phasenplan
- Erstellung Projektauftrag - Grobe Lösungsvarianten - Lösungsvarianten analysieren - Kosten-/Nutzenbetrachtung pro Variante - Bewertungsdokumente erstellen - Weiteres Vorgehen vorbereiten
1.1 Ziele
Nachdem der Projektantrag freigegeben wurde, müssen die Projektziele definiert werden. Kriterien - Lösungsneutral - Messbar
- Erreichbar - 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 Beschreibung der nötigen Anforderungen an das System Vollständigkeit Alle Anforderungen sind enthalten Widerspruchsfreiheit Gegenseitiges Widersprechen der Anforderungen ist eliminiert
Verständlichkeit In einer verständlichen Form für alle Beteiligten Eindeutigkeit Fehlinterpretionen werden vermieden Prüfbarkeit Anforderungen werden so definiert das diese Prüfbar sind
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
Die funktionalen Anforderungen erklären was das System machen muss.
Das Ticketsystem verfügt über eine Ein- und Ausgabemaske, die sich per Knopfdruck ausdrucken lässt.
1.2.2 Nicht Funktionale Anforderungen
Bei den nicht funktionalen Anforderungen wird die Leistung des Produkts beschrieben.
Ein Ticket am Service Desk lässt sich innerhalb von 30 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 3 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 - Erhöhte Kapazitätsanforderung - Neue Organisationsformen
- Geänderte Geschäftsaufgabe - Ablösung von Systemen - 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 4 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 - Nutzwertanalyse
- Risikoanalyse - Stärken- und Schwächenanalyse
Mirco Holtkamp Seite 5 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 - Schnellere Anpassung, Umstellung - Know-how im Hause - Unabhängigkeit - Entspricht exakt den Anforderungen
- Mehraufwand, Personalressourcen - Sicherheit - Mitarbeiterrisiko
Buy Vorteile Nachteile
- Konzentration auf Kerngeschäft - Verringerung der Personalkosten - Kosten kalkulierbar - Arbeit wird mit viel Know-how extern erledigt - Technik (Entwicklungstool müssen nicht beschafft
werden) - SLA bringt gute Absicherung - Dokumentation bereits vorhanden
- Abhängigkeit - Weniger Individuell - Umstellungskosten - Verlust von Schlüsselpersonen - Gezwungener Update
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 - Risikoprofil - Stärken-Schwächen-Analyse (SWOT) - Kiviatdiagramm
- Nutzenprofil - Kostendarstellung
Mirco Holtkamp Seite 6 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. - Arbeitspaketbezeichnung
- Vorgangsdauer -> inkl. Wartezeiten - 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 - Betriebsmittel
- Beschaffende Produkte
Mirco Holtkamp Seite 7 10.03.2009
1.6 Projektauftrag
In der Vorstudie werden viele Informationen zusammen getragen. Es wurden: - Ziele festgelegt - Struktur und Ablauf geplant
- Zeit und Kostenplan erstellt - Verschiedene Varianten geprüft
Der Projektauftrag enthält: - Ausgangslage - Umfang/Abgrenzung - Kurzbeschreibung des Ist-Systems - Ursache des Auftrages (Motivation) - Ziele - Lösungsvorschlag - Stärken/Schwächen der neuen Lösung
- Systembezogenen Restriktionen/Abhängigkeiten
- Termine - Budget - Dokumentation - Informationsverfahren
2. Hauptstudie
Ziele - Wer arbeitet im Projekt? - In welcher Organisationsform wird gearbeitet?
- Welche Aufgaben werden verteilt?
Aufgaben - Rollen verteilen - Personalressourceplanung - Arbeitspakete erstellen - Geschäftsereignisanalyse durchführen - Datenanalyse
- Konfiguration definieren - Schnittstellen definieren - Anforderungen an Datensicherheit festlegen - Anforderungen an Datenschutz festlegen - 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) - Know-how (notwendige Fachwissen)
- Einstellung (Motivation) - 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 - Ferien - Militär
- -Weiterbildung, Sitzungen - Ferien
Leistungskürzende Situationen - Neueinstellung
(Einarbeitungszeit) - Kündigung (Know-how Verlust) - Probezeit
- Versetzung - Teilzeitarbeit - Pensionierung
Mirco Holtkamp Seite 8 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
Formel = Aufwand / Vorgangsdauer = Aufwand pro
Person in Prozent
2. Personalkapazität
3. Vergleich
4. Bereinigung
2.2 Arbeitspaket
2.3 Sicherheit
2.3.1 Höhere Gewalt
- Defekte der Hardware, Stromversorgung, Klimaanlage
- Fehler im Betriebs- oder Kommunikationssystem
Mirco Holtkamp Seite 9 10.03.2009
- Feuer, Explosion im Rechenzentrum - Natürliche Naturkatastrophen
- Streik, Weggang von Schlüsselpersonen
2.3.2 Menschliches Versagen
- Programmabsturz aufgrund eines Programmfehlers
- Bedienungsfehler
- Fehlerhafte Produktion - Verlust der Vertraulichkeit durch
herumliegende Daten
2.3.3 Kriminelle Handlung
- Manipulation von Geräten - Missbrauch vertraulicher Daten - Diebstahl oder Kidnapping von
Geräten, Programmen oder Daten - Einbringen von bösartiger Software
(Viren)
- Hacking - Industriespionage - Vandalismus - Sabotage
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 - Wasserschaden
- etc
2.4.5 Risikoanalyse
Jetzt folgt die eigentliche Risikoanalyse.
2.4.6 Schadensausmas und Eintrittwahrscheinlichkeit
Mirco Holtkamp Seite 10 10.03.2009
2.4.7 Massnahmen
2.4.7.1 Hardware
- USV - Notstromaggregate - Kontrolle / Wartung Hardware,
Performacemessung
- RAID Systeme - Sicher für Harddisk und andere
Massenspeicher
2.4.7.2 Daten- und programmierbare Massnahmen
- Datenbanksicherungstechniken
- Replikation, Synchronisation redundanter Bestände
- Wiederanlaufpunkt in ein Programm einbauen
- Automatischer Neustart - Operationelle Datensicherung
(Abfangen von Benutzerfehler) - Zugriffsbeschränkung
2.4.7.3 Verbesserung der Verfügbarkeit
- Redundanzschaffung - Dokumentation (ermöglicht
schnellere und geplante Reaktionen)
- Stellvertretung und Schulung - Störungsüberwachung,
Monitoring
2.4.7.4 Bauliche / Physische Sicherheit
- Einbruchsschutz - Brandschutz - USV - Sicherheit bei der Verkabelung - Sicherheit bei auswärtigen
Geräteeinsatz (Notebook)
- Sicherheitsschleusen - Druckerstation abschliessen
(Einsatz in sensible Daten) - Zugang zu Gebäude
kontrollieren
2.4.7.5 Manipulation von Eingabe
- Funktionstrennung respektive Vieraugenprinzip
- Zugriffsschutzsysteme mit restriktiver Vergabe von Rechten
- Periodische Überprüfung von Stammdaten
- Protokollierung wesentlicher Transaktionen
- Interne Kontrollstelle 2.4.7.6 Gegen Manipulation
- Abnahmetest durch Fachbereiche
- Einsatz von Prüfsummen über produktive Programme
- Restriktiver direkter Zugriff auf produktive Programme
- Restriktiver Einsatz von Dienstprogrammen
2.4.7.7 Hacking und Spionage
- Logon mit starker Authentisierung
- Gut administrierte Zugriffschutzsysteme, insbesondere an den Netzeingängen
- Verschlüsselung von gespeicherten Daten
- Permanente Realtime- Überwachung der Netzwerke
- Einmalpassworte löschen - Gezwungener
Passwortwechsel - Gezielter Einsatz / Kombination
mehrerer Authentifizierungsmittel
- Firewall - Callback
2.4.7.8 Organisatorische Massnahmen
- Daten klassifizieren in Geheim, Vertraulich, Normal
- Benutzerbeschränkung - Clean Desk
- Aufteilung in Sicherheitszonen - Einschliessen von Datenträgern - Verhaltensregeln, Weisungen - Schulungen
2.4.7.9 Technische Massnahmen
- Zugriffsicherheit (Benutzeridentifikation, Passwort)
- Schutz gegen aussen, Callback, Firewall
- Schutz der eigenen Datenbestände (RAID, Backup)
- Verschlüsselung der Daten - Zentrale Verteilung von
Software - Berechtigung auf
Betriebsystemebene
Mirco Holtkamp Seite 11 10.03.2009
2.5 Authentisierung
Logische Merkmale - Passwort - Einmalpasswort - Abfragen von Spezialwissen - Anwendung von
Codierungsalgorithmen Physische Merkmale - Schlüssel - Ausweis - Automatisch lesbare Karten - Standalone Token – Generator,
Streichliste Biometrische Merkmale - Fingerabdruck - Handgeometrie - Netzhautmuster - Spracherkennung - Bildererkennung - Gewicht - Schriftenerkennung - Eingaberhytmus - Genetische Muster (DNA) Kombinierte Verfahren - Personalausweis
- Karte mit Personen spezifischen Zusatzpasswort (Magnetkarte)
- Standalone Token (Kombination mit Passwort
Indirekte Verfahren - Callback - Standorterkennung - Leitungsverschlüsselung Sicherheit Die gesetzten Sicherheitsbestimmungen müssen voll unterstützt werden. Kosten- / Nutzen Die Kosten müssen mit dem Nutzen übereinstimmen. Einfachheit Einfach zu erlernen. Erfassungsaufwand, Geschwindigkeit Die Geschwindigkeit muss in einem guten Verhältnis zur Sicherheitsstufe stehen. Benutzerakzeptanz Wichtiger Aspekt ist die Akzeptanz der User.
2.6 Datenschutz / Strafrecht
Der Grundgedanke des Datenschutzes liegt im Schutz des Persönlichkeitsrechts. Sicherheit = Prinzipiell: „Zustand ohne Gefahren“ Kurze Massnahmenübersicht: - Zugangskontrolle - Datenträgerkontrolle (Berechtigungen) - Transportkontrolle (Transfer) - Bekanntgabekontrolle
- Speicherkontrolle - Benutzerkontrolle - Zugriffskontrolle - Eingabekontrolle
Bestimmungen aus dem Strafrecht
Strafbestand Artikel Inhalt Urkundenfälschung StGB 251 Unbefugte Datenbeschaffung / StGB 143 Datendiebstahl, Datenspionage
Mirco Holtkamp Seite 12 10.03.2009
Datenspionage Unbefugtes Eindringen in ein Datenverarbeitungssystem
StGB 143bis Hacking
Datenbeschädigung StGB 144bis Sachbeschädigung, Viren Betrügerischer Missbrauch einer Datenverarbeitungsanlage
StGB 147 Computerbetrug, 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) - Verfügbarkeit (Availability)
- Integrität (Integrity) - Verbindlichkeit (Non-repudiation)
Bedrohung - Menschliches Versagen - Vorsätzliche Handlung - Technisches Versagen
- Höhere Gewalt - Organisatorische Mängel
Mirco Holtkamp Seite 13 10.03.2009
2.6.1.1 Netzplanerhebung
2.6.1.2 Gruppengliederung
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 werden, die im Netzplan durch ein einzelnes Objekt dargestellt wird.
2.6.1.3 Erhebung Komponenten
2.6.1.4 Erhebung Applikationen
2.6.1.5 Erhebung Systeme pro Applikation
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 Systeme
Schutzbedarfsfeststellung für Kommunikationen
Schutzbedarfsfeststellung für Räume
Mirco Holtkamp Seite 14 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 Organisation
Regelung des Passwortgebrauchs
1 CHF 0.- (2 Arbeitstage)
CHF 0.-
Serverraum Vermeidung von wasserführenden Leitungen
3 CHF 20'000.- (12 Arbeitstage)
CHF 0.-
Server S4 USV 1 CHF 1'000.- (1 Arbeitstag)
CHF 100.-
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 - Festlegung von Details über Ablauf und Produkte - Vertragsabschluss vornehmen (falls Externe
beteiligt) - Testdrehbuch vorbereiten - Schulung vorbereiten
- Datendesign fertig stellen - Online Dialog spezifizieren (Menüstruktur, etc) - Ablauffolge der logischen Transaktionen
festlegen - Testdrehbuch erstellen - 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 15 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 16 10.03.2009
3.2.1 ERM /ERD
Mirco Holtkamp Seite 17 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 18 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
W# Zahl Erste Ziffer: Weisswein 1, 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 19 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
ist nicht auffindbar - Informationen unvollständig - Datenmenge falsch
eingeschätzt
- Widerstände bei Befragung - Rahmenbedingungen ändern
sich - Betriebsblindheit
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 20 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
3.2.2.6 Data Mart
Autonomer Data Mart Unter einem Data Mart versteht man ein bereichspezifisches oder funktionales Data Warehouse.
Verteiltes Data Mart
Unternehmensweites Data Warehouse
Mehrschichtiges Data Warehouse
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 21 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 - 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
- fehlendes Know-how (Erfahrung)
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 22 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 23 10.03.2009
Strukturdiagramm Verhaltensdiagramm Architekturdiagramm
Klassendiagramm
Interaktionsdiagramm Sequenzdiagramm Kollaborationsdiagramm Aktivitätsdiagramm Zustandsdiagramm Use-Case-Dialog
Kompositionsdiagramm Verteilungsdiagramm
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 24 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 25 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 26 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 - Mögliche Synonyme - Definition (1-2 Sätze)
- Eventuelle ähnliche Begriffe oder Definitionen
- Einschränkungen auf bestimmte Anwendungsbereiche
Mirco Holtkamp Seite 27 10.03.2009
- Verantwortlicher - Status
- Änderungshistorie
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 28 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.)
Strukturierte
Analyse
VerhaltensmodellUmgebungsmodell
Ereignistabelle
Seite 35
Kontext-
diagramm
Seite 36
System-
bezeichnung
Seite 37
Datenfluss-
diagramm
Seite 38
Mini
Spezifikation
Seite 43
Data Dictionary
Seite 42
ERM /ERD
Seite 53
Vorteile / Nachteile der Strukturierte Entwicklung
Vorteile Nachteile
- meist langjährige Erfahrung - für prozedurale Aufgaben (Step by Step,
Batch) - für Massendatenverarbeitung mit relativ
einfachen Datenstrukturen - bei relativ stabilen Anforderungen
- Methodenbruch - Redundanzen (Methoden) - hoher Aufwand bei
Zusatzimplementierung
Mirco Holtkamp Seite 29 10.03.2009
- bei extremen Performance-Ansprüchen (real Time Systeme)
- bei sequentiellem Projektvorgehen
3.4.1 Systemanalyse
Aktivitäten - Anforderung ermitteln - Anforderung festlegen und
beschreiben - Anforderung analysieren
- Anforderungen simulieren und ausführen (exploratives Prototyping)
- Anforderung verabschieden
Qualitätsziele - Vollständigkeit - Konsistent - Eindeutigkeit
- Durchführbarkeit - Abnahmetest geeignet
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 30 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 31 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 32 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 - Organisation und Ablauf anpassen - Infrastruktur anpassen (Hardware/Netzwerk) - Aufbau Supportstelle - Testen - Einführung planen
- Räumliche Anpassungen planen - Netzwerke anpassen - Hardware anpassen - Datenmigration durchführen - Aufbau Supportstelle
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
Planung, Steuerung und Kontrolle des kompletten Testprozesses.
4.1.3.2 Testplanung
Organisatorischen und zeitlichen Ablauf der Tests.
Mirco Holtkamp Seite 33 10.03.2009
4.1.3.3 Testspezifikation
4.1.3.4 Testdurchführung
Durchführung gemäss Testplan
4.1.3.5 Testaufzeichnung
Fehlermeldungen protokolliert und priorisiert.
4.1.3.6 Testauswertung
Zusammenfassung aller Tests mit Fazit. Ergebnis -> Testbericht
4.1.4 Testmethoden
4.1.4.1 Ereignistabelle
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.
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.
Mirco Holtkamp Seite 34 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 - Schulung - Abnahme - Projektabschlussbericht
- Erfahrungssicherung - Einführungsnachbearbeitung - Projektauflösung
Aufgaben - Einführung des neuen Systems - Schulung der Mitarbeiter - Beim Auftraggeber den Antrag auf Projektschluss
stellen
- Übergabe der Projekt- und Systemdokumentation - Erstellen des Projektauflösungsprotokoll - Projektabschlusssitzung - Auflösen aller projekteigenen Ressourcen
5.1 Einführungsformen
5.1.1 Schlagartige Einführung
Vorteile Nachteile - Einmalige, einfache Datenübernahme - Keine Doppelbelastung für Benutzer
- Nach Einführung oftmals kein Weg zurück - Hohes Einführungsrisiko
5.1.2 Schrittweise Einführung
Vorteile Nachteile
- Benutzer kann sich langsam an das neue System gewöhnen
- Erfahrungen können stufenweise gesammelt werden
- Hohe Belastung für den Benutzer, da konstante Veränderungen anfallen
- Grosser Aufwand für die Erstellung von temporären Schnittstellen
5.1.3 Parallel Einführung
Vorteile Nachteile
- Benutzer kann sich langsam in das neue System einarbeiten
- Kleines Einführungsrisiko
- Sehr hoher IT Ressourcenbedarf, Netzauslastung
- 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 35 10.03.2009
- Erhöhung der Kostentransparenz - Kostenkontrolle der vereinbarten
Dienstleistung - Transparenz der Leistungen und der
Verrechnung schaffen
- Ermitteln von Kostenverursachern - Vereinfachte Budgetierung von ICT
Leistungen - Qualität und Image verbessern
Voraussetzungen - SLA muss in der Leistungsbeschreibung
messbar sein - Klare Definition von Verantwortlichkeiten
- Feedbacksysteme über die Kundenzufriedenheit
- Klare Definition der Servicegeber und Servicenehmer
Vorteile Nachteile
- Gesicherter Grundstock für Qualität - Effiziente Kommunikation zwischen Kunden und
ICT - Objektiv messbare Grössen für die
Kostenverrechnung - Zuständigkeit ist klar definiert
- Aufwendig - Geschäftsbeziehungen können unter Druck
geraten - Leistungsdruck für Mitarbeiter steigt - Mitarbeiter haben das Gefühl überwacht zu
werden
5.4 Schulung
5.4.1 Gruppenschulung / Seminar
Vorteile Nachteile - Breite Wissensvermittlung - Kostengünstig (Lehrpersonal) - Gruppenzwang - Konkurrenzverhalten steigert Effizienz - Feste Termine - Isolierter Raum - Klares Themengebiet - Vorbereitetes Lehrpersonal
- Produktionsausfall Mitarbeiter - Fehlende Anonymität, Angst in der Gruppe Fehler
zu machen - Oberflächlichkeit, Einstellung der Teilnehmer - Einzelbedürfnisse werden vernachlässigt
5.4.2 Einzelschulung
Vorteile Nachteile - Schulung 100% auf Bedürfnisse angepasst - Individuelle Betreuung, Stärken/Schwächen
können optimal berücksichtigt werden - Gute Lernkontrolle
- Zeitaufwand - Kosten - Störungsanfälligkeit
5.4.3 Externe Schulung
Vorteile Nachteile - Infrastruktur vorhanden - Reisespesen
Mirco Holtkamp Seite 36 10.03.2009
- Ablenkung vom Job - Keine Störungen - Lehrpersonal kann in eigenen Räumen effizienter
agieren
- Reisezeit - Abweichung der Schulinstallation von der
Businessinstallation
5.4.4 System – Unterstützende Schulung
Vorteile Nachteile - Freie Zeitwahl für die Teilnehmer - Keine Reisen
- Grosser Aufwand für Herstellung - 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) - Fehlerquote (Vorher/Nachher)
- Effizienz / Durchlaufzeit
5.4.8 Kosten
Personalkosten - Dozent - Arbeitsausfall
- Spesen - Organisation
Sachmittel - Kursraum - Infrastruktur
- Papier, Ordner, Schreibzeug - Bücher, Lehrmittel
5.5 Administration
5.5.1 Projektabschlussbericht
- Beurteilung des gesamten Projektteams - Positive und Negative Erfahrungen - Aussagen über geplante und effektive
Kosten
- Auflisten der Aufgaben - Begründung für Abweichung
5.5.2 Erfahrungssicherung
5.5.3 Einführungsnacharbeitung
5.5.4 Projektauflösung
- Beim Auftraggeber den Antrag auf Projektabschluss stellen
- Übergabe aller Dokumentationen
- Offizielle Abschlusssitzung
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 37 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 38 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 39 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 40 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.