M157 IT System Einführung P1

Verschiedene Dokumentationsarten

Installationsdokumentation

Die Installationsdokumentation umfasst:

• Hardware und Software: Alle benötigten Komponenten für die Installation.
• Schritt-für-Schritt-Anleitung: Detaillierte Anweisungen zur Installation, Anfangs-Konfiguration und Testmöglichkeiten (Funktionstest der Rohinstallation inkl. Testkonzept).
• Darstellung: Tabellen und Screenshots zur bildhaften Dokumentation.
• Zusätzliche Informationen: Lizenzschlüssel, Hardwarespezifikationen und Peripherie.

Betriebsdokumentation

Die Betriebsdokumentation enthält:

• Informationen für Administratoren: Notwendig für den täglichen Betrieb.
• Notfallkonzept: Zentralisierte Informationen im Notfallhandbuch.
• Wichtige Konfigurationen: Konfigurationsdateien, Updates, Zugänge, Einstellungen (Passwörter in Passwortliste).
• Wartungsbefehle: Back-ups, Funktionstests, Logdateien, "Morning Checks" usw.

das sind ofach sini unterlaga zemmagfasst. schrieben bitte passwörter ned ofach i a lista ine

Benutzerdokumentation

Die Benutzerdokumentation umfasst:

• Handbücher für Anwendungen: Anleitung für Endanwender mit wenig Informatikkenntnissen.
• Problemlösung: Vorgehen bei Problemen (Hotline, Kontaktmöglichkeiten).
• Client-Software Konfigurationen: Einstellungen, die Benutzer vornehmen müssen, um mit dem Serversystem (z.B. Internetserver, Dateiserver, Mailserver) zu kommunizieren.

Prüfungsrelevante Zusammenfassung: Kapitel 1 bis 1.8

1 Anforderungen analysieren

1.1 Kundenanforderungen

• Requirements Engineering: Entscheidend für den Erfolg eines Projekts. Missverständnisse oder unvollständige Anforderungen führen zu fehlerhaften Systemen.
• Kano-Modell:
  • Basisfaktoren: Grundlegende Anforderungen, die bei Nichterfüllung Unzufriedenheit hervorrufen.
  • Leistungsfaktoren: Erwartete Merkmale, deren Erfüllung Zufriedenheit erzeugt.
  • Begeisterungsfaktoren: Unbekannte Merkmale, die beim Entdecken Begeisterung auslösen.

der scheiss hon mir mol bim bolis ka

1.1.1 Arten von Anforderungen

• Funktionale Anforderungen: Beschreiben, was das System tun muss.
• Qualitätsanforderungen: Betreffen Leistung, Verfügbarkeit, Zuverlässigkeit usw.
• Randbedingungen: Einschränkungen, die die Handlungsfähigkeit des Systems begrenzen.

1.1.2 Einteilung von Anforderungen nach rechtlicher Verbindlichkeit

• Verwendung von Schlüsselwörtern wie must, should, may, um rechtliche Verbindlichkeiten zu definieren.

1.2 System und Kontext: IST und SOLL

1.2.1 Der Systembegriff

• Ein System ist ein dynamisches Ganzes mit miteinander verbundenen Teilen.

1.2.2 Systemabgrenzung

• Definition von Systemgrenzen zur Abgrenzung des geplanten Systems von seiner Umgebung.

1.2.4 IST-Zustand

• Dokumentation der aktuellen Situation zur Identifikation von Stärken und Schwächen.

1.2.5 Was ist ein Problem?

• Diskrepanz zwischen IST-Zustand und SOLL-Vorstellung wird als Problem wahrgenommen.

1.2.6 Problemlösung

• Systematischer Ansatz zur Überführung des IST-Zustands in den SOLL-Zustand.

1.2.8 Anforderungen definieren

• Anforderungen als zentraler Bestandteil des Pflichtenhefts.

1.3 Restriktionen und Rahmenbedingungen

• Funktionale Anforderungen: Beschreiben was das System tun soll (z.B. Funktionen, Aufgaben).
• Nicht-funktionale Anforderungen: Beschreiben wie gut das System seine Aufgaben erfüllen soll (z.B. Leistung, Zuverlässigkeit, Sicherheitsaspekte).
• Rahmenbedingungen und Restriktionen: Einschränkungen, die die Lösungsmöglichkeiten begrenzen.

1.4 Spezifikation von Komponenten

• Nutzung von verschiedenen Techniken und Aktivitäten zur Spezifikation der Anforderungen, z.B. UML.

1.5 Konzeptionelle Darstellung eines IT-Systems

• UML-Diagramme: Verschiedene Perspektiven zur Beschreibung von Systemen, wie Struktur-, Funktions- und Verhaltensperspektive.

es isch zwor meh für entwicklig (OOP) und databanka aber i hinterfrögs ned

1.6 Anforderungsschablonen

• Verwendung von Satzschablonen zur Formulierung funktionaler Anforderungen.

1.7 Evaluation

• Evaluationsphase ist situativ im Projektablauf einzuordnen, um Angebote zu analysieren und bewerten.

1.7.2 Die Evaluationsmatrix

• Nutzung einer Matrix zur Bewertung von Anforderungen und deren Erfüllungsgrad.

1.8 Aspekte der Migration

• Umsetzungskonzept: Beantwortung der Fragen: Was, Wie, von wem und bis wann umgesetzt werden soll.

Prüfungsrelevante Zusammenfassung: Software-Migration Powerpoint

Definition von Software-Migration

• Software-Migration bezeichnet den Prozess der Übertragung von Software, Daten oder IT-Systemen von einer Umgebung, Plattform oder Technologie zu einer anderen.

Gründe für Software-Migration

• Umstellung auf moderne Technologien
• Verbesserte Leistung und Skalierbarkeit
• Erhöhte Sicherheit und Kosteneffizienz
• Unterstützung neuer Geschäftsanforderungen

Arten der Software-Migration

1. Daten-Migration: Übertragung von Daten zwischen Systemen.
2. Anwendungs-Migration: Verschieben von Anwendungen auf neue Plattformen oder Umgebungen.
3. Plattform-Migration: Wechsel der zugrunde liegenden Infrastruktur oder Technologie.
4. Versions-Migration: Aktualisierung auf neue Softwareversionen.

Herausforderungen bei der Software-Migration

• Kompatibilitätsprobleme: Sicherstellen, dass neue und alte Systeme kompatibel sind.
• Datenintegrität und Verlust: Gewährleistung, dass keine Daten verloren gehen oder beschädigt werden.
• Minimierung von Ausfallzeiten: Minimierung der Betriebsunterbrechungen während des Migrationsprozesses.
• Mangel an Fachkräften: Verfügbarkeit von qualifiziertem Personal zur Durchführung der Migration.

Vorteile der Software-Migration

• Zugang zu neuen Funktionen: Nutzung verbesserter Software-Features.
• Bessere Leistung und Effizienz: Optimierung der Systemleistung.
• Verbesserte Sicherheit und Compliance: Erfüllung von Sicherheitsstandards und Vorschriften.
• Flexibilität und Skalierbarkeit: Anpassungsfähigkeit an wachsende Geschäftsbedürfnisse.

i han so ko lust meh