Process Description of Software Development with VisualWorks

  1. The Ticket System
    • Every development happens because there are tasks. These tasks include: further development, troubleshooting, analysis, or instructions.
    • A number and a title are given to each task. Further parameters are: a product's belongings, a customer order, the urgency of task, every responsible person, team members to-be-informed, shortcut to other tasks, resolved in, and conducted tests. Furthermore, task datas could be suspended
    • Every task runs through several situations. In our system, there are the following situations:
      • 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 the time tracking in the task breakdown system. Even interim stages, where there are 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 complete 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 the development, necessary statements, such as: what was changed and which tests belong to the changes, are given to the evaluator.
    • 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 the altered codes (with the help of the merge tool)
      2. Review the comments
      3. Running the test suites (SUnit)
      4. Implementation of the code critic whereby we utilize an extended version that also reviews comments.
      5. Testing the application
      6. Feedback to the developers when there are problems with clear desciptions of the existing problems.
      7. Integrating the changes into the string (also valid when 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 stem.
    • Our industry clients have also adopted this procedure and they can apply it successfully.

  3. Technical Information
    • We have adopted the task system MARS (Minimal Action Request System) from Cincom and we call our task 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 the ones that make working with the merge tool to be simpler  (Res107008, Res107022, Res107179)

  4. Examples and Screenshots
    • We use a setting that opens the merge tool whenever changes are made: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 stem 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 could be seen that both of these tasks were evaluated together and were integrated into the stem.
    • More versions can be seen on 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 done by 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 proves itself sensible, even though it was an undertow at first. Publishing the AR version and then performing the integration procedure with the help of the merge tool.
    1. It is guaranteed that the task number appears in the version number later, and;
    2. No unwanted changes in a basic version is carried over.
   

  1. [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.
 
Smalltalk-Tip