nicht schon alle einmal gewünscht das wir ein Programm wie eine Schraube am Fließband erstellen könnten? Falls wir uns dafür eine Spezifikations- und Entwicklungsumgebung wünschen könnten - wie würde diese aussehen?
erstes bräuchten wir eine Sprache in der wir die Anforderungen verbal in Sätzen beschreiben können. Aber was würden wir in der Sprache beschreiben? Es gäbe: • Eine Liste von Systemen (das zu Spezifizierende und Fremdsysteme mit denen interagiert wird). • Eine Liste an Zielen des Programmsystems. • Eine Liste an Stakeholdern. • Eine Liste an Anforderungen mit einem schematischen Satzbau wie beispielsweise beim Sophist Konzept. • Ein Glossar für Begriffe. • Ein Glossar für Prozesse und Prozesswörter, nebst Synonymen. Damit ließe sich das klassische Lastenheft darstellen. Eine Lösung versucht das Projekt "rassi":https://github.com/funthomas424242/rassi bereitzustellen.
fachlichen Anforderungen müssten wir User Stories formulieren. Eine User Story besteht aus: • Verbale Story Formulierung. • Liste von Commitments. • Notizen zur Conversation mit dem fachlichen Entscheider (meist Product Owner). Durch eine Zuordnung mehrerer User Stories zu einer Anforderung kann geprüft werden ob die Anforderung von den zugeordneten User Stories vollständig abgedeckt wird. Sprachen zur Beschreibung von User Stories sind im Bereich BDD (Verhaltensgetriebene Softwareentwicklung) zu finden. In der Regel erfolgt die Beschreibung in der Sprache Gherkin welche eine Aufteilung in Gegeben, Wenn und Dann Bereiche vornimmt. Außerdem werden diese UserStories gleich mit dem JUnit Framework verbunden. Beim konkreten Einsatz ist zu überlegen, wie die Commitments und die Conversation in der Sprache bedient werden können. • Gherkin: NatSpec, JNario, JBehave, NBehave, Cucumber, SpecFlow, SubSpec, ... • Others: NatSpec, ...
wird davon ausgegangen, dass alle UserStories zusammenn letzlich die gesamte fachliche Funktionalität vollständig beschreiben. Sollte etwas fehlen, wird ein Fehler vom Test gemeldet werden. Dann muss nachspezifiziert werden und es gibt eine neue UserStory - irgendwann ist das System vollständig beschrieben. Letztlich werden die Userstories fachliche Workflows beschreiben. Die Programmmodule werden aber kleinere Einheiten bilden und allein keine UserStory abdecken. Daher sind weitere Moduttests mit JUnit notwendig. Beim Modultest soll auch fachliches Verhalten getestet werden aber auf viel niedrigerem Niveau. So kann die fachliche Forderung eine sortierte Adressliste sein. Ein Modul könnte die Implementierung der Liste oder des Comperators sein. Auch dann kann fachliches Verhalten getestet werden aber das fachliche Verhalten entspringt nun der technischen Domäne und gehört damit nicht ins Lastenheft.
ist und die Modultests bereitstehen, müssen Letztere noch vom Status rot in den Status grün wechseln :) Das gelingt nur durch eine korrekte Implementierung. Gehen wir im Rahmen der Automatisierung von einem modellgetriebenen Ansatz aus so müssen wir jetzt das technische Modell erstellen. Was würden wir in unserem technischen Modell beschreiben? • Wir würden die Oberfläche beschreiben z.B. durch JavaFXScript, Thinlet, GUI4J, ... • Wir würden die Datenbank beschreiben z.B. durch HEDL in Verbindung mit Liquibase oder Flyway • Wir würden die Programmsteuerung und -logik beschreiben z.B. mit einer formalen Sprache für Flow Design
erreicht? Gelöste Probleme • Wir hätten eine fachliche Spezifikation die sogar die Ansprechpartner im Fachbereich verstehen ;) • Wir hätten User Stories mit denen wir einen agilen und damit iterativen Entwicklungsansatz unterstützen mit samt zugehöriger Vorteile. • Wir hätten die Commitments der User Stories als formale Akzeptanztests realisiert. • Wir hätten eine Testgetriebene Entwicklung. • Wir hätten eine modellgetriebene Entwicklung (technisches Modell). • Wir hätten einen sehr hohen Automatisierungsgrad durch die technische Modellierung mit anschließender Generierung erreicht. • Wir hätten alle User Stories mit zugehöriger Conversation dokumentiert. Weiter bestehende Probleme • Wir müssten weithin bestimmte Teile im Quellkode manuell implementieren. • Wir werden nur bestimmte Anwendungstypen mit diesem Ansatz erstellen können, die anderen Typen benötigen andere Lösungen. • Wir können die formale Korrektheit der erstellten Programme weiterhin nicht beweisen - schon allein wegen dem nicht zu erbringenden Beweis der Terminiertheit.
huluvu424242
satoshi256kbyte
rkaga
hollycummins
drumath2237
deka_morita
gam0022
irinanazarova
iwatsukayura
dske104
minodriven
ichirokano2
optim
tammyeverts
aleyda
bluesmoon
reverentgeek
nonsquared
trallard
inesmontani
charlesmeaden
rmw
madoxten
stephaniewalter
