12
Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 06/26/22

Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Embed Size (px)

Citation preview

Page 1: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA IT AG

Vortrag auf der 27. DENK in Bamberg

04/11/23

Page 2: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 2

Allgemein

Rahmenbedingungen

Konzeptionelle Vorstellungen bei CA zwar vorhanden, aber Termin ungewiss

Auf Grund eines neuen Organisationsmodells brauchte die FIDUCIA eine sofortige Lösung (Trennung in Application Management und Projekte)

„Verlustfreies“ Einbinden in bestehendes Prozeßmodell

Page 3: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 3

Vorstellung von CA

Page 4: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 4

Technische Umsetzung

Erweiterungen

Rollenbasierende Entwicklung

Neues Environment CONCTEST

Elementregistrierung

Integration „Parallel Development Option“ in das Prozeßmodell

Notification

Page 5: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 5

Rollen (1)

Rollen bestimmen die Verantwortung und sind die Basis für die Notification:

KMVAM - Konfigurationsmanagement-Verantwortlicher in AM Ein KMVAM ist immer für einen gesamten Leistungsbereich zuständig. Erhält alle Mails bezüglich Elementveränderungen (z.B. Kontrolldateiänderungen, Ausleihvorgänge durch Projekte, Freigaben von Projekten etc.) Ist für einen Leistungsbereich kein KMVAM vorgesehen, geht die gesamte Notification an den Abteilungsleiter.

KMVPRJ - Konfigurationsmanagement-Verantwortlicher in AM Ein KMVPRJ ist immer für eine Projekt zuständig. Erhält alle Mails bezüglich Elementveränderungen (z.B. Kontrolldateiänderungen, Ausleihvorgänge durch AM oder andere Projekte, Freigaben von anderen Projekten oder AM etc.)

PRJLTR - Projektleiter An die Projektleitung werden lediglich Ausnahmesituationen gemeldet (z.B. Freigabe eines parallelen Elements ohne Merge, obwohl dieser notwendig ist.

Page 6: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 6

Rollen (2)

UIDOWN - Element-Eigner Darunter wird die Person verstanden, welche in der Registrierungstabelle für ein Element registriert ist. Meldungen erfolgen nur, wenn eine parallele Bearbeitung erfolgt.

UIDINT - Interessent Mit dieser Rolle kann das Konzept des KMVAM etwas filigraner gestaltet werden. Jeder Interessen kann sich zu einem Programm mit dieser Rolle registrieren. Vorgänge mit diesem Element werden dann auch an diesen Interessenten gesandt.

DSNOWN - Datei-Eigner Ist Besitzer(in) einer Datei (i.d.R. die Programmbibliothek eines Projektes). Compilieren andere Projekte per Testcompile auf diese Bibliothek, wird eine entsprechende Notification geschickt.

Page 7: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 7

Neues Environment CONCTEST

ENTW QS FEHLER VERSAND

CONC TEST

Retrieve Add Transfer

Retrieve Add

Move

1. Jedes Projekt ist als eigenes System definiert

2. Jedes Projekt hat seine eigene „Dateilandschaft“

In CONCTEST gilt:

3. Jedes Projekt muss einer definierten Test-umgebung zu-geordnet werden

4. Keine „Sicht“ auf AM und andere Projekte per Mapping

Page 8: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 8

Elementregistrierung

Die Elementregistrierung findet in einer DB2-Tabelle statt

Jeder Ausleihvorgang für zu einem Registrierungseintrag, wobei pro System nur ein Ausleihvorgang gestattet ist

Jeder Registrierungseintrag weist einen sog. „Basislevel“ auf. Dies ist VV.LL in VERSAND zum Zeitpunkt des Ausleihvorgangs und wird bei MOVE/TRANSFER wieder mit VERSAND abgeglichen.

Jeder Registrierungseintrag ist mit einem Status versehen (INIT, WORK, LOCK, INV, SYNC)

Application Management wird wie ein Projekt behandelt und unterliegt ebenfalls der Registrierung

Page 9: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 9

Integration „Parallel Development Option“ in das Prozeßmodell

Page 10: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 10

Notification

Aktive Statusmeldungen sind das A & O des Parallel Development

Funktioniert nur dann, wenn das Rollenmodell gelebt und die Elementzuordnungen richtig sind

Verbindet das Rollenmodell mit Ereignissen, d.h. nur die Rollen werden informiert, für welche das Ereignis von Bedeutung ist.

Page 11: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Parallel Development in der FIDUCIA | Wilhelm Alexy | Seite 11

Und was da sonst noch zu bedenken wäre

Merge ist teuer

Test ist schwierig

Page 12: Parallel Development in der FIDUCIA IT AG Vortrag auf der 27. DENK in Bamberg 04.02.2014

Ihr IT-Partner

Vielen Dank