01d_Anhang D_Standards-zur-Softwareentwicklung_im_BVL.pdf

[Seite 1]

Anhang D

Standards zur Softwareentwicklung

Stand: 01.10.2020

Seite 1/35

[Seite 2]

Anhang D

Inhaltsverzeichnis

1 Ziel ................................................................................................................................ 3 2 Geltungsbereich ............................................................................................................ 4 3 Begriffe .......................................................................................................................... 5 4 Projektorganisation...................................................................................................... 11 5 Systemlandschaft ........................................................................................................ 12

5.1 Kodierung und Zeichensätze ..............................................................................12 5.2 Clients und Barrierefreiheit .................................................................................12 5.3 Applikationsserver & Frameworks ......................................................................13 5.4 Relationale Datenbanken ...................................................................................14 5.5 Identitätsmanagement und Zugriffsrechte ..........................................................17

5.5.1 Authentifizierung ................................................................................... 17 5.5.2 Autorisierung ........................................................................................ 17

5.6 Schnittstellen und Datenaustausch ....................................................................17 5.7 Netztrennung und Verwaltungsnetz ....................................................................18

6 Entwicklung ................................................................................................................. 19

6.1 Entwicklungsumgebung .....................................................................................19 6.2 Quellcode-Organisation ......................................................................................19 6.3 Dokumentation der Softwareprojekte .................................................................19 6.4 Namensgebung ..................................................................................................21 6.5 Internationalisierung ...........................................................................................21 6.6 Strukturierte Ablage von Primärdaten .................................................................22 6.7 BVL-interne Server- und Entwicklungsorganisation ............................................22 6.8 Extern entwickelte Software ...............................................................................23

7 Tests und Abnahme der Software ............................................................................... 24 8 Freigabe von Anwendungen für den Produktivbetrieb ................................................. 25 9 Nachweisdokumente ................................................................................................... 26 10 Mitgeltende Unterlagen ............................................................................................... 27 11 Änderungen an diesem Dokument .............................................................................. 28 Anhang: Quellcode-Organisation .......................................................................................... 30 Anhang: Architekturkonzept ................................................................................................. 34

Seite 2/35

[Seite 3]

Anhang D

1 Ziel

Für die Entwicklung und den Betrieb von Software im BVL und für das BVL werden Standards

definiert.

Ziel dieser Standards ist ein vereinfachter Entwicklungsprozess, bei dem der Einarbeitungs-

aufwand der Entwickler in neue Projekte möglichst geringgehalten wird und Vor- bzw. Nach-

teile einzelner Aspekte der Softwareentwicklung nicht jedes Mal neu gegeneinander abgewo-

gen werden müssen. Außerdem soll die Zusammenarbeit im Team dadurch erleichtert werden,

da die Kommunikation der Entwicklerinnen und Entwickler auf den gleichen Technologien ba-

siert. Durch den Wegfall eines großen Teils der Einarbeitung soll eine bessere Vertreterrege-

lung und eine bessere Übergabe der Produkte von Entwicklungs-projekten an den Betrieb

erreicht werden.

Die in diesem Dokument getroffenen Entscheidungen zur (möglichst einheitlichen) Infrastruk-

tur und zu den verwendeten Technologien dienen dazu, verbindliche Vorgaben zu treffen, so

dass im Vorfeld der Betrieb und die spätere Wartung der Software in Z32 geplant werden kann.

Die Standards sind sowohl für interne Projekte als auch Projekte mit externen Partnern ver-

bindlich - Projekttypen nach V-Modell XT Bund: 3.1 Systementwicklungsprojekt (AN). 3.2 Sys-

tementwicklungsprojekt (AN/AG). Es werden keine Alternativen zu den aufgeführten Produk-

ten und Technologien verwendet. Sollten sich bestimmte Anforderungen technisch nicht um-

setzen lassen, so wird eine alternative Technologie in der AG Programmierung besprochen

und gemeinsam beschlossen. Gleiches gilt für neue Technologien und neue Versionen der

verwendeten Werkzeuge/Software. Die Abstimmung kann im Bedarfsfall auch kurzfristig per

E-Mail oder per Telefon mit Protokoll erfolgen.

Die hier getroffenen Festlegungen beziehen sich folgend meist auf Individualsoftware – sie

gelten aber auch (wenn anwendbar) für Standardsoftware. Abweichungen von hier definierten

Standards für die Einführung einer Standardsoftware sind nur per Einzelfallentscheidungen

unter Einbindung von RefL Z32 möglich.

Seite 3/35

[Seite 4]

Anhang D

2 Geltungsbereich

Die einheitlichen Vorgaben dieses Dokumentes gelten für die hausinterne Entwicklung, und

sollen auch bei einer externen Auftragsvergabe verwendet werden.

Seite 4/35

[Seite 5]

Anhang D

3 Begriffe

Allgemeine Begriffe

Spezifische Begriffe

Seite 5/35

[Seite 6]

Anhang D

Seite 6/35

[Seite 7]

Anhang D

1 Siehe hierzu https://tools.ietf.org/html/rfc4120

Seite 7/35

[Seite 8]

Anhang D

Seite 8/35

[Seite 9]

Anhang D

Seite 9/35

[Seite 10]

Anhang D

Seite 10/35

[Seite 11]

Anhang D

4 Projektorganisation

Die Projektorganisation und der Projektablauf im BVL und in der Zusammenarbeit mit externen

Partnern sind in der BVL_PA_07_0003_000 Projekte detailliert beschrieben. Folgend werden

die Mindestanforderungen für die Projektdurchführung dargestellt:

 Vor der Erstellung von Leistungsbeschreibungen für Softwareprojekte wird normaler-

weise in einem Fachkonzept das gesamte im Projekt Umzusetzende zusammenge-

stellt. Dabei werden auch diejenigen Projektziele beschrieben, die im Rahmen der Pro-

jektarbeit nicht durch Software umgesetzt werden sollen (z.B. Organisationsänderun-

gen, Schulungen, etc.).

 Auf der Basis des Fachkonzepts wird entschieden, ob die Umsetzung über eine oder

mehrere Softwareentwicklungen erfolgen soll und welcher Teil des Fachprozesses IT

gestützt umgesetzt werden soll.

 Die konkreten Anforderungen (Leistungsbeschreibung) an eine neue Software werden

schriftlich in Form eines Lastenhefts erstellt. Die detaillierten Anforderungen werden

anschließend vom Auftragnehmer in ein Pflichtenheft umgearbeitet, welches von Fach-

seite und IT abgenommen werden muss. Erst danach erfolgt die Umsetzung. Bei spä-

teren Änderungswünschen werden die jeweiligen Änderungsanforderungen schriftlich

niedergelegt und priorisiert.

 Eine Zeit- und Ressourcenplanung wird schriftlich verfasst und vom Projektleiter fort-

geschrieben.

Seite 11/35

[Seite 12]

Anhang D

5 Systemlandschaft

Anwendungen werden in der Regel als Webanwendungen implementiert: Dabei wird generell

dem Standard SAGA 5.0 gefolgt. Außerdem werden Anwendungen als Jakarta-EE-Weban-

wendungen umgesetzt.

Die Architektur der Webanwendungen folgt dem 4-Schichten-Modell (ggf. auch 5-Schichten

möglich):

 Client

 Web-Schicht

 Modell-Schicht

 Datenbank

 (optionale 5. Schicht) Sicherungsschicht

Die genauen Produkte (Software und Version) sind verbindlich für das gesamte BVL im

Dokument BVL_TA_04_9311_Z3_Systemumfeld–Entwicklung geregelt.

5.1 Kodierung und Zeichensätze

Die Standardkodierung auf allen Abstraktionsschichten ist UTF-8. Dies gilt ebenso für Res-

sourcen und Mediadateien, die im Rahmen der Dokumentation erstellt werden. Aufgrund der

zahlreichen Möglichkeiten Zeichenketten zu verarbeiten, muss die Prüfung auf unzulässige

Zeichen auf Applikationsebene z. B durch Bean Validation erfolgen. Es besteht zwar die Mög-

lichkeit, dies mit Spaltenbeschränkung (constraint) in die Schemadefinitionen aufzunehmen,

jedoch müsste in einem solchen Fall die Fehlerbehandlung auf allen Abstraktionsschichten

der Applikation durchgeführt werden – dies sollte daher vermieden werden bzw. in Ergänzung

zu der Validierung auf Applikationsebene erfolgen.

5.2 Clients und Barrierefreiheit

Als Clients werden Webbrowser eingesetzt. Plug-Ins (z.B. Java Laufzeitumgebung, Flash) dür-

fen für die Nutzung nicht nötig sein. Falls Plug-Ins verwendet werden sollen, muss hierzu eine

Genehmigung durch RefL Z31 und RefL Z32 eingeholt werden.

Die Anwendungen sollen mindestens im Internet Explorer und im Mozilla Firefox lauffähig sein.

Für Webbrowser auf mobilen Geräten wie Smartphones und Tablet Rechnern soll eine Unter-

stützung von Android und iOS erfolgen, sofern sie nicht per Einzelfallentscheidung durch RefL

Z32 für Verwaltungsanwendungen ausgeschlossen werden.

Seite 12/35

[Seite 13]

Anhang D

Außerdem ist folgendes zu beachten:

 Für die Darstellung der Inhalte ist der Online-Style-Guide der Pressestelle umzusetzen.

Sofern Anforderungen an die Barrierefreiheit es erfordern, kann formlos eine Ausnah-

megenehmigung zur Abweichung vom Guide bei der Pressestelle beantragt werden.

 Es soll eine Trennung von Design (CSS) und Inhalt (HTML) erfolgen.

 Die Anwendung muss barrierearm gemäß BITV 2.0 und WAI-ARIA sein, dies betrifft

insbesondere:

o Die Umsetzung der Anforderungen der BITV ist im Geschäftsbereich des BMEL

auch für alle internen Anwendungen verbindlich.

o Für den Einsatz auf unterschiedlichen Endgeräten muss responsives Webde-

sign (RWD) zur Anwendung kommen.

o Zur Sicherstellung einer möglichst barrierefreien Anwendung sind darüber hin-

aus die Normen DIN EN 301549:2018-08 (Richtlinien für barrierefreie Webin-

halte) und ISO 14289‑1:2014 (PDF/UA) maßgeblich und müssen beachtet wer-

den.

5.3 Applikationsserver & Frameworks

Die Web-Schicht und Modell-Schicht laufen auf einem Jakarta-EE-zertifizierten Applikations-

server als Jakarta-EE-Anwendung. Als Alternative zum Jakarta-EE-Applikationsserver ist ggf.

der Einsatz anderer Webserver bzw. HTTP-Server möglich (Einzelfallentscheidung durch RefL

Z32).

Neben der Sprache werden auch strategische Frameworks oder Bibliotheken festgeschrieben.

Für Datenbanken mit Weboberfläche gelten dabei folgende Vorgaben:

 Verwendung von Jakarta EE. Der bereitgestellte Funktionsumfang durch den Applika-

tionsserver entspricht dem Full Profile. Empfohlen wird jedoch ein möglichst sparsamer

Einsatz der bereitgestellten Dienste.

Seite 13/35

[Seite 14]

Anhang D

 Als Frontend-Technologie wird JSF mit Facelets eingesetzt, um W3C-konformes HTML und CSS zu generieren.2 Abweichungen sind ggf. nach Absprache möglich.

 Als Persistenztechnologie wird JPA vorausgesetzt. Für das objektrelationale Mapping

muss der mitgelieferte OR-Mapper des Jakarta-EE-Applikationsservers verwendet

werden. Wird im Ausnahmefall ein anderer Webserver bzw. HTTP-Server eingesetzt,

muss die Auswahl des OR-Mapper in Rücksprache mit RefL Z32 erfolgen.

 Sowohl für die Model- als auch die Controller-Schicht müssen EJB zum Einsatz kom-

men.

 Für regelmäßige Aufgaben sind zeitgesteuerte Beans (timer beans) zu verwenden, um

Datenbankoperationen transaktionssicher und über die Geschäftslogik der Anwendung

durchführen zu können. Der Einsatz von Cronjobs ist zu vermeiden und muss in Aus-

nahmefällen durch RefL Z32 genehmigt werden. Falls Cronjobs eingesetzt werden,

müssen diese im Installations- und Betriebshandbuch vollständig dokumentiert sein.

 Für die statische Quellcodeanalyse müssen geeignete Werkzeuge zum Einsatz kom-

men, die in Kombination mit dem Build-Werkzeug verwendet werden. Die hierfür not-

wendigen Konfigurationen werden durch Ref Z32 bereitgestellt bzw. mit Ref Z32 abge-

stimmt.

 Für die statische Schwachstellenprüfung der Abhängigkeiten der Anwendung muss ein

geeignetes Werkzeug zum Einsatz kommen, das in Kombination mit dem Build-Werk-

zeug verwendet wird.

 Generell wird mit dem MVC-Pattern gearbeitet.

5.4 Relationale Datenbanken

Die Speicherung von fachlichen Daten erfolgt in normalisierter Form in einem relationalen Da-

tenbankmanagementsystem (DBMS) unter Verwendung der JDBC. Diese Festlegung gilt für

alle Neuimplementierungen und ist bei Anpassungen von bestehender Individualsoftware zu

prüfen. Ausnahmen vom Standard für das DBMS und ggf. die Verwendung von nicht-relatio-

nalen DBMS erfordern eine Genehmigung von RefL Z32.

2 Siehe hierzu auch http://validator.w3.org/ und http://jigsaw.w3.org/css-validator/

Seite 14/35

[Seite 15]

Anhang D

Außerdem gelten folgende Vorgaben:

 Die Datenbankzugriffe müssen über Container-verwaltete Datenquellen (data sources)

erfolgen. Die Verwendung von Deployment-spezifischen Konfigurationen für Daten-

bankverbindungen (z. B. via Deployment-Deskriptoren, Quelltextkodierungen etc.) sind

unzulässig.

 Der Einsatz von herstellerspezifischen Erweiterungen des SQL-Standards ist unzuläs-

sig. Gelieferte SQL-Skripte (siehe Abschnitt 6.2) müssen ohne Änderungen im zu un-

terstützenden DBMS ausführbar sein. Der Einsatz von Prüfroutinen, um diese Anfor- derung zu umgehen, ist unzulässig.3

 Der Einsatz von Triggern, Stored Functions, Stored Procedures, speziellen Index-Ty-

pen, speziellen Datentypen etc. ist unzulässig.

 Technische Primärschlüssel müssen durch die Datenbank vergeben werden (identity columns).4 Hierfür ist die Verwendung des JPA-Erzeugungstyps IDENTITY zu ver- wenden, sofern es sich um einen nummerischen Primärschlüssel handelt. Die Verwen- dung von Identifikatoren wie UUIDs im Sinne von synthetischen Schlüsseln5 ist zuläs-

sig, falls technisch sichergestellt ist, dass es zu keinen Kollisionen (Mehrfachzuweisun-

gen) kommt.

 Technische Zeitstempel müssen mit einer Auflösung in Millisekunden eingesetzt wer-

den. Hierzu ist der SQL-Datentyp TIMESTAMP(3) zu verwenden. Für Zeitstempel

auf fachlicher Ebene mit geografischem Bezug (Zeitzone) ist der SQL-Datentyp

DATETIME zu verwenden. Für die technische Darstellung von Zeitangaben ist der

Standard ISO-8601 anzuwenden.

3 Nach Rücksprache mit RefL Z32 sind Konfigurationskommandos zulässig, um das korrekte Parsen bei Daten- imports steuern zu können, bspw. bei Oracle: ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH24:MI:SS.FF';

4 Bezüglich Oracle: https://oracle-base.com/articles/12c/identity-columns-in-oracle-12cr1

Bezüglich PostgreSQL: https://www.postgresql.org/docs/10/static/sql-createtable.html

Bezüglich MySQL: https://dev.mysql.com/doc/refman/8.0/en/example-auto-increment.html 5 Siehe hierzu https://de.wikipedia.org/wiki/Surrogatschl%C3%BCssel

Seite 15/35

[Seite 16]

Anhang D

 Bei der Speicherung großer binärer Objekte in der Datenbank (@Lob) muss im Rah-

men von Konzeptworkshops festgelegt werden, wo die Primärdaten gespeichert wer-

den und mit welchen Mechanismen sie vor Manipulationen geschützt werden, z. B.

durch eine kryptografische Hashfunktion (Fingerprint) oder eine elektronische Signatur.

Erfordert die Anwendung die Speicherung zahlreicher oder großer Binärdaten, müssen diese dateibasiert entsprechend dem Filesystem Hierarchy Standard6 und transakti- onsgeschützt7 abgelegt werden. Der Speicherort muss konfigurierbar sein, i.d.R. han-

delt es sich um /opt/data. Abweichungen davon erfordern die Zustimmung von RefL

Z32.

 Der Einsatz von nativen SQL-Kommandos im Quelltext ist unzulässig. Sämtliche Da-

tenbankanfragen müssen über den OR-Mapper abgewickelt werden.

 Für häufig auftretende Datenbankanfragen stehen folgende Technologien zur Verfü-

gung: EJB Named Query, EJB-QL oder die JPA Criteria API.

Der Aufbau der initialen Datenbankstruktur (Schema) und die Befüllung mit initialen Datenban-

kinhalten (Konstanten) werden über den Schema-Manager durchgeführt. Die Konfigurations-

dateien des Schema-Managers werden im Unterordner src/main/database des Projektes

gespeichert. Bei Änderungen durch eine neue Lieferung der Software werden die Konfigurati-

onsdateien ebenfalls dort abgelegt, so dass der Schema-Manager in Kombination mit dem

Build-Werkzeug das Datenbankschema aktualisieren kann.

 Auslagerung von Geschäftslogik auf die Datenbank ist generell unzulässig.

 Zur Sicherstellung der Synchronizität zwischen Datenbankschema und Modell-Schicht

ist im Deployment-Deskriptor persistence.xml die Schema-Validierung zu konfigu-

rieren, z. B.:

6 Siehe hierzu auch http://refspecs.linuxfoundation.org/fhs.shtml 7 Siehe hierzu auch https://narayana.io/sub-projects/index.html, Abschnitt „Transactional File I/O“

Seite 16/35

[Seite 17]

Anhang D

5.5 Identitätsmanagement und Zugriffsrechte

5.5.1 Authentifizierung

Für das Identitätsmanagement wird Red Hat SSO in allen Netzsegmenten (Intranet, DMZ)

eingesetzt. Die Installation von Red Hat SSO erfolgt über die Paketverwaltung des eingesetz-

ten Betriebssystems. Erfolgt in Ausnahmefällen die Pflege der Benutzer über die Anwendung,

muss eine geeignete Bibliothek für den LDAPv3-basierten Zugriff auf Red Hat SSO eingesetzt werden, die RFC 3062 implementiert.8 Passwortrichtlinien werden zentral über Red Hat SSO

durchgesetzt. Die Konfiguration von einem oder mehreren Parametern der Passwortrichtlinie

in der Fachanwendung ist unzulässig.

5.5.2 Autorisierung

Die Autorisierung muss in Red Hat SSO durch Konfiguration entsprechender Sicherheitsbe-

reiche erfolgen, die von der Anwendung als Vorbedingung für die implementierten Anwen-

dungsfälle ausgewertet werden. Zusätzlich muss in Red Hat SSO auch eine Gruppe für jede

Anwendung eingerichtet werden, der nur die Benutzer zugeordnet werden, die sich in der je-

weiligen Anwendung anmelden dürfen. Über Red Hat SSO ist SSO über SAML zu realisieren.

In begründeten Ausnahmefällen ist auch das Kerberos-Protokoll möglich. Die hierfür notwen-

digen Maßnahmen werden in Absprache mit Referat Z32 festgelegt.

5.6 Schnittstellen und Datenaustausch

Als Datenaustauschformat zwischen verschiedenen Anwendungen wird XML eingesetzt, da-

bei sind die XÖV-Regeln zur Modellierung von XML umzusetzen, siehe Tabelle 1 auf Seite 20.

Für den Datenaustausch sind zustandslose Web-Services auf Grundlage von JAX-RS zu ver- wenden.9 Die jeweilige technische Umsetzung ist dabei für den jeweiligen Anwendungsfall zu

prüfen und eine Abweichung vom empfohlenen Vorgehen mit RefL Z32 abzustimmen. Nach

Absprache ist bei Bedarf auch eine nachrichtenorientierte Umsetzung gemäß JAX-WS mög-

lich.

8 Für Schreibzugriffe auf den LDAP muss die vom BVL vorgeschriebene Richtlinie für die Speicherung von Pass- wortinformationen eingehalten werden, die beim Einrichten eines OpenLDAP-Servers konfiguriert wird. Eine RFC-3062-konforme Bibliothek verwendet die „LDAP Password Modify Extended Operation“, so dass die OpenLDAP-Konfiguration beachtet wird. 9 Sie hierzu auch https://docs.oracle.com/javaee/7/tutorial/jaxws.htm

Seite 17/35

[Seite 18]

Anhang D

5.7 Netztrennung und Verwaltungsnetz

Die netztopologische Platzierung der Anwendung ist abhängig vom Anwenderkreis und dem

Schutzbedarf der verarbeiteten Daten. Diese Frage muss im Rahmen der Konzeptworkshops

unter Unterstützung von Z3 und unter Beteiligung des IT-SiBe erörtert werden. Grundsätzlich

gilt, dass Anwendungen für die Öffentlichkeit in der DMZ platziert werden müssen. Anwendun-

gen in der DMZ können ausschließlich auf Ressourcen und Fremdsysteme zugreifen, die sich

ebenfalls in der DMZ befinden.

Soll eine Anwendung den Mitarbeitenden des BVL oder anderen Teilnehmern des NdB zur

Verfügung gestellt werden, muss diese zwingend im sicheren Verwaltungsnetz (Intranet) plat-

ziert werden. Die Bereitstellung der Anwendung für andere NdB-Teilnehmer muss darüber

hinaus in enger Abstimmung mit Z33 und dem IT-SiBe erfolgen, da ggf. eine Genehmigung

für die Verarbeitung von Verschlusssachen des Geheimhaltungsgrades NUR FÜR DEN

DIENSTGEBRAUCH (VS-NfD) beim Geheimschutzbeauftragten des BVL beantragt werden

muss.

Seite 18/35

[Seite 19]

Anhang D

6 Entwicklung

In diesem Kapitel werden Entwicklung, einzusetzende Werkzeuge und Vorgaben für die Um-

setzung beschrieben.

6.1 Entwicklungsumgebung

Für die Übersetzung der Java Programme kommen folgende Werkzeuge zum Einsatz:

 Die Verwendung eines Build-Werkzeuges mit einem Abhängigkeitsmanagement ist

zwingend notwendig.

 Die interne Entwicklung von Individualsoftware erfolgt unter Verwendung einer inte-

grierten Entwicklungsumgebung.

 Für die Pflege der Quellcodes wird ein Versionsverwaltungssystem verwendet.

Grundsätzlich müssen frei verfügbare Programme, deren Lizenz die Nutzung im BVL nicht

einschränkt, für das Kompilieren bzw. Übersetzen der Anwendungen verwendet werden.

Ebenso sollen möglichst nur frei verfügbare Bibliotheken eingebunden werden.

6.2 Quellcode-Organisation

Die Quelltexte und Ressourcen-Dateien müssen anhand des vom Build-Werkzeug vorgege-

benen Layouts organisiert werden. Bezugnehmend auf Abschnitt 5.4 ist hierbei insbesondere

das Verzeichnis src/main/database zu beachten, in dem die Schema-Manager-Konfigura-

tionen zum Erzeugen des Datenbankschemas und der initialen Befüllung der Tabellen abge-

legt werden müssen.

6.3 Dokumentation der Softwareprojekte

Die Dokumentation der Software-Projekte und der neuen Software erfolgt grundsätzlich wie

nachfolgend beschrieben:

 Im IT-Wiki wird das Projekt bzw. die Software nach dem vorgegebenen Schema doku-

mentiert.

 Der Quellcode, ggf. Schema-Manager-Konfigurationen und weitere Dokumentation

wird in der Versionsverwaltung gepflegt.

Seite 19/35

[Seite 20]

Anhang D

Der geänderte Quellcode wird regelmäßig in die Versionsverwaltung übertragen (mindestens

bei jeder neuen Lieferung). Die Daten werden nach den gängigen Standards der Versionsver-

waltung strukturiert abgelegt.

Für die Dokumentation des Quellcodes müssen insbesondere aussagekräftige Kommentare

einfügt werden, so dass die generierte JavaDoc-Dokumentation verständlich und umfassend

ist.

Zusätzlichen zur Visualisierung der Klassenhierarchie, werden Datenbankschema-Visualisie-

rungen und insbesondere Darstellungen der Systemlandschaft erstellt. Hierbei ist UML zu ver-

wenden. Datenbankmodelle sind mittels des Entity-Relationship-Modells (ERM) zu modellie- ren. Dabei ist die Notation nach Elmasri/Navathe10 zu verwenden. Kardinalitäten sind in Min-

Max-Notation anzugeben.

Beim Einsatz von UML und der Definition der XML-Schemata sind folgende Richtlinien des

XÖV-Standard zu beachten:

Tabelle 1 Verpflichtende XÖV-Regelungen für XML-Protokollnachrichten.

10 R. Elmasri, S. B. Navathe: Grundlagen von Datenbanksystemen, Addison-Wesley

Seite 20/35

[Seite 21]

Anhang D

6.4 Namensgebung

Bei der Namensgebung gelten folgende Vorgaben:

 Es gelten die Java-Code-Conventions.

 Jedes Projekt erhält einen BVL-weit eindeutigen Kurznamen ohne Leer- oder Sonder-

zeichen. Groß- und Kleinschreibung darf nicht signifikant sein, da für Java spezielle

Regeln existieren.

 Package-Namen in Java entsprechen der generischen Form

de.bund.bvl...

o projekt bezeichnet den eindeutigen Projektkurznamen.

o layer bezeichnet das Abstraktionsniveau der zugehörigen Pakete. Zulässige

Werte sind model, view, controller, services und utils.

o package bezeichnet den eigentlichen Package-Namen.

 XSD-Schemata werden wie folgt abgelegt:

o URIs werden nach dem Schema http://www.bvl.bund.de//<Pro-

jektkürzel> gewählt.

o Bei Bedarf kann, ähnlich wie beim W3C, unter der URL

http://www.bvl.bund.de//<Kürzel> eine kurze Beschreibung

abgelegt werden.

o Unter http://www.bvl.bund.de//<Kürzel>.xsd werden die

Schema-Definitionen abgelegt. Durch eine abweichende Endung können auch

weitere Ressourcen abgelegt werden.

6.5 Internationalisierung

Um die Webanwendungen möglichst einfach zu internationalisieren, sollen Texte in Resource

Bundles hinterlegt und im Deskriptor

/src/main/webapp/WEB-INF/faces-config.xml

Seite 21/35

[Seite 22]

Anhang D

konfiguriert werden.11 Dies soll auch eine nachträgliche Übersetzung erleichtern.

6.6 Strukturierte Ablage von Primärdaten

Wurde im Rahmen der Konzeptworkshops zwischen dem AN und dem BVL die Notwendigkeit

zur Speicherung von Primärdaten auf dem Dateisystem identifiziert, so muss die Ablage der

Einzeldateien im Dateisystem entsprechend folgendem Schema erfolgen:

/opt/data////

/opt/data/certificates/2019/06/03

Hierbei wird standardmäßig angenommen, dass das Mengengerüst der Primärdaten ein steti-

ges Wachstum aufweist und die Dateiablage für einen effizienten Zugriff strukturiert erfolgen

muss. Standardmäßig genügt eine Unterteilung in Kalendertagen. Sollte die erwartete Datei-

anzahl pro Kalendertag den Schwellwert 100 überschreiten, ist eine Feinunterteilung in Stun-

den, Minuten oder sogar Sekunden vorzunehmen.

6.7 BVL-interne Server- und Entwicklungsorganisation

Das IT-Wiki dient als zentraler Einstiegspunkt. Dort sind alle Informationen zur technischen

Infrastruktur dokumentiert. Zu jedem Softwareprojekt wird eine eigene Wiki-Seite erstellt.

Darüber hinaus gelten folgende Vorgaben:

 „Kleine“ Anwendungen können mit 3-Schichten-Architektur erstellt werden. Welche An-

wendung als „klein“ zu betrachten ist, wird in projektbezogenen Workshops definiert.

 Für jede Anwendung wird neben der künftigen Produktivumgebung auch eine sepa-

rierte Testumgebung aufgebaut.

 Tickets zu Programmfehlern/Änderungsanforderungen (Request for Change) werden,

sobald die Anwendung in den Betrieb übergeht und das Entwicklungsprojekt abge-

schlossen wurde, vom BVL-eigenen IT-Service entgegengenommen.

11 Siehe hierzu auch https://docs.oracle.com/cd/E19798-01/821-1770/gcrri/index.html

Seite 22/35

[Seite 23]

Anhang D

6.8 Extern entwickelte Software

Vorgaben für extern entwickelte Software:

 Der Quellcode extern entwickelter Software wird nach jeder Lieferung in die Versions-

verwaltung eingestellt.

 Alle Unterlagen werden zentral nach den Vorgaben des V-Modell XT Bund abgelegt.

Vorgaben für extern entwickelte Software für Auftragnehmer:

 Der Auftragnehmer stellt ein zugangsgesichertes Bugtracking-Tool über HTTPS bereit,

der Export der Tickets als PDF muss möglich sein. Die BVL-Mitarbeiter/innen sind ver-

pflichtet, regelmäßig zu Dokumentationszwecken im Zusammenhang mit einer Ab-

nahme einen Export der Tickets durchzuführen.

 Lieferungen sollen zugangsgesichert und per HTTPS über Port 443/TCP bereitgestellt

werden (andere Ports sind im BVL für Datentransfer nicht verfügbar).

 Sofern Testsysteme beim Auftragnehmer betrieben werden, müssen diese zugangs-

gesichert und mit HTTPS-Verschlüsselung betrieben werden.

 Alle Softwareentwicklungsprojekte werden nach V-Modell XT Bund durchgeführt.

Seite 23/35

[Seite 24]

Anhang D

7 Tests und Abnahme der Software

Neue Software wird gründlichen Tests unterzogen, insbesondere sollen auch Lasttests durch-

geführt werden. Handelt es sich um intern programmierte Software, müssen sowohl Entwick-

lertests als auch Nutzertests von der Fachseite durchgeführt werden. Soll eine Lieferung eines

externen Auftragnehmers getestet werden, müssen sowohl Tests der Fachseite als auch Tests

durch Mitarbeiter von Z32 durchgeführt werden.

Die Tests sollen möglichst automatisiert durchgeführt werden. Folgende Werkzeuge sollen für

diese Automatisierung eingesetzt werden:

 Durchführung von Frontend- und Akzeptanztests

 Durchführung von Lasttests

 Durchführung von Modultests

 Durchführung von Schnittstellentests

 Durchführung von Integrationstests

Die Testfälle sind schriftlich zu dokumentieren in Form eines Prüfprotokolls. Dieses Prüfproto-

koll ist die Voraussetzung für die Abnahme einer Softwareversion. Zusätzlich ist bei Lieferun-

gen externer Auftragnehmer zu prüfen, ob sich die Individualsoftware fehlerfrei auf den Ser-

vern des BVLs kompilieren lässt.

Der Auftragnehmer verpflichtet sich, dem BVL qualitätsgesicherte Produkte auszuliefern. Die

Qualitätssicherung beinhaltet mindestens Nutzertests, die an den Anforderungen angelehnt

sind. Es wird empfohlen, geeignete Tests zu entwickeln, um die Korrektheit der Software auch

nach Änderungen/Softwareanpassungen zu gewährleisten.

Seite 24/35

[Seite 25]

Anhang D

8 Freigabe von Anwendungen für den Produktivbetrieb

Neue Anwendungen müssen sowohl von der Fachseite als auch von RefL Z32 für den Pro-

duktivbetrieb freigegeben werden. Für die Freigabe des Produktivbetriebes müssen ausführli-

che und dokumentierte Abnahmetests der in den Betrieb zu überführenden Softwareversion

auf einem Testsystem erfolgt sein. Die Dokumentation dieser Tests ist Z32 bei der Prüfung auf

Freigabe für den Produktivbetrieb vorzulegen.

Sind Änderungen an der im Produktivbetrieb befindlichen Software notwendig, so ist die Soft-

ware erneut zu testen. Erst nach positivem Abschluss der Tests dürfen die Änderungen in den

Produktivbetrieb übernommen werden.

Sollte vor dem Produktivbetrieb eine Pilotphase durchgeführt werden, so gelten diese Rege-

lungen zusätzlich auch für die Pilotphase.

Seite 25/35

[Seite 26]

Anhang D

9 Nachweisdokumente

Seite 26/35

[Seite 27]

Anhang D

10 Mitgeltende Unterlagen

Seite 27/35

[Seite 28]

Anhang D

11 Änderungen an diesem Dokument

 Das Dokument wurde in der Version 4.0 den aktuellen Entwicklungen entsprechend

angepasst. Hierzu zählen:

o Endgültige Umbenennung der Spezifikationssammlung Java EE in Jakarta EE.

o Umsetzung der Organisationsverfügung bezüglich Gruppe Z3.

o Definition der Vorgaben zur strukturierten Ablage von Primärdaten.

o Umbenennung des Begleitdokumentes zum Systemumfeld des BVL

BVL_TA_04_9311_Z3_Systemumfeld-Entwicklung.

o Hinzufügen der neuen Anforderungen zur Netztrennung und dem sicheren Ver-

waltungsnetz (Nutzerpflichten des NdB).

o Hinzufügen der aktualisierten Anforderungen an die Barrierefreiheit

 Das Dokument wurde in der Version 3.0 den aktuellen Entwicklungen entsprechend

angepasst. Hierzu zählen unter anderem

o Wechsel auf eine allgemeine Versionsverwaltung. Spezifizierung erfolgt über

das neue Dokument BVL_TA_04_9311_030_Systemumfeld-Entwicklung.

o Wechsel auf einen Jakarta-EE-zertifizierten Applikationsserver

o Verallgemeinerung der Persistierung in relationalen DBMS via JDBC

o Wechsel von Cronjobs auf zeitgesteuerte Beans, die die Geschäftslogik der

Anwendung für die Abwicklung regelmäßiger Aufgaben verwenden

o Einführung eines Schema-Managers

o Einführung von Integrationstests

o Einführung eines generalisierten IDMS mit Zugriff via RFC 3062

o Umbenennung des Begleitdokumentes zum Systemumfeld mit dem neuen QM-

Schlüssel in BVL_TA_04_9311_030_Systemumfeld-Entwicklung

Seite 28/35

[Seite 29]

Anhang D

o Im Abschnitt 3 wurden allgemeine und spezifische Begriffe den Unterabschnit-

ten neu zugeordnet.

 Das Dokument wurde in der Version 2.0 komplett überarbeitet.

Wesentliche inhaltliche Änderungen:

o Kapitel „Begriffe“ erweitert um „spezifische Begriffe“

o Umstrukturierung der Kapitel: Gliederung nach Systemlandschaft und Entwick-

lung mit entsprechenden Unterkapiteln

o Kapitel „Tests und Abnahme“ neu eingefügt bzw. Kapitel „Test“ erweitert

o Das Dokument wurde so umgestellt, dass allgemeingültige Vorgaben beschrie-

ben werden. Die Festlegung von konkreten Versionsvorgaben wurde ausgela-

gert und erfolgt in dem Dokument BVL_TA_04_9311_903_Systemumfeld -

Entwicklung

Seite 29/35

[Seite 30]

Anhang D

Anhang: Quellcode-Organisation

Nachfolgend wird eine Ordnerstruktur vorgeschlagen, die für die Organisation sämtlicher Res-

sourcen einer Lieferung verwendet werden kann. Die Struktur orientiert sich an den Anforde-

rungen, die in diesem Dokument formuliert wurden.

12 Siehe hierzu auch http://www.mastertheboss.com/javaee/batch-api/batch-applications-tutorial-on-wildfly

Seite 30/35

[Seite 31]

Anhang D

13 Siehe hierzu auch http://jsefa.sourceforge.net/

Seite 31/35

[Seite 32]

Anhang D

14 Bezüglich zulässiger Deskriptoren siehe auch

https://docs.jboss.org/author/display/WFLY8/Deployment+Descriptors+used+In+WildFly

Seite 32/35

[Seite 33]

Anhang D

Seite 33/35

[Seite 34]

Anhang D

Anhang: Architekturkonzept

Abbildung 1 Mustervorlage für die Anwendungsarchitektur

Seite 34/35

[Seite 35]

Anhang D

Entsprechend den Vorgaben für das Architekturmodell (siehe Abschnitt 5.3), den zu berück-

sichtigenden Spezifikationen und der Organisation des Quellcodes (siehe Abschnitt 6.2) ver-

anschaulicht Abbildung 1 das empfohlene Grundgerüst für die Architektur der Anwendung.

Seite 35/35