Hallo, ich habe das Problem das ich eine Spezifikation fuer Software schreiben muss. Jedoch erschlagen mich einfach die kombinatorischen Moeglichkeiten. Das Geraet ist ein Jump Starter fuer Autos und hat ein LCD Display. Fangen wie mal mit den Benutzer und den aeusseren Inputs an... Er kann 5 verschiedene Buttons druecken (ON, Light, Test, 12V, 24V) - 5 Zustaende - ein Button zu einer Zeit) . Das Geraet wird an eine Autobatterie angeschlossen (2 Zustaende - angeschlossen / nicht angeschlossen), es kann geladen werden (2 Zustaende) und es kann externe Geraete (Handy, Tablet) laden (2 Zustaende). Die Spannung der angeschlossene Autobatterie wird gemessen und dort haben wir 6 verschiedene Zustaende. Im Inneren ist eine LiFEPO4 Batterie die abhaengig von der Batteriespannung und Batterietemperatur verschiedene Dinge erlaubt bzw. nicht erlaubt. Zum Beispiel kann die Batterie zwischen -20 und 60 Grad und 14.6 und 12.95V das Auto starten, aber nur zwischen 0 und 45 Grad geladen werden. 30 Zustaende). Wie entwickelt man fuer soetwas Software bzw ein Zustandsdiagram? Ich sitze hier mit Visio und Excel aber irgendwie ist das alles Krampf. Oder benutze ich endlos Saetze ala IF... else... Aber auch hier ended das irgendwie im Nirwana... Hat da jemand Ideen? Klar gibt es Vereinfachungen... z.B wenn die int. Batteriespannung unter 10.5V ist passiert nichts mehr. Trotzdem gibt es endlose Kombinationen... Hilfe...
Vielleicht einen Kommentar den ich einfuegen moechte... Bisher haben wir immer erst die User - Menufuehrung gemacht und dannn die entsprechenden Bedingungen abgearbeitet...
Daniel D. schrieb: > Fangen wie mal mit den Benutzer und den aeusseren Inputs an... > Er kann 5 verschiedene Buttons druecken Benutzereingaben: - Button 1 -> Action - Button 2 -> Action ... - Button 5 -> Action > Das Geraet wird an eine > Autobatterie angeschlossen > (2 Zustaende - angeschlossen / nicht angeschlossen), Hardware -> Stromversorgung > Die Spannung der angeschlossene Autobatterie wird gemessen > und dort haben wir 6 verschiedene Zustaende. Hardware -> Stromversorgung -> Einzelheiten > und es kann externe Geraete (Handy, Tablet) laden (2 Zustaende). Hardware -> Ladefunktion > Im Inneren ist eine LiFEPO4 Batterie die abhaengig von der > Batteriespannung und Batterietemperatur verschiedene Dinge erlaubt bzw. > nicht erlaubt. ... Hardware -> Ladefunktion -> Einzelheiten > Wie entwickelt man fuer soetwas Software bzw ein Zustandsdiagram? - In Funktionen zerlegen, - Diese einzeln beschreiben - anschliessend gruppieren. - Dann Abhängigkeiten festlegen ( wenn möglich vermeiden und als Funktioen definieren) So erhält man einzeln erstellbare Module und das Gerüst für den Testplan. Viel Spass > Ich sitze hier mit Visio und Excel aber irgendwie ist das alles Krampf. > Oder benutze ich endlos Saetze ala IF... else... Aber auch hier ended > das irgendwie im Nirwana... Würde ich mit Plain Text und Stichpunkten anfangen. Gruppieren, Numerieren und Formatieren als letztes.
Daniel D. schrieb: > Vielleicht einen Kommentar den ich einfuegen moechte... > > Bisher haben wir immer erst die User - Menufuehrung gemacht und dannn > die entsprechenden Bedingungen abgearbeitet... Am besten ist imo als erstes die Bedienungsanleitung zu schreiben.
Danke... erstmal. Werde vielleicht nochmal mit dem Schreiben versuchen. Sehe auch das es schon eine Menge Einschreaenkungen durch die User Menus gibt. Sollte jemand noch Tips haben wuerde ich gern mehr hoeren. Ich bin bestimmt nicht der einzige der solche Dinge fragt. LG
Daniel D. schrieb: > Wie entwickelt man fuer soetwas ... ein Zustandsdiagram? Ganz vorsichtig :) Zu der Komplexität deines Problem sage ich am Ende noch was. Ansonsten, nach dem alten Prinzip Divide et impera (teile und herrsche): Hierarchische Zustandsdiagramme, bei denen Zustände aus Teilzuständen zusammengesetzt werden. Nach seinem Erfinder werden die auch Harel Zustandsdiagramme genannt und UML hat sich für seine Zustandsdiagramme fleißig dran bedient. > Ich sitze hier mit Visio Hmmm, nicht ganz so schlecht, aber such mal nach spezieller Software für (UML) Zustandsdiagramme. > und Excel Excel ist einfach nur Dreck der eines Ingenieurs unwürdig ist. > Oder benutze ich endlos Saetze ala IF... else... Aber auch hier ended > das irgendwie im Nirwana... Auch da gibt ein paar Dinge, aber das ist alles ziemlich übel. Einmal fällt mir aus der Mottenkiste der Computerei "Structured English" ein. Ich meine das war in DeMarcos Buch Structured Analysis and System Specification https://www.amazon.com/Structured-Analysis-System-Specification-DeMarco/dp/0138543801 DeMarco hat die Computerwelt später mit Büchern wie Peopleware bereichert. Ebenfalls aus der Ecke der Telekommunikation, in der man traditionell mit vielen Systemzuständen arbeitet, kommt ein Monster Namens Specification and Description Language (SDL) https://en.wikipedia.org/wiki/Specification_and_Description_Language SDL hat eine graphische und eine Textrepräsentation. Deshalb erwähne ich es. Wenn du mal eben ISDN mit seinen hunderten von Zuständen beschreiben möchtest, nun, SDL wurde für viele Teile von ISDN verwendet. > Trotzdem gibt es > endlose Kombinationen... Hilfe... Vielleicht auch noch mal der Hinweis: Don't Panik. Deine paar Zustände sind ein Fliegenschiss. Das kannst du wahrscheinlich mit Bleistift und Papier hin bekommen. Einfach mit Geduld und Spucke.
Moin, Fuer solche Sachen nutze ich eine Geraetebeschreibungsssprache (speziell dafuer entwickelten XML-Dialekt). Dabei wird jegliche Funktionalitaet auf 'Eigenschaften' abstrahiert und Abhaengigkeiten voneinander als Ereignisse. Das reicht eigentlich fuer komplexe Designs aus, insbesondere beim Definieren der Funktionalitaet im Sinne 'Lastenheft'. Aus dem XML laesst sich dann so gut wie alles generieren (wo es Sinn macht), wie Header, Dokumentation, Source-Skelette, UML/dot-Diagramme, bis sogar zur Hardware. Kann man dann dem Auftraggeber fruehzeitig vorlegen und eine effektive Kostenabschaetzung passt dann auch recht gut. Allerdings muss man in XML bisschen was investieren, es amortisiert sich spaetestens bei grossen Projekten, besonders dann aber, wenn man das ganze mehrmals machen muss (ganze Geraeteklassen..). Nur if/else-Sachen wuerde ich vermeiden. Kann man mit XSL zwar verarzten, aber ist das, was schliesslich den Aufwand macht - und teils 'unlesbar'. Stylesheets liegen in der Opensource: https://gitlab.com/hackfin/netpp Empfohlener Editor : XMLMind XML Editor (v.5.3.0). Ansonsten: Tafel, Bleistift, Papier. Manchmal werden hier sogar Skizzen wieder eingescannt und kommen in die Doku :-)
Martin S. schrieb: > Fuer solche Sachen nutze ich eine Geraetebeschreibungsssprache (speziell > dafuer entwickelten XML-Dialekt). Das klingt sehr interessant! Wo findet man ein Beispiel wie sowas aussieht?
Ich wuerde mir mal ueberlegen, wie ich das Gebilde testen werde.
In dem Paper findest einen Screenshot: https://section5.ch/wp-content/uploads/2019/10/netpp-embedded-world2011.pdf Der XXE-Editor ist eigentlich das Kernwerkzeug fuer den 'Designer', sei es 'top down' (erst Eigenschaften definieren, Implementierung spaeter klaeren) oder 'bottom up'(bestehende Geraeteklassen wie z.B. Modbus-Controller verarzten). Das uebergeordnete netpp-Framework (zur Geraetesteuerung) muss man nicht zwingend benutzen. Hilft aber beim Rapid Prototyping / automatischen Funktionstest der Eigenschaften (typischerweise per Python-Script). Ansonsten habe ich hier noch einige Demos (virtuelle Fabriksteuerungen) im Docker-Container, wenn's ernst wuerde :-)
Daniel D. schrieb: > Hat da jemand Ideen? Unzureichende Beschreibung. Typisch für Leute die nur Speks erstellen und nicht realisieren. Was ist wenn während einer Aktion ein anderer oder derselbe Knopf nochmal gedrückt wird. Was wenn sich während einer Aktion eine Bedingung (Temp, Spannung) über eine Grenze verândert. Wie stellt man sicher, dass bei einem 12V System nicht ein 24V Jumpstart angefordert wird. Wie erkennt man dass der Anlasser blockiert und einen Kurzschluss oder Batteriewackelkontakt. Usw.
Toby P. schrieb: > Am besten ist imo als erstes die Bedienungsanleitung zu schreiben. Das ist für etwas Neues die beste Wahl. Und das ist wirklich ernst und kommplett gemeint. - Die Übersichtsseite, wo alle Elemente des Gerätes benannt und grob zugeordnet werden - Die Gefahrenhinweise, wann und wo das Geräte nicht zum Einsatz kommen darf - die Sicherheitsvorkehrungen zum Betrieb - die genau Bedienung (Und da ist es völlig OK, wenn Du mit einem Texteditor oder was immer Du kannst Menüs gestaltest, mit Enter/Escape/Navigation/Zahlen eingeben etc.) - die Fehlerbehebung (welche Fehler können auftreten, wie werden die behoben) Nur wenn Du die ganze Bedienungsanleitung auch wirklich selber schreibst, weisst Du, was das Gerät kann und wie man es bedient.
Daniel D. schrieb: > Sollte jemand noch Tips haben wuerde ich gern mehr hoeren. Ich bin > bestimmt nicht der einzige der solche Dinge fragt. Der Tipp mit der Benutzer-Anleitung ist auf jeden Fall gold-richtig! Wenn Du nicht in der Lage wärest, dem Benutzer einfach zu erklären, wie das Gerät zu funktionieren hat, dann kann man es auch nicht einfach in Software gießen. Wenn klar definiert ist, wie sich das Gerät verhalten soll, dann kann der Software-Entwickler das auch so umsetzen. Wenn Dir das Schreiben der Anleitung schwer fällt, dann kann das bedeuten, dass Dir selbst noch nicht so ganz klar ist, wie das Gerät funktionieren wird, bzw. das die Bedienung zu kompliziert ist. Wenn zum Verständnis der Funktionsweise Zustandsdiagramme nötig sind, dann ist das so. Wenn nicht, dann braucht auch der Software-Entwickler keine Zustandsdiagramme. (Bzw. er malt sich welche, wenn er sie zur Arbeit braucht) Es wird sicher einige Fehler-Zustände geben, die Du in der Benutzer-Anleitung nicht in epischer Breite beschreiben möchtest (oder zumindest anders). (Was soll passieren, wenn keine Batterie angeschlossen ist, oder die Batterie während des Ladens abgenommen wird etc.). Wenn Du eine Software bekommst, möchtest Du diese später prüfen und abnehmen. Dazu überlegst Du Dir am besten Test-Fälle und gibst diese Test-Fälle auch dem Software-Entwickler. Mach kein Geheimnis daraus, welches die Kriterien sind, nach denen Du die Software abnehmen wirst. Du hast ggf. auch nicht funktionale Anforderungen. z.B. Stromverbrauch, Performance, Sicherheit etc.. Wenn Du die nicht einforderst, dann wirst Du die auch nicht bekommen. Aber Vorsicht: wenn Du etwas forderst, dass Dir eigentlich nicht wichtig ist, dann lass es weg, sonst kann es ggf. teuer werden. (oder stell es explizit als Option dar und lass Dir für diese Optionen gesondert die Aufwände schätzen) Welche Anforderungen hast Du an die Software bezüglich defekter Hardware? Soll es einen Power on Self-Test gegeben? Wie soll der getestet werden? Brauchst Du noch Software-Unterstützung in der Fertigung? HTH Torsten
Torsten R. schrieb: > Der Tipp mit der Benutzer-Anleitung ist auf jeden Fall gold-richtig! Im Prinzip stimmt das, wenn der Auftraggeber (oder Marketing) bereits ein vernuenftiges Lastenheft definiert hat. Leider nur seltenst der Fall.. In der Praxis wird dann meistens recht ineffektiv rumiteriert, und der Aufwand bleibt ueberabzaehlbar, meistens zu Lasten des Entwicklers. Aber prinzipiell bin ich auch der Meinung, dass der Entwickler jede Eigenschaft des Geraets, wie auch Randbedingungen (Minimum/Maximum-Werte, etc.), Betriebsarten, woertlich beschreiben soll, dabei fallen schon mal viele Nutzeraspekte auf. Die Integration mit den div. XML-basierten Geraetebeschreibungssprachen ist soweit, dass die Referenz zu den Eigenschaften (seien es Register, Variablen, etc.) direkt in den XML-Docbook-Standard uebersetzt werden, somit der Workflow nur noch beinhaltet: - Eigenschaft definieren (Name, Typ, Info-Text) - Verbal beschreiben, was das Ding macht, Referenz setzen - Dokumentation bauen, PDF zur Kontrolle ausgeben - In Revisionskontrolle/CI einchecken und Marketing kreuzlesen lassen - Derweil Zeit fuer Rapid-Protoyping/funktionalen Simulator haben Die Zeiten, in denen man fuer sowas Word, Excel ("Wuerg", "Ekzem") oder Libreoffice anwirft, sollten eigentlich definitiv vorbei sein. Aber damit die Layouter was zu tun haben: Man kann auch alles in Framemaker/LaTeX usw. ausgeben.
Danke fuer die Kommentare... Die Idee der Gebrauchsanweisung ist recht gut und hilft. Und ich bin auch schon dabei diese zu schreiben. Jedoch gibt es einige Dinge die im Hintergrund laufen die der Benutzer gar nicht weiss und nicht wissen muss. Wir haben im Team es geschafft ein recht vollstaendiges Statediagram zu zeichnen. Mein Chef hat mehr ueber die Bedienung von VISO geflucht. Zusaetzlich haben wir eine Excel Tabelle als State Transition Table verwendet. Das ging ganz OK... Wir haben uns aber nicht schlecht ueber den Aufwand gewundert. Wir sassen zeitwweise mit bis zu vier Leuten in einem Raum. Reichlich Kaffee und Plaetzchen haben geholfen und es wurde ab und zu auch mal recht spaet... Wir werden sehen wie gut es geworden ist wenn Supplier in China mit gefuehlten tausend Fragen kommt... Danke nochmals... und schoenes Wochenende. LG
Daniel D. schrieb: > Fangen wie mal mit den Benutzer und den aeusseren Inputs an... > > Er kann 5 verschiedene Buttons druecken (ON, Light, Test, 12V, 24V) - 5 > Zustaende - ein Button zu einer Zeit) . Hoffentlich weiss der Benutzer das und hält sich auch daran. Die Software muss auch mit gleichzeitig gedrückten Knöpfen klar kommen.
Daniel D. schrieb: > Jedoch gibt es einige Dinge die im Hintergrund laufen die der Benutzer > gar nicht weiss und nicht wissen muss. Verwechsle da nur nicht Was und Wie.
Daniel D. schrieb: > Mein Chef hat mehr ueber die Bedienung von VISO geflucht. > Zusaetzlich haben wir eine Excel Tabelle als State Transition Table > verwendet. Ist das jetzt ein Troll-Versuch? Schau dir mal YED an, bevor du mit so einem Krempel weitermachst.
Daniel D. schrieb: > Wie entwickelt man fuer soetwas Software bzw ein Zustandsdiagram? Das kommt erst ganz zum Schluss. Arbeite dich in vielen Iterationen von Außen nach innen. In der ersten Iteration stellst du lediglich fest, - dass es ein Jumpstarter sein soll und - welche äußerlich sichtbaren Funktionen er haben soll. In der nächsten Iteration beschreibst du die Funktionen detaillierter. Was soll wann wie angezeigt werden. Was sollen die Bedienelemente bewirken. Bei jeder Iteration fängst du wieder oben an und arbeitest weitere Details für jeden einzelnen Punkt aus, bis es nicht mehr weiter geht. Danach kannst du einen asiatischen Codemonkey beauftragen, die Vorgaben Zeile für Zeile in eine Programmiersprache zu übersetzen.
Daniel D. schrieb: > Ich sitze hier mit Visio und Excel aber irgendwie ist das alles Krampf. Wenn du Programmierer bist, wird es für dich wahrscheinlich einfacher sein, das Verhalten in Text-Form zu beschrieben und erst danach daraus ein Diagramm zu erstellen. Diagramme verbergen übrigens oft die Komplexität der Details (insbesondere Fehlerbehandlung) damit sie lesbar bleiben. Ich persönlich nutze Diagramme gerne für die High-level Sicht eines technischen Projektleiters, beschreibe dann aber jedes Kästchen detailliert in Text-Form. > Trotzdem gibt es endlose Kombinationen... Das ist normal. Eventuell ist es besser, dich von einem klassischen Programmablaufplan zu trennen und das ganze erst einmal als Tabelle mit Zuständen und Reaktionen aufzuschreiben. Hier ist eine Anregung zur Vorgehensweise: http://stefanfrings.de/multithreading_arduino/index.html#planung (nur dieser eine Absatz)
Ergänzung: Wenn man in einer Besprechung mit mehreren Leuten irgendwelche Diagramme entwickelt, sollte man das an einer Tafel machen statt dass parallel einer versucht das mit einer Software leserlich hinzufummeln. Wenn ich sowas für mich mach, dann fang ich auch auf einem Schmierzettel an. Und, falls nötig, wird das dann sauber mit YED nachgezeichnet und als PDF ausgedruckt. Dazu gehört halt leider die Fertigkeit leserlich mit der Hand schreiben zu können.
Daniel D. schrieb: > Wie entwickelt man fuer soetwas Software bzw ein Zustandsdiagram? Du brauchst kein Zustandsdiagramm für sämtliche Zustände. Da, wo es sinnvoll ist und weiterhilft, kann man natürlich eins erstellen. Zum Beispiel für die generelle Ablaufsteuerung. Auch gilt: Verwende das passende Diagramm für den jeweiligen Anwendungsfall. Wenn zum Beispiel zwei Geräte eine bestimmte Abfolge von Nachrichten miteinander austauschen sollen beim Handshake, dann ist für sowas ein Sequenzdiagramm gut geeignet. Für andere Fälle wiederum mag das ein Aktivitätsdiagramm sein, usw. > Ich sitze hier mit Visio und Excel aber irgendwie ist das alles Krampf. > Oder benutze ich endlos Saetze ala IF... else... Aber auch hier ended > das irgendwie im Nirwana... Das eine ist der Editor, das andere ist die Form. Wir benutzen hier in der Firma DOORS und das funktioniert einigermaßen gut. Als schriftliche Form für die Anforderungen haben sich nach meiner Meinung zwei Dinge bewährt: Für funktionale Anforderungen bzw. für Dinge, die sich zur Laufzeit ändern können (z.B. Reaktion des Systems auf einen Tastendruck, oder auf einen geänderten Sensorwert: PRECONDITION - TRIGGER - REACTION Das sieht dann zum Beispiel so aus: PRECONDITION The system is up and running. TRIGGER The user presses the button "Test" REACTION The menu for "Test" shall be displayed on the LCD Das ist nur ein sehr einfaches Beispiel. Es kann natürlich mehrere Vorbedingungen geben, so zum Beispiel die dass man sich schon in einem bestimmten Unter-Menü befindet. Nun gibt es natürlich auch Dinge, die sich zur Laufzeit nicht ändern. Dazu gehören zum Beispiel solche Sachen wie die IP-Adresse eines Geräts (wenn diese statisch ist), oder das Aussehen eines bestimmten Icons welches auf dem Bildschirm angezeigt werden soll, etc. Dafür schreibt man einfach Prosa-Text, so etwas in der Art: The icon for "Warning" shall be a yellow exclamation mark with a yellow triangle around it. The IP address of the device shall be: 192.168.1.24 > Hat da jemand Ideen? Klar gibt es Vereinfachungen... z.B wenn die int. > Batteriespannung unter 10.5V ist passiert nichts mehr. Trotzdem gibt es > endlose Kombinationen... Hilfe... Wie jemand hier schon erwähnte: Teile und herrsche. Die Funktionalität des Geräts kann man in bestimmte Gruppen aufteilen. Zu jeder dieser Gruppen kann man ein eigenes Kapitel in der Spezifikation erstellen. Diese wiederum kann man in Unterkapitel aufteilen. Das, was logisch zusammengehört, steht eben in selben Kapitel.
Daniel D. schrieb: > Zum Beispiel kann die Batterie zwischen -20 und 60 Grad > und 14.6 und 12.95V das Auto starten, aber nur zwischen 0 und 45 Grad > geladen werden. 30 Zustaende). > ... > Trotzdem gibt es > endlose Kombinationen... Hilfe... Wie kommst du in diesem Beispiel auf 30 Zustände? Oliver
Hallo... Danke nochmals fuer die vielen Antworten. Wie gesagt sind die Tabelle und State-Diagram nicht wirklich toll. Wir lassen das zwei Tage liegen und dann oeffnen wir das und dann finden wir ploetzlich einen Fehler oder hinterfragen uns selbst und was wir da gemacht haben. Aber vielleicht gehoert das einfach dazu. Wir haben ca. 35 Zustaende... Angefangen von einem Welcome Screen, Anweisungen fuer den Anwender ala "Verbinde den Jump Starter mit dem Fahrzeug", usw. bis zu einem Exit Screen. Eine Schwierigkeit die immer noch besteht ist das theoretisch der Anwender ein Geraet (Handy) via USB verbinden kann und der Jump Starter auch gleichzeitig geladen werden kann. Also z.B. der "Welcome State" in 4 Ausfuehrungen existiert: - Welcome Screen - Welcome Screen und USB laden eines Handys - Welcome Screen und der Jump Starter wird geladen - Welcome Screen und der Jump Starter wird geladen und laedt ein USB device Manche dieser Dinge koennen gleichzeitig gemacht werden wie im oberen Fall. Einige Dinge werden verrigelt z.B. waehrend des Jump Start Prozesses. LG
Daniel D. schrieb: > Wir > lassen das zwei Tage liegen und dann oeffnen wir das und dann finden wir > ploetzlich einen Fehler oder hinterfragen uns selbst und was wir da > gemacht haben. Aber vielleicht gehoert das einfach dazu. Was ihr da macht ist ja der nicht unwesentliche Teil der Arbeit eines Software-Entwicklers. Wenn ihr jetzt einem "Codierer" in Indien ganz kleinteilig erzählt, was er der Maschine erzählen soll, werdet ihr im Endeffekt wahrscheinlich nicht viel gespart haben.
Ja,ja. Deswegen laesst man da bevorzugt erfahrene Leute ran. Die haben das alles schon gemacht.
Beitrag #6173330 wurde von einem Moderator gelöscht.
Edson schrieb im Beitrag #6173330: > Ist wohl derzeit Mode, sich über Excel zu mokieren, hm? Wie bei jedem > echten Werkzeug wird auch Excel in den Händen eines begabten Machers > einen guten Beitrag leisten können Was die 'begabten Macher' mit Excel typischerweise fabrizieren, ist der klassische Write-Only code: Nicht skalierbar, kaum debugbar, nicht im Team synchronisierbar, und schon gar keine vernuenftige Revisionskontrolle, geschweige CI moeglich. Fuer persoenliches Prototyping kann man das machen, in der serioesen Entwicklung ist man da schon lange weiter. Und ja, ich habe lange VB-Scripte immer wieder von Version auf Version anpassen muessen und bin definitiv von dieser Art Arbeitsgenerierung geheilt. In der Zeit, in der man mit Excel frickelt, hat man in Python bereits einen funktionalen Prototypen entwickelt.
Daniel D. schrieb: > Eine Schwierigkeit die immer noch besteht ist das theoretisch der > Anwender ein Geraet (Handy) via USB verbinden kann und der Jump Starter > auch gleichzeitig geladen werden kann. Also z.B. der "Welcome State" in > 4 Ausfuehrungen existiert: > > - Welcome Screen > - Welcome Screen und USB laden eines Handys > - Welcome Screen und der Jump Starter wird geladen > - Welcome Screen und der Jump Starter wird geladen und laedt ein USB > device > > Manche dieser Dinge koennen gleichzeitig gemacht werden wie im oberen > Fall. Einige Dinge werden verrigelt z.B. waehrend des Jump Start > Prozesses. Na dann gibt es eben Betriebszustände, die sich gegenseitig ausschließen: Da muss jeder für sich spezifiziert werden. Andere Dinge, die sowohl parallel laufen können als auch alleine - weil sie sich gegenseitig nicht beeinflussen - braucht man nur einmal spezifizieren. Die Anforderungen sind ja immer noch gültig, auch wenn jener Code dann halt gerade nicht durchlaufen wird, weil der Benutzer die entsprechende Option eben gerade nicht angewählt hat.
Martin S. schrieb: > In der Zeit, in der man mit Excel frickelt, hat man in Python > bereits einen funktionalen Prototypen entwickelt. Guter Hinweis! Man kann GUIs sehr schnell mit Python oder Tcl/Tk oder sonst eine Skriptsprache mit GUI-Elementen entwickeln. Dadurch kommt man recht schnell ein Gefühl was fehlt, Zusammenhänge erkennen und auch Nicht-Programmierer können damit arbeiten und sich was vorstellen und Wünsche einbringen.
Würde mich übrigens interessieren, was es denn an meinem Beitrag vom 06.03.2020 13:58 auszusetzen gibt, dass dieser neagtiv bewertet wurde?
Torsten R. schrieb: > Was ihr da macht ist ja der nicht unwesentliche Teil der Arbeit eines > Software-Entwicklers. Wenn ihr jetzt einem "Codierer" in Indien ganz > kleinteilig erzählt, was er der Maschine erzählen soll, werdet ihr im > Endeffekt wahrscheinlich nicht viel gespart haben. So sieht es aus. Natürlich ist das Ausprogrammieren und Testen und Fehler in der Implementierung suchen auch nicht gerade trivial, und nicht mal eben an einem Nachmittag gemacht. Aber eine vernünftige Spezifikation ist schon die halbe Miete. Leider können die wenigsten Leute wirklich gute Spezifikationen schreiben. Man bräuchte dafür vielleicht eine Kreuzung aus einem Informatiker und einem Germanisten. ;-)
Mark B. schrieb: > Man bräuchte dafür vielleicht eine Kreuzung aus einem > Informatiker und einem Germanisten Da ist was dran. Schreibe einfach auf englisch mit dem Wortschatz eines 6 Jährigen, das versteht jeder und ist klarer als so manche elegante deutsche Formulierung. Nicht: "Es wäre schön, wenn sich alle Entwickler in Besprechungen auf ihren Stuhl setzen würden, falls denn ein freier Stuhl gerade verfügbar ist und dieser sich in akzeptablen Zustand befindet und auch sonst keine anderen wichtigen Gründe dagegen sprechen." Sondern: "Sit down!" Ich bestehe auch immer darauf, dass Begriffe wie "must" anstelle von "should" bevorzugt werden. Was optional schön wäre, gehört in ein eigenes Kapitel und wird separat verhandelt.
Daniel D. schrieb: > Die Idee der Gebrauchsanweisung ist recht gut und hilft. Und ich bin > auch schon dabei diese zu schreiben. Anfangs mache ich einen Entwurf (Treatment Scribble …). Würde in etwa so aussehen: Wenn du, lieber Anwender, Knopf A drückst kommt Aktion 1. Drückst du Knopf B passiert 2. Wenn du das alles nicht willst zieh den Stecker oder drücke Knopf C. Mehr nicht, nur den Rahmen. Am besten in der Sprach der Anwender. „Ey alter Finger wech von Knopp C wenn das Gerät rödelt“ würde ich aber nicht in die Endfassung übernehmen ;-). > Jedoch gibt es einige Dinge die im > Hintergrund laufen die der Benutzer gar nicht weiss und nicht wissen > muss. Das ist imo kein Bestandteil der BA. Aus diesem kühlen Grunde schreibt man Sie ja auch. Um den Focus auf die Anwendung zu bekommen, weg vom technischen. Da sind auch irgendwelche Tools wenig hilfreich. Nach meiner Erfahrung ist sogar ein PC nicht Mittel der Wahl und der eigene Schreibtisch der falsche Ort. Etwas das man nicht aus dem FF beherrscht schon gar nicht. Papier und Bleistift finde ich am besten geeignet. Das scanne ich dann später ein, wg. drohender doppelter Arbeit beim tippen, das blockiert. Kann man auch mehrmals scannen und die alten löschen. Das alles im Café oder in der Bahn.
Mark B. schrieb: > Leider können die wenigsten Leute wirklich gute Spezifikationen > schreiben. Man bräuchte dafür vielleicht eine Kreuzung aus einem > Informatiker und einem Germanisten. ;-) Das ist einfache Fall ;-). Es kommen noch Werbetexter, Grafikdesigner und Benutzerpsychologe hinzu. Daniel D. schrieb: > - Welcome Screen > - Welcome Screen und USB laden eines Handys > - Welcome Screen und der Jump Starter wird geladen > - Welcome Screen und der Jump Starter wird geladen und laedt ein USB > device In der BA steht da nur der "Welcome screen". Der Rest ist vermutlich technischer Kram, davon unabhängig. Das Gerät muss dann entscheiden was wann passiert. Dafür gibt es Kriterien die man formuliert. Schafft man es dafür präzise aussagekräftige Begriffe zu finden schreibt sich der Rest oft fast von allein.
Hallo, Danke nochmals fuer die vielen Antworten. Wir hatten diese Woche mehrere Meetings mit unserem Supplier. Ich glaube die Spezifikation ist ganz gut geworden. Letzendlich haben wir es mit Visio und Excel gemacht. Hat aber insgesamt ca. 4 Wochen gedauert und diese Wochen haben wir immer noch Fehler gefunden... Falls interesse besteht werde ich hier mal was dazu schreiben...
Daniel D. schrieb: > Hat aber insgesamt ca. 4 Wochen gedauert und diese Wochen > haben wir immer noch Fehler gefunden... Kein Problem. Wenn ihr vorher mit der Programmierung begonnen hättet, wären die Fehler erst dann aufgefallen oder vielleicht gar nicht. Diese 4 Wochen sind Bestandteil der Entwicklung und keinesfalls verplempert.
Danke... Problem ist das vier Wochen hier eine sehr sehr lange Zeit sind um Spezifikationen zu schreiben. Ich hatte sehr viele Schwierigkeiten und spaeter ist mein Chef dazugestossen. Haette ich das komplett alleine gemacht haette es noch laenger gedauert und jeder haette gedacht was macht der (als ich) da die ganze Zeit... kann doch nicht so schwer sein... Cheers
Daniel D. schrieb: > Problem ist das vier Wochen hier eine sehr sehr lange Zeit sind um > Spezifikationen zu schreiben. Wer sagt denn das? https://www.youtube.com/watch?v=w7KA2LSvsfM Die Zeit, die man in einem Projekt verliert wenn man keine vernünftige Spezifikation hat, dürfte noch viel länger sein.
Mark B. schrieb: > Die Zeit, die man in einem Projekt verliert wenn man keine vernünftige > Spezifikation hat, dürfte noch viel länger sein. Faustregel ist Faktor 10 von Phase zu Phase. - Fehler bei der Implementierung gefunden -> zehnmal aufwendiger zu fixen als in der Spezifikationsphase - Fehler bei der Verifikation gefunden -> hundertmal aufwendiger zu fixen als in der Spezifikationsphase - Fehler erst beim Kunden gefunden -> tausendmal aufwendiger da Technikereinsatz, Produktrückruf oder ähnlich katastrophales Aufwand kann Zeit, Geld und im letzten Fall auch Reputationsverlust sein.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.