Smalltalk    Besonderheiten

Smalltalk Tipp


Prozessbeschreibung der Softwareentwicklung mit VisualWorks

  1. Das Ticketsystem

    1. Jegliche Entwicklung findet aufgrund von Aufgabenstellungen statt. Aufgaben können z.B. Weiterentwicklungen, Fehlerbehebungen, Untersuchungen, Ausbildungsschritte sein.
    2. Jede Aufgabe bekommt eine Nummer und eine Überschrift. Weitere Parameter sind Zugehörigkeit zu einem Produkt, einem Kunden und einem Auftrag, Dringlichkeit der Aufgabe, und jeweilig zuständige Person, zu informierende Teammitglieder, Verknüpfung zu anderen Aufgaben, Gelöst in, durchgeführter Test. Weiterhin können Dateien einer Aufgabe angehängt werden.
    3. Jede Aufgabe durchläuft mehrere Zustände. In unserem System gibt es die Zustände
      1. Open: Aufgabe ist unfertig
      2. inReview: Aufgabe ist aus Sicht des Entwicklers fertig und bedarf der Begutachtung
      3. integrate: Wird von uns nicht verwendet, da bei uns Begutachtung und Integration ein Schritt ist
      4. onDeck: Auch diesen Zustand verwenden wir nicht.
      5. Waitcust: Wir warten auf die Rückmeldung eines Kunden entweder auf weitere Informationen oder auf Abnahme
      6. Deferred: Verschoben, derzeit nicht aktuell
      7. Obsolete: Veraltet, Aufgabe wird nicht mehr benötigt, es gibt aber auch kein Ergebnis
      8. Rejected: Abgelehnt, z.B. ist dies eine doppelt erteilte Aufgabe
      9. Closed: Erledigt, es gibt ein Ergebnis
    4. Jede Aufgabe beginnt im Zustand Open und endet in einem der Zustände Obsolete, Rejected oder Closed.
    5. Bei uns findet die Zeiterfassung im Aufgabenbeschreibungssystem statt. Auch Zwischenschritte, wozu auch Fehlschläge gehören, sollen beschrieben werden.

  2. Die Begutachtung

    1. Vor dem Zustand Closed liegt der Zustand InReview. Es muss eine positive Begutachtung vorliegen, um einen Fall mit Closed zu schließen.
    2. Wir arbeiten in der Regel mit Bündeln (Bundles), die wir als Ganzes publizieren. Beim Versionsschema haben wir die Ideen von Cincom aufgegriffen[1]
    3. Am Ende der Entwicklung steht die Übergabe an den Gutachter mit den notwendigen Angaben, was geändert wurde und welche Tests zu der Änderung gehören.
    4. Wir setzten in all unseren Images in den Einstellungen die Option „Always open Merge Tool before performing Merge“ (siehe auch unten)
    5. Zum Begutachtungsprozess gehören in der Regel folgende Aufgaben
      1. Lesen allen geänderten Codes (mithilfe des Merge-Tools)
      2. Überprüfen der Kommentare
      3. Ausführen der Testsuite (SUnit)
      4. Durchführung der Code-Kritik, wobei wir inzwischen eine erweiterte Version einsetzen, die auch Kommentare prüft
      5. Ausprobieren der Anwendung
      6. Zurückweisen an den Entwickler bei Problemen mit klarer Beschreibung der gefundenen Probleme
      7. Integration der Änderungen in den Strang (auch zulässig, wenn die Probleme ausschließlich in Kommentaren liegen)
      8. Codeänderungen außer Formatierungen führen dazu, dass der Schritt zu einem Entwicklungsschritt wird und die Aufgabe der Begutachtung an ein anderes Teammitglied fällt. In diesem Fall findet auch keine Integration in den Stamm statt.
    6. Diese Vorgehensweise haben auch schon Industriekunden von uns übernommen und setzen sie erfolgreich ein.

  3. Technische Angaben

    1. Wir haben das Aufgabensystem Mars (Minimal Action Request System) von Cincom
    2. übernommen und nennen unsere Aufgaben ebenso ARs.
    3. Ebenfalls setzen wir ein Store-Unterstützungspaket für diesen Prozess ein, das wir auch schon Kunden in angepasster Fassung geliefert haben. Diese Kunden setzten unterschiedliche Ticketsysteme ein.
    4. Wir setzen derzeit standardmäßig in VisualWorks 8.2 folgende Resolutions ein:
      1. Res104181
      2. Res106266
      3. Res106722
      4. Res107008
      5. Res107022
      6. Res107179
      7. Res107211
      8. Res107278
      9. Res107284
      10. Res107302
      11. Res107311
      12. Res107345
      13. Res107477
      14. Res107522
      15. Res107547
      16. Res107701
      17. Res106667

    5. Darunter sind einige, die das Arbeiten mit dem Merge-Tool deutlich vereinfachen (Res107008, Res107022, Res107179)

  4. Beispiele und Bildschirmfotos

    1. Wir verwenden eine Einstellung, dass sich das Merge-Tool bei jedem Einmischen von Änderungen öffnet:


    2. Im Published-Item-Dialog von Store kann man erkennen, an welchen Aufgaben gearbeitet wurde. Als weitere Hinweise auf den Reifegrad der Version gibt auch das Blessing Level an:


    3. Es kann auch vorkommen, das ein Entwickler an mehreren Aufgaben arbeitet, bevor er sie gemeinsam zur Begutachtung gibt, sichtbar ist dies an den doppelten Aufgabennummern. So kann die Versionsnummer 8.2 - 30 + AR 8887 1 + AR 8897 1 folgendermaßen verstanden werden:
      1. Der Entwickler ist ausgegangen von der Version 8.2 - 30, das ist die 30. Stammversion der eigentlichen Versionsnummer 8.2

      2. Zunächst hat er an der Aufgaben 8887 gearbeitet und bei dieser Arbeit einmal publiziert.

      3. Anschließend hat er an Aufgabe 8897 gearbeitet aufbauend auf seiner Arbeit an Aufgabe 8887.

      4. Am Reifegrad Integrated kann man erkennen, dass diese beiden Aufgaben gemeinsam begutachtet wurden und in den Stamm integriert wurden.

    4. Etwas mehr Versionen kann man an einem anderen Paket erkennen:



      Hier ist durch das Anklicken zusätzlich sichtbar, dass die Version MARS Client Report
      (8.1.1 - 6 + AR 8887 3 + AR 8897 1,georg) von Daniel integriert in die Version 8.1.1 - 7 wurde.

    5. Das Merge-Tool zeigt die Änderungen dem Gutachter an:



      In diesem Fall hat offensichtlich eine Refaktorierung stattgefunden. So erscheint die nun verwendete Methode reportApplication als neue Methode in der Liste.

  5. Eine Besonderheit gibt es bei uns beim Paar-Programmieren

    1. Beim Paar-Programmieren darf Programmierung und Begutachtung gleichzeitig stattfinden.
    2. Es hat sich als sinnvoll herausgestellt, trotzdem zuerst eine sog. AR-Version zu publizieren und danach dem Integrationsschritt mithilfe des Merge-Tools durchzuführen.
      1. So wird sichergestellt, dass später die Aufgabennummer in der Versionskette sichtbar ist und
      2. keine ungewollten Änderungen in eine Stammversion übernommen werden.
Georg Heeg
21. Februar 2017


[1] Versioning
  • "Trunk" package versions are of the form <versionprefix><space><dash><space><non-negative-integer>. For example: 7.7 - 1.
  • Upon starting work on a new release, bundles and packages must be republished whole with version zero.
  • All changes must be backed up by an AR, and all ARs must be merged back into the trunk from their specific, AR versioned packages.