Softwaretechnik- Praktikum: 6. Vorlesung Vkrit Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de V6-2 Übersicht I Einleitung II Ergänzungen zur Software-Entwicklung III Software Management IV Software Qualitätssicherung V Zusammenfassung Softwaretechnikpraktikum: III Software-Management Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de V6-3 III Software-Management III.1 Grundlagen III.2 Planung III.3 Organisation III.4 Personal/Leitung III.5 Kontrolle III.6 Diskussion & Zusammenfassung III.7 Literaturhinweise III.1 Grundlagen 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 Dies umfasst Aufgaben wie Planung, Organisation, Leitung und Überwachung Kurzform: Das Management sorgt dafür, dass gewählte Ziele durch Mitarbeiter erreicht werden. V6-5 V6-6 1
Gewinn & Produktivität Primäres Ziel ist es Gewinn zu machen und diesen auch noch zu maximieren Maximales Ergebnis Bei minimalem Aufwand Ergebnis Produktivität = Aufwand Fragen: (1) Welche Faktoren beeinflussen die Produktivität? (2) Wie misst man Produktivität? (3) Wie steigert man die Produktivität? (1) Welche Faktoren beeinflussen die Produktivität? Externe Einflüsse Qualität Wert Quantität Produktivität Zeit Kosten Komplexität Schwierigkeitsgrad Personalaufwand Randbedingungen V6-7 V6-8 Weitere Einflussfaktoren Produkt Anwendungsgebiet Techniken Prozesse, Methoden, Werkzeuge Wiederverwendung Mitarbeiter Ausbildung & Erfahrung (Anwendungsgebiet oder Methodik) Individuelle Produktivität (schlechtester : bester = 1 : 10; durchschnitt : bester = 1 : 2,5) Management Arbeitsplatz (Einzelzimmer, Telefon (andere Störungen) Teamgröße (je größer desto schlechter) Firmenkultur Qualifikation / Fortbildung Motivation Einflussfaktoren der Aufwandsschätzung Qualität + Entwicklungsdauer Produktivität - - + Quantität Kosten Einflußfaktoren Quantität Qualität Entwicklungsdauer Kosten Produktivität ist normalerweise immer eine gleichbleibende Fläche Das Teufelsquadrat [Balzert1996] V6-9 V6-10 (2) Wie misst man das Ergebnis? Antworten: Marktwert des Produktes Erzielbarer Umsatz bzw. Gewinn Aber: Schwer meßbar und noch schwerer prognostizierbar Kein inhärentes Maß des Produkts (z.b. Marktlage) nicht Informatik Bewertung durch Marketing/Vertrieb Pragmatische Lösung Wert: Man misst nur die Quantität nicht den Wert Qualität wird durch extra Maßnahmen gewährleistet (siehe später Kapitel IV) Quantität : Meist wird das Ergebnis durch die Anzahl der Programmzeilen der resultierenden Software quantifiziert: LOC = lines of code (Sourcecode ohne Kommentare) V6-11 V6-12 2
LOC: Bewertung - abhängig von der Programmiersprache (aber es gibt Umrechnungsfaktoren) - abhängig vom Programmierer - ignoriert andere Dokumente (die sind aber oft proportional zu LOC) - Qualität des Codes wird nicht bewertet + einfach meßbar + relativ gutes Maß für das Ergebnis Wie misst man den Aufwand? Summe aller entstandenen Kosten! Beobachtungen: Personalkosten sind der Hauptanteil dieser Kosten Andere Kosten sind i.w. proportional zu den Personalkosten Deshalb: Der Aufwand wird meist durch die gesamte investierte Arbeitszeit an der resultierenden Software quantifiziert (MM = Mitarbeitermonate, PJ = Personenjahre) V6-13 V6-14 Produktivität (pragmatisch) Beobachtungen: Wert ist kein inhärentes Maß des Produkts, so dass es zweckmäßiger ist nur die Quantität zu messen Personalkosten sind der Hauptanteil der Entwicklungskosten und andere Kosten sind i.w. zu diesen proportional LOC Produktivität MM _ (3) Wie steigert man die Produktivität? Typische Maßnahmen zur Steigerung der Produktivität durch das Softwaremanagement sind: Verbesserte Methoden einsetzen Abläufe (Prozesse) verbessern Wiederverwendung Einsatz von CASE-Tools Wir können dabei unterscheiden zwischen kurzfristigen Maßnahmen, die innerhalb eines Projekts oder einer Phase wirken, und langfristigen Maßnahmen, die über mehrere Projekte hinweg wirken. V6-15 V6-16 Produktivität & Maßnahmen Produktivität Langfristige Maßnahme Beispiele für Maßnahmen: Einsatz von CASE-Tools Neue SE-Methode Wiederverwendung Beobachtung: Kurzfristige Maßnamen führen oft zu langfristigem Produktivitätsverlust Langfristige Maßnahmen führen oft zu kurzfristigem Produktivitätsverlust Zeit Management Aktivitäten III.2 Planung Zeitplanung Personalplanung Kostenplanung III.3 Organisation Aufgaben festlegen organisatorische Strukturen definieren Verantwortlichkeiten festlegen III.4 Personal/Leitung Personalmanagement Mitarbeiter führen und motivieren Kommunikation fördern Konflikte lösen III.5 Kontrolle Versions- und Konfigurationsverwaltung Zeiterfassung / Fehlererfassung / Fortschritte kontrollieren (Metriken) Probleme (frühzeitig) identifizieren Abhilfemaßnahmen einleiten V6-17 V6-18 3
III.2 Planung 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 (frei nach in Anlehnung an /Koontz, O Donnell 72/) Planung ist keine einmalige Angelegenheit, sondern sie muss sich dynamisch und flexibel anpassen, wenn sich die Umgebung oder die Entwicklung ändert Jede erfolgreiche Software-Entwicklung beginnt mit einem guten Plan Zukünftige Unsicherheiten und Änderungen, sowohl innerhalb der Entwicklungsumgebung als auch von externer Quelle, erfordern eine sorgfältige Planung, um die Risiken zu reduzieren. Prozessmodell Prozessmodelle sind die destillieren Projektpläne erfolgreicher Softwareprojekte Sie sind stark idealisiert und abstrahieren von Details Gerade darin liegt die Stärke von Prozessmodellen Ein Projektplan verfeinert, konkretisiert, ergänzt und modifiziert ein gewähltes Prozeßmodell V6-19 V6-20 Machbarkeitsstudie z.b. Wasserfallmodell V-Modell (Vereinfachte Version) Anforderungsdefinition Abnahme Anforderungsdefinition Grobentwurf Systemtest Analyse Entwurf Feinentwurf Integrationstest Das Wasserfallmodell ist ein extrem idealisiertes Modell! Implementierung & Test Wartung Modulimplement. Modultest V6-21 V6-22 Weitere Prozessmodelle Prototypenmodelle Evolutionäre bzw. inkrementelles Modelle Spiralmodell Idee: Schrittweise Entwicklung des Produkts Frühzeitige Prototypen (lauffähige Meilensteine) Softwarepflege ist Teil der Entwicklung Prozessmodell Projektplan eine Phase in weitere Vorgänge aufteilen In einem Projektplan werden die Vorgänge weiter konkretisiert (u. evtl. weiter verfeinert): Beginn / Ende Zuweisung von Personen zu Rollen Aufwand für die beteiligten Personen in ihren Rollen Bearbeitungsdauer V6-23 V6-24 4
Meilensteine Zur Kontrolle des Projektfortschritts werden im Projektplan Meilensteine definiert Ein Meilenstein ist eine Menge von Dokumenten in einem bestimmten Zustand, die zu einem bestimmten Zeitpunkt vorliegen müssen typischerweise sind es die Dokumente, die am Ende einer Phase oder eines Vorgangs vorliegen kennzeichnen den Beginn und das Ende eines Projekts den Abschluss jeder Phase den Abschluss einer Gruppe von Vorgängen innerhalb einer Phase Kriterien für Meilensteine Überprüfbarkeit Es ist überprüfbar, ob der Meilenstein erreicht ist (nicht: Dokument ist zu 75% fertig) Überschaubarkeit Die Dokumente können in überschaubarer Zeit erstellt werden (Wochen oder Monat, nicht Jahr) Regelmäßigkeit Die Meilensteine treten in regelmäßigen Abständen auf V6-25 V6-26 Projektpläne Es gibt verschiedene Notationen: Netzplantechnik (z.b. meta potential method (MPM)) Vorgänge als Knoten Verbindungspfeile symbolisieren Abhängigkeiten Meilensteine als Vorgänge mit der Dauer 0 Gantt-Diagramm Auswertungen von Netzplänen in Form von Balkendiagrammen Vorgangsbezogenes bzw. aufgabenbezogenes Gantt-Diagramm Vorgänge auf der Vertikalen und Personen/Stellen auf dem Balken Personalbezogenes Gantt-Diagramm Mitarbeiter auf der Vertikalen. Eigenschaften von Vorgänge Zeiten für einen Vorgang Vorgangsdauer = Arbeitszeit, die ein Vorgang prinzipiell erfordert Arbeitsdauer = Zeit, die eine Ressource dafür aufwendet Gesamtzeitraum = Kalenderzeit, die für den Vorgang benötigt wird Termintypen für einen Vorgang/Meilenstein Geplante Termine Legen fest, wann ein Vorgang beginnen und enden muss Späteste Termine Spätester Zeitpunkt, an dem ein Vorgang beginnen darf, ohne das Projektende zu verzögern. Tatsächliche Termine Errechneter oder tatsächlicher Start- oder Endtermin V6-27 V6-28 Beziehungen zwischen Vorgängen Vorgangsbeziehungen Legen die Reihenfolge von Vorgängen fest Normalfolge: Ende-Anfang (EA) Z.B. Abhängigkeit bzgl. des Endergebnisses des Vorgangs Anfangsfolge: Anfang-Anfang (AA) gleicher Anfang Endfolge: Ende-Ende (EE) gleiches Ende Zusätzlich kann eine positive/negative Wartezeit angegeben werden Netzplantechnik Review des Lastenheftes 3.10 4.10 1t 1. Version Lastenheftes 1.10 3.10 3t EE+3t Aufwandschätzung 3.10 5.10 Analysemodell 2t 2.10 6.10 4t Meilenstein 2. Version Lastenheftes 4.10 9.10 3t Machbarkeitsstudie 9.10 9.10 0t Legende: Name Frühster Anfang Frühstes Ende Dauer Notizen V6-29 V6-30 5
Gantt-Diagramm Termindurchrechnung Zeitliche Anordnung der Vorgänge unter Berücksichtigung der gegenseitigen Abhängigkeiten Vorwärtsrechnung Bestimmen der frühesten Termine Anfangszeitpunkt + Dauer = frühestes Ende Rückwärtsrechnung Bestimmen der spätesten Termine Endzeitpunkt - Dauer = spätester Anfang Ein Netzplan ist zeitkonsistent, wenn keine negativen Puffer auftreten. V6-31 V6-32 Puffer und Kritischer Pfad Einsatzmittelplanung Einsatzmittel dienen zur Durchführung der Vorgänge Personal, Betriebsmittel (Maschinen, Materialien), Geldmittel Ressourcen = Personal und Betriebsmitteln Einsatzmittelplanung Bedarf an Einsatzmitteln vorhersagen Einsatzoptimierung durch Aufzeigen von Engpässen und Leerläufen. Einsatzplanung (Personal) Personalplanung Termintreue Einsatzplanung: Welche Personalkapazität? Kapazitätstreue Einsatzplanung: Frühester Endtermin? Vorgehen: 1 Ermitteln des Personalvorrats 2 Errechnen des Personalbedarfs 3 Vergleich von Bedarf und Vorrat 4 Optimierung der Auslastung. V6-33 V6-34 Erweiterung um Ressourcen Gantt-Diagramm mit Ressourcen V6-35 V6-36 6
Ressourcentabelle Kostenplanung Kostenplanung stützt sich auf Daten der technischen Planung kaufmännischen Planung Gemeinkosten (indirekte Kosten) Mietkosten Kosten der Verwaltung Ressourcenkosten Hängen mit Ressource zusammen Beispiel: Stundensatz des Mitarbeiters Summieren sich über den Zeitraum, den die Ressource für die Arbeit an einem Vorgang aufbringt. V6-37 V6-38 Zusammenfassung Prozessmodell auswählen und Projektplan ableiten (mit Meilensteine) Aufwandsschätzung durchführen und Bedarfsüberlegungen anstellen Zeit Vorgangsdauer = Aufwand / Bedarf Netzplan durchrechnen Terminbeschleunigung prüfen Risiko minimieren Ressourcen Ressourcen schätzen und zuordnen Ressourcenauslastung überprüfen Bedarfsoptimierung vornehmen Kosten zuordnen Softwaretechnikpraktikum: Aktuelle Aufgaben und Fragerunde V6-39 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? Was ist Reverse Engineering? Mir unklare Fragen: Wie genau sollen die Klassen zb. Actor in ComponentAndBehavior von uns dokumentiert werden? Geht es hier um Das Was oder auch um das Wie? 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. V6-41 V6-42 7
Wiederholung: Reverse-Engineering (2/3) Anmerkungen Es sind keine Fragen aufgekommen, zu mindest nicht zu dem konzeptionellen Rahmen zu diesem Thema, der in den Materialien und der Vorlesung dargelegt wurde. Auf der anderen Seite haben wir bei den Arbeiten für das Analyse- Entwurfs-Dokument versucht Reverse-Engineering an dem Beispiel- Editor zu betreiben, um uns an diesem orientieren zu können. Dabei haben wir gemerkt, das der theoretische Background schön und gut ist, uns aber konkrete praktische Methoden fehlen, die es uns ermöglichen, systematisch eine Dokumentation aus einem gegebenen Quellcode abzuleiten. Wegen mangelnder Zeit und genau wegen diesen fehlenden Methoden gestalteten sich die Arbeiten dann recht chaotisch und dementsprechend ist das Analyse-Entwurfs-Dokument ausgefallen. Naja, meine Frage ist nun, ob wir zu diesem Thema noch praktische Methoden kennen lernen werden? Deswegen machen wir ja das Tutorial, aber Wiederholung: Reverse-Engineering (3/3) 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 fehlt! 2 x Test statt Reverse-Engineering 1x unklar wer der Verantwortliche ist V6-43 V6-44 Aufgabe: Pflichtenheft Hinweis Nur für den Simulationsalgorithmus! Zusammenhängende Darstellung aller fachlichen Anforderungen an das Produkt (Sicht des Benutzers). Es sollte beschrieben, was das Produkt leisten sollte, nicht wie es das leistet Heute 15 Uhr ct Tutorial zum Reverse Engineering (E3.327) Programmierberatung wöchentlich Mittwochs 14-15 Uhr ct in E3.327 Bemerkungen: Umfang: Simulationsalgorithmus: max. 10 Seiten Reuse des Lastenhefts! V6-45 V6-46 Fragen? V6-47 8