VL

Verfahrensweisen, die durch Informationstechnik ermöglicht oder unterstützt, aber auch erst erforderlich werden.

In Software umgesetzte Methoden, die durch den Einsatz von Informationstechnik erforderlich sind. Werkzeuge (synonym tools) erfüllen einen oder mehrere Zwecke.

zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresysteme

In Software umgesetzte Methoden, die durch den Einsatz von Informationstechnik erforderlich sind. Werkzeuge erfüllen einen oder mehrere Zwecke.

• Branchen-spezifische Software

• Brachen-neutrale Software

• Standard-Software

• Individual-Software

• On-Premise

• Software-as-a-Service

Probleme:

• Schnelle Veränderungen

• Komplexe Tool-Ökosysteme

• Vorherrschende Paradigmen

• Geringe Vergleichbarkeit

• Unbekannte Anforderungen

• Evolution der Werkzeuge

• Zweckentfremdung von Werkzeugen

Gegenmittel:

• Standardisierung

• Visuelle interaktive Analysen

• Mitarbeiter-Entwicklung

  • Zertifizierung

  • "Train the Trainer" Ansatz

  • Messen

• Co-Development

• Beratung

ITMW-Verständnis

• Zusammenspiel von IT-Methoden und Werkzeugen

• Bewertung von ITMW

ME ist eine Methode zur systematischen Erstellung von Methoden

• Wichtige Prinzipien: meta-modeling, reuse, modularity und flexibility

Method Engineering in the fiel of information systems is the “discipline to construct new methods from existing methods.” It focuses on the “design, construction and evaluation of methods, techniques and support tools” for information systems development.

• Aktivität

  • Planbare Verrichtungseinheit in Ablauffolge, die Ergebnisse erzeugen

• Ergebnisse

  • Input und Output von Aktivitäten, die verändert oder genutzt werden

• Rolle

  • Zusammenfassung von Entwurfsaktivitäten aus Sicht eines Aufgabenträgers

• Metamodell

  • Struktur von Entwurfsdaten über alle Entwurfsergebnisse als Datenmodell

• Techniken

  • Anleitungen, wie Entwurfsergebnisse erzeugt werden können

SD

• Projektvorbereitung

  • Projektziele festlegen

  • Methodische Vorbereitungen

  • Organisatorische Vorbereitungen

• Ist-Analyse

• Soll-Konzeption

• Systemevaluation

• (Customizing & Installation)

• (Schulung)

1. Vorbereitung

• Stakeholder-Analyse

• Ist-Situation erheben

• Vorgehen festlegen

2. Anforderungen erheben

• Features

• Szenarien

• K.O.-Kriterien

• Lastenheft erstellen

3. Marktübersicht

• Longlist erstellen

• Shortlist erstellen

• Request for Information (RFI)

• Request for Proposal (RFP)

4. Demonstration

• 2-3 zur Demonstration

• 1-2 Testinstallation

• Stakeholder Feedback

5. Entscheidung

• Preisverhandlungen

6. Einführung

• Datenmigration

• Schulung

Ziel:

• Ermittlung der Anforderungen des Auftraggebers an das zu entwickelnde System.

Mittel:

• Anforderungen werden schriftlich in einem Dokument (Anforderungskatalog) festgehalten.

Bedeutung:

• Entscheidender Einfluss auf den Prozess/Projektverlauf.

• Wesentlicher Bestandteil zur Sicherung von Qualität und Produktivität.

• Beeinflusst Akzeptanz und Wartbarkeit durch Entwicklung der Anforderungen im direkten Dialog mit Kunden und Anwendern.

• Phasen der Anforderungsanalyse:

  1. Aufnahme und Erfassung

  2. Strukturierung und Abstimmung

  3. Prüfung und Bewertung

Probleme:

• Fachbegriffe der Softwaretechnik sind Anwendern/Auftraggebern nicht vertraut.

• Fachbegriffe des Kunden sind Entwicklern unbekannt.

• Notwendigkeit einer Interpretationsfunktion.

• "Übersetzung" der beiden Begriffswelten erforderlich.

• Begriffsdefinitionen im Dokument vorsehen.

1. Ausgangssitation und Zielsetzung

2. Produkteiinsatz

3. Produktübersicht

4. Funktionale Anforderungen, Nichtfunktionale Anforderungen (Funktionalität, Benutzbarkeit, Zuverlässigkeit, Effizienz, Änderbarkeit, Übertragbarkeit)

5. Risikoakzeptanz

6. Skizze des Lebenszyklus und der Systemarchitektur

7. Lieferumfang

8. Abnahmekriterien

• Innovation

• Mehrwert schaffen

• Wettbewerbsfaktor

• stabiler Betrieb Kosten sparen

• Der unklare Wertbeitrag der IT

• Konzentration auf Informatikmethoden

• Die gedankliche und führungstechnische Trennung zwischen Business und IT

• Finanzplanung

• Kostencontrolling

• Analysen

• Benchmarking

Als Ziel wird häufig die “Bill of IT” genannt, d.h. die Aufschlüsselung einzelner Leistung, deren Beitrag und Kosten. (Gemeinsamkeit mit IT-Service-Management)

• Schwierige Kostenverteilung aufgrund vielschichtiger IT-Kosten.

• IT oft unter den größten Kostenblöcken.

• Verhältnis von Betriebs- zu Investitionsausgaben im Schnitt 80% zu 20%.

• Ziel: Mehr Geld für Geschäftsziele durch Verlagerung zu Investitionsausgaben.

• Vermeidung von Investitionen, die als Betriebsausgaben realisierbar sind (z.B. durch Cloud Computing oder Outsourcing).

Praktiker:

• Menschen, die Strategien umsetzen.

Praktiken:

• Beschreiben Routinen, Normen und Werkzeuge der Strategieumsetzung.

• In Sets von (Teil-)Praktiken gebündelt.

Praxis:

• Umfasst konkrete soziomaterielle "strategische Handlungen".

• Bezieht sich auf geteilte Routinen und angeeignete Artefakte der Strategieumsetzung.

• Episoden folgen wiederholten, sequenziellen "Prozess"-Mustern

• Strategy Execution Gap:

  • Lücke zwischen Strategieentwicklung und -umsetzung.

• Strategy Awareness:

  • Mangelnde strategische Bewusstheit und Verständnis.

Business Process Management ist ein systematischer Ansatz, um sowohl automatisierte als auch nicht automatisierte Prozesse zu erfassen, zu dokumentieren, zu optimieren, auszuführen. zu messen und zu überwachen.

Unternehmensarchitektur stellt ein aggregiertes Gesamtbild einer Organisation dar mit dem Ziel, die Gesamtzusammenhänge zu strukturieren und gleichzeitig den Korridor für die zukünftige Entwicklung und Gestaltung aufzuzeigen.

• Behandelt institutionalisierte Prozesse, Aktivitäten und Rollen.

• Umfasst Planung, Entscheidung, Durchführung und Kontrolle des IT-Einsatzes in Unternehmen.

• Betont die untrennbare Verbindung von fachlichen und technischen Aspekten.

• Software-Entwicklung (SE):

  • Auch bekannt als Software Engineering oder Softwaretechnik.

  • Zielgerichtete Bereitstellung und systematische Anwendung von Prinzipien, Methoden und Werkzeugen für die ingenieurmäßige Entwicklung und Anwendung umfangreicher Softwaresysteme.

CASE (Computer Aided/Assisted Software Engineering):

• Begriff für rechnergestützte Softwareentwicklung.

• Betont den wesentlichen Einsatz von Werkzeugen.

Umfasst den Bauplan und die Konstruktionsregeln eines Softwaresystems. Sie kann auf unterschiedlichen Granularitätsebenen spezifiziert werden. Konstruktionsregeln für Softwarearchitekturen werden insbesondere durch Architekturmuster bestimmt.

Fachliche Sicht

• Anforderungen, Kooperation & Benutzbarkeit

Statische Sicht

• Subsysteme, Schnittstellen,Beziehungen & Verantwortlichkeiten

Verteilungssicht

• Rechner, Prozesse & Netzwerke

Laufzeitsicht

• Interaktion, Synchronisation & Performanz

• Verschlechterung der ursprünglichen Struktur einer IT-Lösung.

• Entsteht durch unkoordinierte Änderungen oder Vernachlässigung der Designprinzipien.

• Kann zu Problemen bei Wartung, Skalierung und Erweiterung führen.

  
  

• Software ist schwerer zu verstehen

• Erweiterungen verursachen viele Seiteneffekte

  • Zeit & Kosten steigen

  • Neue Fehler werden produziert

• Erfüllung der Qualitätsmerkmale sinkt

Bad Smell (“Gott-Klasse”)

• enthält 90% des Quelltextes und ist für alles zuständig

Methoden, die mehrere Bildschirmseiten lang sind

• sind schlecht wartbar

Klassen mit mehreren hundert Methoden/Exemplarvariablen

• sind meist zu groß

—> Gleichmäßig große Klassen, Packages, Subsysteme und Schichten entwerfen

• God Class: Steuerung der Oberfläche, Steuerung der fachlichen Abläufe, Datenbankverbindung

  • mit Namen {} Manager, {*} Service

• Kopplung: Steuerungsklassen benutzen 100-150 andere Klassen

  • kein objektorientierter sondern ein prozedualer Entwurf

—> Ausgewogene Größenverhältnisse führen zu geringerer Kopplung

• Zweck:

  • Bewertung und Analyse von Softwarearchitekturen.

• Schwerpunkte:

  • Identifikation von kritischen Architekturszenarien.

  • Bewertung von Qualitätsattributen

• Ziele:

  • Früherkennung von Risiken und Schwächen in der Architektur.

  • Unterstützung bei Entscheidungen durch Trade-off-Analysen.

  • Ableitung von Handlungsempfehlungen für Architekturverbesserungen.

• Bewertungsmethode

  • Stakeholder Methode vorstellen, Bedeutung von Qualitätszielen klarstellen

• Geschäftsziele vorstellen

  • wichtigste Projektziele & Faktoren, die für wirtschaftlichen Erfolg notwendig sind

• Architektur präsentieren

  • Mit Bezug auf vorher genannten Geschäftsziele

• Architekturansätze identifizieren

  • Welche Lösungsansätze für welche Einflussfaktoren verwendet, Architekturstile, Muster, keine Analyse

• Qualitätsbaum erstellen

  • Qualitätsmerkmale identifizieren, durch Sezenarien priorisieren

• Architekturansätze analysieren (1)

  • Zusammenhänge zwischen wichtigsten Szenarien & Architekturenentscheidungen herstellen, um zu belgen dass Architektur die Szenarien erfüllen kann

• Szenario-Brainstorming

  • weitere Szenarien erstellt, mehr Stakeholder einbinden als bei Qualitätsbaumerstellung

• Architekturansätze analysieren (2)

  • wichtigste Szenarien aus vorgängigen Schritt als Grundlage

• Ergebniss präsentieren

  • auch Risikothemen darstellen

• Identifizierte Architekturansätze

• Qualitätsbaum

• Qualitätsszenarien und deren Anwendungen auf die Architektur

• Fragen zu spezifischen Qualitätsmerkmalen, die die Architektur erfüllen soll - und die Antworten darauf

• Identifizierte riskante und risikolose Entwurfsentscheidungen

• Ein Satz von Top-Risiken, die die Business Ziele gefährden

• Vor allem: Früh identifizierte Risiken

• Eindeutige Qualitätsanforderungen

• Verbesserte Architekturdokumentation

• Dokumentierte Basis für Architekturentschiedungen

• Verbesserte Kommunikation zw. Stakeholdern

• —> Höhere Qualität der Softwarearchitektur

• Untersuchung der inneren Struktur eines Software-Produkts

• Ziel: Verständnis und Bewertung der Architektur

• Aufdecken potenzieller Gefahren für Softwarequalität

• Berücksichtigung des zukünftigen (Weiter-)Entwicklungsprozesses

• Tests sind in der SE unerlässlich

• Aber auch aufwändig und teuer

• Mit Hilfe von Werkzeugen wird eine hohe Testautomatisierung angestrebt.

• Testen ist die Ausführung eines Programms mit der Absicht, Fehler zu finden

  
  

  und

• Dokumentation der genauen Ausführungsbedingungen wie z.B. Version, Testfälle und Resultate

• TDD (Test Driven Development):

  • Schreiben eines Tests, der fehlschlägt.

  • Schreiben einfachsten Codes für den bestandenen Test.

  • Red-Green-Refactor-Schleife bis zur Fertigstellung.

• BDD (Behavior Driven Development):

  • Erstellen einer fehlschlagenden, ausführbaren Spezifikation.

  • Schreiben einfachsten Codes für bestandene Spezifikation.

  • Wiederholung bis Release-Kandidat bereit ist.

• Unterschied TDD und BDD:

  • TDD: Entwicklungspraxis, Tests von Entwicklern.

  • BDD: Team-Methodik, automatisierte Spezifikationen von Benutzern oder Testern.

• Funktionalität: Angemessenheit, Richtigkeit

• Zuverlässigkeit: Reife, Fehlertoleranz

• Benutzbarkeit: Verständlichkeit, Erlernbarkeit

• Effizienz: Zeitverhalten, Verbrauchsverhalten

• Wartbarkeit/Änderbarkeit: Analysierbarkeit, Modifizierbarkeit

• Übertragbarkeit: Anpassbarkeit, Austauschbarkeit

Sammlung von Best Practices für verschiedene Aufgaben des IT-Betriebs

• Im Fokus: Kosten einsparen, Zuverlässigkeit steigern

• Besonders bekannt: Incident Management, Configuration Management, Service Level Agreements

IT Operations Control (Steuerung des IT-Betriebs) überwacht und steuert die IT Services und die IT Infrastruktur

Großer Markt; alle großen PLayer sind vertreten

• >Ticket-Tool / Request-Tracker

• Configuration Management Database (CMDB)

• ITSM-Lösungen (Alle ITIL-Prozesse unterstützt)

• Nutzt spezielle systemnahe Software zur Nachbildung von Hardware als virtuelle Maschine.

• Virtualisierungssoftware kann auf vollwertigem Betriebssystem (Typ 2) oder direkt auf Hardware (Typ 1) laufen.

• Technische IT-Infrastruktur wird immateriell, Ebenen schwer trennbar.

Vorteile der Virtualisierung:

1. Höhere Auslastung

2. Geringere Kosten (Strom, Kühlung, Stellplatz)

3. Vereinfachte Administration

Nachteile der Virtualisierung:

1. Geringere Leistung

2. Overhead

3. Nicht geeignet für spezielle Hardware-Anforderungen

Vorteile von Infrastructure as Code

• Versionierung

• Testbarkeit

• Wiederholbarkeit

• Teilen

• Updates

Docker:

• Containerisierungsplattform

• Verpackt Anwendungen in eigenständige Container

• Vereinfacht Entwicklung und Bereitstellung

DevOps verbessert die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb, um den Lebenszyklus der Softwareentwicklung zu optimieren und eine schnellere Bereitstellung von Anwendungen zu ermöglichen.

Vorteile:

1. Schnelle Bereitstellung

2. Bessere Zusammenarbeit

Nachteile:

1. Einführungskomplexität

2. Sicherheitsbedenken

• Vorteile von DevOps:

  • Entwickler verbringen weniger Zeit in Meetings mit Operations.

  • Schnellere Kapazitätsprognosen und Implementierung von Änderungen in der Cloud.

• Effizientere Kommunikation

• Selbständige Umsetzung in der Cloud

• Beschleunigte Prozesse

• Monitoring:

  • Methode zur sinnvollen Überwachung von hybriden und Multi-Cloud-IT-Betrieben.

  • Schlüsselprinzip: "If You Can't Measure It, You Can't Manage It."

• ITIL (IT Infrastructure Library):

  • IT Operations Control: Überwacht und steuert IT-Services und Infrastruktur.

  • Führt routinemäßige Aufgaben im IT-Betrieb aus.

  • Enthält Job Scheduling, Backup, Wiederherstellung, Print- und Output-Management, sowie Wartungsarbeiten.

• Internationale Norm für Informationssicherheit.

• Gilt für private, öffentliche und gemeinnützige Organisationen.

• Beschreibt Anforderungen an Einrichtung, Realisierung, Betrieb und Optimierung von Informationssicherheits-Managementsystemen.

• Veränderung der Bedrohungslage erfordert bessere Schutzmechanismen.

• Schwierigkeiten bei der Umsetzung neuer rechtlicher Anforderungen.

• Boom im IT-Sicherheitsmarkt mit vielen Anbietern und neuen Ansätzen.

• Herausforderung: Teilaspekte werden oft isoliert betrachtet.

• Zunehmender Einsatz einzelner Sicherheitstools führt zu Komplexität.

• Schwierigkeiten bei der Integration in einen strategischen Rahmen, insbesondere im Kontext der DSGVO (GDPR).

• Bewertung von Arbeitsweisen, besonders in Softwareentwicklung.

• Unterteilung in Reifegrade als Benchmark.

• Messung von Prozessdefinition und -konsistenz.

• Höherer Reifegrad = besser implementierter Prozess.

• Besser kann bedeuten: dokumentiert, organisationseinweit genutzt, messbare Kennzahlen.

OpenSAMM:

1. Software Assurance Maturity Model

2. Von OWASP organisiert, freiwilig, Sponsoren, Experten-Community

3. Version 1.5, 2.0 angekündigt, bei GitHub veröffentlicht

4. Nutzer u.a. Dell, HP, ING

BSIMM:

1. Building Security In Maturity Model

2. Von Synopsis organisiert, Studien mit verschiedenen Unternehmen

3. Version 9, als Creative Commons verfügbar nach Registrierung

4. Definiert 4 Domains, jeweils 3 Practices, 3 Maturity Levels, deskriptiv

OWASP Top 10:

• Open Web Application Security Project (OWASP): Gemeinschaft für sichere Anwendungen und APIs.

• Ziel: Organisationen befähigen, vertrauenswürdige Anwendungen und APIs zu entwickeln, kaufen und pflegen.

• Ursprüngliches Ziel des OWASP Top 10-Projekts: Bewusstsein bei Entwicklern und Managern schärfen.

• De facto Standard für Anwendungssicherheit geworden.