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


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


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


- 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


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


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


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


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


- 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


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


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


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


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


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.


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


3.2.1 ERM /ERD


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)


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


L# AutoWert AutoWert = Zahl

PLZ Zahl -

Lieferant Text -

Adresse Text -

Wein


W# Zahl Erste Ziffer: Weisswein 1, Rotwein 2, Champagener 3

L# Zahl -

Bezeichnung Text -

Inhalt Zahl -

Preis Währung -

Jahrgang Zahl -

Bestellung


B# Zahl -

K# Zahl -

W# Zahl -

Menge Zahl -

PreisTot Währung -

Datum Datum -

Ort


PLZ Zahl -

Ort Text -

Kundenart


KA# AutoWert AutoWert = Zahl

Bezeichnung Text -


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


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)


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.


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.


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.


- 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.


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.


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


- 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).


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


- 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


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.


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


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.


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.


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


- 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


- 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.


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.


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.


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


- 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.

Date post:	25-Jun-2015
Category:	Documents
Upload:	tommyr25
View:	551 times
Download:	0 times

FA Kochbuch IAD

Documents