| recall |
|---|
header |
Software Engineering beschäftigt sich mit der systematischen Entwicklung großer Softwaresysteme und Methoden, Techniken und Werkzeugen zur Entwicklung großer Software mit dem Ziel, Software hoher Qualität kostengünstig innerhalb eines festen Budgetrahmens und zum geplanten Zeitpunkt zu produzieren.
Mit dem Software-Engineering werden die Ziele verfolgt große Softwareprojekte mit
- hoher Qualität (Qualitätssicherung)
- geringen Kosten (Management)
- im Zeitrahmen (Management) abzuschließen.
Alle Aktivitäten, die zu einem lauffähigen Softwaresystem führen.
- produktbezogene Aktivitäten (Ergebnisse gehen direkt ins Produkt ein)
- prozessbezogen Aktivitäten (Organisations- und Managementrahmen)
- Anforderungsermittlung
- Entwurf
- Implementierung
- Projektplanung
- Projektleitung
- Projektkontrolle
- Produktverwaltung
- Qualitätsmanagement
- Software ist nicht sinnlich wahrnehmbar: Verständnis kann nur durch erklärende Texte oder Erprobung eines Produkts verstanden werden
- Software ist Text: Sie kann wie ein Text an veränderliche Bedürfnisse angepasst werden.
- Software ist digital: Verfahren der kontinuierlichen Ingenieursmathematik greift nicht. Wegen der großen Anzahl Zustände, sind die Mittel der Logik und Mathematik nur eingeschränkt praktikabel.
- >5 Personen arbeiten daran
- Entwicklung >1 Jahr
- Komplexität: Verknüpft mehrere Realitätsbereiche und Fachgebiete
- Umfangreiche Artefakte: Spezifikationen, Programme, Dokumente
- Lange Lebensdauer (>10 Jahre): Versionierung
- Prägt Arbeitsweisen
Beherrschen von Komplexität
- Kopplung
- Kohäsion
Anwendungssysteme (oft kurz Anwendungen oder Applikationen genannt) sind Softwareprodukte, die in einem bestimmten Anwendungsbereich eingesetzt werden. Sie unterstützen Arbeitsprozesse (Auftragsbearbeitung, Lagerhaltung) oder steuern technische Prozesse (Flugüberwachung, Kraftwerksteuerung). Allgemein unterstützen Sie Geschäftsprozesse eines Unternehmens.
- Individualsoftware
- Standardsoftware
- Systemsoftware
Ein Anwendungssystem, das für einen speziellen Auftraggeber in einem bestimmten Anwendungsbereich erstellt wird. Beispiele:
- Steuerungssoftware für eine Fertigungsstraße
- Website / Portal einer Firma
Software, die einen bestimmten Anwendungsbereich abdeckt und durch Konfiguration an die unterschiedlichen Bedürfnisse verschiedener Anwender angepasst werden kann. Hierzu gehören z. B. Finanzbuchhaltungs- und Materialwirtschaftssysteme, Branchenlösungen für Handwerksbetriebe und Office-Programme für Textverarbeitung und Tabellenkalkulation.
Anwendungen, die sich keinem bestimmten Anwendungsbereich zuordnen lassen. Beispiele:
- Betriebssysteme
- Compiler
Die zusammengehörige Abfolge von Verrichtungen zum Zwecke einer Leistungserstellung. Ausgang und Ergebnis des Geschäftsprozess ist eine Leistung, die von einem internen oder externen Kunden angefordert und abgenommen wird.
Ein Workflow ist die Unterstützung oder Automatisierung von Geschäfts(teil)prozessen durch ein Computersystem.
Workflow-Modelle dienen für die Automatisierung von Geschäftsprozessen durch ein Computersystem. Sie präzisieren Details von Geschäftsprozessen und liefern eine konsistente Gesamtbeschreibung.
Business Process Reengineering
- Organisatorischer Aspekt: Wer führt aus
- Funktionaler Aspekt: Was wird ausgeführt
- Ablaufbezogener Aspekt: Wann (in welcher Reihenfolge) wird ausgeführt
- Operationaler Aspekt: Wie wird ausgeführt
- Informationsbezogener Aspekt: Womit wird ausgeführt (Inputs)
- Kausaler Aspekt: Warum wird ausgeführt
Anwendungssysteme, mit denen Geschäftsprozesse als Workflow-Modell spezifiziert und ausgeführt werden können.
Softwarequalität ist die Gesamtheit der Eigenschaften oder Merkmale, welche ein Produkt in Verwendung und (Weiter-)Entwicklung aufweist, um die gegebenen Anforderungen zu erfüllen.
- Produktqualität
- Gebrauchsqualität
Die Produktqualität betrachtet die Qualität der Software unabhängig vom Einsatzkontext. Hierbei geht es um den Quellcode, den Binärcode und zugehörige Dokumente. Die Produktqualität wird anhand innerer Qualitätsmerkmale charakterisiert.
- Korrektheit der Software bezüglich Spezifikationen
- Verständlichkeit
- Änderbarkeit
- Wiederverwendbarkeit
Die Gebrauchsqualität bezieht sich auf die Fähigkeit der Software, die an sie gestellten Anforderungen im jeweiligen Einsatzkontext zu erfüllen. Die wird mittels äußerer Qualitätsmerkmale ermittelt.
- Korrektheit bezüglich des Einsatzkontextes
- Zuverlässigkeit
- Effizienz
- Aufgabenangemessenheit
- Erwartungskonformität
- Fehlerrobustheit
- Änderbarkeit/Wartbarkeit (nichtfunktionale Anforderung: Qualität)
- Benutzbarkeit (nichtfunktionale Anforderung: Qualität)
- Effizienz (nichtfunktionale Anforderung: technisch)
- Funktionalität (funktionale Anforderung)
- Übertragbarkeit (nichtfunktionale Anforderung: Qualität)
- Zuverlässigkeit (nichtfunktionale Anforderung: Qualität)
- Analysierbarkeit: Aufwand, um Mängel oder Ursachen von Versagen zu diagnostizieren oder um änderungsbedürftige Teile zu bestimmen.
- Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Änderbarkeit erfüllt.
- Modifizierbarkeit: Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung an Umgebungsänderungen.
- Stabilität: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen.
- Testbarkeit: Aufwand, der zur Prüfung der geänderten Software notwendig ist.
- Attraktivität: Anziehungskraft der Anwendung gegenüber dem Benutzer.
- Bedienbarkeit: Aufwand für den Benutzer, die Anwendung zu bedienen.
- Erlernbarkeit: Aufwand für den Benutzer, die Anwendung zu erlernen (zum Beispiel Bedienung, Ein-, Ausgabe).
- Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Benutzbarkeit erfüllt.
- Verständlichkeit: Aufwand für den Benutzer, das Konzept und die Anwendung zu verstehen.
- Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Effizienz erfüllt.
- Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung.
- Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebsmittel bei der Erfüllung der Funktionen. - Ressourcenverbrauch, wie CPU-Zeit, Festplattenzugriffe usw.
- Angemessenheit: Eignung von Funktionen für spezifizierte Aufgaben, zum Beispiel aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen.
- Sicherheit: Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern.
- Interoperabilität: Fähigkeit, mit vorgegebenen Systemen zusammenzuwirken.
- Konformität: Fähigkeit des Softwareprodukts, Standards, Konventionen oder gesetzliche Bestimmungen und ähnliche Vorschriften bezogen auf die Funktionalität einzuhalten.
- Ordnungsmäßigkeit: Merkmale von Software, die bewirken, dass die Software anwendungsspezifische Normen oder Vereinbarungen oder gesetzliche Bestimmungen und ähnliche Vorschriften erfüllt.
- Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, zum Beispiel die benötigte Genauigkeit von berechneten Werten.
- Anpassbarkeit: Fähigkeit der Software, diese an verschiedene Umgebungen anzupassen.
- Austauschbarkeit: Möglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zu verwenden, sowie der dafür notwendige Aufwand.
- Installierbarkeit: Aufwand, der zum Installieren der Software in einer festgelegten Umgebung notwendig ist.
- Koexistenz: Fähigkeit der Software neben einer anderen mit ähnlichen oder gleichen Funktionen zu arbeiten.
- Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit erfüllt.
- Fehlertoleranz: Fähigkeit, ein spezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht-Einhaltung ihrer spezifizierten Schnittstelle zu bewahren.
- Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Zuverlässigkeit erfüllt.
- Reife: Geringe Versagenshäufigkeit durch Fehlerzustände.
- Wiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen. Zu berücksichtigen sind die dafür benötigte Zeit und der benötigte Aufwand.
Interne und externe, ggf. zusammengesetzte, Metriken.
- Wird eine Software zu mächtig, geht dies ggf. zulasten der Angemessenheit (Funktionalität), weil dann bei kleinen Problemen mit Kanonen auf Spatzen geschossen wird
- Effizienz kann zu verminderter Übertragbarkeit führen, weil Software auf eine Plattform / Hardware spezialisiert wird
- Eine erhöhte Benutzbarkeit und Attraktivität kann zu Ungunsten der Effizienz führen, da optisch ansprechende Effekte den Ressourcenverbrauch erhöhen. Beispiel: vim, effizient aber unattraktiv
- Systemdokumentation
- Benutzerdokumentation
Eine gute Dokumentation ist
- vollständig
- konsistent zur aktuellen Version
- verständlich für Lesergruppe
- strukturierter, logischer Aufbau
- einheitliches Format
- sachlich, präziser Schreibstil
- Anforderungsermittlung (Requirements Engineering)
- Analyse
- Entwurf
- Implementierung
- Tests
- Systemeinführung
- Auftraggeber
- zukünftige Benutzer
- Anwendungsexperten
- Projektleiter
- Analytiker
- Entwickler
- Tester
- funktionale Anforderungen
- Funktionen / Eigenschaften
- Operationen
- Abläufe
- Ausnahmebehandlung
- einzuhaltende Geschäftsregeln
- externe Schnittstellen
- Benutzerschnittstelle
- Eingabeformat
- Ausgabeformat
- Schnitstellen für dritte Systeme
- Funktionen / Eigenschaften
- nichtfunktionale Anforderungen
- technische Anforderungen
- Performance
- Lastverhalten
- Beschränkungen durch Rahmenbedingungen (OS, DBMS, Entwicklungsumgebung, ...)
- Qualitätsanforderungen
- Nutzbarkeit
- Zuverlässigkeit
- Sicherheit
- Wartbarkeit
- technische Anforderungen
- Extrahieren
- Verhandeln
- Spezifizieren
- Verifizieren
- Validieren
Wünsche und teils verborgene Anforderungen an das zu erstellene Softwareprodukt ermitteln und in für alle Beteiligten verständlicher Form explizit machen.
Ordnen der Anforderungen nach Wichtigkeit, Kritikalität, Stabilität. Deadlines für die Implementierungen jeder Funktion erstellen.
Dokument erstellen, das als Entwicklungsgrundlage verbindliche Basis der Abnahmetests durch den Auftraggeber dient.
Anforderungsspezifikation
Validieren soll die Vollständigkeit der Anforderungsspezifikation sicherstellen und dass sie alle Erwartungen des Auftraggebers und der Benutzer trifft. "Building the right product."
Verfizieren soll die Korrektheit der Einzelspezifikationen sicherstellen und deren Konsistenz untereinander. "Building the product right."
Aufbereitung der Anforderungsspezifikation als Grundlage für den Entwurf. Dieser Schritt kann auch in die Anforderungsermittlung und den Entwurf aufgeteilt werden. Bei großen Projekten ermöglicht die Analyse als einzelner Schritt eine granularere Aufteilung des Entwicklungsprozesses.
Auf Basis der Anwendungsspezifikation wird die innere Struktur der Software festgelegt. Hierbei ist das Ziel die Komplexität der Software durch Aufteilung in funktionale Einheiten, sog. Module, in beherrschbare Dimensionen zu bringen. Das Ergebnis des Entwurfs ist die Entwurfsspezifikation.
Die Entwurfsspezifikation bescheibt das Zusammenspiel der Module der Software (APIs, Schichten, etc.). Programmtechnische Details sind nicht Teil des Entwurfs.
- Jedes Modul behandelt ein zusammmenhängendes Teilproblem (starke Kohäsion)
- Module untereinander sollten möglichst unabhängig sein (schwache Kopplung)
- Die Schnittstelle eines Moduls soll nur beschreiben, was das Modul leistet, wie es das tut, sollte verborgen sein (Geheimnisprinzip, bessere Wartbarkeit)
Der problembezogene Zusammenhang von Operationen eines Moduls
Eine Programm- oder Klassenbibliothek ist eine Sammlung von selbstständigen Unterprogrammen / Modulen, die für die Wiederverwendung gedacht ist.
Ein Framework ist eine Sammlung kooperierender Klassen, die Grundstruktur und Kontrollfluss in der Software für eine bestimmte Problemstellung anbietet. Das Framework bildet einen generischen Rahmen, der für eine Software genutzt, spezialisiert und "zusammengesteckt" werden kann. Es geht über eine Programmbibliothek hinaus, weil es Kontrollflüsse festlegt.
Ein Entwurfsmuster ist ein Lösungsschema für gängige Herausforderungen in der Softwareentwicklung. Es beinhaltet keine konkreten Implementierungen, sondern nur Beschreibungen von Hierarchien, Verknüpfungen von Klassen und Kontrollflüssen, die sich in der Vergangenheit bewährt haben.
In sich abgeschlossene Softwarebausteine, die gemäß einem Komponentenmodell aufgebaut sind und zusammengesteckt werden können (Beispiel COM, Enterprise Java Beans)
Während der Implementierung werden die in der Entwurfsspezifikation beschriebenen Module in Programmcode umgesetzt. Das Ergebnis ist eine Ansammlung von Quelltexten der verschiedenen Module aber im Allgemeinen noch kein funktionsfähiges Programm
Beim Testen wird geprüft, ob der Prüfgegenstand (Klasse, Modul, Applikation) seine Spezifikation erfüllt. Beginnend beim Einzeltest der Module (Unittest, Modultest) geht man durch Verknüfpung von Modulen zu Integrationstests und schließlich zum Systemtest über. Beim Auftraggeber erfolgt der Abnahmetest.
Bei der Systemeinführung wird eine Software von der Entwicklungsumgebung in die Einsatzumgebung (Produktivumgebung) gebracht und die nötigen organisatorischen Maßnahmen beim Anwender durchgeführt. Zur Systemeinführung gehören auch vorbereitende Maßnahmen wie Schulungen, Druchführung von Beta-Tests, Einrichten einer Support Hotline.
Vorgehensmodelle schaffen den organisatorischen Rahmen einer Entwicklungsaktivität. Die Entwicklung wird in Phasen unterteilt, die mit einem Meilenstein abgeschlossen werden. Sie sollen den Arbeitsablauf vereinheitlichen und langfristig stabil halten, um eine verlässliche Arbeitsgrundlage zu schaffen.
- Worauf baut eine Aktivität auf?
- Was soll bei einer Aktivität untersucht / entwickelt werden?
- Mit welcher Methode / Technik soll das passieren?
- Welche Ergebnisse sind zu erarbeiten?
- Wasserfallmodell
- V-Modell
- Spiralmodell
- SCRUM
- Extreme Programming
- Kanban
- Rational Unified Process
- evolutionäres Prototyping
- ...
- adaptiert aus Bau- und Produktionsgewerbe (mit echt abgeschlossenen Phasen)
- lineares (nicht iteratives) Vorgehensmodell
- aufeinanderfolgende, abgeschlossene Phasen
- keine Rückschritte
- einfaches Management wegen klarer zeitlicher Vorgaben und abgeschlossener Phasen
- vollständige und korrekte Ergebnisse nach jeder Phase (in der Theorie)
- eigene Wartungs-Phase verdeutlicht, dass Arbeit über Rollout hinaus besteht
- Softwareentwicklung hat keine abgeschlossenen Phasen
- Menschen machen Fehler, Entdeckung in späteren Phasen, Rollback zur Korrektur nicht vorgesehen
- Anforderungsspezifikationen sind niemals perfekt, kein Nachschärfen möglich
- lauffähiges Produkt erst ganz am Ende (Big Bang), ggf. werden erst hier Fehler bemerkt
- Zeitpläne nicht eingehalten -> späte Phasen (Tests!) entfallen teilweise
- gebündelt am Ende testen ist schlechte Qualitätssicherung -> späte Erkennung von Fehlern
Wasserfall mit Iterationen ermöglicht Rückkehr in frühere Phasen. Testing bleibt allerdings zeitlich ans Ende gestellt.
Die Erstellung von benutzbaren (Teil-)Funktionen einer Anwendung in frühen Entwicklungsstadien, um die Anforderungsspezifikation zu validieren.
Wünsche und Vorstellungen der Kunden / Benutzer können bestätigt / abgeklärt werden.
- horizontale Prototypen bilden die Software in der Breite ab. Beispiel: Klickdummy für ein GUI
- vertikale Prototypen bilden einen speziellen Aspekt der Software ab. Beispiel: Datenbankanbindung
Der Prototyp selbst wird entweder verworfen (Wegwerfprototyp) oder weiterverwendet und eingebaut. Letzteres verschlechtert meist die Qualität des Endprodukts, weil Prototypen nicht besonders sorgfältig erstellt werden.
Wegwerfprototyp für jedes Modell, Prototypen, die verfeinert und integriert werden eigenen sich nur für iterative Vorgehensmodelle, da sonst eine Verfeinerung nicht vorgesehen ist
Bei iterativen Vorgehensweisen sind Wiederholungen und Korrekturen der bisherigen Arbeit vorgesehen.
Der Entwicklungsprozess wird mehrfach für einzelne Features der Software durchgespielt. Hierdurch wird erreicht, dass nicht erst alles am Ende fertig wird (Big Bang), sondern auch schon während der Entwicklung die Richtung der Anwendung erkennbar ist. Die inkrementelle Vorgehensweise ist nicht zwingend auch iterativ, aber beide passen gut zusammen, da ggf. auch Änderungen am vorherigen Inkrement vorgenommen werden müssen, wenn man das nächste bearbeitet.
Die eher theoretische Betrachtung des Problems über Anforderungsermittlung und Entwurf wird vernachlässigt und stattdessen sehr früh mit der Implementierung begonnen und so explorativ die Anwendung an die Geschäftsprozesse und Randbedingungen angepasst. Wird jeder so erarbeitete Stand als Prototyp behandelt, spricht man von evolutionärem Prototyping. Im Gegensatz zur inkrementellen Vorgehensweise bleiben hier die Anforderungen und Entwurfsüberlegungen lange unklar und müssen sich durch die Implementierung selbst herauskristallisieren, was auch zum Verwerfen der bisherigen Arbeit führen kann.
Rational Unified Process
Ein iteratives und inkrementelles Vorgehensmodell zur Softwareentwicklung mit stark überlappenden Entwicklungsphasen.
- Geschäftsprozessmodellierung (Business Modeling)
- Anforderungsermittlung (Requirements)
- Analyse und Entwurf (Analysis and Design)
- Implementation
- Test
- Inbetriebnahme (Deployment)
Für das System relevante Geschäftsprozesse werden in Anwendungsfällen dokumentiert, um ein einheitliches Verständnis zwischen Systementwicklern und Anwendern zu schaffen
- Konzeption (Inception)
- Ausarbeitung (Elaboration)
- Konstruktion (Construction)
- Übergang in den Betrieb (Transition)
Anforderungen an das System und Umfang des Projekts wird ermittelt. Erste Entwurfsüberlegungen und ggf. Implementierungen finden statt. Auflisten von
- Erfolgsfaktoren
- Projektrisiken
- Aufwandschätzung
- Terminplan
Abschluss der Phase bildet die Validierung der Anforderungen und Prüfung des Kosten- und Terminplans.
Abschluss der Anforderungsermittlung, erster ausführbarer Entwurfsprototyp
Weiterentwicklung des Entwurfsprototyp und Implementierung der ausstehenden Funktionen, Integration, Tests. Erste Beta-Version.
System wird beim Anwender in Betrieb genommen. Ggf. Beta-Testing mit ausgewählten Benutzern. Manuals, Schulungen, Aufbau einer Support-Struktur. Abnahme durch Auftraggeber.
- Konfigurationsverwaltung (Configuration- & Change Management)
- Projektmanagement
- Umgebung (Environment)
Was ist die Aufgabe des Supporting Workflows "Konfigurationsverwaltung" im Rational Unified Process?
Versionsverwaltung der prozessbegleitend erstellten Dokumente, Benachrichtigung bei Änderungen etc.
Zwischen konkurrierenden Zielen vermitteln. Risiken managen, Probleme beseitigen.
Bereitstellung von Hard- und Software für die Anwendungsentwicklung, Schulung und Unterstützung der Projektmitarbeiter.
Ein Implementierungs-zentriertes, feininkrementelles, iteratives (evolutionäres) Vorgehensmodell der Softwareentwicklung.
- kleine Releases
- Planspiel (Ermittlung der auszuarbeitenen Featues)
- Tests
- Systemmetapher
- einfacher Entwurf (KISS)
- Refaktorisierung
- Programmieren in Zweierteams (Pair-Programming)
- gemeinsames Code-Eigentum
- Programmierrichtlinien
- kontinuierliche Code-Integration (Continuous Integration)
- Dokumentation (Selbstdokumentierend)
- geregelte Arbeitszeiten
- Anwendervertreter in Teams
- Release-Zyklen von 1-3 Monaten mit wenigen Unterschieden zwischen den Releases
- Mehrere Iterationen pro Release (1-3 Wochen)
- Arbeitspakete in Iterationen (1-3 Tage)
- Planung, Implementierung und Abnahmetests (durch Anwender) bei jedem Release
Planung eines Releases. Wünsche der Kunden werden in User Stories beschrieben, mit Prioritäten versehen und beim nächsten Inkrement berücksichtigt oder geschoben (Backlog).
Test Driven Development: Tests stellen die Anforderungen der Kunden dar. Tests sind vor der Implementierung einer User Story vorzunehmen.
Metaphern ersetzen Entwurfsspezifikationen und beschreiben einzelne Module der Software mit Worten einer für Kunde und Entwicklung verständlichen Sprache, dokumentiert in einem Glossar.
Implementierung sollten keine eventuell auftretenden Sonderfälle oder Wiederverwendungen vorhersehen und stattdessen so einfach und funktional wie möglich gehalten werden.
Kontinuierliche Verbesserung der Entwurfsqualität (testgestützt) ohne Änderung der Funktion. Heißt auch: Nicht optimale Entwürfe sind in Ordnung und können nachträglich verbessert werden.
Geteilte Arbeit, ein Entwickler schreibt die Implementierung, der andere macht auf Fehler aufmerksam und gibt die Richtung des Entwurfs vor. Regelmäßiges Wechseln und Rollen und Teams.
Jeder Code gehört jedem Teammitglied und liegt in jedermanns Verantwortung.
Durch Einhaltung von Programmierrichtlinien entsteht selbstdokumentierender Code in gleichem Stil, der von allen Teammitgliedern verstanden und geändert werden kann.
Wegen der kurzen Release-Zyklen sollen neue Bestandteile schnell in die bestehende Code-Base integriert werden. Unterstützt wird das Vorgehen von Continuous Integration Tools, die automatisiert Tests ablaufen lassen.
Der Code sollte selbstdokumentiert und verständlich sein. Ist er das nicht, muss refaktorisiert werden. Separate Dokumentation wird zu schnell vom Code überholt und ist damit nicht mehr korrekt.
Überstunden sind zu vermeiden, da die Arbeitsweise hohe Konzentration erfordert und jeder Entwickler jeden Tag hoch konzentriert arbeiten können soll ohne durch Überstunden beeinträchtigt zu sein. Alle Entwickler sollten gleichzeitig arbeiten, damit beste Vorraussetzungen für Kommunikation gegeben sind.
Wegen der fehlenden Anforderungsermittlung und der kurzen Release-Zyklen ist es nötig dicht mit einem Systembenutzer zusammen zu arbeiten, damit die Releases und User Stories ständig von einem Kunden validiert werden.
- Alle Entwickler sollten sehr gute und breite Qualifikationen mitbringen, damit jederzeit flexibel gut zusammenarbeitenden Teams gebildet werden können.
- Alle Beteiligten müssen sich auf die XP Praktiken einlassen. Kunden müssen einen fähigen Vertreter ins Entwicklungsteam entsenden können.
- Die Vertragsgestaltung ist bei diesen Vorgehen kompliziert. Kein Beteiligter kann Anspruch auf Planungssicherheit erheben.
- kleine Projekte mit <16 Entwicklern
- alle Entwickler mit gleichen Arbeitszeiten und am Besten am gleichen Ort, da viel Kommunikation nötig ist
- es muss viele Tests geben, die die ganze Funktionalität abdecken aber nicht zu lang laufen dürfen
Durch den Entfall einer initialen Anforderungsermittlung läuft man Gefahr das später entdeckte große Anforderungen die bisherige Arbeit zunichte machen.
- durch den immateriellen Entwicklungsgegestand ist die Fertigstellung eines Teilprodukts nur schwer prüfbar. Aussagen der Entwickler sind immer subjektiver Art oder im schlimmsten Fall unehrlich.
- Personalplanung geht unabhängig von den Qualifikationen von der Austauschbarkeit der Entwickler aus
- Bei großen Projekten sind die Unterschiede zwischen Projekten meist so groß, dass Erfahrung nicht besonders wertvoll ist
- Projektplanung muss interne Iterationen im Zeitplan berücksichtigen
- Vor dem Angebot: Voruntersuchung, Aufwandsschätzung, Machbarkeitsstudie, Zeitbedarfsschätzung, Kosten/Nutzen-Analyse
- Bei Auftrag: Ablauf-, Termin-, Ressourcen- und Kostenplanung (Projektplanung)
- Im Projekt: Leitung des Entwicklerteams, Projektcontrolling
- Nach dem Projekt: Abschlussanalyse, lessons learned
Die Managementaktivitäten müssen auf das Vorgehensmodell abgestimmt sein. Je nach Vorgehensmodell sind Managementaktivitäten zu unterschiedlichen Zeitpunkten und Anlässen durchzuführen.
Bei einem integrierten Entwicklungsprozess sind Entwicklung, Management und Qualitätssicherung vollständig in das Vorgehensmodell integriert.
- Spiralmodell
- V-Modell
- Klärung von Produktanforderungen sofern für die Voruntersuchung notwendig
- grobe Aufwandsschätzung bezüglich personellen Einsatzes und benötigter Betriebsmittel
- Machbarkeitsstudie bezüglich verfügbarer Mitarbeiter und deren Qualifikationen
- Schätzung der Entwicklungsdauer
- Kosten/Nutzen-Analyse
- alle zu erledigenden Aktkivitäten werden in Vorgänge aufgeteilt
- Abhängigkeiten zwischen Vorgängen identifizieren
- Vorgänge in Ablaufreihenfolge bringen
- auf Basis der Vorgangsdauer ergeben sich Termine und Ressourcenbedarf
- Festlegung von Meilensteien mit dem Auftraggeber
- Terminplanung mit Netzplanarten
Ein Vorgang ist eine in sich abgeschlossene identifizierbare Tätigkeit, die innerhalb einer angemessenen Zeitdauer durchgeführt werden kann.
Vorgänge ohne Pufferzeit
eine Reihe von kritischen Vorgängen
- Vorhersage des Bedarfs an Personal- und Betriebsmitteln
- Engpasse und Leerläufe vermeiden
- personelle Einsatzplanung auf Basis von:
- parallele Ausführung von Vorgängen
- Qualifikation
- zeitliche / örtliche Verfügbarkeit
- organisatorische Zuordnung
- möglichst gleichmäßige Auslastung des verfügbaren Personals
- Erfassung aller direkten und indirekten Kosten
- Erstellung eines Projektfinanzplans: Welche Mittel müssen wann und wo eingesetzt werden
Überprüfung der Zielerreichung an den Meilensteinen sowie laufende Termin- und Kostenkontrolle und ggf. Maßnahmen zur Korrektur bei Abweichung.
objektive Bewertungskriterien, Nachvollziehbarkeit
- unmittelbare Maßnahmen:
- Überstunden
- Personal Umverteilung
- bessere Hardware
- bessere Software
- mittelbare Maßnahmen (um gleiche Probleme in Zukunft zu vermeiden):
- lessons learned
- Planungsfehler beseitigen
- schriftliche Dokumentation aller Änderungswünsche
- Klärung der Motivation des Änderungswunsches
- Genehmigung / Ablehnung
- Planung und Integration der Änderungen in den Projektplan
- Überwachung der Durchführung
Ein potentielles Problem und eine Eintrittswahrscheinlichkeit. Ein Problem ist widerum ein eingetretenes Risiko.
Risiken identifizieren und Maßnahmen ergreifen, um ihr Eintreten zu verhindern
- unzureichende Qualifikation des Personals
- unrealistische Termin- und Kostenvorgaben
- Entwicklung von falschen Funktionen / Eigenschaften
- Entwicklung der falschen Benutzerschnittstelle
- Entwicklungen, die über das Ziel hinaus schießen ("vergolden")
- permanente Anforderungsänderungen
Risiko-
- Identifikation (Listen mit potentiellen Probleme)
- Analyse (Schadenswahrscheinlichkeit und Schadensausmaß feststellen)
- Prioritätenbildung (Probability-Impact-Matrix)
- Management-Planung (Vorbereiten von Maßnahmen beim Eintreten von Risiken)
- Überwindung (Risiken durch geeignete Maßnahmen ausschließen)
- Überwachung
Ein generisches, iteratives und inkrementelles Vorgehensmodell mit besonderem Fokus auf die Risikoabschätzung und -beseitigung.
- hoher Problemlösungsgrad durch kombinierte Qualifikationen
- Nutzung unterschiedlicher Qualifikationen
- geringere Gefahr von Sackgassen
- gegenseitige Anregung / Verstärkung
- Koordinierungs- und Kommunikationsaufwand
- lange Diskussionen / langsame Entscheidungsfindung
- Konkurrenzdenken / Profilierung
- schwer kontrollierbare Gruppendynamik
- Leistungsdruck auf Teammitglieder
20%
wrap-up
- wrap-up
- Archivierung der Projektresultate und -unterlagen
- Projektorganisation auflösen, Mitarbeiter neu verteilen
- Abschlussfeier
Ohne Qualitätssicherung nur fehlerfreie Software bei fehlerfreier Arbeit. Menschen machen aber Fehler.
Die Summe alle Maßnahmen (technische und Managementaktivitäten), die garantieren, dass ein Produkt die Spezifikation erfüllt.
- konstruktive Qualitätssicherung
- analytische Qualitätssicherung
Vermeidung von Qualitätsmängeln durch den Einsatz von Methoden, Konstruktionsprinzipien, Verfahren, Werkzeugen und Vorgehensmodellen in der Entwicklung. Die konstruktive Qualitätssicherung zielt auf Gebrauchs-, Produkt und Prozessqualität.
Nachträgliche Analyse eines Produkts auf Erfüllung der Qualitätsansprüche.
- statische Prüfungen
- dynamische Prüfungen
Statische Prüfungen sind nicht auf die Ausführbarkeit des Prüfgegenstandes angewiesen, können also auf alle Artefakte der Softwareentwicklung angewendet werden.
Dynamische Prüfungen nutzen die Ausführbarkeit des Prüfgegenstands, beziehen sich in der Softwareentwicklung auf den Programmcode.
- Metriken
- Automatische Analysatoren
- Reviews
- Inspektion
- Walk-Throughs
Was sind Beispiele für Code Metriken der statischen Prüfungen in der analytischen Qualitätsicherung?
- Lines of Code (LoC)
- Anzahl von:
- Statements
- Klassen
- Attributen einer Klasse
- Methoden einer Klasse
- Packages
- Verschachtelungstiefe
- Nicht erreichbarer Code
- Nutzung vor Initialisierung
- Style Checker
- Zyklomatische Komplexität (McCabe)
- Paket-Abhängigkeiten
- Abstraktheit (abstrakte Klassen / Interfaces vs. konkrete Klassen)
Programmanalyse in Form von Flussgraphen oder cross-reference-Listen, um Inkonsistenzen / Unvollständigkeiten aufzudecken.
Manuelle Prüfverfahren, bei dem ganze Teams den Prüfgegenstand analysieren, wodurch die Betriebsblindheit des Autors umgangen wird.
Beide Methoden finden meist unterschiedliche Fehler und sollten daher beide zum Einsatz kommen
- Inspektion: Review-Team bereitet Inspektion vor (Checklisten), Autor des Prüfgegenstands stellt ihn vor, Review-Team diskutiert, Moderator protokolliert gefundene Fehler (primär Verifikation)
- Walk-Through: formloser; Testspezialist stellt Testszenarien vor, Review-Team arbeitet gemeinsam durch, keine Checklisten, mehr Fokus auf Anforderungen (primär Validierung)
Standardkonformität und Schlüssigkeit (Verifizierung)
Vollständigkeit und Angemessenheit (Validierung)
Testing
Es kann keine Fehlerfreiheit nachgewiesen werden, sondern nur existierende Fehler gefunden werden.
funktionale Testverfahren
strukturelle Testverfahren
Black-Box Verfahren prüfen, ob die Ausgabe eines Programm(teil)s bei bestimmter Eingabe der Erwartung entspricht. Es müssen also möglichst fehleranfällige Eingabekombinationen ermittelt werden, um Fehler zu finden. Die innere Struktur des Programms wird dabei ignoriert. Bei White-Box Verfahren ist die innere Struktur bekannt und es wird mit Coverage-Tests versucht jeden möglichen Pfad im Programm durch geeignete Wahl der Eingaben zu durchlaufen.
- Modultests / Unit-Tests
- Integrationstests
- Systemtest
- Abnahmetest
Test von einzelnen Prozeduren / Klassen / Komponenten um Black- und White-Box Verfahren
Zusammenspiel von Modulen (Black- und White-Box), also ob Schnittstellen korrekt spezifiziert und implementiert sind.
Gibt die Reihenfolge vor in der Module integriert werden, entweder
- top-down: vom aufrufenden zum aufgerufenen Modul
- bottom-up: vom aufgerufenen zum aufrufenden Modul
Gesamtsystem wird auf Einhaltung der Anforderungsspezifikation getestet (Black-Box). Performanz-, Last-, Stress- und Robustheitstests zur Prüfung nicht-funktionaler Anforderungen.
Testen im realen Umfeld (Black-Box) gegen die Erwartungen der Anwender. Prüft
- Gebrauchstauglichkeit
- äußere Korrektheit
- Zusammenspiel mit anderen Systemen in der Einsatzumgebung
Ein wiederholter Test nach (vermeindlicher) Fehlerbeseitigung.
Capabilitiy Maturity Model
Ein Reifegradmodell zur Beurteilung der Qualität des Softwareprozesses von Organisationen sowie zur Bestimmung der Maßnahmen zur Verbesserung desselben.
- initial
- repeatable
- defined
- managed
- optimized
Zielvorgaben, technische und Management-Aktivitäten der aktuellen Stufe erfüllen, um nächste zu erreichen.
ISO 9000, 9001, 9000-3
Unterstützung und Teilautomatisierung von Entwicklungsprozessen.
- mehr Entwicklungszeit für kreative Inhalte statt repetitive Tätigkeiten
- höhere Produktivität durch Automatisierung
- standardisierter Output für Einheitlichkeit und Konsistenz zwischen Entwicklern
- Verbesserung des Prozesses und des Produkts durch Unterstützung bei Methodenanwendung
Softwareentwicklungsumgebung
Sammlung von Hardware- und Softwarewerkzeugen, die die Entwicklung von Software in einem bestimmten Anwendungsbereich unterstützen.
- Programmierumgebungen (Integretad Development Environment (IDE))
- CASE-Tools (Computer Aided Software Engineering)
- Software-Engineering-Umgebungen
Wenig bis keine Unterstützung bei Anforderungsermittlung / Entwurf. Für gewöhnlich
- Editor mit Syntax-Highlighting
- Browser für mehrere Code-Dateien
- einfaches Ansprechen von Compilern
- Integration des Debuggers
CASE steht für Computer-aided Software Engineering, es handelt sich also um Werkzeuge für die Softwareentwicklung.
Unterstützung bei Spezifikation und Entwurf von Software, meist grafische Darstellung, wenig bis keine Unterstützung beim eigentlichen Programmieren. Können ggf. Code-Snippets generieren
Multiple Darstellungen von Entwürfen gehen alle auf einen gemeinsamen Quelltext zurück
Unterstützung für langlebige Softwareprojekte. Decken die Bereiche der CASE-Tools ab, aber darüber hinaus noch Konfigurations- und Versionsmangement, Qualitätssicherung und Projektmanagement.
- basiert auf DBMS, sodass auch andere Werkzeuge auf die Datenbasis zugreifen können
- offen (wohldefinierte Schnittstelle) für die Anbindung weiterer Werkzeuge
- Werkzeuge für
- Anforderungsermittlung
- Entwurf
- Implementierung (Programmiersprache)
- Test
- Debugging
- Management von
- Projekt
- Dokumentation
- Konfiguration
Unified Modeling Language
- Kapselung
- Geheimnisprinzip
- Vererbung / Generalisierung
- Wiederverwendbarkeit
Durchgängigkeit von Methoden und Techniken bei der Anforderungsermittlung, Entwurf und Implementierung. Von abstrakten, unscharfen Modellen in schrittweiser Verfeinerung ergibt sich der Programmcode fast automatisch.
- Strukturelle Modelle (Klassendiagramme)
- Funktionale Modelle (Anwendungsfalldiagramme)
- Verhaltensorientierte Modelle
- Ablaufverhalten (Interaktionsdiagramme: Sequenzdiagramm, Kollaborationsdiagramm)
- Objektverhalten (Zustandsdiagramme)