<img src="//salesviewer.org/LE-002231-005.gif" style="visibility:hidden;">

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

Jetzt abonnieren!

Aktuell beliebt:

image 38

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)

image 39

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

image 23

image 24

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

image 25

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

image 26

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.

image 27
image 28

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.

image 29

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).

image 30

 

Jetzt abonnieren!

Aktuell beliebt: