Anleitung zur Erstellung von Open-Source Software

Programme, Applikationen, Anwendungen. Was tun, wenn die App spinnt?
Antworten
Bernd Malessa
Beiträge: 6
Registriert: Montag 6. Januar 2020, 18:18

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: 6
Registriert: Montag 6. Januar 2020, 18:18

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: Mittwoch 20. September 2017, 07:32

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: 6
Registriert: Montag 6. Januar 2020, 18:18

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: 6
Registriert: Montag 6. Januar 2020, 18:18

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.

Antworten