Georg Heeg eK

Smalltalk-Tipp

Package NameSmalltalk-Tipp
Package text (de)

Prozessbeschreibung der Softwareentwicklung mit VisualWorks

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

  2. Die Begutachtung
    • Vor dem Zustand Closed liegt der Zustand inReview. Es muss eine positive Begutachtung vorliegen, um einen Fall mit Closed zu schließen.
    • Wir arbeiten in der Regel mit Bündeln (Bundles), die wir als Ganzes publizieren. Beim Versionsschema haben wir die Ideen von Cincom aufgegriffen. [1]
    • Am Ende der Entwicklung steht die Übergabe an den Gutachter mit den notwendigen Angaben, was geändert wurde und welche Tests zu den Änderungen gehören.
    • Wir setzten in all unseren Images in den Einstellungen die Option „Always open Merge Tool before performing Merge“ (siehe auch unten).
    • 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 Hauptstrang (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 im Hauptstrang statt.
    • Diese Vorgehensweise haben auch schon Industriekunden von uns übernommen und setzen sie erfolgreich ein.

  3. Technische Angaben
    • Wir haben das Aufgabensystem Mars (Minimal Action Request System) von Cincom übernommen und nennen unsere Aufgaben ebenso ARs.
    • 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.
    • Wir setzen derzeit standardmäßig in VisualWorks 8.2 folgende Resolutions ein:
      • Res104181
      • Res106266
      • Res106722
      • Res107008
      • Res107022
      • Res107179
      • Res107211
      • Res107278
      • Res107284
      • Res107302
      • Res107311
      • Res107345
      • Res107477
      • Res107522
      • Res107547
      • Res107701
      • Res106667
    • Darunter sind einige, die das Arbeiten mit dem Merge-Tool deutlich vereinfachen (Res107008, Res107022, Res107179).

  4. Beispiele und Bildschirmfotos
    • Wir verwenden eine Einstellung, durch welche sich das Merge-Tool bei jedem Mergen von Änderungen öffnet:

      System/Pictures/SmalltalkTipp-zeiss-image01.png

    • Im Published-Item-Dialog von Store kann man erkennen, an welchen Aufgaben gearbeitet wurde. Als weitere Hinweise auf den Reifegrad der Version gibt man auch das Blessing-Level an:
      System/Pictures/SmalltalkTipp-zeiss-image03.png

    • Es kann auch vorkommen, dass ein Entwickler an mehreren Aufgaben arbeitet, bevor er sie gemeinsam zur Begutachtung abgibt, 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 Aufgabe 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 und in den Stamm integriert wurden.
    • Etwas mehr Versionen kann man an einem anderen Paket erkennen:
      System/Pictures/SmalltalkTipp-zeiss-image05.png

      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.
    • Das Merge-Tool zeigt die Änderungen dem Gutachter an:
      System/Pictures/SmalltalkTipp-zeiss-image07.png

      In diesem Fall hat offensichtlich eine Refaktorisierung 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 dürfen Programmierung und Begutachtung gleichzeitig stattfinden.
    2. Es hat sich als sinnvoll herausgestellt, trotzdem zuerst eine sog. AR-Version zu publizieren und danach den Integrationsschritt mithilfe des Merge-Tools durchzuführen.
      1. So wird sichergestellt, dass später die Aufgabennummer in der Versionskette sichtbar ist und...
      2. ...dass keine ungewollten Änderungen in eine Stammversion übernommen werden.

    [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.
Package text (en)

Process Description of Software Development with VisualWorks

  1. The Ticket System
    • Every development happens because there are tasks. These tasks may include: further development, troubleshooting, analysis, or instructions.
    • Each task is given a number and a title. Further parameters are: a product's belonging, a customer order, the urgency of the task, each responsible person, team members to-be-informed, shortcuts to other tasks, resolved in, and conducted tests. Furthermore, task files can be attached to a task.
    • Every task runs through several situations. In our system, there are the following situation:
      • Open: Task is unfinished
      • inReview: Task is completed according to the developer and needs evaluation
      • integrate: We do not use this because the evaluation and integration are one single step
      • onDeck: We do not use this situation either
      • Waitcust: We are waiting for the customer feedback which could be either further information or approval
      • Deferred: Shifted, not updated at the moment
      • Obsolete: Outdated, task is no longer required and there is no result either
      • Rejected: Rejected e.g. this task has been issued twice
      • Closed: Completed, there is a result
    • Every task begins in an Open situation and ends in either Obselete, Rejected or closed situations.
    • We have time recording in the task breakdown system. Even interim stages, including failures, have to be described.
  2. The Evaluation
    • Before the Closed situation, there is the inReview situation. There has to be a positive evaluation in order to finish a situation with Closed.
    • We usually work with bundles that we publish as a whole. We picked up the ideas for the version scheme from Cincom. [1]
    • At the end of development, the product and necessary statements are given to the evaluator, e.g. what was changed and which tests belong to the changes.
    • In all of our images, we used the "Always open merge tool before performing merge" (see below) option in Settings.
    • The following tasks usually belong to the evaluation process:
      1. Reading all of the altered code (with the help of the merge tool)
      2. Reviewing the comments
      3. Running the test suite (SUnit)
      4. Implementation of the code critique whereby we utilize an extended version that also reviews comments.
      5. Testing the application
      6. Feedback to the developers if there are problems, with clear desciptions of the problems found
      7. Integrating the changes into the string (also valid if the problems only exist in the comments)
      8. Code changes other than formatting can turn the step into a development step and the task of evaluation will be burdened to another team member. In this case, there will be no integration in the string.
    • Our industry clients have also adopted this procedure and they apply it successfully.

  3. Technical Information
    • We have adopted the task system Mars (Minimal Action Request System) from Cincom and we call our tasks ARs as well.
    • Furthermore, we implemented a store support package for this process that we have delivered to the customers as the adapted version. These customers implemented different ticket systems.
    • At the moment, we implement the following standard resolutions in Visualworks 8.2:
      • Res104181
      • Res106266
      • Res106722
      • Res107008
      • Res107022
      • Res107179
      • Res107211
      • Res107278
      • Res107284
      • Res107302
      • Res107311
      • Res107345
      • Res107477
      • Res107522
      • Res107547
      • Res107701
      • Res106667
    • Among them are some that make working with the merge tool a lot simpler (Res107008, Res107022, Res107179).

  4. Examples and Screenshots
    • We use a setting that opens the merge tool whenever changes are merged:System/Pictures/SmalltalkTipp-zeiss-image01.png

    • In the published item dialog from Store, the task that is being worked on can be seen. The Blessing level is also present as further reference of the maturity level of the version:
      System/Pictures/SmalltalkTipp-zeiss-image03.png
    • It is also possible that a developer is working on multiple tasks before they submit all of them for evaluation, which is indicated by the double task numbers. The version number 8.2 - 30 + AR 8887 1 + AR 8897 1 can be interpreted by these following steps:
      1. The developer is assigned to the 8.2 - 30 version, which is the 30th root version of the current version number 8.2
      2. Firstly, he had worked on task 8887 and has already published this work once.
      3. Afterwards, he worked on task 8897 based on his work in task 8887.
      4. On the maturity level 'Integrated', it can be seen that both of these tasks were evaluated together and were integrated into the root.
    • More versions can be seen in another package:
      System/Pictures/SmalltalkTipp-zeiss-image05.png

      It can be seen here by clicking that the MARS Client Report version
      (8.1.1 - 6 + AR 8887 3 + AR 8897 1,georg) by Daniel has been integrated into the 8.1.1 - 7 version.
    • The merge tool displays the changes for the evaluator:
      System/Pictures/SmalltalkTipp-zeiss-image07.png

      In this case, there was a refactoring. The now used reportApplication method appears as a new method on the list.

         5. Our Specialty in Pair-Programming

  1. In pair-programming, the programming and evaluation processes can happen at the same time.
  2. It has proved useful to publish a so-called AR version and to then perform the integration procedure with the help of the merge tool.
    1. This way, it is guaranteed that the task number appears in the version number later, and...
    2. ...that no unwanted changes are carried over into a basic version.
   

[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.
Package image
Package tag
Package prerequisiteVisualWorks 9.0
Package video
Package PDF
Package responsible
Contact
Imprint
Press