Anleitung zur Erstellung von Open-Source Software

Programme, Applikationen, Anwendungen. Was tun, wenn die App spinnt?
Antworten
Bernd Malessa
Beiträge: 9
Registriert: 06.01.2020

Anleitung zur Erstellung von Open-Source Software

Beitrag von Bernd Malessa »

Ziel dieses Projektes ist es eine Anleitung zur Entwicklung gemeinnütziger Software-Projekte zu erstellen und einen entsprechenden Support anzubieten.
Dabei soll u.a. die Vorgehensweise anhand der Umsetzung eines oder mehrerer nicht trivialer Softwareprojekte hier umfangreich dokumentiert werden.

Dieses Projekt richtet sich daher an Mitmenschen, die Interesse an der Softwareentwicklung haben und gerne bei der Entwicklung von gemeinnütziger OpenSource-Software mitarbeiten möchten. Die zu entwickelnde Software ist dabei erst einmal nicht festgelegt. Projektvorschläge sind daher willkommen. Mitmachen dürfen alle, die so etwas gerne einmal ausprobieren möchten. Ein wenig Programmierkenntnisse in einer objektorientierten Sprache bzw. das Interesse eine solche zu erlernen wären natürlich hilfreich, sind aber keine Voraussetzung für die Mitarbeit. In jedem Softwareprojekt werden unterschiedlichste Skills benötigt und Programmieren ist nur einer davon. Das Schreiben der Projektdokumentation, die Anforderungsanalyse und das Testen sind letztlich genauso wichtig für den Erfolg eines Softwareprojekt.

Die zu erstellende Software sollte einem gemeinnützigen Zweck dienen und die erstellten Programme und Dokumentationen sollen nach der Fertigstellung unter einer noch festzulegenden OpenSource-Lizenz im Internet zum Download angeboten werden. Das Ziel ist es dabei nicht, die ultimativ beste Software zu entwickeln, sondern über den Weg dahin ein Verständnis zubekommen, wie viele Aspekte bei der Erstellung einer nicht trivialen Software zu berücksichtigen sind. Insofern gilt hier das Motto: Der Weg ist das Ziel.

Was wir hier nicht machen wollen, ist das Ausfechten irgendwelcher "Glaubenskriege" nach dem Motto, diese oder jene Programmiersprache, Entwicklungsumgebung, Datenbank etc. ist die einzig wahre Lösung und alles andere ist Schrott. Ich habe in den letzten 25 Jahren in der IT der Telekom an vielen verschiedenen IT-Projekten mitgearbeitet und wenn ich dabei eines gelernt habe, dann die Tatsache, das viele Wege nach Rom führen. Für die ersten Erfahrungen ist es daher nicht so wichtig die ultimativ beste Lösung zu bauen, sondern immer wiederkehrender Anfängerfehler zu vermeiden.

Sobald sich die passende Projektaufgabe gefunden hat, würde ich gerne den komplette Lebenszyklus eines Softwareprojekt über Anforderungsanalyse, Festlegung der Systemarchitektur, Entwicklung des internen Softwaredesign, die Programmierung, das Testen etc. inklusiver der dazugehörenden Projektdokumentation anhand etablierter Best-Practices aus meiner Sicht erläutern und dokumentieren. Diskussionen und Verbesserungsvorschläge sind dabei natürlich jederzeit willkommen. Bei Bedarf wird dafür gesorgt, dass ein interaktiver Austausch über Telefon- oder Videokonferenz ermöglicht wird. Wie sich das dann genau entwickeln wird, kann ich heute auch noch nicht sagen. Das ist dann auch abhängig von der Anzahl der Interessenten und deren Präferenzen. Heute stehen im Internet so viele kostenlose Informationen und Videos über Open-Source Softwareenwicklung zur Verfügung, dass es sicher vermessen wäre zu glauben, dass man im Rahmen einer ehrenamtlichen Tätigkeit noch etwas Neues oder Besseres anbieten kann, aber manchmal ist es gerade der persönliche Austausch und das konkrete eigene Projekt, welches dazu beiträgt, überhaupt einen guten Einstieg in dieses Thema zu finden.

Sofern sich kein Projektvorschlag aus der Community findet, würde ich gerne diesen hier machen:
Ein "Tool zur Erstellung einer beamtenrechtlichen Versorgungsauskunft".

Das ist insofern ganz praktisch, weil hier aus technischer Sicht erstmal alle Möglichkeiten offen bleiben, d.h. es kann sowohl als Einzelplatzsystem, aber auch als Webanwendung umgesetzt werden. Außerdem sind die fachlichen Anforderungen an dieses Projekt sicher mindestens genauso komplex, wie die Implementierung dieser Anforderungen in eine Software. Als langjähriger Beamter bei der Telekom, der sehr lange auf die entsprechende Versorgungsauskunft der Bundesanstalt für Post- und Telekommunikation warten musste, weis ich auch, dass dafür ein Bedarf bei den noch im Arbeitsleben stehenden Kolleginnen und Kollegen besteht. Aufgrund der sehr komplexen fachlichen Anforderungen, wäre es natürlich super, wenn sich hier auch Interessenten finden, die Ihr fachlichen Know-Know aus dem Beamten- und Versorgungsrecht einbringen möchten. Insbesondere bei der fachlichen Anforderungsanalyse und dem Testen wäre dieses Know-How sehr wertvoll.

Ich denke, das soll es zur Vorstellung des Projekt erstmal gewesen sein. Jeder der an diesem Projekt mitarbeiten möchte, kann sich gerne melden!
Bin mal gespannt auf die Rückmeldungen.

Bernd Malessa
Beiträge: 9
Registriert: 06.01.2020

Re: Anleitung zur Erstellung von Open-Source Software

Beitrag von Bernd Malessa »

Da aus der Community bisher noch kein Vorschlag für eine individuelle Softwarelösung eingegangen sind, werden ich erst einmal mit dem von mir vorgeschlagenen "Tool zur Berechnung einer beamtenrechtlichen Versorgungsauskunft" weitermachen.

Bevor wir mit der Projektarbeit starten, benötigen wir aber noch eine Art Fahrplan, eine Methodik bzw. ein Vorgehensmodell nach dem wir arbeiten möchten.
Wie soll die Projektarbeit organisiert und strukturiert werden? Welche relevanten Parteien (Stackholder) sind involviert und müssen berücksichtigt werden?
Welche Aufgaben stehen überhaupt an und in welcher Reihenfolge sollten die Arbeiten an diesen Aufgaben sinnvoll gestartet werden.

In der Vergangenheit (ca. bis zum Beginn des sog. Internetzeitalter in den 1990-2000er Jahre) war das vorherrschende Modell für die Vorgehensweise in der Softwareentwicklung das sog. Wasserfallmodell. Bei diesem Modell wurde alle Phasen des Software-Entwicklungsprozess sequentiell nacheinander abgearbeitet. Das von allen relevanten Projekt-Stackholdern abgenommene Endergebnis der vorgelagerte Projekt-Phase wurde benötigt, um mit der nächsten Projekt-Phase starten zu können. Konkret konnte mit der Implementierung einer Software erst dann gestartet werden, wenn alle fachlichen, technischen Anforderungen an das Projekt vollständig erfasst waren und eine entsprechend Architektur und das Design der Software-Lösung vollständig spezifiziert und von den relevanten Stackholdern abgenommen wurde. An den Übergänge der jeweiligen Entwicklungsphasen wurde sog. Milesstone-Reviews durchgeführt. Erst wenn diese Reviews erfolgreich durchlaufen wurden, konnte mit der nächsten Projektphase gestartet werden.

Die folgende Grafik gibt eine Übersicht über die im Wasserfall-Model vorhandenen Projekt-Phasen.

download/file.php?mode=view&id=34

Da Nachteil des Wasserfall-Model wird relativ schnell klar. Spätere Erweiterungen oder Änderungen in den fachlichen Anforderungen können nur mit hohen Aufwand aufgenommen werden und erfordern immer einen Rücksprung in eine eigentlich bereits abgeschlossene Phase des Entwicklungsprozess. Fehler in der fachlichen Spezifikation werden z.B. erst sehr spät in der Test-Phase erkannt. Solche Änderungen in den Anforderungen werden dann sehr aufwändig und damit sehr kostenintensiv.
Die verschiedenen am Projekt beteiligten Personen oder Gruppen arbeiten in diesem Model oft nicht miteinander, sondern gegeneinander. Das "über den Zaun werfen" von Projekt-Dokumenten hat noch nie gut funktioniert. Natürlich benötigt jedes Projekt auch eine bestimmte Ordnung im Entwicklungsprozess, aber im Wasserfall-Modell fehlt jeglicher Freiraum, um flexibel mit sich ändernden Projektanforderungen umgehen zu können. Diese Nachteile haben dazu geführt, dass dieses Vorgehensmodell dahingehend erweitert wurde, mehr Flexibilität zuzulassen. Ab ca. den 2000er Jahren wurde das Wasserfall-Prozessmodel mehr oder weniger ersetzt durch eine Vorgehensweise, die mehr Flexibilität im Entwicklungsprozess ermöglichen sollte. Es gab eine größere Anzahl unterschiedlicher Prozessmodelle, die aber im Kern alle dasselbe Ziel adressierten. Die Softwareentwicklung sollte flexibler gegenüber sich ändernden Anforderungen während der Entwicklung des Softwareprodukt werden.
Ein Vertreter dieser neuen Vorgehensweise war der "Rational Unified Process". Parallel dazu entwickelte sich die UML (Unified Modelling Language). Mit der UML wurde es nun möglich die Dokumentation um standardisierte grafische Modelle wie z.B. UseCase-Diagrammen, Klassen-Diagrammen, Komponenten-Diagramme etc. zu erweitern. Dies ermöglicht eine bessere Kommunikation zwischen fachlichen und technischen Stackholdern, da sich viele Sachverhalte grafisch deutlich aussagekräftiger darstellen lassen, als dies durch reine Textbeschreibungen möglich wäre. Außerdem sah der RUP ein iteratives Vorgehen bei der Umsetzung vor. Ein Projekt wurde in mehrere Iteration aufgeteilt, wobei dann für jede Iteration die verschiedenen Phasen wie Anforderungsanalyse, Implementierung, Test etc. wie im Wasserfall abgearbeitet wurden. Durch diese Vorgehensweise konnten relativ einfach noch nachträglich neue oder geänderte Anforderungen für eine spätere Iteration berücksichtigt werden. Eine Trennung zwischen den eher fachlich und technisch am Projekt arbeitenden Stackholdern war in diesem Vorgehnsmodell jedoch immer noch stark ausgeprägt.

Die folgende Grafik gibt einen Überblick über die im "Rational Unified Process" (RUP) unterschiedenen Disziplinen und Phasen des Software-Entwicklungsprozess.

download/file.php?mode=view&id=35

Heutzutage ist eine möglichst kurze "Time to Market" die erste Priorität vieler Softwareprojekte. Es wird nicht mehr so viel Wert auf eine vollständige und widerspruchsfreie Dokumentation gelegt, bevor man mit der Implementierung überhaupt erst anfängt, sondern man möchte möglichst schnell mit einem "Minimum Viable Product" einen Mehrwert schaffen. Fachseite und Entwicklung arbeiten nicht getrennt wie im Wasserfallmodell oder im "Rational Unified Process", sondern in einem Team zusammen, um die Entwicklungszeit zu minimieren. Auch die Kundenseite ist bereits in dieser frühen Phase beteiligt und muss daher nicht so lange warten, bis sie zum ersten mal das fertige Produkt zu Gesicht bekommt. Neue Anforderungen oder Änderungswünsche werden in einem sog. "Backlog" gesammelt, priorisiert und dann in sog. "Sprints" umgesetzt. Das Vorgehensmodel für diese Methodik nennt sich "Scrum-Modell". Es werden in relativ kurzen Iteration (meistens innerhalb einer Zeitspanne von 2-4 Wochen) neue Programmversionen geplant, implementiert, getestet und dem Kunden bereitgestellt. Nicht der "Big Bang", sondern viele kleine Änderungen in kurzen Zeitabständen. Der Kunde bekommt nicht das eine große "Ding", sondern aus den Rückmeldungen der betroffenen Projekt-Stakeholder werden die Prioritäten festgelegt und die Iterationen geplant und der Projekt-Backlog wird so sukzessive abgearbeitet. Für jemanden, der viel Wert auf eine saubere Dokumentation und abgegrenzte Verantwortung legt, ist diese Vorgehensweise natürlich "gewöhnungsbedürftig", aber der wirtschaftliche Erfolg gibt dieser Vorgehensweise heute recht.

Auch hier eine kleine grafische Übersicht über die das SCRUM-Model

download/file.php?mode=view&id=36


Die meisten kommerziellen oder Open-Source Software-Projekte werden heute nach der SCRUM-Methodik geplant und umgesetzt.
Die o.g. Vorgehensweisen nach dem "Wasserfall-Model" oder nach dem "Rational Unified Process" kommen heute vor allem noch in sicherheitskritischen Bereichen zur Anwendung - dort wo nicht die "time to market", sondern eine saubere Dokumentation und eine klar abgegrenzte Verantwortung einen hohen Stellenwert eingeräumt bekommt.

Für unsere geplantes Projekt bietet sich natürlich auch eher die SCRUM-Methodik an. Alles was uns so an fachlichen und technischen Anforderungen einfällt, werden wir zunächst in einem Projekt-Backlog sammeln. Wenn wir dann eine erste Übersicht über die umzusetzenden Anforderungen gewonnen haben, werden wir uns die Prioritäten dieser Anforderungen ansehen und dann versuchen diese Anforderungen in Iteration, die jeweils ca 2-4 Wochen dauern sollten, umzusetzen. In diesen Iterationen werden dann die fachlichen Anforderungen (wie sich bspw. aus dem BeamtVG ergeben) festgelegt, programmiert, getestet und in die sukzessive wachsende Anwendung integriert.
Parallel dazu müssen wir natürlich auch sowas wie eine Softwarearchitektur und eine Komponenten-Design entwickeln, das eine gewisse Stabilität gewährleistet und in der Lage ist, Änderungen und Erweiterungen zuzulassen. Das ist eben die Kunst in der Softwareentwicklung. Eine Software so zu bauen, das sie einerseits stabil läuft, aber andererseits auch erweiterbar und wartbar bleibt. Funktionale vs. nicht funktionale Anforderungen gleichwertig zu berücksichtigen. Das ist dann aber ein anderes Thema und dazu werden ich dann irgendwann auch noch mal einen separaten Beitrag hier in diesem Forum schreiben.
Dateianhänge
Scrum_Framework.jpg
RUP Phase Model.png
1-wasserfall-.png

Schulschrat
Beiträge: 4
Registriert: 20.09.2017

Vereinsheim-Software

Beitrag von Schulschrat »

Hallo Bernd Malessa,
was Du da schreibst klingt ja sehr expertös :-) Vielleicht klinke ich mich mit meinem Problemchen hier ein: ich benötige für unseren Vereinsheim ein Programm, mit dem ich die laufenden Kosten usw. etwas komfortabler als mit meiner bisherigen Excel-Tabelle erfassen kann und dabei sollen auch Verbrauchsberechnungen, Prognosen usw. möglich sein.
Folgende Parameter sollten anfangs detailliert erfasst werden können: Strom (2 Zähler, Tagesverbrauch usw.) , Wasser , Heizung (Tagesverbrauch, Brennerlaufzeit, und einige weitere). Die Werte werden jedoch nur sporadisch erfasst, müssen also teilweise interpoliert werden. Es sollen dann Vergleichsdaten (wie war das im letzten Juni?) und Prognosen (wann steigt der Verbrauch so, dass die Brennerdüse getauscht werden muss?) und viele weitere Ideen, die man mit berechnen könnte. Ich verfolge Deine Ausführungen erst einmal mit Interesse weiter und kommen dann gerne mit präzisen Fragen, wenn es recht ist :-)
Gruß vom Schulschrat (alles für den Verein :-)

Bernd Malessa
Beiträge: 9
Registriert: 06.01.2020

Re: Vereinssoftware

Beitrag von Bernd Malessa »

Hallo Schulschrat,

vielen Dank für die Rückmeldung. Als ich mein Projekt beim Prot-In Support e.V. für meine ehrenamtliche Tätigkeit im Engagierter Ruhestand vorgestellt habe,
habe ich meine Idee u.a mit folgenden Sätzen beschrieben:
...
In der Vereinsarbeit oder bei gemeinnützigen Organisationen besteht gelegentlich der Wunsch, für wiederkehrende manuelle Tätigkeiten eine Softwarelösung einzusetzen.
Die Rede ist hier nicht vom Aufbau einer Homepage im Internet oder dem Einsatz einer softwarebasierten Mitgliederverwaltung oder ähnlichem, sondern von einer individuellen Problemstellung, für die selbst nach ausreichender Recherche keine frei verfügbare bzw. kostengünstige Softwarelösung gefunden werden kann.

Hier stellt sich also die Frage: Weitermachen wie bisher oder selber eine Softwarelösung für dieses Problem entwickeln.

Häufig ist zumindest ein Basiswissen über Programmierung bereits vorhanden. Zudem existieren unzählige Tutorials in Form von Videos und Dokumente für alle möglichen Programmiersprachen, Frameworks und sonstige Entwicklertools im Internet, z.B. auf Youtube. Sobald die Problemstellung aber etwas komplexer wird, fehlt oft das Wissen, wie man so eine individuelle Softwarelösung überhaupt angehen und umsetzen könnte. Die reine Betrachtung unter technischen Aspekten, wie sie in den verfügbaren Tutorials vermittelt wird, ist in aller Regel nicht ausreichend, um eine individuelle Software so zu entwickeln, dass sie auch noch erweiterbar und wartbar bleibt. Es gilt also die fachlichen Anforderungen und die notwendigen technischen Skills für die Umsetzung so zusammenzuführen, dass allgemein anerkannte Standards und BestPractices berücksichtigt werden.
...

Das passt ja ziemlich gut auf deine Anfrage. Insofern freue ich mich wirklich, wenn ich dir ein paar Anregungen oder Hinweise geben kann, die dir bei deinem Vorhaben hilfreich sein können. In den nächsten Wochen plane ich so etwas wie eine wöchentliche Kolumne zu den verschieden Themenbereichen im Softwareentwicklungprozess wie z.B. fachliche Anforderungsanalyse, Festlegung des Datenmodel etc. aber auf zum Thema Programmierung, wobei ich da natürlich nicht jede Programmiersprache abdecken kann. Meine Beispiele und das von mir erwähnte ausgewählte Projekt "Versorgungsauskunftrechner" werde ich in der Programmiersprache Java implementieren.
Das ist eine objektorientierte Programmiersprache, für die sich im Internet tonnenweise gute Dokumentation und Tutorials findet.

Du kannst aber auch gerne direkt mit deinen Fragen auf mich zukommen. Wenn es eher allgemeine Fragen oder Anmerkungen sind, direkt als Antwort auf einen meiner Beiträge oder als "Persönliche Nachricht", wenn es sich um eine spezielle Frage zu deinem geplanten Projekt handelt.

Wenn du möchtest, kannst du für dein geplantes Projekt aber auch gerne ein eigenes Thema im Software-Forum des Bürgerportal neu anlegen. Evtl. interessiert diese Lösung ja auch noch weitere Leute, die etwas ähnliches suchen. Dann könnten wir gemeinsam versuchen, dein Projekt, neben dem "Versorgungsauskunft-Rechner", als Musterbeispiel für ein gemeinnütziges Software-Projekt zu nehmen. Die weiteren Überlegungen und Arbeitsschritte dazu würden wir dann ebenfalls im Bürgerportal dokumentieren.

Viele Grüße
Bernd

Bernd Malessa
Beiträge: 9
Registriert: 06.01.2020

Fachliche Anforderungsanalyse für das OpenSource Software-Tool "Versorgungsauskunft-Rechner"

Beitrag von Bernd Malessa »

Nachdem ich in der letzten Woche etwas über das allgemeine Vorgehensmodel in der Softwareentwicklung geschrieben habe, möchte ich heute langsam in die Projektarbeit für den "Versorgungsauskunft-Rechner" einsteigen und mich dem Thema "Fachliche Anforderungsanalyse" zuwenden.
Egal, nach welchem Vorgehensmodel wir vorgehen - das Wasserfall-Modell, ein Objektorientiertes Vorgehensmodell (z.B. Rational Unified Process) oder nach einem agilen Vorgehensmodell auf SCRUM-Basis. Bei allen fängt der Entwicklungsprozess mit der fachlichen Anforderungsanalyse an. Ich hatte ja schon im letzten Beitrag angedeutet, dass sich für unser geplantes Projekt eher ein leichtgewichtiger Prozess eignet und deshalb werden ich auch gar nicht erst versuchen eine 100% vollständige, konsistente und fehlerfreie Anforderungsanalyse durchzuführen. Außerdem fehlt dazu momentan auch der Gegenpart oder Auftraggeber, der dann für das Ergebnis dieser Anforderungsanalyse eine Art Abnahme durchführen könnte. Ziel ist es deshalb, hier den Umfang und die Grenze für das beabsichtigte Softwareprojekt festzulegen. Das hilft auch dabei, ein wenig Ordnung in unsere Gedanken zu bringen. Das sollte man generell nicht unterschätzen, wie wichtig es ist, seine Ideen für das beabsichtigte Projekt dann auch tatsächlich mal aufzuschreiben und nicht nur im Kopf mit diesen Ideen herum zu jonglieren. Vieles wird erst dann wirklich klar, wenn man sich zwingt diese Ideen, Anforderungen und Rahmenbedingungen aufzuschreiben und parallel dazu versucht, das ein oder andere UML-Diagramm zu erstellen.

Ziel der fachlichen Anforderungsanalyse ist es, die Anforderungen an das zu entwickelnde System zu ermitteln, zu strukturieren und zu prüfen.
Das Ergebnis einer Anforderungsanalyse wird dann meistens in einem Lastenheft dokumentiert. Bei einer agilen Softwareentwicklung, wie in unserem Projekt, ist das Ziel der Anforderungsanalyse die Erstellung eines Anforderungs-Backlog. Dabei kann es sich um funktionale, aber auch um nichtfunktionale Anforderungen handeln. Eine funktionale Anforderung wäre beispielsweise: das Tool soll in der Lage sein, den Ruhegehaltssatz und/oder den Versorgungsabschlag auf der Basis der eingegebenen Daten zu errechnen. Eine nichtfunktionale Anforderung könnte beispielsweise sein, dass dieses Tool über ein Web-Frontend im Browser zu bedienen sein soll.
Das Ziel der Anforderungsanalyse ist es also, eine Spezifikation als Grundlage für den anschließenden Systementwurf und die Realisierung der Software zu erstellen.

Wir können und sollten bereits auch in dieser frühen Phase des Entwicklungsprozess nichtfunktionale Anforderungen betrachten, aber wir beschäftigen uns hier noch nicht mit irgendwelchen technischen Restriktionen, z.B. der Frage, welche Datenbank, welche Programmiersprache oder welches Framework für die Implementierung einzusetzen ist. Die Beschreibung der fachlichen Anforderungsfälle erfolgt komplett frei von irgendwelchen technischen Restriktionen.

Wie werden nun die fachlichen Anforderungen ermittelt und welcher Input wird dafür benötigt?
Für den "Versorgungsauskunft-Rechner" ergeben sich viele Anforderungen in erster Linie aus den gesetzlich festgelegten Bestimmungen, die sich zum Beispiel im Beamtenversorgungsgesetz und im Bundesbeamtengesetz finden. Alleine mit dem Gesetzestext kommt man aber auch nicht weit, zumindest dann nicht, wenn man kein Jurist ist und/oder mit diesem Thema täglich zu tun hat. Wir benötigen noch weiteren Input in Form von Ausführungsbestimmungen, Beiträgen, Fachbüchern und anderer verfügbarer Dokumentation zu diesem Thema. Alles was wir dazu in die Hände bekommen und uns beim Verständnis für diese fachliche Domäne weiterhilft ist geeignet. Das können z.B. auch themenbezogene Foren im Internet (z.B. beamtentalk.de) sein oder Interviews/Unterhaltungen mit fachlich kompetenten Mitmenschen, die uns hier dabei helfen, diese Materie zu verstehen. Hilfreich ist auch die Einsicht in Versorgungsauskünfte, wie sie von der Bundesanstalt für Post- und Telekommunikation (BAnstPT) erstellt werden. Je mehr Infos und Einsicht in die Materie wir bekommen, umso konkreter und vollständiger können wir die Anforderungen an unser geplantes Softwareprogramm beschreiben und dokumentieren.

In den wenigsten Fällen ist man ja der erste, der die Idee hat, eine Softwarelösung für ein bestimmtes Problem zu erstellen.
Es lohnt sich daher auf jeden Fall auch, zunächst einmal zu recherchieren, was es denn bereits alles an verfügbaren Lösungen gibt. Eventuell existiert ja bereits eine Lösung die alle unsere Anforderungen erfüllt und wir können uns die Arbeit komplett ersparen. Für das von mir angedachte Tool habe ich mehrere kostenfreie Lösungen gefunden. Richtig zufrieden bin ich damit aber nicht. Meiner Meinung nach bilden alle vorhandenen kostenfreie Lösungen nur die einfachsten Sachverhalte ab. Es wird z.B. bei der Erfassung von ruhegehaltsfähigen Zeiten keine Unterscheidung dahingehend gemacht, ob die erfassten Zeiten generell als ruhegehaltsfähig anerkannt werden
müssen (z.B. § 6,8,9 BeamtVG) oder ob die eingegebenen Zeiten als SOLL-Zeiten (§ 10 BeamtVG) oder KANN-Zeiten (§12 BeamtVG) zu betrachten sind. Der Wechsel zwischen Teilzeit- und Vollzeitbeschäftigung wird bei der Erfassung der ruhegehaltsfähigen Zeiten ebenfalls meistens nicht unterstützt. Dasselbe gilt für Kindererziehungszeiten.

Hier sind mal die Links zu zwei kostenfreien Versorgungsauskunft-Rechnern, die ich im Internet gefunden habe:
  • n-heydorn.de/pensionsrechner.html
  • hilfreiche-tools.de/pensionsrechner
Es existieren natürlich auch professionelle Lösungen, an die wir mit unseren Möglichkeiten vermutlich nicht herankommen werden. Die Lizenzkosten für solche professionellen Programme dürften jedoch für die allermeisten Interessierten das Budget sprengen und insofern versuchen wir hier den Mittelweg zu finden. Wir möchten etwas Besseres bauen, als das was kostenfrei verfügbar ist, sind uns aber durchaus bewusst, das die Materie so komplex ist, das wir vermutlich nicht das Niveau und den Feature-Umfang einer hochpreisigen, professionellen Software erreichen werden.

Hier ist mal die Adresse für so eine kostenpflichtige Software:
  • ams-software.de/html/rgbausk.html


Bis jetzt war es ja noch ziemlich schwammig und wenig konkret. Jetzt werden wir aber konkreter und schreiben unsere fachliche Anforderungen an die zu erstellende Software auf:
  • Das Programm soll eine Versorgungsauskunft erstellen, aus der für den Anwender nachvollziehbar ersichtlich wird, wie diese Berechnung durchgeführt wurde.
    Dafür orientieren wir uns an den von der BAnstPT erstellten Versorgungsauskünften. D.h. wir möchte die Berechnung der folgenden Beträge bzw. Faktoren für
    den Anwender nachvollziehbar erstellen
    - Berechnung der Höhe des Ruhegehalt
    - Aufstellung und Berechnung der ruhegehaltsfähige Zeiten
    - Berechnung eines ggf. vorzunehmenden Versorgungsabschlag
    - Berechnung des ungekürzten Kindererzeihungszuschlag
    - ggf. durchtzuführende Vergleichsberechnungen bei Besitzstandsregelungen

  • Der Antragsteller einer Versorgungsauskunft soll die Möglichkeit haben, dem System die folgenden, für eine Versorgungsauskunft, erforderlichen Angaben zu übergeben:
    • Welche Art des Ruhestand wird beantragt (Ruhestand wg. gesetzlicher Altersgrenze, Antrags-Ruhestand, Engagierter Ruhestand, Vorruhestand (Altersteilzeit), Dienstunfähigkeit, Dienstunfall)
    • Datum der Begründung des Beamtenverhältnis
    • Datum des geplantes Eintritt in den Ruhestand
    • Anzuwendendes Recht (wir unterstützen zunächst nur Versorgungsauskünfte für Bundesbeamte; länder-, kommunal- oder sonstige körperschaftsspezifische Regelungen werden zunächst nicht berücksicht, können aber evtl. in einer Folgeversion unterstützt werden)
    • Welche Altersgrenze soll zur Anwendung kommen (Gesetzliche Altersgrenze oder eine besondere Altersgrenze)
    • Bestand das Beamtenverhältnis am 31.12.1991 und am 01.01.1992 (ggf. ist eine Vergleichsberechnung gem. §85 BeamtVG erforderlich)
    • Name und Vorname des Antragsteller (optional)
    • Geburtsdatum des Antragsteller
    • Ist ggf. eine Schwerbehinderung vorhanden und muss diese in der Versorgungsauskunft berücksichtigt werden?
    • Besoldungsdaten des Antragsteller: Laufbahngruppe, Besoldungsgruppe, Besoldungsstufe, Ruhegehaltsfähige Amtszulage, sonstige ruhegehaltsfähigen Zulagen
    • Art des Familienzuschlag
    • Die Auflistung aller für die Versorgungsauskunft relevanten ruhegehaltsfähigen Zeiten
      Davon eine Zeitperiode, die als Start-Datum das Datum der Begründung des BeaV (siehe oben) hat. Diese Zeitart muss nach $6 BeamtVG immer als ruhegehaltsfähig anerkannt werden.
      ggf (Wehr- oder Zivildienstzeiten (§8-9 BeamtVG)
      ggf. weiter Soll-Zeiten (§10)
      ggf. weiter Kann-Zeiten (§12)
    • Kindererziehungszeiten. Dabei muss unterschieden werden zwischen Kindererziehungszeiten für
      - Kinder, die vor dem 01.01.1992 geboren wurden und
      - Kindern, die nach dem 31.12.1991 geboren wurden
  • Unser geplantes Tool soll es ermöglichen, alle zulässigen Arten von ruhegehaltsfähige Zeitabschnitte zu erfassen. Dabei möchten wir diese Zeiten so konkret wie möglich unterscheiden, z.B. Zeiten im Beamtenverhältnis, Ausbildungszeiten, Zeiten im Vorbereitungsdienst, Wehrpflicht- oder Zivildienst etc. Grundsätzlich muss unterschieden werden können zwischen Zeiten, die grds. immer anzuerkennen sind und solchen Zeiten, die im BeamtVG als ruhegehaltsfähige Kann- oder Soll-Zeiten definiert sind.
    Die Zeitperioden haben ein Start und ein Enddatum. Die Anzahl der Tage in diesem Zeitraum soll vom Programm automatisch ermittelt werden. Da diese Zeiten nicht immer vollständig als ruhegehaltsfähig anerkannt werden (z.B. werden Studienzeiten nur bis zu einem bestimmten Umfang anerkannt), soll die Möglichkeit bestehen, die vom Programm berechnete Anzahl an ruhegehaltsfähigen Tagen manuell zu ändern. Teilzeitbeschäftigung innerhalb einer Zeitperiode soll über einer Faktor abgebildet werden. Per Default hat dieser Faktor für eine Vollzeitbeschäftigung den Wert 1,0. Bei Teilzeit von z.B. 50% der regulären Arbeitszeit soll die Möglichkeit bestehen diesen Faktor manuell auf 0,5 zu ändern. Es soll auch die Möglichkeit bereitgestellt werden, zu einer erfassten Zeitperiode einen Freitext zu erfassen, in dem detaillierter auf die Umstände eingegangen werden kann. Sofern diese Versorgungsauskunft dann später von einem fachkundigen Versorgungsservice geprüft wird, ist dies evtl. eine sehr hilfreiche Information.

    Die Liste der bisher bekannten relevanten ruhegehaltsfähigen Zeitarten findet sich in der folgenden Aufstellung:
    • Zeiten, die grds. als ruhegehaltsfähig anerkannt werden

      Beschäftigungszeiten im Dienst eines öffentlich-rechtlichen Dienstherrn im Beamtenverhältnis (§ 6 BeamtVG)
      Ausbildung im Vorbereitungsdienst (Beamter auf Widerruf)
      Wehrdienst- oder Zivildienstzeiten (§8 und §9 BeamtVG)
      Altersteilzeit (§ 93 BBG)
    • Sog. SOLL-Zeiten

      Zeiten im Angestelltenverhältnis im öffentlichen Dienst (§10 BeamtVG)
    • Sog. KANN-Zeiten

      Sonstige Zeiten (§ 11 BeamtVG)
      Vorgeschriebene oder Förderliche Ausbildungs- und Studienzeiten (§12 BeamtVG)
    • Sonderregelungen für Zeiten, die mit einem höheren Faktor anerkannt werden können

      Aufbauhilfe in den neuen Bundesländern
      Verwendung in Ländern mit gesundheitsschädlichem Klima (§ 13 BeamtVG)
  • Wir möchten in unserem Programm so viel wie möglich an Validierungen durchführen. Die User-Eingaben sollen auf korrekte Formate (z.B. gültiges Datumsformat, nummerische Werte etc.) geprüft werden. Es sollen aber auch alle erforderlicher fachlichen Validierungen durchgeführt werden. Es macht beispielsweise keinen Sinn eine Berechnung für eine Berechnung des Ruhegehalt wegen altersbedingten Eintritt in den Ruhestand zu berechnen, wenn der Antragsteller zu dem Zeitpunkt noch nicht die gesetzliche Altersgrenze erreicht hat. Daher müssen wir für jede Art des Ruhestand (Altersbedingter Ruhestand, Antrags-Ruhestand, Engagierter Ruhestand, Dienstunfähigkeit, Dienstunfall) die entsprechenden gesetzlichen Bestimmungen ermitteln und diese in unseren dokumentierten Anforderungen festhalten. Für jede Versorgungsauskunft muss eine ruhegehaltsfähige Zeitperiode erfasst werden, deren Start-Datum dem Datum der Begründung des Beamtenverhältnis entspricht.
  • Unsere geplante Software soll auch die Möglichkeit anbieten, die vom Anwender erfassten Daten zu speichern und diese Daten später erneut einzulesen. Damit hätten wir auf die Möglichkeit, diese Daten später noch einmal zu ändern oder von einer anderen Person überprüfen zu lassen.
  • Im Fall eines Ruhestand wegen Dienstunfähigkeit oder Dienstunfall soll die Zurechnungszeit gem. §13 BeamtVG berechnet werden.
  • Das System soll die Möglichkeit anbieten, die erstellte Versorgungsauskunft formatiert auszudrucken.
  • Wünschenswert wäre auch, in dem Programm kontextbezogenen Hilfetext anzuzeigen. Bei der Erfassung der ruhegehaltfähigen Zeiten könnte
    beispielsweise der entsprechende Gesetzestext oder andere kontextspezifische Erläuterungen angezeigt werden.
  • Das System soll zumindest 3 verschiedene User-Rollen unterscheiden können und ein Berechtigungskonzept für die Rollen Antragsteller, Administrator und Support-Mitarbeiter abbilden
  • Ein Anwender in die Rolle "Antragsteller" benötigt keine Authentifizierung am System. Diese Rolle kann die für die Versorgungsauskunft relevanten Daten im System erfassen und auf der Basis dieser Daten vom System eine Versorgungsauskunft errechnen lassen. Diese Versorgungsauskunft wird dem Antragsteller angezeigt und kann von ihm dann gespeichert und ausgedruckt werden.
  • Ein Anwender in der Rolle "Support-Mitarbeiter" benötigt eine Authentifizierung am System (Login mit UserId und Password). Diese Rolle hat dieselben Rechte wie die Rolle Antragsteller. Zusätzlich hat diese Rolle die Möglichkeit bereits erstellte Versorgungsauskünfte erneut einzulesen und zu bearbeiten. Zusätzlich kann diese Rolle erläuternden Freitext an den ruhegehaltsfähigen Zeiten der Versorgungsauskunft erfassen. Weiterhin soll die Möglichkeit bestehen, das Freitext direkt an der vom System generierten Versorgungsauskunft erfasst und gespeichert werden kann. Damit soll die Möglichkeiten geschaffen werden, solche Information, die sich nicht über einen Algorithmus errechnen lassen im Kontext der jeweiligen Versorgungsauskunft zu speichern.
  • Die Rolle Administrator benötigt ebenfalls eine Authentifizierung am System. Diese Rolle soll die Möglichkeit haben, die im System hinterlegten besoldungs- und versorgungsrelevanten Daten zu bearbeiten oder neu zu erfassen. Dazu gehören beispielsweise die zum Zeitpunkt des Ruhestandseintrittsdatum gültige Besoldungstabelle, aber auch andere Parameter, die sich regelmäßig ändern, z.B. der aktuelle Rentenwert, welcher für die Berechnung des Kindererziehungszuschlag benötigt wird.


Ebenso wichtig wie eine möglichst präzise Beschreibung der geplanten Geschäftsfälle, die vom System unterstützt werden sollen ist es, die Grenzen unserer geplanten Software festzulegen und dazu gehört auch zu dokumentieren, was in unserem Projekt "out of scope" ist. Da fallen mir spontan die folgenden Aspekte ein:
  • Keine Netto-Berechnung (ohne Steuer, Sozialabgaben), d.h. wir berechnen nur die Brutto-Versorgungsbezüge, Steuerklasse und Sozialabgaben etc. bleiben außen vor
  • Die Anrechnung von gesetzlichen Renten oder anderen Einkommensarten wird wir in unserem Programm ebenfalls nicht berücksichtigen. Dies würde die Komplexität enorm erhöhen. Kompetente Ansprechpartner könnten diese Anrechnungsberechnung dann außerhalb des Programms vornehmen. Wir werden in der vom System generierten Vorsorgungsauskunft aber einen entsprechenden Hinweis aufnehmen und anzeigen, dass weitere Einkommensarten ggf. zu einer Kürzung der Versorgungsbezüge führen können.
  • Wir beabsichtigen in unserer geplanten Software den Kindererziehungszuschlag zu berechnen. Aufgrund der Komplexität bei der Berechnung etwaiger Kürzungen des Kindererziehungszuschlag werden wir in unseren Versorgungsauskünften allerdings nur den generellen Hinweis aufnehmen, das der Kindererziehungszuschlag gekürzt oder komplett entfallen kann, wenn während der Kindererziehungszeit eine Voll- oder Teilzeitbeschäftigung vorgelegen hat oder wenn für diese Kindererziehungszeiten in der gesetzlichen Rentenversicherung Ansprüche vorhanden sind.

Nachdem wir alle funktionalen und nichtfunktionalen Anforderungen so präzise wie möglich aufgeschrieben haben, werden wir versuchen diese in Cluster zusammenzufassen und in unserem Projekt-Backlog aufzunehmen. Für diese Zwecke verwendet man entweder spezielle Programme (z.B. mal nach "Tool Anforderungsmanagement Requirements engeneering o.ä." googlen) oder findet seine eigene Organisation in Form von geeigneten Listen, Dokumenten, Ablagen etc.
In der Telekom-IT haben wir für das Anforderungs-Backlog die (kostenpflichtige) Software Programm "JIRA" verwendet. Damit hat man dann noch viel mehr Möglichkeiten die Anforderungen zu strukturieren.

An diesem Punkt kann man auch mal damit anfangen und versuchen, den Stand der fachlichen Anforderungsanalyse in Form von UML-Diagrammen abzubilden. Dafür eignen sich insbesondere UML UseCase- und Interaktions- bzw. Sequenz-Diagramme. Ich füge hier mal ein paar Beispiele für solche UML-Diagramme ein, welche die o.g. Ausführungen nochmal grafisch zusammenfassen. Die Diagramme wurden mit dem kostenfreien OpenSource-Tool ArgoUML (argouml.de.softonic.com) erstellt:

Übersicht über die im System bekannten bzw. unterstützten Aktoren und UseCases
download/file.php?mode=view&id=41

Detaillierte Sicht auf den UseCases "Versorgungsauskunft berechnen"
download/file.php?mode=view&id=42

Interaktionsdiagram "Erstellung einer Versorgungsauskunft"
download/file.php?mode=view&id=40

Im Endergebnis sollte die fachliche Anforderungsanalyse zumindest so weit durchgeführt werden, dass wir auf dieser Basis unseren ersten Softwareentwurf angehen können.
Wir sind uns jetzt darüber im klaren, dass wir sicher noch nicht 100% aller Anforderungen berücksichtigt haben, aber der grobe Rahmen ist jetzt klar. Wer die Liste der Anforderungen noch erweitern oder konkretisieren möchte ist gerne eingeladen entsprechende Vorschläge hier einzubringen.

Nächste Woche geht es dann weiter. Dann werden wir uns damit beschäftigen, wie unsere Entwicklungsumgebung aussehen soll. Welche Tools wir dafür benötigen und wie unserer erster technische Entwurf aussehen könnte. Evtl. macht es auf jetzt schon Sinn über einen GUI-Prototypen nachzudenken, um ein Verständnis dafür zu bekommen, wie die für die Berechnung der Versorgungsauskunft relevanten Daten vom Antragsteller dem System bereitgestellt werden.

Bernd Malessa
Beiträge: 9
Registriert: 06.01.2020

Aufbau der Entwicklungsumgebung für das Projekt "Versorgungsauskunft-Rechner"

Beitrag von Bernd Malessa »

Nachdem ich in der letzen Woche einen längeren Beitrag zum Thema "Fachliche Anforderungsanalyse" geschrieben habe, möchte ich diese Woche in die praktischen
Tätigkeiten der Projektarbeit überleiten. Letztlich besteht das Ziel eines jeden Softwareprojekts darin, eine lauffähige Software zu erstellen, die den Anforderungen der sie
nutzenden User erfüllt. Um eine Software zu erstellen, benötigen wir aber eine ganze Anzahl unterschiedlichster Tools, die ich heute mal kurz vorstellen möchte.

Die Welt der IT so vielfältig, dass es natürlich eine Rolle spielt, in welchem Kontext man das Projekt startet. Zum Beispiel, welche technischen Skills die am Projekt beteiligten Personen mitbringen oder welche Trends momentan gerade besonders angesagt sind. Je nachdem welche Art von Software erstellt werden soll, eignen sich bestimmte Technologien dafür besonders oder im Gegenteil überhaupt nicht und so weiter.

Da wir hier über Open-Source Software reden und wir keinen Auftragsgeber haben, der unsere Arbeit bezahlt und dessen Vorstellungen bzw. Vorgaben wir berücksichtigen müssen, sind wir glücklicherweise erst einmal frei in der Wahl unserer Mittel. Deshalb bin ich jetzt mal so frei und entscheide einzig und alleine aufgrund meiner persönlichen Präferenzen und auf der Basis meiner vorhandenen Skills, wie die Software-Entwicklungsumgebung für das geplante Projekt "Versorgungsauskunft-Rechner" aussehen soll.

Bei dem Vorhaben eine nicht triviale Software zu bauen, sind zunächst einmal die folgenden Fragen zu beantworten:

In welcher Programmiersprache wollen wir das Projekt umsetzen. Eignet sich eine Programmiersprache für unser Vorhaben besonders oder überhaupt nicht und welche Gründe können wir dafür anführen. Wenn wir uns für eine Programmiersprache entschieden haben, stellt sich die nächste Frage. Programmieren wir alles mit einem einfachen Editor und kompilieren unseren erstellten Sourcecode mit den Core-Utilities der jeweiligen Programmiersprache (z.B. mit dem Java-Compiler des Java Development Kit in einer DOS-Console oder Unix-Shell) oder nutzen wir dafür eine integrierte Entwicklungsumgebung (IDE) in der alle erforderliche Tools enthalten sind. Welche kostenfreien Tools existieren und wo bekommen wir die her? Wir benötigen für unsere erstellte Artefakte (Sourcecode, Dokumentationen etc) auch so etwas wie eine Versionskontrolle. Das dient uns zur Sicherung unseres Projektfortschritts und dazu im Fehlerfall auf einen lauffähigen Stand zurücksetzen zu können. Sobald mehrere Personen im Projekt mitarbeiten, wird eine gemeinsame Ablage für die im Projekt erstellten Artefakte benötigt. Für diesen Zweck ist es eigentlich immer zwingend notwendig, sich mit der Frage bzgl. der Versionskontrolle frühzeitig auseinander zu setzen. Wenn wir noch weitere Anforderungen für die Dokumentation oder Anforderungsanalyse haben, benötigen wir ggf. noch ein Tool zur UML-Modellierungs und evtl. auch noch ein Bildbearbeitungsprogramm, falls wir Bilder, Icons o.ä. grafische Elemente benötigen, die wir selber erstellen oder anpassen müssen.

Hier wäre mal die von mir präferierte Liste der Tools, die ich für die Umsetzung des Vorhaben "Versorgungsauskunft-Rechner" einsetzen möchte:

Programmiersprache: Java (eine aktuelle Version des Java Development Kit, mindestens jedoch JDK 8)
Entwicklungsumgebung : Eclipse IDE for Java Developers (mindestens Version: 2019-12 (4.14.0))
UML-Tool: Argo-UML
Bildbearbeitung: GIMP
Versionsverwaltung: Aktuelle GIT-Version (mindestens Version 2.9.0)

Was sind die Gründe für meine Entscheidung?

Einzig und alleine meine persönlichen Erfahrungen und Kenntnisse. Mit einer anderen Konstellation an "Tools und Toys" kann man sicher dasselbe Ziel erreichen, aber die Welt der IT ist so vielfältig, dass es unmöglich ist, sich in alle Facetten und Tools der Softwareentwicklung so einzuarbeiten und auszukennen, wie es manchmal wünschenswert wäre. Jeder erarbeitet sich mit der Zeit seinen eigenen Werkzeugkasten und kennt sich dann damit einigermaßen aus. Der Spruch "Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel." hat natürlich auch seine Berechtigung, aber irgendwann muss man ja auch mal anfangen und dann spricht aus meiner Sicht auch nichts dagegen, erst einmal mit dem anzufangen, was man zur Verfügung hat. Solange man für gute Argumente offen bleibt ist das ok. Genauso unsinnig wie der Gedanken, alles immer genau so zu tun, weil es schon immer so gemacht wurde, ist die Vorgehensweise immer das letzte "hippe Ding" zu nehmen, nur weil das jetzt in allen einschlägigen Internetforen und Fachzeitschriften gepusht und hochgelobt wird. Oft ist das letztlich auch nur "alter Wein in neuen Schläuchen". Was sich dann wirklich mal an neuen Ideen und Konzepten durchsetzt ist auch nicht immer sofort zu erkennen. Manchmal braucht man neben der immer hilfreichen Erfahrung auch etwas Glück, um bei seinen Entscheidungen - worauf konzentriere ich mich, wo arbeite ich mich intensiv ein, welche Tools verwende ich etc - auf das richtige Pferd zu setzen.

Es gibt ein paar Quellen, an denen man sich bei seiner Entscheidungen orientieren kann, wenn man z.B. vor der Frage steht, in welche Programmiersprache man seine Zeit und Energie investieren sollte, wenn man beabsichtigt eine neue Programmiersprache zu erlernen. Eine Quelle für Inspiration ist der TIOBE-Index (siehe auch https://de.wikipedia.org/wiki/TIOBE-Index). Dort bekommt man zumindest mal einen guten Anhaltspunkt, welche Programmiersprachen besonders relevant sind. Manche Sprachen eignen sich für bestimmte Anwendungsgebiete besser als andere. Die Anforderungen bei der Entwicklung von Web-Anwendungen, App-Entwicklung oder maschinennahe Softwareentwicklung von Gerätetreibern unterscheiden sich einfach deutlich voneinander und deshalb existieren eben auch unterschiedliche Programmiersprachen. Manche Sprachen haben eine extrem große Community, die mit kostenloser Dokumentation, Programmierbeispiele, YouTube-Videos etc. den Einstieg leichter machen. Andere Programmiersprachen sind extrem mächtig hinsichtlich ihres Feature-Umfang, sind aber auch extrem aufwändig zu erlernen und/oder nur für einen kleinen spezifischen Anwendungsbereich geeignet, mit entsprechend kleiner Community, die aushelfen kann, wenn's mal nicht weitergeht.

Ich möchte für die Entwicklung des geplanten "Versorgungsauskunft-Rechner" jedenfalls auf die o.g. Technologien und Tools zurückgreifen. Die Programmiersprache Java in einer halbwegs aktuellen Version (mindestens Java 8) und als Entwicklungsumgebung die Eclipse IDE. Beides ist als OpenSource kostenfrei verfügbar. Die Links zum Download füge ich hier mal ein:

Java: https://openjdk.java.net/
Eclipse: https://www.eclipse.org/downloads/

Eine leistungsfähige IDE ist schon alleine deshalb erforderlich, weil erst damit auch das Debugging und Refactoring ermöglicht wird. Die Entwicklung alleine mit einem Editor und mit den Command-Line-Tools des Java SDK ist vielleicht noch für einfaches Ausprobieren ausreichend, aber wenn das Projekt komplexer wird, dann verliert man da einfach zu schnell den Überblick.

Für das Thema UML-Modellierung habe ich im letzten Beitrag ja schon das Tool "Argo-UML" empfohlen.
Für die Bildbearbeitung eignet sich als kostenfreies Tool "GIMP".

Für die Versionsverwaltung möchte ich gerne GIT (https://git-scm.com/downloads) verwenden. Das ist ebenfalls OpenSource. Die Frage, ob wir die Versionsverwaltung lediglich auf dem eigenen, lokalen Rechner einsetzen oder dafür ein zentrales Repository anlegen, auf das alle Projektbeteiligte zugreifen können, lasse ich erstmal offen. Für die ersten Arbeiten kann man zunächst mit einer lokalen Lösung anfangen, auch um erste Erfahrungen im Umgang mit diesem Tool zu erlangen. Je weiter das Projekt fortschreitet, desto wichtiger wird es, dass alle Projektbeteiligten einen Zugriff auf den aktuellen Projektstand bekommen. Spätestens dann benötigen wir ein zentrales Repository für die Ablage unserer erstellten Software-Artefakte. Für die OpenSource-Projekte existieren im Internet kostenfreie Lösungen (z.B. Github) für die Versionsverwaltung und das Hosting von Softwareprojekten. Dazu dann später mal mehr in einem separaten Beitrag.

Auf der Basis dieser ausgewählten Tools und Technologien ist die nächste Aufgabe, die nun ansteht, die Entwicklung eines GUI-Prototypen. Aus den Ergebnissen der fachlichen Anforderungsanalyse und unter Zuhilfenahme der o.g. Tools sollte nun die nächste Aufgabe darin bestehen, einen GUI-Protoypen (GUI=Graphical User Interface) zu entwickeln. Sobald der fertig ist, hat man etwas vorliegen, an dem man sein Projekt anderen Interessierte gut vorstellen kann. Es macht schon ein Unterschied, ob man seine Ideen lediglich mit Textdokumenten oder Powerpoint-Folien einem Dritten vorstellt oder ob man ein Programm startet und anhand der graphischen Nutzerschnittstelle die verschiedenen UseCases demonstriert. Die Implementierung der Geschäftslogik wird in diesem GUI-Prototypen soweit wie möglich durch simulierte Werte oder Konstanten ersetzt. Wichtig ist, dem zukünftige Anwender mit diesem Prototypen die Ideen vorzustellen. Bereits hier gewinnt man im Feedback der zukünftigen Anwender wertvoller Erkenntnisse. Sofern erforderlich kann man diese neu gewonnenen Erkenntnisse dann noch in die weitere Projektplanung aufnehmen und das Anforderungsbacklog entsprechend erweitern. Vermutlich wird man bei der Entwicklung des GUI-Prototypen auch noch den einen oder anderen Mangel in seinen eigenen Annahmen aufdecken. Das ist auch völlig ok. Ich jedenfalls finde es sehr realistisch anzunehmen, dass man es nicht schaffen wird, in der vorangegangenen Anforderungsanalyse alle relevanten Aspekte aufzudecken und von Anfang an zu berücksichtigen. Das ist ja auch der Grund, warum heutzutage in der Softwareentwicklung, zumal in der OpenSource-Community", nicht mehr nach dem Wasserfall-Vorgehensmodel arbeitet, sondern weitgehend Methoden der "agilen Softwareentwicklung" einsetzt.

Das soll es dann für heute gewesen sein. Wer Vorschläge oder Ideen für den GUI-Prototypen hat, kann die gerne hier im Forum teilen. Meinetwegen auch handgefertigte Skizze, die mittels Foto in das Forum hochgeladen werden oder mir als persönliche Nachricht geschickt werden.

Bernd Malessa
Beiträge: 9
Registriert: 06.01.2020

GUI-Protoyp für den Versorgungsauskunft-Rechner

Beitrag von Bernd Malessa »

Heute möchte ich die ersten Ergebnisse des GUI-Prototypen für den "Versorgungsauskunft-Rechner" anhand einiger Screenshots zeigen. Bevor ich dazu komme, möchte ich aber noch einige Worte über die zugrunde liegende Technik verlieren.

Jede Programmiersprache bzw. Programmierumgebung bringt ihre eigene Technologie für die Realisierung eines Graphical User Interface (GUI) mit.
In der Programmiersprache Java verwendet man für die Implementierung von sogenannten Rich-Client-Anwendungen häufig das bereits im JDK (Java Development Kit) bzw. JRE (Java Runtime Environment) mit ausgelieferte SWING-Framework. Ganz ähnlich funktioniert das "Standard Widget Toolkit (SWT)". Dieses Framework wurde ursprünglich von der Firma IBM entwickelt und ist heutzutage ebenfalls als OpenSource-Software kostenfrei verfügbar. Die GUI der für unser Projekt ausgewählten Entwicklungsumgebung, die Eclipse IDE, wurde beispielsweise mit dem SWT-Framework implementiert. Im Prinzip funktionieren beide Frameworks (SWING und SWT) relativ ähnlich. Der Featureumfang des SWT-Framework ist etwas umfangreicher und die erstellte GUI sieht meiner Meinung nach auch besser aus. Beim SWING-Framework erkennt man irgendwie immer sofort, das dieses Programm in Java programmiert wurde. Das ist beim SWT-Framework anders. Die SWT-Widgets (z.b. Button, Eingabefelder, Listen, Tabellen etc.) nutzen für das Rendering die Grafikschnittstelle des Betriebssystem und die damit erstellte GUI ist somit nicht von anderen nativen Applikationen zu unterscheiden. Da dieses Framework in der Eclipse-IDE sehr gut unterstützt wird und dafür auch eine große Community existiert, die mit kostenfreien Tutorials Unterstützung beim Erlernen liefert sowie User-Foren, die bei der Fehlersuche Hilfestellung geben können, habe ich das SWT-Framework für die Implementierung des GUI-Prototypen verwendet.

Ein weiteres GUI-Framework in der Java-Welt ist das modernere JavaFX. Dieses Framework ist allerdings nicht Bestandteil des JDK bzw. JRE, sondern muss separat heruntergeladen und eingebunden werden. Da ich bisher noch keinerlei Erfahrung mit JavaFX gemacht habe, werde ich mich in diesem Projekt damit nicht weiter befassen.

Für unseren geplanten GUI-Protoypen möchte ich vorschlagen, dass wir die Implementierung als sog. Rich-Client-Anwendung durchführen werden. Rich-Client-Anwendungen werden im Gegensatz zu Web-Anwendungen auf dem Rechner installiert, auf dem das Programm später zur Ausführung gebracht wird. Web-Anwendungen haben natürlich den Vorteil, dass sie nur einmal an zentraler Stelle auf einem im Netz zugänglichen Server installiert werden müssen und Änderungen in Form von Updates oder Fehlerbehebungen direkt allen Nutzern zur Verfügung gestellt werden. Der Umfang der für die Erstellung von Web-Anwendungen notwendigen technischen Skills ist meiner Meinung nach aber deutlich umfangreicher. Neben Kenntnissen in HTML, CSS, Javascript und evtl. noch dem ein oder anderen Web-Framework, benötigen wir auch noch einen Web- bzw. Application-Server im Netz, der auch entsprechend administriert werden muss. Alles in allem ist es zumindest für den Start einfacher, wenn wir die Implementierung des "Versorgungsauskunft-Rechner" zumindest für die erste Version als Rich-Client-Anwendung planen und umsetzen. Sofern wir weitere Versionen des Tools planen, kommen wir ggf. nochmal auf die Implementierung als Web-Anwendung zurück. Für den späteren Anwender ist es natürlich schon wesentlich angenehmer, wenn er die Anwendung direkt im Browser aufrufen kann und nicht erst dafür Sorge tragen muss, dass er ein Java-SDK oder Java-JRE in der richtigen Version auf seinen Rechner installieren muss, damit er unsere Applikation nutzen kann. Wenn wir es richtig hinbekommen, sollten wir später größere Anteile der Geschäftslogik 1:1 aus der Rich-Client-Anwendung in die Web-Anwendung übernehmen können und insgeheim spiele ich dieses Thema gedanklich auch schon durch. Als Stichworte nenne ich mal RCP (Rich Client Platform) und RAP (Remote Application Platform). Wen es jetzt schon interessiert, der kann mal danach googlen. Das sind Technologien, aus dem Eclipse-Umfeld (unsere IDE, die wir im Projekt nutzen) mit denen es ermöglicht wird, mit mehr oder weniger Aufwand, Rich-Client-Anwendungen automatisch in Web-Anwendungen zu transformieren. Bis wir allerdings irgendwann evtl. mal dahin kommen, haben wir aber noch viel Arbeit vor uns.

Die GUI-Entwicklung ist meiner Meinung nach relativ aufwändig zu erlernen und wenn man im Projekt die Möglichkeit hat, bietet es sich an, sich zu spezialisieren. Manche Leute fühlen sich eher in der Frontend-Entwicklung zuhause, anderen wiederum sagt das überhaupt nicht zu. In kleineren Projekten mit wenigen Mitarbeitern gelingt das aber leider eher selten. Wenn im Projekt für die Implementierung der Software mehr unterschiedliche Skills benötigt werden, als Mitarbeiter vorhanden sind, dann wird schon klar, dass man sich in allen Bereichen zumindest ein wenig auskennen sollte.

Bis man sich mit den Möglichkeiten und Eigenarten des eingesetzten GUI-Frameworks einigermaßen auskennt, wird vermutlich jeder, der sich darauf einlässt, die ein oder andere frustrierende Erfahrung machen. Der Umgang mit Layout-Manager, das Event-Handling, die Implementierung von Event-Listenern zwecks sauberer Trennung von GUI und Applikationslogik sind nicht trivial und erfordern etwas Geduld beim Erlernen. Als Hilfe kann man zum Einstieg auch sog. GUI-Builder verwenden. Damit ist sog. Rapid-Prototyping möglich. Window- oder GUI-Builder sind spezielle Tools mit denen man sich seine gewünschte grafischen Oberflächen (Fenster, Dialoge, Menus, Tabellen, Buttons etc) zusammenklicken kann. Hört sich erstmal super an, aber auch hier wird man schnell feststellen, das man letztlich doch verstehen muss, was der GUI-Builder da so automatisiert erstellt hat. Meine Erfahrung ist, dass man spätestens dann, wenn man versucht sein eigenes Problem anzugehen, nicht darum herumkommt, sich mit den Untiefen der GUI-Entwicklung und der dazu verwendeten Frameworks zu beschäftigen. In den ersten Tutorials sieht alles immer super easy aus, aber spätestens beim ersten eigenen Versuch seine individuelle GUI zu bauen, wird man feststellen, dass es doch nicht so einfach ist. Und dann haben wir über ergonomische und barrierefreie grafische Benutzerschnittstellen noch gar nicht angefangen zu sprechen.

Soviel zur Einleitung. Meine bisher erstellten GUI-Elemente möchte ich jetzt mal kurz vorstellen. Ausgehend von den in der Anforderungsanalyse gesammelten Anforderungen, habe ich mir überlegt, wie die GUI aussehen könnte, um eine Versorgungsauskunft zu berechnen und anzuzeigen bzw. auszudrucken.
Dafür benötigen wir von Anwender verschiedene Eingaben, die für die Berechnung der Versorgungsauskunft zwingend erforderlich sind. Wenn der Anwender alle Daten erfasst hat, sollte zunächst eine Validierung dieser Daten vorgenommen werden. Sofern die Validierung erfolgreich durchgeführt wurde, wird die Versorgungsauskunft vom System errechnet und diese Berechnung dem Anwender am Bildschirm in einer formatierten Darstellung angezeigt. Diese formatierte Darstellung orientiert sich dabei an den von der Bundesanstalt für Post und Telekommunikation (BAnstPT) ausgestellten Versorgungsauskünften.

Mein GUI-Prototyp für den "Versorgungsauskunft-Rechner" sieht wie folgt aus. Der Antragsteller gibt die für die Versorgungsauskunft relevanten Daten in drei verschiedenen Eingabemasken ein. Dies ist deshalb erforderlich, um die GUI nicht zu überfrachten und die Daten einigermaßen übersichtlich zu strukturieren.

Für die Berechnung sind folgenden Daten relevant:

Die sog. Grunddaten umfassen u.a. die Angaben zur Art des angestrebten Ruhestand, das Datum des Beginn des Ruhestands sowie alle für die Versorgungsberechnung relevanten persönlichen Daten des Antragsteller. Diese Daten werden in der Eingabemaske "Grunddaten" erfasst. Wie dies aussehen könnte, sieht man im folgenden Screenshot.
Erfassung der Grunddaten für eine Versorgugnsauskunft
Erfassung der Grunddaten für eine Versorgugnsauskunft

das Tool unterstützt die Berechnung einer Versorgugnsauskunft für die folgenden "Arten des Ruhestand".
Erfassung_Grunddaten_2.PNG

Fehlerhafte Validierung von Eingabedaten wird wie folgt angezeigt:
Validierung.PNG
Validierung.PNG (10.46 KiB) 169 mal betrachtet


Die Zusammenstellung der "ruhegehaltfähigen Zeiten" erfolgt auf einer separaten Eingabemaske. Die einzelnen Zeiträume werden in einer Tabellenstruktur erfasst. Die Art der "ruhegehaltsfähigen Zeit" kann aus einer Auswahlliste ausgewählt werden. Durch Angabe eines Faktor kann Vollzeit oder Teilzeitbeschäftigung während einer Zeitperiode abgebildet werden. Die Anzahl, der in einer Zeitperiode enthaltenen Kalendertage wird vom System automatisch berechnet. Im Normalfall sollte die Anzahl der Kalendertage mit der Anzahl der "ruhegehaltsfähigen Tage" übereinstimmen. Allerdings ist es durchaus möglich, das nicht die komplette Anzahl der Kalendertage als ruhegehaltsfähige Zeit anerkannt wird. Deshalb muss es möglich sein, die Anzahl der "ruhegehaltsfähigen Tage" manuell zu überschrieben, z.B. weil Studienzeiten nur bis zu einem bestimmten Anteil als ruhegehaltsfähig anerkannt werden.
Erfassung der ruhegehaltsfähigen Zeiten
Erfassung der ruhegehaltsfähigen Zeiten
Auswahlliste der ruhegehaltsfähigen Zeiten
Auswahlliste der ruhegehaltsfähigen Zeiten
Die Versorgungsauskunft soll gemäß den in der Anforderungsanalyse gesammelten fachlichen Anforderungen auch den (ungekürzten) )Kindererziehungszuschlag berechnen können. Für diesen Zweck existiert eine weitere Eingabemaske, in welcher die Kindererziehungszeiten erfasst werden können. Bei der Berechnung des Kindererziehungszuschlags wird grds. zwischen Kindern, die vor dem 01.01.1992 geboren wurden und solchen Kindern, die nach dem 31.12.1991 geboren wurden unterschieden. Dies ist in der Eingabemaske entsprechend berücksichtigt.
Erfassung der Kindererziehungszeiten
Erfassung der Kindererziehungszeiten
Aus diesen 3 verschieden Datenblöcken (Grunddaten, Zusammenstellung der ruhegehaltsfähigen Zeiten, Zusammenstellung der Kindererziehungszeiten) kann nun die Versorgungsauskunft berechnet werden. Wie diese Versorgungsauskunft aussehen könnten, kann man sich auf den folgenden Screenshots anschauen.
Versorgungsauskunft_Anzeige_1.PNG
Versorgugnsauskunft_Anzeige_2.PNG
Versorgungsauskunft_Anzeige_3.PNG

Es wäre natürlich auch wünschenswert, wenn man die erfassten Daten speichern könnte, damit man diese Daten und die darauf basierende Berechnung zu einem späteren Zeitpunkt noch einmal überarbeiten kann oder evtl. auch von fachkundiger Seite überprüfen lassen könnte. Für diese Zwecke werden in der GUI entsprechende Menu-Punkte eingebunden, die das Speichern und das erneute Einlesen vorher gespeicherter Daten ermöglicht.
Menupunkte zum Speichern und erneuten Einlesen der erfassten Daten
Menupunkte zum Speichern und erneuten Einlesen der erfassten Daten

Abschließend, sozusagen als Sahnehäubchen, wäre noch das Ausdruck der errechneten Versorgungsauskunft bzw. das Speichern in einer PDF-Datei wünschenswert. Idealerweise sollte die in der GUI angezeigte formatierte Versorgungsauskunft 1:1 als PDF-Datei abgespeichert werden können, um dann im Anschluss das PDF-Dokument auszudrucken.

Ich hoffe die eingebundenen Screenshots bringen die Idee rüber, die ich in diesem Projekt umsetzen möchte. Falls noch Verbesserungsvorschläge vorhanden sind, können diese gerne hier im Forum vorgetragen und diskutiert werden. Die nächsten Schritte werden jetzt wie folgt angegangen.

Der GUI-Prototyp wird jetzt Stück für Stück weiter ausgebaut und verfeinert. Ziel ist es, die im Prototyp investierte Arbeit soweit wie möglich zu nutzen und darauf aufbauend die endgültige Lösung zu entwickeln. Parallel dazu müssen wir uns dann auch langsam an die Entwicklung des sog. Anwendungskern heranwagen. Wenn wir nicht in unwartbaren "Spagetticode" landen wollen, dann ist dies die vielleicht anspruchsvollste Aufgabe. Durch die Bildung von fachlichen und technischen Softwarekomponenten und mit den Werkzeugen, die uns die objektorientierten Programmierung in der Programmiersprache Java liefert, werden wir versuchen eine saubere Trennung von fachlichen und technischen Aspekten in unserer geplanten Anwendung zu erreichen. Der sog. Anwendungskern sollte so weit es geht frei von technischen Restriktionen sein und möglichst durch sog. UnitTests automatisiert getestet werden können. Diese UnitTests werden dann eine große Hilfe sein, wenn wir im weiteren Projektfortschritt unsere Anwendung ausbauen und durch Refactoring-Massnahmen evtl. unseren bereits fertiggestellten Programmcode ändern oder umstrukturieren müssen. Durch die Testfälle habe wir dann jederzeit die Möglichkeit, die Lauffähigkeit und Funktionalität unserer Software sicherzustellen.

Das ist dann aber wieder ein neues Thema und wird dann in einem separaten Beitrag besprochen.

Bernd Malessa
Beiträge: 9
Registriert: 06.01.2020

Audruck der Versorgungsauskunft

Beitrag von Bernd Malessa »

In der fachlichen Anforderungsanalyse für das Projekt "Versorgungsauskunft-Rechner" wurde seinerzeit der UseCase aufgenommen, dass die Möglichkeit bestehen soll, die vom System errechnete Versorgungsauskunft ausdrucken zu können. Da die Versorgungsauskunft bereits im GUI-Prototypen (siehe letzter Beitrag) angezeigt werden kann, wäre es natürlich naheliegend, den Aufbau und die Formatierung aus der GUI für den Ausdruck zu übernehmen. An diese Aufgabe habe ich mich in den letzten Tagen herangewagt und es hat einigen Aufwand gekostet, dieses Problem zu lösen.

Wie bin ich bei der Implementierung des UseCase vorgegangen?
Der GUI-Prototyp wurde mit Hilfe des SWT-Framework erstellt und in diesem Framework existiert eine GUI-Komponente "StyledText". Diese Komponente ermöglicht es, einen formatierten Text zu erstellen und in der GUI zur Anzeige zu bringen. Die entsprechenden Screenshots habe ich ja im letzten Beitrag eingebunden. Neben der Formatierung mit unterschiedlichen Schriftgrößen, Schriftarten, Farben usw. besteht auch die Möglichkeit Grafiken in den Text einzubinden. Diese Feature habe ich genutzt, um im Header das Logo des "Prot-In-Support e.V." anzuzeigen. Ein kleines bisschen Eigenwerbung sozusagen, falls das Tool sich irgendwann mal doch als nützlich erweisen sollte. Die Komponente "StyledText" ermöglicht es bereits "out-of-the-box", den Text an einen Drucker weiterzuleiten und entsprechend auszudrucken. Also genau das, was wir für unsere Zwecke benötigen.

Die Idee war also, die vom System errechnete und formatiert in der GUI angezeigte Versorgungsauskunft auszudrucken. Noch besser als der direkte Ausdruck über einen Drucker wäre allerdings, diesen Druck in ein PDF-Dokument umzuleiten. Dieses PDF-Dokumente könnte dann bei Bedarf ausgedruckt werden oder aber als Anhang in einer Mail verschickt werden. Jedenfalls wäre ein Druck in eine PDF-Datei wesentlich flexibler für die verschiedensten Anwendungsszenarien. Im Prinzip ist das auch gar nicht so schwierig. Für die verschiedenen Betriebssysteme existieren Druckertreiber, die genau diese Funktionalität bereitstellen. Ich verwende als Betriebssystem "Window 10" und dafür existiert der Druckertreiber "Microsoft Print to PDF". Bin mir nicht mehr ganz sicher, ob dieser Druckertreiber bereits Bestandteil der Grundinstallation von "Windows 10" ist oder ob man das nachinstallieren muss. Jedenfalls ist dieser Druckertreiber kostenfrei. Für andere Betriebssystem wird es ähnliche Lösungen geben.
Druckertreiber Pint2PDF
Druckertreiber Pint2PDF
Das hörte sich erstmal sehr verlockend an. Einerseits liefert das GUI-Framework schon die Möglichkeit den in der GUI angezeigten Text auszudrucken. Zusätzlich existiert ein Druckertreiber, der es ermöglicht, den Ausdruck in ein PDF-Dokument umzuleiten. Leider war es dann doch nicht ganz so einfach. Aber jetzt erstmal der Reihe nach.
Der erste Versuch zeigte schnell welche Probleme gelöst werden mussten, um das gewünschte Ergebnis zu erreichen. Das Ausdruck ein PDF-Dokument war, so wie ich es erwartet hatte, grundsätzlich möglich. Allerdings ging die Formatierung im PDF-Ausdruck komplett verloren. Die Ursache dafür war, das für das Rendering in der GUI bzw. auf dem Bildschirm andere Rechnungseinheiten verwendet werden als beim Drucken. Das Zeichnen der Anzeigen auf dem Bildschirm basiert auf der Bildschirmauflösung in Pixeln, während beim Drucker die sog. DPI-Auflösung (dots per inch) zur Anwendung kommt. Die Schriftgrößen, Schriftarten und Schriftfarben wurden vom SWT-Framework zwar direkt richtig umgerechnet und sahen im PDF-Dokument schon brauchbar aus, aber die für die Formatierung verwendeten Tabstops in der GUI passten für den Druck überhaupt nicht mehr. Im Gegensatz zur Anzeige der Versorgungsauskunft in der GUI müssen wir uns beim Drucken auch überlegen, an welchen Stellen wir einen Seitenumbruch haben möchten, damit das Ganze nachher noch einigermaßen ordentlich aussieht. Außerdem wurde die Header-Grafik mit dem Prot-In-Support Logo nicht in den PDF Ausdruck übernommen. Hier sind einige Screenshots die zeigen, wie das erste Ergebnis des Druck aussah.

PDF ohne Header-Grafik
PDF ohne Headergrafik
PDF ohne Headergrafik
PDF mit Seitenumbruch an der falschen Stelle
PDF ohne richtigen Seitenumbruch
PDF ohne richtigen Seitenumbruch
PDF mit falscher Formatierung aufgrund der Länge der verwendeten Tabstops
PDF mit falscher Formatierung der Tabstops
PDF mit falscher Formatierung der Tabstops
Das Problem mit der unterschiedlichen Auflösung im Display und im Drucker und den unterschiedlichen Masseinheiten für die Tabstops lies sich relativ leicht lösen.
Das entsprechende Stück Software im GUI-Prototypen wurde von mir so umgeschrieben, dass die Versorgungsauskunft vor dem Ausdruck nochmal neu formatiert wird, damit die Formatierung auch für den PDF-Ausdruck passt. Bis da wieder alles ordentlich aussah, war einiges and "Trial and Error" Versuchen nötig, aber letzlich war es reine Fleißarbeit. Richtig aufwändig wurde es dann aber bei der Übernahme der Header-Grafik in den PDF-Ausdruck und den Seitenumbrüchen im PDF-Dokument an den passenden Stellen. Nach sehr vielen Versuchen und viel Analyse wurde es irgendwann klar, das diese Features in der verwendeten GUI-Komponente (StyledText) des SWT-Frameworks überhaupt nicht unterstützt werden. Das bedeutete, dass Druck so wie geplant nicht funktionieren konnte. Also entweder auf die Grafik und erzwungenen Seitenumbrüche im Ausdruck verzichten oder alles selber neu implementieren oder evtl. ein anderes Framework verwenden. Alles selber neu zu implementieren schied als Alternative sofort aus. Das Berechnen für das Rendering ist wirklich sehr komplex. Man muss quasi jeden einzelnen Druckpunkt irgendwie berechnen und dann auch noch die entsprechenden Rahmenbedingungen wie Schriftgrößen, Zeilenvorschub, Seitenumbruch berücksichtigen. Ich kann sowas nicht bzw. ich traue mir in der zur Verfügung stehenden Zeit nicht zu, das Drucken bis in das letzte Detail selber zu implementieren. Eine andere Alternative wäre die Verwendung eines anderen Frameworks für die Konvertierung in ein PDF-Dokument. Das OpenSource-Framework "The Apache FOP Project"(https://xmlgraphics.apache.org/fop/) existiert genau für diese Zwecke. Allerdings würde dies auch erst einmal eine intensive Einarbeitung in dieses neue Framework erfordern. Die letzte Alternative wäre die existierende SWT-Komponente "StyledText" so zu erweitern, das die Header-Grafik in den Ausdruck übernommen wird und das Seitenumbrüche an den gewünschten Textstellen erzwungen werden können. Das SWT-Framework ist ja ebenfalls OpenSource und grundsätzlich kann man daran natürlich auch Erweiterungen vornehmen. Allerdings ist das dann doch auch aufwändiger, weil man dann nicht mehr nur das Public-API der Komponente kennen muss, sondern auch die dahinter liegende Implementierung verstehen muss.

Letztlich habe ich mich auf mein Bauchgefühl verlassen und mich gegen den Schwenk auf das "Apache FOP - Framework" entschieden. Stattdessen habe ich mir die Sourcen des SWT-Framework besorgt und durch relativ aufwändiges Debuggen herausgefunden, welche Stellen ich erweitern muss, um die Grafik aus der Anzeige im Display in den Ausdruck zu übernehmen und Seitenumbrüche den den gewünschten Textstellen zu erzwingen. Für so ein relativ kleines Feature war das natürlich ein enorm hoher Aufwand. Insgesamt habe ich dann diesen beiden Features einige Tage Aufwand investiert, aber dabei habe ich auch sehr viel Neues gelernt und darauf kommt es letztlich ja auch an. Hin und wieder kommt man immer mal wieder an so einen Showstopper und dann muss man entscheiden, wie man weiter vorgeht. Wenn man Terminstress hat, könnte man natürlich auch zur Entscheidung gelangen, dass man das Feature, welches zum Showstopper führt erstmal außen vor lässt. Für dieses Projekt habe ich aber bereits in der Projektbeschreibung erwähnt, dass in diesem Projekt der Weg das Ziel sein soll und deshalb nehmen wir uns auch die Zeit, solche Probleme zu lösen und nicht einfach zu ignorieren. Außerdem ist es für die eigene Motivation auch eine schöne Bestätigung, wenn man schlussendlich doch noch zum gewünschten Ergebnis kommt.

Jedenfalls bin ich jetzt mit dem Druck in ein PDF-Dokument doch einigermaßen zufrieden. Ich habe ich noch ein paar Screenshots angefertigt, die zeigen, wie die Versorgungsauskunft jetzt nach dem Ausdruck in einem PDF-Dokument aussieht. Das dazugehörige PDF-Dokument habe ich ebenfalls als Anlage beigefügt. Wie man im PDF-Dokument erkennen kann, sind an einigen Stellen noch fehlerhafte Formatierungen vorhanden, aber das ist jetzt nur noch Kleinkram und wird in den nächsten Tagen noch bereinigt.


PDF jetzt mit Header-Grafik
PDF mit Header-Grafik
PDF mit Header-Grafik
Seitenumbruch jetzt an der passende Stelle
PDF mit Seitenumbruch
PDF mit Seitenumbruch
Formatierung jetzt mit passenden Tabstops
PDF mit passenden Tabstops
PDF mit passenden Tabstops

PDF-Dokument
mustermann.pdf
(178.21 KiB) 3-mal heruntergeladen

Antworten