Softwaretechnik- Praktikum: 8. Vorlesung

Softwaretechnik- Praktikum: 8. Vorlesung Raum E 3.343 Tel. 60-3307 Email: axenath@uni-paderborn.de

Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software Management IV Software Qualitätssicherung V Zusammenfassung V8-2

Softwaretechnikpraktikum: III Software-Management Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de

III Software-Management III.1 Grundlagen III.2 Planung III.3 Organisation III.4 Personal/Leitung III.5 Kontrolle III.5.1 Versions- und Konfigurationsmanagement III.6 Diskussion & Zusammenfassung III.7 Literaturhinweise V8-4

Problem bei Software [Balzert1998] Kontrollmethoden können nur die bisher benötigte Zeit und die entstandenen Kosten als Maßstab nehmen! Vorgaben (Standards) für Entwicklungsaktivitäten nicht definiert (und schriftlich fixiert) oder nicht durchgesetzt Software-Meßtechnik nicht ausreichend Fehlende Software-Maße (Metriken) über den Entwicklungsprozess und das Produkt. V8-5

Aufgaben des Managements (1) Vorgaben entwickeln und festlegen (2) Kontroll- und Berichtssystem etablieren (3) Prozesse und Produkte vermessen (4) Korrigierende Aktionen initiieren (5) Loben und Tadeln [Balzert1998] V8-6

(1) Vorgaben [Balzert1998] des Prozessmodells und von Produktivitäts- sowie Prozessmetriken von Qualitätssicherungsmethoden und Qualitätsmetriken Standards helfen hier Einarbeitungs- / Umschulungskosten sowie die notwendige Kommunikation zwischen Teammitgliedern zu verringern den Personalaustausch zwischen Projekten sowie die Weitergabe von Erfahrungen zu verbessern Wartung und Pflege zu vereinfachen Kontrolle zu erleichtern V8-7

(2) Kontrolle & Berichte [Balzert1998] Kontrolle des Prozesses Budgetüberprüfungen Meilensteinüberprüfungen Verfolgung der Top 10-Risiken Qualitätssicherung Kontrolle des Produkts Konfigurationsmanagement Qualitätssicherung Berichtssystem muss Kontrollen sicherstellen! V8-8

(3-5) Messen & Feedback [Balzert1998] (3)Prozesse und Produkte vermessen Mess- und Überprüfungsverfahren auswählen und etablieren (4)Korrigierende Aktionen initiieren Überstunden anordnen usw. Projektplan ändern (5)Loben und Tadeln Nichtmonetäre Belohnungen. V8-9

Software-Metrik Software-Metrik Kenngröße eines Software-Produkts Kenngröße eines Software-Prozesses Meßtechnik (1) Definition der Meßziele (2) Ableitung der Meßaufgaben aus den Meßzielen (3) Bestimmung der Meßobjekte (4) Festlegen der Kenngröße und Meßeinheit (5) Zuordnung der Meßmethoden und Meßwerkzeuge zu den Meßobjekten und Meßgrößen (6) Ermittlung der Meßwerte (7) Interpretation der Meßwerte. V8-10

Beispiel-Metrik: Umfang [Balzert1998] (1) Meßziel: Bestimmung der Anzahl der nicht kommentierten Quellanweisungen (2) Meßaufgabe: Zählen der Anzahl der nicht kommentierten Quellanweisungen eines Programms (3) Meßobjekt: Auswahl eines zu vermessenden Programms. (4) Kenngröße: Anzahl Quellanweisungen einschl. Compiler- Anweisungen und Datendeklarationen, aber ohne Leerzeilen oder Kommentarzeilen (5) Meßeinheit: Lines of Code (LOC ) oder KLOC (6) Meßmethoden/Meßwerkzeuge: Automatischer Zeilenzähler (7) Interpretation: Repräsentiert den Umfang der produzierten Software V8-11

Gütekriterien für Software-Metriken [Balzert1998] 1 Objektivität (Intersubjektivität) Objektiv, wenn keine subjektiven Einflüsse des Messenden auf die Messung möglich 2 Zuverlässigkeit (Meßgenauigkeit) Maß ist stabil und präzise (zuverlässig) 3 Validität (Gültigkeit, Meßtauglichkeit) Eindeutiger und unmittelbarer Rückschluß auf die Ausprägung der Kenngröße 4 Normierung Gibt es eine Vergleichbarkeitsskala, dann ist ein Maß normiert. 5 Vergleichbarkeit Kann ein Maß mit anderen Maßen in eine Relation gesetzt werden? 6 Ökonomie Möglichst geringe Kosten Abhängigkeiten Automatisierungsgrad Anzahl der Meßgrößen Anzahl der Berechnungsschritte 7 Nützlichkeit Werden mit einer Messung praktische Bedürfnisse erfüllt? V8-12

III.5.1 Konfigurationsmanagement Siehe Vorgriff (erste Vorlesung) Einfaches Softwarekonfigurationsmanagement (SKM) In dieser Vorlesung: 1. Historie und aktuelle Herausforderungen zur Motivation Realität Unterschiedliche Daten unterschiedliche Anforderungsmanagementsysteme 2. Konzepte von Konfigurationsmanagementsystemen (KM) [Balzert1998] V8-14

Realität des KM!!! Viele Kunden mit noch mehr Wünschen Mehrere Produkte Evtl. zusammengefasst in Produktlinien Sehr viele Entwickler Plugin Plugin Komp Komp Broadcast max10t Int i=0; Anforderungen Software-KM PDM Test-Management V8-15

Anforderungen Werden teils stärker strukturiert Hierarchisierungen Attribute Mit Meta- Informationen, z. B.: Forderung oder Wunsch V8-16

Software-KM Schon kennen gelernt!?! Modellbasierte Entwicklung und Mischverfahren V8-17

Produktdatenmanagement Historisch aus dem Maschinenbau Unterstützt eine andere Arbeitsmethodik Strukturorientiert Exklusiver Zugriff Häufig enge Integration in spezielle Modellierungswerkzeug e, insb. CAx (z.b. Computer Aided Design) V8-18

III.5.1 Konfigurationsmanagement Siehe Vorgriff (erste Vorlesung) Einfaches Softwarekonfigurationsmanagement (SKM) In dieser Vorlesung: 1. Historie und aktuelle Herausforderungen zur Motivation Realität Unterschiedliche Daten unterschiedliche Anforderungsmanagementsysteme 2. Konzepte von Konfigurationsmanagementsystemen (KM) [Balzert1998] V8-19

Konzepte von KM-Systemen (1) Versionierung (2) Produktstrukturen (3) Varianten (4) Konfigurationen (5) Nebenläufige Entwicklung (6) Release-Management (7) Workflow-Management (8) Änderungsmanagement V8-20

(1) Versionierung Wie überarbeite ich Dateien? Motivation Durch inkrementelles oder iteratives Arbeiten wird eine Datei mehrfach überarbeitet. Zugriff auf alte Bearbeitungsstände soll oder muss möglich sein Begriffe: Revision Version Tag Baseline Release Vorab zum Tester geschickt Release 1 v1 v2 v3 v4 v1 v2 v3 V8-21

(1) Versionisierungsmechanismen Was versioniere ich eigentlich? Die neue Datei oder die Überarbeitung? Versionsbasierter Ansatz Änderungsbasierter Ansatz (change set) v1 v2 v3 v4 v1 v2 v3 v1 v2 v3 v4 v1 v2 v3 1,3 2 2,4 3 Versionsbasierter Ansatz Änderungsbasierter Ansatz V8-22

(2) Produktstrukturen Wie greife ich auf meine Dateien zu? CVS: Identifikation der Dateien durch Pfad und Namen Subversion: Dateien erhalten eigene Identität und können verschoben werden In PDM-Systemen: Geschäftsobjekte Beziehungen Ist Teil von Ist abgeleitet aus Ist eine Art von Ist äquivalent zu V8-23

(3) Varianten Wie nutze ich eine Datei für mehrere Kunden oder Produkte, wenn diese jeweils andere Anforderungen erfüllen soll? Bugfixes auf Release und neue Funktionalität für nächsten Release trennen Unterschiedliche Produkte!!! Mehrere Produkte Evtl. zusammengefasst in Produktlininen Release 1 Release 2 Neue Funktionalität Verzweigen (Branch) Mischen (Merge) Bugfix V8-24

(4) Konfigurationen Wie bekomme ich die Dateien aus dem Repository, die ich gerade braucht? Konfigurationen werden gebildet durch Configuration-Query Anfragesprache unterscheiden sich in Auswahl nach Dateien Zugriff auf Versionen von Dateien Meta-Information Zeit Bearbeiter Auszeichnungen, wie Baselines, Tags, Labels Über Änderungen v1 v2 v3 v4 v1 v2 v3 v1 v2 v3 v4 v1 v2 v3 1,3 2 2,4 3 Achtung: im Bereich Maschinenbau wird unter Konfiguration häufig die Parametrisierung oder Ausstattung eines Produkts verstanden Last changes from Maik V8-25

(5) Nebenläufe Entwicklung Sperrverfahren (siehe Vorlesung 2) Aber: Granularität beachten Auf Objektebene Auf Dateien Strukturen V8-26

(6) Release Management Im Praktikum: Wie stelle ich mein Plugin zur Verfügung? Wie erstelle ich den kompilierten Code? Wie binde ich Bibliotheken ein? Wie kommen Hilfstexte mit ins Plugin Im SKM häufig durch externe Tools Export Funktionalität von Exclipse Zip, ant, make, In anderen Bereiche gut unterstützt: Report Generation in Doors Assembly Structure, Erstellung von Teilelisten für ERP (Enterprise Resource Planning) aus Basis von Meta-Daten Insbesondere Abhängigkeiten aus den Produktstrukturen werden berücksichtigt. V8-27

(7) Workflow Muss zu Prozessplänen passen V-Modell, SPEM Reifegrade Worklists Besonders weit entwickelt in PDM- Systemen initial created reviewed final V8-28

(8) Änderungsmanagement Beantragen von Änderung Analysieren der Auswirkung einer Änderung Voraussetzung: Traceability Welche Beziehungen sind modelliert? Impact-Analysis Auswirkungsanalyse Anforderung Test geplant In Bearb. QS vorgelegt Modell QS akzeptiert V8-29

III.6 Diskussion & Zusammenfassung (1/2) Software Management umfasst alle Aktivitäten und Aufgaben, die von einem oder mehreren Managern durchgeführt werden, um die Aktivitäten von Mitarbeitern zu planen und zu kontrollieren damit ein Ziel oder der Abschluss einer Aktivität erreicht wird, die durch die Mitarbeiter alleine nicht erreicht werden können. Primäres Ziel eines Unternehmens ist es seinen Gewinn zu maximieren, so dass ein optimales Verhältnis von erzieltem Wert zu Aufwand (Produktivität) entsteht. In der Softwaretechnik setzt man pragmatisch Wert mit Umfang und Aufwand mit Personalaufwand gleich. Planung bedeutet im voraus zu entscheiden, was zu tun ist, wie es zu tun ist, wann es zu tun ist und wer es zu tun hat. Dabei ist Planung keine einmalige Angelegenheit, sondern sie muss sich dynamisch und flexibel der Entwicklung anpassen. V8-31

Diskussion & Zusammenfassung (2/2) Um erfolgreich Software zu entwickeln muss mittelfristig eine geeignete Aufbauorganisation identifizieren und etablieren werden und kurzfristig benötigte projektspezifische Festlegungen beim Projektstart erfolgen. Wegen der notwendigen fachlichen Qualifikationen und der hohen Innovationsgeschwindigkeit ist Spezialisierung unvermeidlich. Dabei sprechen deren Vorteile für eine horizontale Spezialisierung. Deren Nachteile müssen durch das Software-Management vermieden werden. Managementaktivitäten müssen sicherstellen, dass die laufenden Tätigkeiten mit dem Plan übereinstimmen. Dafür ist der Kontrollprozess der (1) Pläne und Vorgaben festlegt, (2) die Ausführung gegen diese Pläne und Vorgaben kontrolliert und (3) bei Abweichungen zu Korrekturen führt (Soll-Ist Vergleich). V8-32

II.7 Literaturverzeichnis [Balzert1996] Helmut Balzert: Lehrbuch der Software-Technik: Software- Entwicklung. Spektrum Akademischer Verlag 1996. [Balzert1998] Helmut Balzert: Lehrbuch der Software-Technik: Software- Management, Software- Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag 1998. V8-33

Softwaretechnikpraktikum: Aktuelle Aufgaben und Fragerunde Fragerunde und aktuelle Aufgaben

Wiederholung: Reverse-Engineering (1/3) Fragen: Welche Daten sollen beim Reverse Engineering der anderen Plug-ins erworben werden? Nur Klassendiagramm oder auch Verhaltensdiagramme? Welche Abläufe zwischen den Schnittstellen sollen wie im Verhaltensdiagramm erfasst werden? Welche Tools, die sich zum Reverseengineering eignen, sind empfehlenswert? Sollen wir beim Reverse Engineering des Design Teile des Pflichtenhefts, die Klassendiagramme, Aktivitätendiagramme und Teile des Analyseheftes mit seinen Sequenzdiagramme erstellen? Oder reichen UML Diagramme? Müssen alle beginn-user-doc an denen more description here steht, die in den Klassen sind, von uns dokumentiert werden? Wenn ja wie genau? Mir unklare Fragen: Wie genau sollen die Klassen z.b. Actor in ComponentAndBehavior von uns dokumentiert werden? Geht es hier um Das Was oder auch um das Wie? V8-35

Was ist Reverse Engineering? Was Was wird wird mit mit Design in in V5- V5-9 gemeint? **Entwurf** [Chikofsky&Cross1990] E. J. Chikofsky and J. H. Cross, Reverse Engineering and Design Recovery: A Taxonomy IEEE Software, vol. 7, pp. 13--17, Jan./Feb. 1990. V8-36

Wiederholung: Reverse-Engineering (3/3) Wurde adressiert beim Tutorial: Was sind gute Startpunkte für das Reverse Engineering? Welches Vorgehen ist sinnvoll? Da alle Quellen, die ich mir angeschaut habe (Vorlesungsfolien, Wikipedia (deutsch + englisch), Dokumente der Uni Bremen) sehr vage in Bezug auf das Vorgehen beim Reverse Engineering waren, würde ich mir ein kleines, praktisches Beispiel für das Tutorium wünschen. Sonstiges: 3x keine Fragen gestellt! 2 x Fragen zum Test statt Reverse-Engineering 1x unklar, wer der Verantwortliche ist V8-37

Aufgaben/Abgaben: V8-38

Fragen? V8-39