Soll-Konzept unterschied zum System- und Programmentwurf

[Ente19]

Ich habe in meiner Dokumentation Inhaltspunkte wie Ist-Analyse und Soll-Konzept. Da aber Entscheidungen anderer Abteilungen eine Rolle bei der Umsetzung spielten und das ein komplexeres System ist habe ich mir den Punkt System- und Programmentwurf noch vorgestellt.

Ich dachte unter dem Punkt schreibe ich warum es besser ist oder notwendig ist diese Programmiersprache zu verwenden und warum die Anwendung aufgesplittet werden mußte. Diese Entscheidungen waren aus Sicherheitgründen von aneren Abteilungen empfohlen worden.

Nun bin ich aber mit dem Soll-Konzept dran und weiß ncith sorecht was ich da schreiben soll, wenn ich die meisten Sachen beim System- und Programmentwurf schreibe. Ich laufe gefahr redundante Daten zu bekommen. Projektziel und System- und Programmentwurf werden zum grlßten Teil identisch mit dem Soll-Konzept sein.

Kann mir vielleicht jemand sagen wo ich da die Unterscheidung machen muss oder ob ich den System- und Prgrammentwurf einfach in das Soll-Konzept mit schreiben soll.

Ich danke...

[just_me]

1. Grenze dein System ab

Deine Projektdokumentation bezieht sich ausschließlich auf deine Arbeit. Die Schnittstellen zu den anderen Abteilungen/Modulen/Projekten sind zwar implizit, mehr aber nicht.

Begründungen zur Programmiersprache und Abgrenzungskriterien zu nebenläufigen Projekten sind Bestandteil der Planung.

2. Der SOLL-Part beschreibt keine Details.

Schildere hier die wesentlichen Anforderungen und Bedingungen.

(Diese Informationen sind mit Blick auf das Lastenheft (und partiell auch Pflichtenheft) redundant, häufige Querverweise sind daher angebracht.)

3. Der Entwurf ist detailliert.

Hier führst du Details zu den unter Punkt 2 genannten Anforderungen und Bedingungen aus.

(Diese Informationen sind mit Blick auf das Pflichtenheft redundant, häufige Querverweise sind daher angebracht.)

ich bitte ...

[Ente19]

Sorry wenn ich das nochmal ein bisschen genauer brauche...

zu 1) das ganze System ist zwar komplex um zu erläutern warum so und nicht anders, aber es ist alles mein Projekt. Alle Teilaufgaben in der Entwicklung und Planung sind von mir durchgeführt worden. Ausnahmen sind hier ein paar Vorgaben aus Sicherheitstechnischen Sichten die unsere Technik vorgeschrieben hat.

zu 2) komme ich hier nicht schon auf redundante Daten wenn ich in der Beschreibung des Projektes die Ziele beschrieben habe?

zu 3) kannst du hier vielleicht ein Beispiel für dumme geben, die Abgrenzung der einzelnen Punkte fällt mir wirklich sehr schwer... vielleicht sitze ich da heute schon zu lange vor

ich danke danke...

[just_me]

Verstehe ich dich richtig, wenn ich folgendes behaupte:

- du hast ein hochkomplexes System

- dieses hast du in weniger als 70 respektive 35 Stunden entwickelt

- es ist so komplex, dass es nicht möglich ist, dieses darzustellen

- es existiert real

... bist du mit Einstein verwandt?

Gleichgültig wie komplex dein System ist, es lässt sich IMMER detailiert und sauber beschreiben.

Da du ja im Vorfeld bereits ein - wahrscheinlich sehr umfangreiches - Pflichtenheft geschrieben hast, in dem du jeden einzelnen Faktor berücksichtigtest, sollte es dir eigentlich nicht wirklich schwerfallen, eine "lockere" Zusammenfassung zu schreiben.

Machen wir mal gemeinsam ein Beispiel ...

Stelle dir vor, du wolltest ein Auto bauen.

Du begründest also ein neues Projekt, welches sich das Auto zum ZIEL erhebt.

Zunächst einmal hältst du in einer Wunschliste alles fest, was das Auto können SOLL, DARF, und KEINESFALLS SOLL.

Nehmen wir an, es SOLL Blinken, DARF über 100 km/h fahren, und SOLL KEINESFALLS Fliegen können.

Nun setzt du dich in eine stille Ecke und reflektierst, wie du das erreichen kannst. Wahrscheinlich wird dir einfallen, dass du verschiedene Details brauchst, um das realisieren zu können.

Also machst du einen Entwurf, in dem du all die Details fein säuberlich aufmalst, benennst, ausrechnest, beschreibst, schilderst, ...

Wenn du hier Dinge verwendest, beispielsweise die Hupe eines anderen Herstellers, dann hältst du auch diesen Punkt eindeutig fest.

Im Laufe deiner Arbeit fällt dir auch ein (oder auf), was und wie du testen kannst, um die gewünschte Funktionalität sicherstellen zu können.

So entsteht nach und nach die Bastelanleitung für das Auto.

Wenn das getan ist, brauchst du nur noch das Ding zu bauen, zu testen, das Handbuch in das Handschuhfach legen, und schlussendlich zum Händler/Kunden zu bringen.

Wie du siehst, steht all das also bereits im Lastenheft respektive im Pflichtenheft. Und was dort redundant sein soll, kann ich nicht erkennen.

Deine Projektdokumentation gibt dem Gutachter (Chef, Prüfer, Projektleiter, etc.) lediglich einen Gesamtüberblick aus der Perspektive: "Was hat der Bursche eigentlich in den letzten ein (oder zwei) Wochen getrieben? Was hat er für die Unsummen an Gehalt, die ich ihm jeden Monat in den Rachen werfen muss, an Gegenleistungen erbracht?"

Es ist also nicht mehr besonders sinnvoll, dem Gutachter Dinge zu erzählen, die ihn a) nicht oder nur am Rande interessieren und die er - Interesse vorausgesetzt - an anderer Stelle (Archiv, Anhang, etc.) nachlesen kann.

Natürlich ist es notwendig, zu sagen, dass so und nicht anders, aber die Begründungen stehen bereits im Pflichtenheft, so dass du diese nur heranziehen und in aller gebotenen Kürze schildern musst.

Woran du im Moment sicher hängst, ist ganz einfach zu klären:

Jedes Dokument wird mit einem anderen Ziel erstellt. Daher sind die Informationen insbesondere in der SOLL-Anforderung, den ZIELEN, etc. abstrakt durchaus redundant. Das relativiert sich aber, weil du es jedesmal aus einer anderen Perspektive beschreibst.

Beispiel: (Achtung: Nur symbolisch!)

Lastenheft: (Allgemeine Schilderung des WAS aus der Sicht des Kunden.)

Ich will ein Auto, das Blinken kann. Es wäre schön, wenn es auch mindestens 100 km/h fahren kann, muss es aber nicht. Oh, und fliegen will ich damit nicht.

Pflichtenheft: (detaillierte Schilderung des WAS aus der Sicht der Techniker.)

Das Auto muss Blinken können. Um das realisieren zu können, brauchen wir eine Lampe, 10 m Kabel, eine Energiequelle, und und und ...

Projektdokumentation: (Beschreibung des WIE aus der Sicht der Projektinvolvierten.)

Wie man dem Pflichtenheft entnehmen kann, musste das Blinken umgesetzt werden. Dazu habe ich die dort dokumentierten Teile so verbaut, dass ich ...

ich bitte bitte...

[Ente19]

mensch, jetzt habe ich ja ein richtig schlechtes gewissen Dich zu so einer riesen Antwort getrieben zu haben....

Aber ich muss sagen sie war sehr gut. Ich denke ich habe es geschnackelt... und... Einstein... wer ist das?

Das System in welches meine Anwendung hineingestrickt wird ist sehr komplex und vielleicht nicht einfach zu verstehen. So habe ich es schwer dabei verständnis für das Projekt und was genau es tut zu vermitteln. Ist halt ein bisschen schwer darzulegen was für Informationen ich von wo habe, den Prüfern zu vermitteln das ich nicht alle Entscheidungne alleine getroffen habe (was ja muss ist darauf hinzuweisen) und gleichzeitig eine lockere verständliche Info zu über den Ablauf zu geben.

Aber ich glaube du hast mich da auf einen sehr guten Weg und einige doch gute Ansätze gebracht. Ich danke Dir wirklich sehr!