Von der Idee zur fertigen Applikation

Hallo LV-Gemeinde,

da ich nocht wußte wo ich das Thema sonst platzieren kann, hab ich mal den Smalltalk genommen.

Wie der Titel meines Beitrages hoffentlich schon aussagt, möchte ich euch mal fragen, wie ihr eure Programme von der Idee in die Tat umsetzt. Hierbei geht es mir vorwiegend um die Zwischenschritte, wie den Projektentwurf etc.

Ich arbeite nun schon seit über einen Jahr mit LabVIEW und bisher ist der Weg zum fertigen Programm noch recht laienhaft. An das Prinzip mit den ersten Vorüberlegungen mit Beistift und Papier bin ich irgendwie noch nicht rangekommen, weil ich einen sinnvollen Weg hierfür noch nicht gefunden habe. Klar macht man Vorüberlegungen, aber diese sind meistens irgendwie nicht so recht schlüssig, so dass ich in den meisten Fällen einfach drauf losprogrammiere. Dabei sieht man Probleme erst dann, wenn die Korrektur meist schon sehr viel Zeit in Angriff nimmt.

Aus diesem Grunde würde mich einmal interessieren, wie ihr an eure Problemstellungen rangeht, welche Strategie ihr verfolgt und wie ihr den Arbeitsaufwand abschätzt. Vielleicht hat ja jemand unter euch eine gute Hilfestellung für mich parat, wie man am effizient programmiert.

Ich freue mich auf eine anregende Diskussion.

Schöne Grüße
Falk

Ich mache es so:

1) Grober Entwurf der FPs: Datendartellung, Dateneingabe und Buttons
2) Danach dem Chef oder Kunde zeigen und fragen was zu ändern ist
3) Programmstruktur überlegen: wieviele Programmodule, Tasks, Kommunikation zwischen den Modulen
4) Mit dem tiefsten Modul anfangen, z.B. enfachen Senden und Empfangen der Daten von/zum Gerät
5) Hauptmodul = Bedienung des GUIs
6) Beide Module verbinden
7) Alle anderen Module ähnlich aufbauen
8) Programm ausprobieren, testen u.s.w.
9) Dem Kunde zeigen
10) Verbesserungen
11) Doku

eg

' schrieb:Ich mache es so:

1) Grober Entwurf der FPs: Datendartellung, Dateneingabe und Buttons
2) Danach dem Chef oder Kunde zeigen und fragen was zu ändern ist
3) Programmstruktur überlegen: wieviele Programmodule, Tasks, Kommunikation zwischen den Modulen
4) Mit dem tiefsten Modul anfangen, z.B. enfachen Senden und Empfangen der Daten von/zum Gerät
5) Hauptmodul = Bedienung des GUIs
6) Beide Module verbinden
7) Alle anderen Module ähnlich aufbauen
8) Programm ausprobieren, testen u.s.w.
9) Dem Kunde zeigen
10) Verbesserungen
11) Doku

Bei mir geht es meist ähnlich aber in meiner ERfahrung ist es hilfreich mit der Doku nicht bis am Ende zu warten. Gerade bei etwas grösseren Projekten weiss man dann nÄhmlich nicht mehr wie die verschiedenen Dinge genau funktionieren, und vor allem worauf man beim Bedienen genau achten muss um es gut zu machen. Kostet dann oft sehr viel Zeit um das wieder herauszusuchen manchmal durch Ausprobieren aber manchmal geht's nicht ohne denn Code nochmal gut anzuschauen, was sehr viel Zeit kosten kann.

Punkt vier ist bei mir meist weniger ein Modul als eine Library von Funktionen um mit den verschiedenen Geräten, Applikationen, etc. etc. zu kommunizieren..

Rolf Kalbermatter

' schrieb:Bei mir geht es meist ähnlich aber in meiner ERfahrung ist es hilfreich mit der Doku nicht bis am Ende zu warten. Gerade bei etwas grösseren Projekten weiss man dann nÄhmlich nicht mehr wie die verschiedenen Dinge genau funktionieren, und vor allem worauf man beim Bedienen genau achten muss um es gut zu machen. Kostet dann oft sehr viel Zeit um das wieder herauszusuchen manchmal durch Ausprobieren aber manchmal geht's nicht ohne denn Code nochmal gut anzuschauen, was sehr viel Zeit kosten kann.

Punkt vier ist bei mir meist weniger ein Modul als eine Library von Funktionen um mit den verschiedenen Geräten, Applikationen, etc. etc. zu kommunizieren..

Rolf Kalbermatter

Ja, aber meistens hat man für die Dokumentation keine Zeit, obwohl diese sehr wichtig ist. Beim letzten Projekt habe ich ein Tag lang von 9 bis 22 Uhr nur die Doku geschrieben, weil am nächsten Tag schon der Kunde kommen sollte. Ideal wäre die Dokumentation während des Projektablaufs zu erstellen und zu ändern. Dennoch, wenn das Projekt schon vollständig ist, muss die Doku nur ein Mal geschriben werden und nicht mehr angepasst werden. Genau diese Möglichkeit lockt die Leute dazu die Doku ganz zum Schluss zu schreiben.
Was die Bezeichnung "Modul" angeht, ist diese sehr unklar definiert und hängt vom Projekt ab. Es kann eine Task, ein VI (z.B. OSG), eine Klasse oder eine VI-Bibliothek sein. Ein Modul ist IMHO ein Teil eines Programms, egal wie es aussieht.

Gruß, eg

Ich werfe mal einen Link in die Runde:
http://zone.ni.com/devzone/cda/tut/p/id/4434

Das ist der LabVIEW Style Guide. Er enthält viele tolle Hinweise zur sauberen Programmierung und Projektplanung. Was meint ihr - ist das wirklich nützlich, oder nur theoretisch gut klingender Kram, der praktisch nicht angewendet werden kann?

Moinmoin!
@eg & rolfk: bin beeindruckt, so professionell hab' ich noch nie programmiert
@monoceros84: ohne die ~100 Seiten komplett gelesen zu haben,
Im Prinzip alles sehr richtig und wichtig,
aber was aus den 97 Seiten zuerst?
Beim Überfliegen fielen mir ein paar Fragen/Statements auf, die sehr eingängig sind
(und damit leicht zu merken und zu beherzigen); sowas wie
“We can incorporate all the features in the first release. If the
application does not include every feature, it is useless.”

@Endanwender:
Was ich anfangs immer falsch gemacht habe (und LV verführt einen dazu) ist,
die Aufgabe nicht zu definieren.
Die Antwort auf die simple Frage: Was soll das Programm können?
schwebt einem zwar irgendwie im Kopf rum, aber die späten Änderungen kommen
oft, weil man wichtige Details nicht zu Ende gedacht hat.
Mein persönlicher Klassiker: Fehler in der Logik der Benutzerführung
(wann will/darf/_soll_ der User von wo nach wo?)
für die Informatiker hier: der endliche Zustandsautomat des GUI war nicht definiert

Sowas kann man mit einer gewissen, selbstauferlegten Hemmschwelle vor dem Coding-Beginn
ganz gut in den Griff kriegen und erst mal ein paar Notizen machen.
(professionell heisst das dann Pflichtenheft)
Wichtig dabei sind, neben der Programmlogik die nötigen Datenstrukturen und die Operationen darauf.
(das ist dann schon das Gerüst für die Implementierung)

Und: hab' keine Angst, Code wegzuschmeissen!
Gerade in LV kann man herrlich Prototypen erstellen, die nur dazu dienen, etwas auszuprobieren!

Was mir beim erstellen des "Pflichtenheftes" meißt passiert, ist das ich ganz viele Ideen habe,
was das Programm alles tollen können müsste!
Wohl daher das obige Zitat, denn ich muss mich dann immer sehr zwingen, mich auf das wichtige
zu beschränken.

und ich glaube, jetzt werd' ich noch ein paar von den 97 Seiten lesen :-)
herzlichen Gruß
PeeGee

Anzeige

' schrieb:@monoceros84: ohne die ~100 Seiten komplett gelesen zu haben,
Im Prinzip alles sehr richtig und wichtig,
aber was aus den 97 Seiten zuerst?
Beim Überfliegen fielen mir ein paar Fragen/Statements auf, die sehr eingängig sind
(und damit leicht zu merken und zu beherzigen); sowas wie
“We can incorporate all the features in the first release. If the
application does not include every feature, it is useless.”

Ich habe auch nicht alles gelesen. Viele Absätze kommen einem auch irgendwie aus anderen Anleitungen/Tutorials bekannt vor...

Allerdings ist der von dir genannte Abschnitt sehr gut. Weiterhin die Dinge zur Projektplanung (Stichwort: Wasserfall), Zeitschätzung und die Hinweise zum "richtigen" Design eines Blockdiagramms.