Post on 17-Sep-2018
SOFTWARE MANAGEMENT
DER BLICK VON AUSSEN: VORGEHENSMODELLE
WERKZEUGE REQUIREMENTS- UND CHANGE-MANAGEMENT
PRODUKTREIFE QUALITÄTSMANAGEMENT
KONFIGURATIONSMANAGEMENT
Die Mission
Software-Entwicklung erfordert Qualifikation und Methodik Vorgehensmodell, Zeitplanung, Leitung Entwicklungswerkzeuge Versionsverwaltung Bugtracker Testplan und –system… (c)schmiedecke 2013 SE2 2
ein starkes Team auf großer Mission
UND…
Anforderungsmanagement
Anforderungsgetriebene Entwicklung Entwicklung ohne Anforderung "Verschwendung"
Anforderungen des Auftraggebers / Product Owners
Anforderungen sind verbal und unsystematisch (z.B. User Stories)
Management-Aktionen: priorisieren, schätzen, einplanen
Anforderungs – und Änderungsmanagement Anforderungen erzeugen Features, Code, Testfälle
Anforderungen ändern sich
Rückbau / Anpassung systematisch erforderlich
Rückverfolgbarkeit (Tracability)
Änderungen werden Anforderungen (priorisieren, schätzen, einplanen)
So wichtig, dass der Begriff "Requirements Engineering" geprägt wurde
(c)schmiedecke 2013 SE2 3
(c) schmiedecke 13 SE2-11-Software-Management 4
Was sind Anforderungen?
Verschiedene Kategorien: funktionale / nicht funktionale Anforderungen
Passwortschutz / Barrierefreiheit
zahlreiche Unterkategorien!
fachliche / technische Anforderungen Einstellbarkeit des Dispolimits / Portabilität
Fließende Grenzen Während des Prozesses Verschiebung in Richtung funktional bzw. technisch
Vor allem sind Anforderungen nicht formal! die differenzierte Ausdrucksfähigkeit der natürlichen Sprache ist essentiell
d.h. wir benötigen einen formalisierten Prozess für nicht formalisierte Artefakte.
Dokumentation von Anforderungen
Teilformalisierte Artefakte Formale Referenz (e.g. Nummer)
Freier Text
Attribute / Tags: Kategorie, Priorität, Historie
Bewertung
Tracing-Informationen
(c) schmiedecke 13 SE2-11-Software-Management 5
Anforderungen an Anforderungen
• Überprüfbar
• Verständlich
• Eindeutig
• Nachverfolgbar
• Gut abgegrenzt
(c) schmiedecke 13 SE2-11-Software-Management 6
"Keine wichtigen Interaktionen ohne Login."
"Die Software weist eine hohe Performance auf."
"Transaktionen werden durch den Benutzer oder durch das System ausgelöst."
(c) schmiedecke 13 SE2-11-Software-Management 7
Anforderungsdynamik: Differenzierung durch Erkenntnis
• Anforderungen ändern sich zwangsläufig!
• Anforderungsmanagement muss die Konsequnezen beherrschen! – Identifizierung / Referenzierung der Anforderungen
– Prozessschritte bei Anforderungsänderungen
– Nachverfolgbarkeits-Strategie
– Werkzeugeinsatz
Erst- Anforderungen
Modifizierte Anforderungen
Erstes Problem- verständnis
Erweitertes Problem- verständnis
(c) schmiedecke 13 SE2-11-Software-Management 8
Anforderungsdynamik: Vernetzung
• Zurückverfolgbarkeit zur Quelle – ursprüngliche Beteiligte bei jeder Änderung konsultieren
• Querbezüge unter Anforderungen – andere Anforderung Ursache der Anforderung?
– andere Anforderung Konsequenz der Anforderung?
– Anforderung abhängig von anderer Anforderung?
– andere Anforderung abhängig von der Anforderung?
– schwächere Beziehung zu anderen Anforderungen
• Nachvollziehbarkeit der Umsetzung – umsetzende Modell- / Entwurfs- / Implementierungsobjekte
– abhängige Modell- / Entwurfs- / Implementierungsobjekte
– (noch) widersprechende Modell- / Entwurfs- / Implementierungsobjekte
Vernetzungskonzepte
Enterprise Architect (Sparx Systems): Anforderungen sind (UML)-Modellobjekte, die andere
referenzieren:
Anforderung besteht aus Teilanforderungen
Anforderung ist aus Anforderung hervorgegangen
Anforderung ist in Use Case berücksichtigt
Anforderung bezieht sich auf Klasse / Paket / Assoziation
(c) schmiedecke 13 SE2-11-Software-Management 9
Vernetzungskonzepte Requisite Pro (Rational Software) Anforderung ist markierter Teil eines Dokuments /
Artefakts (Quelle) Anforderung hat Attribute Anforderung bezieht sich auf andere Anforderungen Anforderung bezieht sich auf Artefakte
(c) schmiedecke 13 SE2-11-Software-Management 10
(c) schmiedecke 13 SE2-11-Software-Management 11
Requirements-Werkzeuge
• Requirements-Werkzeuge
– datenbankgestützte Anwendungen
– Anforderungen können erfasst und miteinander vernetzt werden.
– Abhängigkeitsstrukturen visualisierbar
• Einfache Werkzeuge (Bsp. OSRMT) – Anlegen von Anforderungen verschiedener Typen – Verlinken mit Quelldokumente – Anlegen von Traces zwischen Anforderungen
• Integrierte Werkzeuge (Requisite Pro, In-Step, EA) – gemeinsames Dokumenten-Repository der Werkzeuge – Koopereation mit einem CASE-Tool – Abhängigkeit zu Modellelementen und Artefakten spezifizierbar
Qualitätsmanagement
Qualitätssicherung Systematische Testdatengewinnung
Unit-, modul- und Integrationstests
Testautomatisierung
(c)schmiedecke 2013 SE2 12
Qualitätsmanagement Prozessdefinition, die Qualität des Produkts sicherstellt
Prozessmanagement
Prozessreife nach dem CMM (Capability Maturity Model)
Zertifizierung …
(c) schmiedecke 13 SE2-11-Software-Management 13
Prozessmanagement
Prozessmanagement bedeutet Gestaltung und Kontrolle des Entwicklungsprozesses
nach anerkannten Regeln
Management ist Voraussetzung für Prozessreife z.B. nach CMM (Capability Maturity Model) :
Stufe 1: Initialer Prozess = Ad-hoc-Prozess
Stufe 2: Wiederholbarer Prozess = Intuitiver Prozess
Stufe 3: Definierter Prozess = Qualitativer Prozess
Stufe 4: Gesteuerter Prozess = Quantitativer Prozess
Stufe 5: Optimierender Prozess = Rückgekoppelter Prozess
(c) schmiedecke 13 SE2-11-Software-Management 14
Schritte zur Prozessreife
Vorgehensmodelle Definieren den Prozess in Einzelschritten und deren Interdependenzen
CMM Stufe 3
Schaffen die Voraussetzungen für die Prozesssteuerung
CMM Stufe 4
Metriken Werden für die Steuerung / Quantifizierung benötigt
Sind die Grundlage der Optimierung / Rückkopplung CMM Stufe 5
Metriken typischerweise in "% Zielkonformität"
Pünktlichkeit wichtige Metrik (% Zeitüberschreitung)
ALM – Application Life Cycle Management
A1
A2
(c)schmiedecke 2013 SE2 15
Managementaufgaben der Gesamtmission:
Strategische Produktplanung
Ideen, Visionen, Weiterentwicklungsmöglichkeiten
Marktwert
Kosten
Lebensdauer
Firmenkontext
Produktmanagement
Releases,
Konfigurationen,
Anpassungen
Gesamtcontrolling
Zeit- und Ressourcenplanung und –kontrolle
Preisgestaltung, Absatzkontrolle
(c) schmiedecke 13 SE2-11-Software-Management 16
Konfigurationsmanagement (SCM)
...und im Gegensatz zu Nachwuchs
– existieren verschiedene Entwicklungsstufen desselben Produkts nebeneinander,
– sind nicht alle Teile zusammengewachsen.
Software entwickelt sich...
(c) schmiedecke 13 SE2-11-Software-Management 17
Chaospotential! • Bereits korrigierte Fehler tauchen wieder auf.
• Vermeintlich geänderte Features sind unverändert.
• Es ist unbekannt, ob in der ausgelieferten Version bestimmte Fehler behoben sind oder nicht.
• Es gelingt nicht, eine Version herzustellen, in der alle Änderungen bis zu einem bestimmten Stichdatum enthalten sind, nach dem das System instabil wurde.
• Die ausgelieferte Version läuft nicht, weil dafür alle Komponenten neu übersetzt wurden, in der Testphase dagegen nur die aktuell geänderten.
• Ein Datenverlust erzwingt für die Weiterentwicklung den Rückgriff auf eine ältere Version – und es ist unbekannt, welche bereits behobenen Fehler sie noch enthält.
(c) schmiedecke 13 SE2-11-Software-Management 18
Konfigurationen
• Eine Konfiguration ist ein "Freeze" – Projektzustand zu einem bestimmten Zeitpunkt – freigegeben – mit zugesicherten Eigenschaften
• umfasst Vielzahl von Software-Elementen – Modelle, Spezifikationen, Dokumentationen – Module mit Testfällen – Werkzeuge – Datenbestände
• beschrieben durch ein KID (Konfigurations-Identifizierungs-Dokument).
• Auslieferung umfasst nur einen Teil einer Konfiguration.
(c) schmiedecke 13 SE2-11-Software-Management 19
KID – Konfigurations-Identifizierungs-Dokument
• Elemente sind Dateien
• Identifizierung über den Dateinamen nicht eindeutig: – Namenskonventionen oft nicht projektübergreifend durchsetzbar
(verschiedene Werkzeuge)
– Umbenennungen erschweren Referenzierung
– logische Strukturierung oft anders als technische oder organisatorische
• Eindeutige Bezeichnungskonvention im KID – mit Abbildung auf Dateinamen und Attribute
– kann beliebige Struktur reflektieren
– Mehrfachnennung bedeutet Mehrfachnutzung
• Werkzeuge gehören dazu – auch mit Version!
Datenstruktur des KID (nach Balzert)
Attribut Beispiel
Typ Produktkonfiguration Beta
Version V 1.8.0 Beta
Status abgenommen 23.09.2009 gt/tz
Pflichtenheft SemOrg V.1.4.0
UML-Modell SemOrg25_2
GUI SemOrg25_2_6
Source-Version V 1.8.0 Beta (Subversion SemOrg)
Test-DB SemOrgT Dump1.8.0 (Subversion SemOrg)
Bibliotheken NGUI.jar 2.2.14; truebind.jar 4.0; ……
IDE eclipse 3.7
Java-SDK 1.4.02
DBMS Oracle 10g Deutsch
… (c)schmiedecke 2013 SE2 20
(c) schmiedecke 13 SE2-11-Software-Management 21
Konfiguration, Baseline, Daily Build
• Konfigurationen – sind benannte und freigegebene Projektzustände – mit gesicherten Eigenschaften.
• Baselines:
– Zwischenzustände als Fallback – auch: "Referenzkonfigurationen" genannt – Quasi "Schnappschüsse" – getestet, aber dokumentierte Fehler möglich
• Daily Builds: Tagesstände – kleinmaschige Referenzkonfigurationen – zugesichert: Standardtests laufen durch bzw. scheitern wie
dokumentiert – v.a. in agilen Projekten üblich
• wirken allgemein qualitätssteigernd!
(c) schmiedecke 13 SE2-11-Software-Management 22
Versionen
• Version – Eigenschaft des einzelnen Software-Elements
– typischerweise als Nummer erfasst:
– Release-Nr . Level-Nr 0.4, 0.5, 1.0, 1.1, 1.2, 1.3, 2.0,...
– Verteilung / Vertrieb: Releases als Gesamtauslieferung oder Update, Levels als Patches
• Versionsverwaltung – Automatische Versionierung
– Checkin / Checkout-Modell (exklusiver Schreibzugriff)
– Checkout / Merge-Modell (explizite Konfliktbehandlung)
– Speicherung nach dem Delta-Prinzip
– zumindest zwischen Releases.
(c) schmiedecke 13 SE2-11-Software-Management 25
Varianten
Baumartige Verzweigungen. Zu jeder Version muss die Ausgangsversion
gespeichert werden.
Gründe für Varianten: Fortentwicklung ausgelieferter Systeme
(Kundenvarianten) Parallelkonfigurationen für verschiedene Plattformen
(Plattformvarianten) Rückbau eines instabilen Zweiges
(Entwicklungsvarianten)
(c) schmiedecke 13 SE2-11-Software-Management 26
Release-Strategie • Releases sind teuer
– Alle kleineren Änderungen als Levels einstufen. – für wichtige Levels Patches verteilen.
• Release-Faktoren: – Umfangreiche neue Funktionalität – Technische Qualität:
System weist schwerwiegende oder weitreichende Mängel auf, die viele Nutzer betreffen.
– Plattform-Änderungen: neue Version bei Betriebssystem oder Software-Plattform
– Markt, Wettbewerb Konkurrenz-Produkt ist neu oder in neuer Version erschienen
– Marketing-Forderung Termine wie Messen oder Schulungen
– Kunden-Forderung Kunde hat Erweiterung geordert und bezahlt
(c) schmiedecke 13 SE2-11-Software-Management 27
Konfigurations-DB
• Querbezüge zwischen Konfigurationen müssen ermittelbar sein: – welche Konfigurationen setzen noch auf Java 2 auf?
– welche Konfigurationen benutzen Modul X in Version Y oder kleiner?
– welche Konfigurationen wurden vor dem 1.1.07 erstellt?
– welche Konfigurationen haben eine Version von Modul X, die auf Version Y zurückgeht?
Querbezüge zwischen Konfigurationen müssen ermittelbar sein
• Ohne Werkzeug geht es nicht! – mindestens Konfigurationsdatenbank
– KIDs daraus generierbar
• besser: In IDE oder CASE-Tool integriertes Konfigurationswerkzeug
– ....
(c) schmiedecke 13 SE2-11-Software-Management 28
Konfigurations-DB
Datenmodell (vgl. KID): Konfiguration, Baseline, Build
Software-Elemente Typ, Version, Autor, Vorgängerversion, Änderungsdatum,
Werkzeugreferenz
Testdaten (ggf. DB-Dump)
Abhängigkeiten von anderen Software-Elementen
Software-Werkzeuge Compiler, Laufzeitumgebung, Middleware, Bibliotheken,
Fremdkomponenten jeweils mit Version
IDE, CASE-Tool, Testwerkzeuge, Analysewerkzeuge, ...
Auslieferungsdatei, Installer
(c) schmiedecke 13 SE2-11-Software-Management 29
Wie reagiert man darauf?
• Die Firmenleitung hat beschlossen, ab sofort auch Mac/OS zu unterstützen. Das betreffend Produkt existiert in 2 technologischen und 3 Komfortvarianten.
• Ein Windows-Nutzer hat einen gravierenden Fehler gemeldet, der auf Linux-Systemen nicht reproduzierbar ist. In der Konsequenz kann ein Feature zumindest auf Windows-Systemen nur noch eingeschränkt angeboten werden.
• Das aktuelle Release erweist sich unter Lastbedingungen als instabil. Die Ursache ist nicht erkennbar. Aktuell wird an einem neuen Level gearbeitet, das auf dieses Release aufsetzt.
(c) schmiedecke 13 SE2-11-Software-Management 30
SCM-Werkzeuge
• AccuRev
• ClearCase
• Serena Dimensions
• Perforce
• SpectrumSCM
• Surround SCM
• Sablime
• Smart Bear
• SET-LIBER
• Telelogic Synergy (ehem. Synergy/CM, ehem. CM/Synergy, ehem. CCM)
• Trac
• uvm.
Quelle Wikipedia
(c) schmiedecke 13 SE2-11-Software-Management 31
Zusammenfassung
• SCM dient der Kontrolle des Produkts
– während Entwicklung und Betrieb / Wartung.
• Konfiguration: benannter und freigegebener Projektstand
– interne Zwischenstände bilden Baselines (Referenzkonfigurationen )
– Besonders in agilen Projekten erstellt man täglich Referenzkonfigurationen, Daily Builds.
• Verbindliche Versionszählung für alle Software-Elemente.
– Jede Änderung führt zu einer neuen Version.
– Große Änderungen ergeben ein Release.
– Zwischenstufen heißen Levels.
– Parallele Entwicklungszweige heißen Varianten.
(c) schmiedecke 13 SE2-11-Software-Management 32
Zum Schluss: Father Brown's Meinung
Father Brown laid down his cigar and said carefully:
"It isn't that they can't see the solution. It is that they
can't see the problem."
G.K.Chesterton, The Father Brown Stories.
Cassell & Co, London 1929