Developer Tool – Lou400

Das Tool ist ein Quellen- und Objektmanagementwerkzeug. Es organisiert die Tätigkeiten des Entwicklers, begleitet und unterstützt ihn von der Planung bis zur Installation einer Softwareadaption.

Im Gegensatz zu anderen Source-Management-Werkzeugen die plattformunabhängig arbeiten, ist das Developer Tool auf die Eigenarten des IBM i-Systems bzw. der DB2 eingestellt und darauf abgestimmt. Demnach werden zum Beispiel nicht nur die Quellen unterstützt, sondern auch Objekte.

Die Organisation von Versionen und Installationen über das Developer Tool sind auf die Entwicklung von Individualsoftware ausgelegt und unterstützen eine prompte Reaktion seitens der IT auf Fachabteilungs-, Kunden- bzw. Marktwünsche.

Definition, Protokollierungen und weitere Informationen sorgen für die nötige Nachvollziehbarkeit und Transparenz des gesamten Entwicklungsprozesses.

 

Abgetrennt von anderen Bereichen werden Einstellungen sowie Applikationsparameter festgelegt.

  • Applikationen/Ebenen/Hierarchien
  • Vererbungseinstellungen
  • Container
  • Element-Regeln
  • Standard-Befehle
  • Element bzw. spezifische Arten
  • Systeme, Stages, Partitionen, Umgebungen

       I. Quellen und Objekte

 

a. Der Request

… ist ein abgekapselter Entwicklungsbereich. Sämtliche Eingriffe seitens des Entwicklers erfolgen in diesem Bereich. Abgetrennt von den Umgebungen und den Tätigkeiten anderer aber jedem Entwickler zugänglich.

Der Request ist mit einem „Ticket“ eines Berichtsassistenzsystems vergleichbar. Es konzentriert sich dabei vollständig auf den Entwicklungsprozess um diesen so effizient wie möglich unterstützen zu können. Aus technologischen bzw. organisatorischen Gründen entstehen meist mehr Requets zu einem „Ticket“. Gegebenenfalls können solche Verknüpfung, Verwandtschaften und Verbindungen abgebildet und nachvollzogen werden.

Aktionen innerhalb eines Requests haben den Aufbau einer individuellen Entwicklungsumgebung für diesen Request zur Folge. Sämtliche Versionen die davor oder zum selben Zeitpunkt ausgeliefert werden, werden dafür herangezogen.

 

Detailinformationen:

  • Applikationszuordnung
  • Freitextbeschreibung
  • Versionszugehörigkeit
  • Aktueller Entwickler
  • Referenzen Extern (Verbindung zu Berichtsassistenzsysteme)
  • Referenzen Intern (Verbindung zu anderen Requests)

Weitere Möglichkeiten eines Requests, welche den Unternehmenswünschen anpassbar sind:

  • Klassifizierung (z.B.: Wartung, Änderungsanforderung, Projekt)
  • Verrechnung (z.B.: Aufwand, Pauschal)
  • Aufwandserfassung (z.B.: Stundenangabe, automatische Berechnung, erzwungene Eingabe)
  • Organisationsinformationen (Organisator, Status, Fortschritt)
  • Entwicklungsstatus, verschiedene Prioritäten, Farbeinstellungen, Aktivitäten und mehr

b. Das Element

… ist frei definierbar. Unterstützt werden hierbei Quellen (Teildateien), kompilierte Objekte sowie Objekte welche auf keiner Quelle basieren (ist bis zu Streamfiles oder Datenbankeneinträge erweiterbar).

Für den Entwickler auf einer Ebene dargestellt und bearbeitbar, vereinfachen die Elemente den Überblick und erhöhen die Effektivität was schließlich der Qualität zugutekommt.

  • Typisierung
  • Beschreibung
  • Version
  • Elementartspezifische Informationen

c. Die Markierung

Werden Elemente bearbeitet erfolgt dies über eine Markierung. Jede Markierung kann nur unter gewissen Voraussetzungen gesetzt werde. Diese Voraussetzungen werden, wenn es die Situation erlaubt, aufgrund eines strengen Regelwerks automatisch geschaffen um ein flüssiges Arbeiten zu gewährleisten.

 

  • *NEW
    Neue, dem System noch nicht bekannten, Elemente
  • *CHECKOUT
    stellt das Element für die Entwicklung zur Verfügung
  • *CHANGE
    Änderung der Element-Kopfinformationen (Beschreibung, Art)
  • *DELETE
    markiert ein Element für eine Löschung (wird zum Zeitpunkt des *CHECKINs durchgeführt)
  • *DISPLAY
    zeigt das Element an
  • *EDIT
    editieren des Elements
  • *FREEZE
    friert eine Elementversion ein; eine andere Version wird zuvor installiert
  • *SPRINT
    Elementversion wird von neuerer Version innerhalb derselben Release überschrieben
  • *INFO
    zeigt Markierungsinformationen bzw. Markierungsverlauf an
  • *LINK
    verknüpft Request mit einem Element
  • *MOVE
    verschiebt Element in fremde Request
  • *REMOVE
    entfernt Element aus der Entwicklung
  • *SHORT
    zeigt Kurzinformation der Markierung an
  • *UNDO
    macht Elementmarkierung rückgängig (bei *DELETE anzuwenden)

 

Die *CHECKIN Markierung wird zum Zeitpunkt der Installation gesetzt. Sie kann nicht vom Entwickler auf einzelne Elemente angewendet werden, dient aber der Nachvollziehbarkeit der Elementveränderung im Zuge eines Release.

 

Durch die *SUPPORT Markierung kann dem Werkzeug von außen eine Version zugefügt bzw. überschrieben werden. Dies dient für Schnittstellen zu anderen, ähnlich gelagerten Werkzeugen wie zum Beispiel Generatoren.

 

d. Der Entwicklungsstatus

Der Entwicklungsprozess wird vorrangig durch den Entwicklungsstatus auf Requestebene dargestellt. Der Status wird dem Unternehmensprozess angepasst und wie folgt gesteuert:

 

  1. Eröffnet (*OPEN)
    Ist außerhalb einer Version.
    Arbeiten zeigen nur innerhalb dieses Requests Auswirkung.
    Request wird von keiner anderen Arbeit beeinflusst.
  2. Entwicklung (*DEVELOP)
    Ist außerhalb einer Version.
    Arbeiten zeigen nur innerhalb dieses Requests Auswirkung.
    Request wird von anderen Arbeiten beeinflusst.
  3. Integration (*INTEGRATE)
    Ist innerhalb einer Version.
    Arbeiten zeigen in allen anderen versionsübereinstimmenden Requests Auswirkung.
  4. Sammlung (*RELEASE)
    Request ist für eine Release bereit.
  5. Betrieb (*LIVE)
    Dies ist ein automatischer Status, welcher im Zuge der Installation ausgelöst und gesetzt wird.

     II. Versionen und Releases

Um Planung und Nachvollziehbarkeit zu gewährleisten werden Softwareversionen mit Auslieferungszeitmarken verbunden. Um praxisnahe Reaktionen zu ermöglichen werden Releases, Patches, Fixes unterstützt sowie Sprints der Scrum-Entwicklungsmethode.

   III. Rollouts und Installationen

Versionen können via Rollout-Mechanismus in die Applikation oder zu Testzwecke in davor gelagerte Bereiche installiert werden.

Es werden unterschiedliche Umgebungen unterstützt. Empfohlen werden mindestens zwei bis drei unabhängige Umgebungen für die Entwicklungs- und Testprozesse und eine, von allen anderen unabhängigen, Produktionsumgebung.

Umgebungs- bzw. Systemunabhängige Daten ermöglichen den Überblick auf alle Umgebungen und ihre installierten Versionen.

Die Bereitstellung und Installation erfolgt unter bestimmten Prozess- bzw. Status-Voraussetzungen, immer über denselben Mechanismus und mit denselben Instruktionen. Damit ist ein reibungsloser Ablauf der Installation im Produktionsbetrieb gewährleistet da sämtliche Befehle, Konvertierungen und Installationsprogramme getestet werden.

 

a. Umgebungen

Eine Umgebung ist ein unabhängiger Bereich, in der die Applikation läuft und arbeitet. Je nach Applikationsarchitektur und Unternehmensinfrastruktur, werden mehr Umgebungen auf einem System oder mehr Systeme existieren und unterstützt.

b. Instruktionen

Die Inbetriebnahme erfolgt Großteiles mit automatisierten Mechanismen. Allerdings können technologische Gründe es erforderlich machen bzw. aus Gründen der Kompatibilität notwendig werden spezielle Befehle, SQL-Statments oder Hilfsprogramme als Release-Instruktion ausführen zu lassen.

Release Instruktionen können…

  • für eine Installation im Allgemeinen,
  • für einen einzelnen Request oder
  • für ein einzelnes Element

… definiert werden. Pro Anweisung können eine Vielzahl an Einstellungen erfolgen um die Instruktionen praxisnah und effizient abzulegen (Reduktion von Befehls-Redundanz).

c. Inbetriebnahme

Die Installation, in einer Umgebung vorgelagerten Bibliothek oder direkt in eine Umgebung, wie im Falle einer produktiven Inbetriebnahme, erfolgt über einen batchfähigen Befehl. Dies kann auch zeitgesteuert erfolgen.

Ein Abschluss bzw. ein Abbruch der Installation führt zu einem Installationsprotokoll und gegebenenfalls zu einem Wiederaufsetzpunkt, mit dessen Hilfe es möglich ist, die Installation fortzusetzen.

  IV. Weitere Funktionen

 

a. Notizen

Die Möglichkeit frei erfassbare Notizen wird bereitgestellt. Es werden mehrere Notizen zu unterschiedlichen Themen (z. B.: Analyse und Release) unterstützt und dem Entwickler auf Request- sowie auf Elementebene zur Verfügung gestellt.

 

b. Referenzen

… dient zum Verknüpfen mit anderen Requests oder externen Berichtssystemen.

  • Nummernkreis
  • Referenz
  • Beschreibung
  • Type (*MAIN, *INFO, *RELEASE)

c. Request-Historie

Jede Veränderung auf Requestebene wird protokolliert und in eine Entwicklungs-, Auslieferungs- und Organisationshistorie dargestellt.

d. Entwicklerübersicht

Ein schneller Blick auf den Online/Offline Status der Entwickler und deren Jobs.

 

e. Erinnerungsassistent und Sitzungsprüfung

Weist auf zukünftige Releases oder Dateninkonsistenzen hin und muss vom Entwickler anfänglich bestätigt werden.

 

f. Aktivitätsprotokolle und Aufwandserfassung

Abgesehen von drei Varianten einer Zeitberechnung, welche protokolliert und ausgewertet werden können, kann der Entwickler manuelle Buchungen vornehmen.