Informationswirtschaft 2 Tools im Ablauf von Software-Projekten - Konfigurationsmanagement. Wolfgang H. Janko Stefan Koch

Transkript

1 Informationswirtschaft 2 Tools im Ablauf von Software-Projekten - Konfigurationsmanagement Wolfgang H. Janko Stefan Koch Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft Wirtschaftsuniversität Wien Augasse 2-6, A-1090 Wien, Österreich Telefon: Stefan.Koch@wu-wien.ac.at URL:

2 Inhaltsverzeichnis 1. Abgrenzung/Thema 2. Beispiele für Tools 3. Konfigurationsmanagement 4. Source-Code-Verwaltung 5. Bug-Tracking 1

3 Abgrenzung Thema sind Tools zur Förderung der Produktivität in der Software-Entwicklung insbesondere solche, die für eine verteilte Entwicklung ( multi-site development ) geeignet sind vielleicht sogar für eine dezentralisierte, stark parallelisierte Entwicklung mit schnellen Release-Zyklen und ohne zentrales Management geeignet ( worst case : Open Source Software- Entwicklung) 2

4 Annahme: Tools die dort erfolgreich sind, werden dies auch unter einfacheren Rahmenbedingungen sein Trend geht hin zu verteilter Entwicklung, virtuellen Teams, schnellen Release-Zyklen Software-Entwicklung in Ländern wie Indien objekt-orientierte Entwicklung Extreme Programming,... 3

5 Aufgaben für Tools (für allgemeine Tätigkeiten sowie solche einzelner Entwicklungsphasen) Kommunikation Koordination Management Analyse Design Programmierung Integration/Test Einsatz/Wartung Diskussion: Welche Tools sind für die Software-Entwicklung nötig/von Interesse? 4

6 Beispiele für Tools Kommunikation/Koordination Groupware: Lotus Notes, MS Outlook,... Workflow-Management-Systeme: allgemeine wie Fabasoft Components, auf Software-Entwicklung spezialisierte (Software Process) wie Process Weaver,... 5

7 Abbildung 1: Mailing-Listen des GNOME Projekts (Ausschnitt) 6

8 Video-Conferencing Mailing-Listen: insbesondere in Open Source Software- Entwicklung, kann viele Teilnehmer erreichen, meistens zu verschiedenen Themen, auch als Abstimmungsmechanismus (Apache-Projekt) Management Zeitplanung: Netzpläne, MS Project Projektdatenbank: SPSS, Excel, Datenbank-Produkte 7

9 Aufwandsschätzung: SPSS, ANGEL, Estimacs Berichte/Auswertungen: SPSS, MS Excel, MS Word, MS Powerpoint Analyse Interviews, Fragebogen Kreativitätstechniken 8

10 Zeichentools: Tgif, Corel Draw,... Modellierungstools: Rational Rose, ARIS Toolset,... Design Zeichentools: Tgif, Corel Draw,... Modellierungstools: Rational Rose, ARIS Toolset,... Programmierung 9

11 Compiler Texteditoren Entwicklungsumgebungen Dokumentationstools Source-Code-Verwaltung Integration/Test 10

12 Testbed: dauerndes Compilieren, fehlerhafte Teile/Komponenten werden sofort entdeckt Bug-Tracking Einsatz/Wartung Bug-Tracking über den Produkten dieser einzelnen Teile liegt das sogenannten Konfigurationsmanagement 11

13 Integration verschiedener Teile: CASE (Computer Aided Software Engineering) CASE-Umgebung besteht aus CASE-Plattform (Basisdienstleistungen wie User Interface, Datenverwaltung, Messaging) und CASE-Werkzeugen Architektur laut Referenzmodell Repository Services Data-integration Services (Versions- und Konfigurationsmanagement) 12

14 Werkzeuge Process-management Services Message Services User-interface Services Sicherheit Verwaltung und Konfiguration 13

15 Konfigurationsmanagement Probleme in der Software-Entwicklung häufige Änderungen an Software-Elementen verursachen Chaos Unklarheiten, ob Fehler bereits behoben wurden Notwendigkeit zur Entfernung vorgenommener Verbesserungen 14

16 Unsicherheit, ob alles neu übersetzt wurde, ob der Kunde neueste Freigabe hat,... sollen durch Konfigurationsmanagement behoben werden Konfigurationsmanagement (IEEE):...discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirement. 15

17 Konfigurationsmanagement:...discipline of identifying the configuration of a system at discrete points in time for purposes of systematically controlling changes to this configuration and maintaining the integrity and traceability of this configurationt hroughout the system life cycle. Aufgaben des Software-Konfigurationsmanagements Sicherstellung von Sichtbarkeit, Verfolgbarkeit und Kontrollierbarkeit eines Produkts und seiner Teile im Lebenszyklus 16

18 Überwachung der Konfiguration, sodaß Zusammenhänge und Unterschiede mit früheren Konfigurationen erkennbar sind Sicherstellung, daß auf vorige Versionen zurückgegriffen werden kann daher nicht nur technischer, sondern auch organisatorischer Anteil Endergebnis sollte eine effizientere Software-Entwicklung und - Wartung sein (durch Sicherstellung von Nachvollziehbarkeit,...) 17

19 Software-Produkt besteht aus Elementen (Code, Dokumentation, Testfälle, Pflichtenheft,...) Software-Element ( configuration item ) jeder identifizierbare und maschinen-lesbare Bestandteil des entstehenden Produkts hat eindeutigen Bezeichner jede Änderung erzeugt ein neues Software-Element (mit neuem Bezeichner) 18

20 kann Quellelement (durch manuelle Eingabe erzeugt) oder abgeleitetes Element (vollautomatisch erzeugt, z.b. Objektcode) sein Atom (unteilbare Einheit) oder Konfiguration (aus mehreren Elementen zusammengesetzt) Konfiguration: benannte und formal freigegebene Menge von Software-Elementen, mit den jeweils gültigen Versionsangaben, die zu einem bestimmten Zeitpunkt im Produktlebenszyklus in ihrer Wirkungsweise und ihren Schnittstellen aufeinander abgestimmt sind und gemeinsam eine vorgesehene Aufgabe erfüllen sollen 19

21 in einem Konfigurations-Identifikationsdokument werden alle Elemente aufgelistet, die zu dieser gehören (auch Hilfsmittel und Werkzeuge wie Compiler) Referenzkonfiguration ( baseline ) ist ein zu einem Zeitpunkt ausgewähltes, gesichertes und freigegebenes Zwischenergebnis (kann nur unter bestimmten Bedingungen wie extensiven Reviews verändert werden) mögliche Konfigurationstypen sind beispielsweise Anforderungskonfiguration, Entwurfskonfiguration, Produktkonfiguration oder Pflegekonfiguration 20

22 Version kennzeichnet Ausprägung eines Software-Elements zu einem bestimmten Zeitpunkt normalerweise Nummer besteht in der Regel aus Release-Nummer.Level-Nummer, beginnt mit 1.0 bei kleineren Änderungen wird Level-Nummer um 1 erhöht, bei größeren Release-Nummer (und Level-Nummer auf 0 gesetzt) 21

23 möglich sind auch Varianten (unterschiedliche Äste der Entwicklung), normalerweise mit Release.Level.Branch.Sequence normalerweise Versionsverwaltung im Checkin/Checkout- Modell, Sammlung in Archiven, Speicherung von Deltas (Änderungen) bestes Beispiel: Source-Code-Verwaltung (siehe dort) wenn ein Element in neuer Version vorliegt, muß auch Konfiguration geändert werden 22

24 jede Änderung hat normalerweise einen Grund, Verwaltung/Prüfung/Verfolgung dieser Gründe meist ebenfalls Teil von Konfigurationsmanagement je nach organisatorischer Festlegung können von allen oder bestimmten Personen Änderungswünsche (Change Requests) eingebracht werden (Ergänzungswünsche, Fehler,...), diese können eingeteilt, überprüft, genehmigt, Programmierern zugewiesen werden (ähnlich den Aufgaben eines Bug Tracking Systems - siehe dort) normalerweise basiert Konfigurationsmanagement auf einer Datenbank 23

25 Source-Code-Verwaltung Versionsverwaltung für Software-Elemente vor allem Source-Code, theoretisch aber auch Dokumentation, Web-Seiten,... Konfigurationsmanagement allgemein verläuft analog, nur mit unterschiedlichen Software-Elementen daher gutes Beispiel für dieses Thema 24

26 insbesondere auch zentraler Punkt in der Open Source Software- Entwicklung einziges Software-Element von Interesse ist der Source-Code viele Leute arbeiten daran Mitwirkende sind extrem verteilt (zeitlich und geographisch) Beispiel für ein Source-Code-Verwaltungssystem: CVS (Concurrent Versions System) 25

27 bei den meisten Open Source Projekten im Einsatz selbst ein Open Source Projekt grundlegende Idee stimmt mit Open Source Entwicklung überein (siehe unten) unterstützt dezentralisierte/verteilte Entwicklung (keine dauernde Verbindung nötig, unterschiedlichste Clients vorhanden, Internet-fähig) Grundidee von CVS (Vorgehen) 26

28 ein zentrales Repository Entwickler laden eine Kopie herunter ( checking out, working copy ) führen Änderungen an dieser Kopie durch laden neue Version in Repository ( commit, check in ), schreiben dazu eine log message (Kommentar), dies führt zu einer neuen Revision (Version) im Repository andere Entwickler können ihre Kopien durch Download neuester Version aktualisieren ( update ) 27

29 wenn jemand ein commit durchführen will, kann ein Konflikt auftreten, weil er an alter Kopie gearbeitet hat (ein anderes commit ist passiert, während er gearbeitet hat) kein Konflikt, wenn er an anderen Files, oder an anderen Teilen gearbeitet hat (System führt merge durch) sonst tritt Konflikt auf, automatisches Update wird durchgeführt, und der Programmier bekommt Konflikte angezeigt und muss sie bereinigen Ansatz daher: copy-modify-merge 28

30 statt: lock-modify-unlock (Entwickler braucht zuerst exklusiven Schreibzugriff lock für eine Datei, wird bei immer mehr Personen, die nicht leicht miteinander kommunizieren können, problematisch) intern es werden nur Deltas ( diffs ), also für jeden Commit die Änderungen gespeichert daher können von jeder Änderung zu jeder anderen die Unterschiede nachvollzogen werden 29

31 When comparing two files, diff finds sequences of lines common to both files, interspersed with groups of differing lines called hunks. Comparing two identical files yields one sequence of common lines and no hunks, because no lines differ. Comparing two entirely different files yields no common lines and one large hunk that contains all lines of both files. In general, there are many ways to match up lines between two given files. diff tries to minimize the total hunk size by finding large sequences of common lines interspersed with small hunks of differing lines. Interface im einfachsten Fall über Command-line 30

32 Befehle: checkout, update, diff, commit, status, log, add, remove Beispiel: Befehle checkout und log (Sourceforge) cvs /cvsroot/enlightenment co e16 cvs /cvsroot/enlightenment log e16 31

33 Output des log-befehles RCS file: /cvsroot/phormation/docs/.cvsignore,v Working file: docs/.cvsignore head: 1.1 branch: locks: strict access list: symbolic names: pre_peaceworks_mods: start: PeaceWorks: keyword substitution: kv 32

34 total revisions: 2; selected revisions: 2 description: revision 1.1 date: 2001/05/29 20:18:27; author: jdhildeb; state: Exp; branches: 1.1.1; Initial revision revision date: 2001/05/29 20:18:27; author: jdhildeb; state: Exp; lines: +0-0 Imported docs. 33

35 ============================================= grafische Benutzerschnittstellen existieren ebenfalls, zum Beispiel Bonsai (Query-Tool von mozilla.org, unter anderem bei GNOME im Einsatz) 34

36 Abbildung 2: Bonsai Verzeichnisansicht 35

37 Abbildung 3: Bonsai Blame-annotated Source 36

38 Abbildung 4: Bonsai Diff Query Form 37

39 Abbildung 5: Bonsai Diff 38

40 Entwicklungsstrategie und Branching gewisse Aspekte der Source-Code-Verwaltung sind organisatorisch zu regeln (z.b. wann gibt es eine neue Version, wer darf wann checkin durchführen,...) Beispiel FreeBSD Branches: Development, Stable/Production (möglicherweise mehrere) Vorgehen bei der Entwicklung 39

41 Abbildung 6: FreeBSD Entwicklungsmodell 40

42 Entwickler schreibt Code Code wird reviewed (z.b. über Mailing-Liste) Entwickler soll Code vor dem Commit testen Code kommt in Development Release Parallel Debugging bei vielen/grösseren Änderungen könnte Development auch destabilisiert werden nach einiger Zeit wird er in die Production Branch gemerged wenn sich genug Änderungen angesammelt haben, setzt code freeze ein (nur Top-Leute dürfen noch ändern), danach wird neue Release herausgebracht 41

43 Abbildung 7: FreeBSD Entwicklungsmodell 42

44 Abbildung 8: FreeBSD Entwicklungsmodell 43

45 Bug-Tracking Begriffsdefinitionen Trouble Ticketing (incident-reporting, issue-tracking systems): verfolgen einfache, unabhängige Aufgaben, möglicherweise Zuordnung zu Personen, Status z.b. open, in-progress, oder closed, oder Web/Java-basiert, zum Teil mit Management-Reports Help-Desk Management/Call Tracking: ähnlich, ein paar weitere Bestandteile wie Anrufverfolgung, Stundenaufzeichnung, CRM-Informationen,... 44

46 CRM-Systeme: um Kunden zu kennen, entsprechend anzusprechen (z.b. Interessen für Marketing-Kampagnen) Bug Tracking: ähnlich Trouble Ticketing, verfolgen aber insbesondere Bugs, erlauben meist unterschiedliche Rollen, idealerweise mit Source-Code-Verwaltung integriert Workflow Management: steuert Abläufe, ebenfalls verschiedene Rollen, oftmals mit Dokumentenmanagement integriert Bug 45

47 Fehler in einem Computer-Programm (historisch wegen Insekten in frühen Computern) besitzt in seinem Verlauf normalerweise mehrere Kennzeichen Status/Lebenszyklus (nach GNATS) open: Anfangszustand, wurde aufgenommen, einer Person zugewiesen analyzed: Person hat analysiert, vielleicht erste Aufwandsschätzung, eventuell Workarounds 46

48 feedback: Problem gelöst, Quelle hat Patch oder Fix erhalten, bleibt in diesem Zustand bis zum Feedback der Quelle closed: nach positivem Feedback suspended Status/Lebenszyklus (nach Bugzilla) unconfirmed: muß überprüft werden new: ist überprüft, zugeordnet zu Entwickler 47

49 fixed: eingechecked und getestet invalid: ist kein Bug wontfix: wird nicht bereinigt, oder ist eigentlich ein feature duplicate: Duplikat eines anderen (Verweis) worksforme: kann nicht reproduziert werden Schwere (severity) 48

50 critical: Produkt funktioniert nicht, oder essentielle Funktionalität fehlt, kein Workaround serious: funktioniert nicht richtig, wichtige Funktionalität fehlt, oder critical mit Workaround non-critical: kein wesentlicher Teil betroffen Priorität (für Behandlung) Klasse (documentation-bug, change-request, enhancementrequest,...) 49

51 Bug-Tracking Systeme unterstützen zugehörige Aufgaben wie Anlegen, Abfragen,... beruhen zumeist auf Datenbanken Integration mit Source-Code-Verwaltung würde Zuordnung von Bug zu Code-Teil (File/Funktion/Klasse) erlauben, damit eventuell auch zu Entwickler, sowie auch im anderen Weg die Zuordnung einer bestimmten Version zu einem Bug bzw. dessen Behebung Beispiele für freie Bug-Tracking Systeme: Bugzilla (mozilla.org), GNATS (GNU Bug Tracking System), Jitterbug (entwickelt mit Samba) 50

52 Abbildung 9: Bugzilla Query Form 51

53 Abbildung 10: Bugzilla Query Result 52