Ich habe mal wieder den Fall, mich in ein System einarbeiten zu müssen,
dass dadurch dokumentiert wurde, dass es eine Software gibt, die das
Ganze treibt. Leider ist die SW vollkommen ohne Kommentare, sodass es
nahezu aussichtslos ist, einen Zusammenhang zwischen dieser konkreten
Realisation und den formellen Anforderungen herzustellen, zumal das
formelle REQ-Heft nicht wirklich vollständig und richtig ist und die SW
extrem abstrakt und verschachtelt ist.
Im Grunde kennt nur der Entwickler die Gründe, was er warum gemacht hat
und man benötigt das Wissen um das System, um die Dokumente richtig zu
verstehen und kann nicht etwa die Dokumente benutzen, um das System und
die Software zu begreifen, zu verstehen und weiter zu entwicklen.
Als Grund wird wieder mal angeben, man habe zu wenig Zeit gehabt, die
Doku zu machen. Man fragt sich, aufgrund welcher Wissensbasis die SW
erzeugt wurde... (???)
Beschleicht euch auch das Gefühl, dass für viele Entwickler, die Lasten-
und Pflichtenhefte mehr störende Belastung sind, als Hilfen?
Ich habe den Eindruck, dass sich das Gros der Entwickler, infolge
verbaler Kommunikation mit Chef, Kollegen und Anderern einfach eine
grobe Vorstellung des Zielsystema machen und dann munter drauflos
programmieren, während der Programmierens denken und sich mit anderen
abstimmen. Die dabei entstehenden Richtungsänderungen und Loops will man
aber nicht mitdokumentieren und schiebt daher die Doku ans Ende des
Projektes, wodurch dann immer wieder keine Zeit mehr ist, sie fertig zu
stellen, weil die gesamte Zeit fürs chaotische Programmieren verbraten
wurde.
Wie seht ihr das?
Wir reden jetzt nicht von Mickiaufgaben, die man eben mal schnell
hinkritzeln kann, sondern von SW, die in Zulassungspflichtigen Geräten
für sensible Bereiche entwickelt wird und Normungen sowie Regularien
unterworfen ist.
Wird bei euch auch nur noch rumgeschmuht?
Frage: Hast Du in er Schule zuerst den Programmablaufplan entwickelt und
dann streng danach programmiert? Ich glaube, so lästig diese Reihenfolge
bereits in der Schule war, so ist es auch im Beruf. Die wenigsten
Softwaren werden erst dokumentiert und dann programmiert. Das ist
Wunschdenken von irgendwelchen Informatiklehrern/Profs: Der Entwickler
will entwickeln, wie der Arzt behandeln. Irgendwelche Dokus schreiben
ist unliebsamer Ballast.
So lange es sich nicht um Assembler-Code handelt gilt of auch die
Devise, Code ist selbsterklärend.
Deraufsichalleingestellte schrieb:> Beschleicht euch auch das Gefühl, dass für viele Entwickler, die Lasten-> und Pflichtenhefte mehr störende Belastung sind, als Hilfen?
Ja.
Zusätzlich:
Wer auch immer die Entwicklung in Auftrag gegeben hat sieht das
üblicherweise ähnlich. Man will etwas was funktioniert, nicht einen
Haufen Papier.
Jeder in der Kette hat was Besseres zu tun als Papier zu erzeugen, und:
"Bisher hat es so doch auch immer geklappt. Ja, außer ..., aber da war
das und der damals dran schuld."
Da kann man nur zusehen das man das Projekt schnell begräbt oder los
wird.
Meist kann man Strukturen nicht mehr nachvollziehen ohne Kommentar.
Da wird es vermutlich besser sein, das Programm neu zu schreiben.
Unkommentierte Software zu verstehen ist manchmal wie ne Minensuche.
Wenn man Pech hat und eine Mine findet ist man weg vom Fenster.
Für c++ hab ich mal von einer Software gehört, bzw. ist mir angeboten
worden mit der man Programmabläufe visualieren können soll.
Da mir das Programm allerdings zu teuer war und ich Zeitnah
keine Verwendung dafür hatte, hab ich mich damit auch nicht
mehr beschäftigt. Der Name war glaube ich Easycode, kann das aber
nicht verbindlich sagen und auch nicht obs was taugt oder nicht.
Die Idee die dahinter stand fand ich aber interessant.
@ Paul (Gast)
>Frage: Hast Du in er Schule zuerst den Programmablaufplan entwickelt und>dann streng danach programmiert? Ich glaube, so lästig diese Reihenfolge>bereits in der Schule war, so ist es auch im Beruf.
Ist das eine belastbare Begründung? Nein. Bestenfalls ein weiterer Fall
von, "Was Hänschen nicht lernt, lernt Hans nimmermehr".
Die meisten dieser "Programmierer" sind "professionelle Frickler", die
mit autistischen Zügen ihre Software zusammenkloppen. Das geht nur
allzuoft schief, es dauert ewig bis es mal fertig ist, von Qualität ganz
zu schweigen.
Und wenn ein Projekt so groß ist, dass mehrere Leute, ggf. sogar
geographisch verteilte Teams dran arbeiten müssen, ist es Essig mit
dieser "Strategie".
> Die wenigsten>Softwaren werden erst dokumentiert und dann programmiert.
Was eine Erklärung für deren Qualität ist.
>Wunschdenken von irgendwelchen Informatiklehrern/Profs: Der Entwickler>will entwickeln, wie der Arzt behandeln. Irgendwelche Dokus schreiben>ist unliebsamer Ballast.
Falsch. Denn gerade bei Software ist Doku nicht Beiwerk, sondern das
Festhalten von Ideen, Konzepten und Vereinbarungen. Diese Arbeit muss
man sowieso VORHER leisten, ehe man auch nur dran denkt, den Compiler
anzuwerfen. Denn Software entwickeln ist DEUTLICH mehr als Programm
eintippen und debuggen. Dass es während der Entwicklung noch Änderungen
geben kann und meist wird ändert nix an den Grundlagen.
>So lange es sich nicht um Assembler-Code handelt gilt of auch die>Devise, Code ist selbsterklärend.
Das ist ebenfalls Wunschdenken. Und es ist oft eine sehr nervige,
zeitraubende Sache, sich diverse Parameter und Eigenschaften quasi im
Reverse Engineering aus einem Projekt saugen zu müssen, die eigentlich
sauber und übersichtlich auf einem Stück Papier stehen sollten.
MfG
Falk
P S Der schnellste und preiswerteste Weg etwas zu tun, ist es gleich
richtig zu tun. Dazu gehört auch Projektdokumentation.
@ Paul (Gast)
>Ist ja alles richtig, was Du schreibst. Aber ehrlich, wie sieht die>Realität aus?
Das ist eine andere Frage.
Marx ist die Theorie.
Murks ist die Praxis.
;-)
>Marx ist die Theorie.>Murks ist die Praxis.
Ich kann Falk nur zustimmen. Die Art, wie viele Software hinkloppen ist
die Art, wie es früher noch ging, als wenig standardisiert war und es
nicht so viel Teamwork gab. Code ist nur insoweit selbsterklärend,
soweit er klein und einfach ist und sich auf elementare IO-Themen
konzentriert. Das ist heute doch garnicht mehr der Fall. Jedem ist es
selbst über lassen, wie er etwas programmiert und der nachfolgende macht
es komplett anders und steht vor böhmischen Dörfern.
> Der schnellste und preiswerteste Weg etwas zu tun, ist es gleich> richtig zu tun.
Und weil man das allgemein erkannt hat, gibt es die Vorgaben bezüglich
Designspezifikation, um Entwickler zu zwingen, sauber zu denken, bevor
sie programmieren. Das schult dann auch fürs nächste Projekt.
Wer das aber nie tut, der lernt auch nie, dass das die bessere Methodik
ist und programmiert immer noch so, wie er es mal auf der Schule gelernt
hat.
Die reale Welt ist so, wie sie der PL vorort macht. Und da gibt es
grosse Unterschiede! Dort, wo man strukturiert vorgeht, fleisst mehr
Zeit in langweilige Doku und Stabilität und als Folge weniger in die
nervige Fehlersuche. Ist wohl Gemschmacksache.
Für mich macht das Konzeptionieren von SW jedenfalls mehr Freude, weil
ich kaum Fehlersuchen und Inbetriebnahmen habe. Bei mir stecken die
Tests auch schon drin und ich kann jederzeit SW auf mehrer Schultern
verteilen, weil die Module klar definiert sind, vor allem Interfaces.
Ausserdem programmieren dann alle ähnlich und können sich helfen. Und:
Man hat ein besseres Gefühl, wann man fertig ist.
Deraufsichalleingestellte schrieb:> Ich habe mal wieder den Fall, mich in ein System einarbeiten zu müssen,> dass dadurch dokumentiert wurde, dass es eine Software gibt, die das> Ganze treibt. Leider ist die SW vollkommen ohne Kommentare, sodass es> nahezu aussichtslos ist, einen Zusammenhang zwischen dieser konkreten> Realisation und den formellen Anforderungen herzustellen, zumal das> formelle REQ-Heft nicht wirklich vollständig und richtig ist und die SW> extrem abstrakt und verschachtelt ist.>> Im Grunde kennt nur der Entwickler die Gründe, was er warum gemacht hat> und man benötigt das Wissen um das System, um die Dokumente richtig zu> verstehen und kann nicht etwa die Dokumente benutzen, um das System und> die Software zu begreifen, zu verstehen und weiter zu entwicklen.
So wie du das schreibst ist das Hauptproblem nicht die fehlende
Dokumentation, sondern die schlechte Qualität der Software. Wenn die
Software so verschachtelt ist, dann würde dir zwar eine gute Doku
helfen, aber das Hauptproblem wäre noch immer die Programmierung selbst.
> Als Grund wird wieder mal angeben, man habe zu wenig Zeit gehabt, die> Doku zu machen. Man fragt sich, aufgrund welcher Wissensbasis die SW> erzeugt wurde... (???)>> Beschleicht euch auch das Gefühl, dass für viele Entwickler, die Lasten-> und Pflichtenhefte mehr störende Belastung sind, als Hilfen?>> Ich habe den Eindruck, dass sich das Gros der Entwickler, infolge> verbaler Kommunikation mit Chef, Kollegen und Anderern einfach eine> grobe Vorstellung des Zielsystema machen und dann munter drauflos> programmieren, während der Programmierens denken und sich mit anderen> abstimmen. Die dabei entstehenden Richtungsänderungen und Loops will man> aber nicht mitdokumentieren und schiebt daher die Doku ans Ende des> Projektes, wodurch dann immer wieder keine Zeit mehr ist, sie fertig zu> stellen, weil die gesamte Zeit fürs chaotische Programmieren verbraten> wurde.
Das Wasserfallmodell (zuerst Doku, dann Programmieren, dann Qualität,…)
hat sich leider als Wunschdenken herausgestellt. Anforderungen ändern
sich viel zu schnell, weil man oft erst während der Programmierung
merkt, wo es konzeptionelle Probleme gibt oder was besser anders, gar
nicht oder zusätzlich realisiert werden soll. Derzeit sind agile
Methoden der Trend. Dort hat man eben keine starren Anforderungen. Dafür
muss(!) die Software sauber geschrieben werden. Die Software soll
sozusagen selbst die Doku sein (zumindest auf der tieferen Ebene). Dafür
muss man aber auch alte (zu komplexe) Konzepte einfach über den Haufen
werfen können ohne etwas kaputtzumachen. Und das geht fast nur mit
modernen Entwicklungsumgebungen und Test-Driven-Design.
Idealerweise ist der Programmcode einfach lesbar. Sprich der Code
dokumentiert sich selbst. Dazu ist es auch notwendig das Design an der
Wartbarkeit auszurichten.
Ein Punkt der in der Praxis leider immer wieder missachtet wird ist der,
dass die Einzelprogramme idealerweise nicht mehr als 100 Zeilen, maximal
jedoch höchstens 10000 Zeilen haben dürfen. Alles darüber ist praktisch
unwartbar.
Hat man doch komplexere Probleme (was ziemlich selten ist) so muss man
das Problem in Teilprobleme aufteilen. Beispielsweise durch mehrere
Einzelprogramme, oder Objekte. Sind dann die Schnittstellen
offensichtlich, kann das auch ohne Dokumentation funktionieren.
Der eine Bereich der Dokumentation ohne den es aber nicht geht ist der
große Überblick. Man muss wissen was denn das Programm überhaupt macht.
Ohne dass bringt auch die Dokumentation der einzelnen Programmschritte
wenig.
Nichts ist sicher wie die nächste Änderung.
Selbst die schönste Doku ist nach x Änderungen von zweifelhafter
Qualität. Fraglich ist auch, ob dem der sie braucht, wirklich die
aktuellste Fassung immer vorliegt und diese das Problem ausreichend
umfassend beschreibt, daß auch "jede Küchenkraft" damit was anfangen
kann.
oszi40 schrieb:> Selbst die schönste Doku ist nach x Änderungen von zweifelhafter> Qualität.
Nein, nicht wenn man sie gewissenhaft pflegt. Benötigt Disziplin.
Christian Berger schrieb:> Der eine Bereich der Dokumentation ohne den es aber nicht geht ist der> große Überblick. Man muss wissen was denn das Programm überhaupt macht.> Ohne dass bringt auch die Dokumentation der einzelnen Programmschritte> wenig.
Genau so ist es, stimme dir in allen Punkten zu.
Gernot B. schrieb:> Das Wasserfallmodell (zuerst Doku, dann Programmieren, dann Qualität,…)> hat sich leider als Wunschdenken herausgestellt. Anforderungen ändern> sich viel zu schnell, weil man oft erst während der Programmierung> merkt, wo es konzeptionelle Probleme gibt oder was besser anders, gar> nicht oder zusätzlich realisiert werden soll.
Deshalb gibt es u.a. auch das V-Modell, dass selbst in der IEC 61508 zur
Anwendung kommt.
Unabhängig davon erlaubt es das Feedback zum Kunden und Änderungen
während der Entwicklung, ohne das am Ende wie nach dem Wasserfallmodell
Kundenwunsch/Umsetzung auf der einen Seite und Zielvorgabe auf der
anderen Seite zu weit auseinanderlaufen.
Perfekt ist nichts, aber ohne anständige Doku wird aus nichts
langfristig noch weniger. Muss ich leider aus eigener Erfahrung in
unserer Firma oft genug feststellen. Dabei wären viele Probleme
vermeidbar.
Gerade in der Softwarentwicklung gilt: "Der Appetit kommt beim Essen!"
Wie schon erwähnt, versteifen sich viele Leute darauf, dass es immer
telefonbuchstarke Spezifikationen geben müsse. So etwas sei
professionell. Anschließend kann man dann überprüfen, ob die Software
der Spezifikation entspricht, und schließt daraus auf die Qualität der
Software.
In Wirklichkeit hat dabei aber nicht die Qualität, sondern die
Einhaltung der Spezifikation nachgewiesen. In wesentlich weniger Fällen
als gemeinhin angenommen ist jedoch schon die Spezifikation brauchbar.
Mit ist ein konkretes militärisches Projekt bekannt, in dem die
Mitarbeiter eines Zulieferers gezwungen waren, streng
spezifikationskonform zu implementieren, obwohl sie wussten, dass es
einen so eklatanten Spezifikationsfehler gab, dass daraus sogar eine
massive Gefahr für Menschenleben resultierte.
Eine Überprüfung und Korrektur wurde aber durch den Auftraggeber nicht
beauftragt und wäre von ihm auch nur ungern gesehen worden, weil er das
als Kompetenzverletzung angesehen hätte.
Letztendlich wurde also die Spezifikationstreue als höheres Gut als
Menschenleben angesehen. Das darf eigentlich nicht passieren,
insbesondere wenn man sich auch anschaut, wie viel Arbeitsaufwand in die
Spezifikationserstellung hineingesteckt wurde.
Natürlich ist klar, dass bei einigermaßen komplexen Projekten, an denen
womöglich etliche Organisationseinheiten beteiligt sind, saubere
Schnittstellen definiert sein müssen. Dennoch dürfen Spezifikation und
Dokumentation nicht zum Selbstzweck ausarten.
Beschreibungen sollten immer so formuliert sein, dass die korrekte
Funktion des Programms das wichtigste Ziel ist.
Wirklich produktiv und vor allem anwendungsnah kann man meist nur dann
entwickeln, wenn man zügig Teilergebnisse produziert, sich diese
anschaut und anschließend übernimmt, überarbeitet oder auch wieder
verwirft. Aus der Sicht der Bürokraten wird das zwar als
Ressourcenverschwendung angesehen, aber ich bin der Überzeugung, dass
diese wesentlich geringer ist als wenn man versucht, gigantische
Funktionalitäten als reine Trockenübung zu planen.
Wichtig ist eine Entwicklungskultur, in der man sich nicht sofort einen
Malus einfängt, wenn man schon implementierten Code wieder wegwirft. Wie
häufig habe ich es schon in (Kunden-)Projekten erlebt, dass Entwickler
an jahrtausendealtem Code hingen, der zwar völlig verwurstet und nur
unter größten Kompromissen in neue Systeme einzubinden ist. Aber diese
Entwickler hätten es als Beleidigung empfunden, deren "Meisterwerk"
einfach in die Tonne zu treten.
Andreas Schweigstill schrieb:> Mit ist ein konkretes militärisches Projekt bekannt, in dem die> Mitarbeiter eines Zulieferers gezwungen waren, streng> spezifikationskonform zu implementieren, obwohl sie wussten, dass es> einen so eklatanten Spezifikationsfehler gab, dass daraus sogar eine> massive Gefahr für Menschenleben resultierte.
Das ist doch gängiger Standard und nennt sich Änderungsmanagement:
Kundenspezifikationen werden 1:1 umgesetzt und seien sie noch so
schwachsinnig. Wenn das Projekt so weit fortgeschritten ist, dass der
Kunde es einem nicht mehr unter wirtschaftlichen Gesichtspunkten
wegnehmen kann, macht man das Projekt durch Nachverhandlungen für die
Firma finanziell gesund. Ich kann jetzt nur für die Automotive-Branche
sprechen, aber ich kenne es nicht anders als dass man schon in der
ersten Angebotsphase gezielt nach Fehlern in der Kundenspezifikation
sucht und diese kommerziell bewertet. Je mehr Fehler man findet, desto
aggressiver kann man mit dem (Grund)-Preis runter gehen. Es braucht halt
nur ein paar gute Vertriebler um den Kunden bei den Nachverhandlungen zu
überzeugen, dass man gerade sehr viel Geld für ihn gespart hat.
Wenn wir es nicht machen würden, dann wären bei uns schon lange die
Lampen ausgegangen.
Üblicherweise ists doch so: Software(bzw Technik)-entwicklung ist dem
Auftraggeber grundsätzlich zu teuer und der Posten "Dokumentation" wird
nur zu gerne zusammengestrichen. Die Argumentation "zu dem Datum muss es
herzeigbar sein" ist doch häufig anzutreffen. Changemanagement dauert
und üblicherweise werden hehre Doku/Spec Vorsätze spätestens bei den
ersten Problemen (welcher Natur auch immer) geopfert.
Wird eine Entwicklung nach Normen (bsp. ISO/IEC 61508 o.ä.) durchgeführt
- mit dem dazugehörigen Papierkrieg - dauert's eben doppelt so lange wie
ohne. DAS will aber niemand bezahlen.
Der Grundsatz "You get what you pay for" gilt eben doch und "Geiz ist
Geil" ist problematisch... oder seh nur ich das so?
Obwohl, ich darf mich derzeit nicht beschweren... - ich bekomm die Zeit
dazu SAchen ordentlich zu erledigen.
Deraufsichalleingestellte schrieb:> Wir reden jetzt nicht von Mickiaufgaben, die man eben mal schnell> hinkritzeln kann, sondern von SW, die in Zulassungspflichtigen Geräten> für sensible Bereiche entwickelt wird und Normungen sowie Regularien> unterworfen ist.
Tja, irgendwer muss die SW abgenommen haben (oder zumindest seinen Namen
dafür hergegeben haben). Außerdem müsste es ein Dokument geben, wer
wofür zuständig war - da lässt sich rauslesen wen du fragen kannst...
Soweit es hier im Thema um Softwaredokumentation geht:
Eine Software muß streng genommen an überhaupt keiner Stelle
dokumentiert sein, wenn sie funktioniert, und Abnahmen besteht. Wer
damit glücklich wird???
Aber wehe, es muß mal jemand noch mal daran arbeiten, und ganz schlimm,
wenn es ein Fremder ist, der den Code gar nicht schrieb.
Man sollte demjenigen Verursacher das an die Stirn heften. Und zwar
nicht mit Post-It, sondern mit einem richtigen Zimmermannsnagel.
Ganz schlimm sind Codes über z.B. mehr als 50000 Codezeilen, die sich
über 30 Dateien erstrecken, und mehrfach geschachtelte Strukturen
darinne sind. Da findet niemand mehr die Nadel im Steckhaufen.
Ich gewöhnte mir frühzeitig an, zu Programmen immer auch Struktogramme
oder Flußdiagramme zu machen. Das kommt der menschlichen Denkweise am
nächsten. Und sowieso, den Code an Ort und Stelle zu kommentieren. Mein
Mitarbeiter hatte nie eine Rückfrage an mich deswegen. Auch wenn das
länger dauert, man kann es in der Doku später nachsehen. Und die paar
Bytes Text machen doch den Kohl auch nicht fett.
Oft habe ich erlebt, daß bewußt und in voller Absicht nichts
dokumentiert wird: Ein Mitarbeiter in einer letzten Firma, wo ich nach
Doku fragte, tippte lächelnd mit dem Finger an seine Stirn, wie man
einen Vogel zeigt, und sagt, das ist alles hier drinnen.
In einer früheren Firma rümpften auch stets ältere Mitarbeiter die Nase,
wenn es darum ging, mal fremden Code zu bearbeiten.
Wilhelm Ferkes schrieb:> Eine Software muß streng genommen an überhaupt keiner Stelle> dokumentiert sein, wenn sie funktioniert, und Abnahmen besteht. Wer> damit glücklich wird???
Die Abnahmen erfordern heutzutage aber in aller Regel ein Nachweis der
Dokumentation.
Stefan L. schrieb:> Die Abnahmen erfordern heutzutage aber in aller Regel ein Nachweis der> Dokumentation.
Das glaubst du doch sicher selbst nicht, daß ein Prüfinstitut oder ein
Kunde Quellcode zu sehen bekommen.
@ Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill)
>Mit ist ein konkretes militärisches Projekt bekannt, in dem die>Mitarbeiter eines Zulieferers gezwungen waren, streng>spezifikationskonform zu implementieren, obwohl sie wussten, dass es>einen so eklatanten Spezifikationsfehler gab, dass daraus sogar eine>massive Gefahr für Menschenleben resultierte.
Das ist wohl leider der Sinn MILITÄRISCHER Projekte. Kommt nur auf den
Standpunkt an. 8-(
MfG
Falk
Stefan L. schrieb:> Deswegen wird ja die Dokumentation geprüft, nicht unbedingt der> Quellcode.
Ach, die Bedienungsanleitung etwa. Vielleicht auch Lasten- und
Pflichtenheft.
Ja, da kann ein fremder Entwickler sich ja auch was zusammen kratzen,
oder besser am Kopf oder noch besser am Arsc* kratzen.
Wilhelm Ferkes schrieb:> Ach, die Bedienungsanleitung etwa. Vielleicht auch Lasten- und> Pflichtenheft.
Hast du schon einmal in letzter Zeit eine Sicherheitszertifizierung mit
dem TÜV mitgemacht? Da wird schon einiges mehr verlangt.
Ich bin eine faule Sau, muss ich zugeben. Deshalb schreibe ich meine
Doku gleich in die Quellen und extrahiere das dann mit Doxy in eine
schicke HTML. Ist einfach und wer das sieht hat erst mal Respekt. Ja,
der macht ja Doku und so umfassend...
Aber das Wichtigste für mich: Ich kann nach 3 Jahren noch sagen was da
läuft.
Stefan L. schrieb:> Hast du schon einmal in letzter Zeit eine Sicherheitszertifizierung mit> dem TÜV mitgemacht? Da wird schon einiges mehr verlangt.
Nein. Bei vielen Dingen wird sowas nicht verlangt.
Wilhelm Ferkes schrieb:> Nein. Bei vielen Dingen wird sowas nicht verlangt.
Das mag sein, aber sobald der TÜV ins Spiel kommt, hat man den ganzen
Kram am Hals.
Und dank SPICE, CMMI und was es nicht alles gibt braucht man nicht
einmal mehr den TÜV.
stiller Beobachter schrieb:> Ich bin eine faule Sau, muss ich zugeben. Deshalb schreibe ich meine> Doku gleich in die Quellen und extrahiere das dann mit Doxy in eine> schicke HTML. Ist einfach und wer das sieht hat erst mal Respekt. Ja,> der macht ja Doku und so umfassend...
Nein, du bist sicher keine faule Sau, aber jemand, der sich Gedanken um
die Dinge rundherum macht. Wie z.B. ich mit den Struktogrammen, und wenn
ich sie nur handgemalt als Papier abheftete. Immer noch besser als gar
nichts.
Stefan L. schrieb:> Das mag sein, aber sobald der TÜV ins Spiel kommt, hat man den ganzen> Kram am Hals.
Stefan, du hast sicher Recht, wenn es um solche Sachen geht. Darum
möchte ich mich ja auch gar nicht streiten. Dann braucht man eben mal
eine etwas andere Vorgehensweise.
Stefan schrieb:
> Das mag sein, aber sobald der TÜV ins Spiel kommt, hat man den ganzen> Kram am Hals.
Na ja, wir haben nicht nur eine TÜV Zertifizierung.
Das ist der Lacher von der Umsetzung.
Damit geht unser PM hausieren und lässt das Siegel auf ganzseitige
Werbung drucken.
Aber vielleicht irre ich mich und der TÜV kann auch schlimmer.
stiller Beobachter schrieb:> Na ja, wir haben nicht nur eine TÜV Zertifizierung.
Ich meinte eine echte Zertifizierung nach einer Sicherheitsnorm (wo es
um Menschenleben geht). Das hat nichts mit diesen dubiosen
"Zertifizierungen" zu tun, die es auf Webseiten und so etwas gibt und
auch nicht mit der ISO9001, die ja ziemlich sinnlos ist.
Und bevor hier wieder alles an Randdingen und Gesetzen auseinander
driftet:
Meine Aussage aus Sicht eines Entwicklers mit den Dirty-Dingen war hier:
Beitrag "Re: Umgang mit und Sinn von technischen Dokumenten"
Ist wohl auch im Sinne des TE.
Ich denke die oben erwähnte Norm dürfte dazugehören:
Bernhard S. schrieb:> Wird eine Entwicklung nach Normen (bsp. ISO/IEC 61508 o.ä.) durchgeführt> - mit dem dazugehörigen Papierkrieg - dauert's eben doppelt so lange wie> ohne. DAS will aber niemand bezahlen.
Deraufsichalleingestellte schrieb:
> Ich habe mal wieder den Fall, mich in ein System einarbeiten zu müssen,
Man kann übrigens mal ein wenig Zeit opfern und das Doxy drüberjagen.
Da tun sich manchmal Abhängigkeiten auf, an die denkt man gar nicht.
Gerade bei schlecht dokumentierten Code kann die Übersicht schon
manchmal helfen.
Stefan schrieb:
> Wird eine Entwicklung nach Normen (bsp. ISO/IEC 61508 o.ä.) durchgeführt
Aha.
Teil 3 der Norm IEC 61508 richtet sich an Software-Entwickler
sicherheitsgerichteter Systeme. Da viele Softwarefehler auf
Spezifikationsmängeln und mangelnder Transparenz in den Abläufen
basieren nehmen Entwicklungsprozesse und Methoden in der Norm einen
breiten Raum ein.
Quelle:
http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/analyseentwurf/articles/232343/?icmp=aut-artikel-artikel-60
Und was macht der TÜV da bei Euch?
Wilhelm Ferkes schrieb:> Das glaubst du doch sicher selbst nicht, daß ein Prüfinstitut oder ein> Kunde Quellcode zu sehen bekommen.
Wenn ein Code-Review von externen vorgeschrieben ist, dann schon. Sonst
gibts keinen Stempel/kein Zertifikat...
stiller Beobachter schrieb:> Ich bin eine faule Sau, muss ich zugeben. [..]> Aber das Wichtigste für mich: Ich kann nach 3 Jahren noch sagen was da> läuft.
Doxygen oder auch Javadoc sind schon eine gute Sache, wenngleich sie ein
paar grundsätzliche Modul/Strukturdiagramme nicht ersetzen können.
Mit einem halbwegs guten Modeller braucht man auch nicht viel machen -
die erzeugen aus C++ & anderen objektorientierten Sprachen
wunderherrliche Diagramme jedweder Art. Das notwendige Kleingeld mal
vorausgesetzt.
Wilhelm Ferkes schrieb:> Wie z.B. ich mit den Struktogrammen, und wenn> ich sie nur handgemalt als Papier abheftete. Immer noch besser als gar> nichts.
Ja, das sollte eigentlich schon jeder in petto haben. Allerdings werden
die mitunter nicht weiter gegeben. Gerade dann nicht, wenn Sourcen z.b.
verkauft werden.
stiller Beobachter schrieb:> Ich bin eine faule Sau, muss ich zugeben. Deshalb schreibe ich meine> Doku gleich in die Quellen und extrahiere das dann mit Doxy in eine> schicke HTML.
O ja, da haben wir wieder einen von der Sorte, die ich am liebsten mit
einem vergifteten Feudel erschlagen möchte. Dieses SCHEISS-Doxygen
erzeugt keine Dokumentation!! Wer sowas benutzt, meint daß es wohl
ausreichend sein müßte, anderen Leuten die Funktionsköpfe an den Kopf zu
werfen. Dokumentationen sind was anderes als bloße Extrakte aus einer
Quelldatei, sie sollen den SINN erklären.
TQXV* perform(void,void,long,char*,BMXFS**);
Ja, da kommt Freude auf, wenn man sowas in hübsches HTML gesetzt als
Doku lesen darf. Gelle?
Ich gehöre offenbar zu einer extremen Minderheit, die sich zuallererst
ein Konzept ausdenkt, anschließend Formate, Schnittstellen und
Strukturen definiert und erst dann mit dem Entwickeln des Zielsystems
beginnt. An dieser Stelle kann ich mir nen Seitenhieb auf die ganze
Unix/Linux-Zunft nicht verkneifen: Die sind absolut stolz darauf, daß es
für IHR Sytem kein wohldefiniertes API gibt, wie man es bei Windows
gewohnt ist. Sowas brauchen Meisterprogrammierer ja nicht, denn sie
beherrschen das Chaos.
Ich gebe noch eins zu bedenken: Manche Leute - insbesondere
Programmierer - glauben, sich durch ein besonders kryptisches Benehmen
unabkömmlich machen zu können und damit sich auf ihrem Arbeitsplatz was
Gutes zu tun. Wer dann mal die Hinterlassenschaft von so einem
aufarbeiten soll, der kommt gewiß ins Fluchen.
W.S.
Bernhard schrieb:
> Mit einem halbwegs guten Modeller braucht man auch nicht viel machen -> die erzeugen aus C++ & anderen objektorientierten Sprachen> wunderherrliche Diagramme jedweder Art. Das notwendige Kleingeld mal> vorausgesetzt.
BOUML http://bouml.free.fr/ oder andre UML Sachen?
Welche machen aus Code Flussdiagramme?
Das tät' mich ja mal interessieren, wegen meiner Faulheit.
W.S. schrieb:
> Dieses SCHEISS-Doxygen
Man muss das Programm auch beherrschen und nicht bloß rummotzen.
Wer hindert Dich daran alle notwendigen Infos im Kommentar zu
hinterlegen?
Was macht Du denn stattdessen?
W.S. schrieb:> Wer sowas benutzt, meint daß es wohl> ausreichend sein müßte, anderen Leuten die Funktionsköpfe an den Kopf zu> werfen.
Nein, eigentlich nicht. Der Sinn dieser Tools wäre schon auch, dass
Funktionen (als auch deren Parameter) vernünftige Namen gegeben werden
und dass diese kurz (wenn nötig) beschrieben werden.
> An dieser Stelle kann ich mir nen Seitenhieb auf die ganze> Unix/Linux-Zunft nicht verkneifen: Die sind absolut stolz darauf, daß es> für IHR Sytem kein wohldefiniertes API gibt, wie man es bei Windows> gewohnt ist.
Also ich hatte das absolute Vergnügen einen Bug (unter Windows) zu
jagen, der dann doch in der API saß - FEHLERHAFTE Dokumentation ist
schlimmer als keine.
Unter Linux habe ich wenigstens die Möglichkeit mir die Sourcen dahinter
anzuschauen - da weiß ich wenigstens woran ich bin. Bei MS kann ich nen
Bugreport schreiben und dann passiert mal Ewigkeiten - schon erraten? -
NIX.
W.S. schrieb:> Ich gebe noch eins zu bedenken: Manche Leute - insbesondere> Programmierer - glauben, sich durch ein besonders kryptisches Benehmen> unabkömmlich machen zu können und damit sich auf ihrem Arbeitsplatz was> Gutes zu tun.
Ich hab Programmierer gesehen die wochenweise verschiedene Projekte
zugewiesen bekamen und das jeweils große. Sie wurden immer dort
eingesetzt wo gerade "Land unter" war.
Wer glaubt sich durch "Kryptik" unersetzlich zu machen opfert jeden
Urlaub und die Möglichkeit Arbeit abzutreten - das ist IRRE und
GRÖSSENWAHN.
W.S. schrieb:
> Ich gebe noch eins zu bedenken: Manche Leute - insbesondere> Programmierer - glauben, sich durch ein besonders kryptisches Benehmen> unabkömmlich machen zu können und damit sich auf ihrem Arbeitsplatz was> Gutes zu tun. Wer dann mal die Hinterlassenschaft von so einem> aufarbeiten soll, der kommt gewiß ins Fluchen.
Diese Personengruppe ist mir bekannt, aber das wird beim Einchecken vom
Teamleader rausgeschmissen.
Was ist denn Deine Aufgabe wenn man fragen darf?
stiller Beobachter schrieb:> Schade ich mache hauptsächlich C/C++ und Assembler :-(
MagicDraw kann C++ handlen, auch Reverse Engineering soweit ich weiß (Es
gibt eine C++ Edition).
stiller Beobachter schrieb:>> FEHLERHAFTE Dokumentation ist schlimmer als keine.>> Schwierig, denn Fehler können korrigiert werden.
Ja, aber nach dem ersten groben Doku Fehler kannst du der nicht mehr
umfassend vertrauen - was hast du dann gewonnen? Bei viel verwendeten
API's gehts ja noch... aber sonst?
Hattest du schon mal eine völlig veraltete Doku zu einer Software? Du
"liest" dich ein und findest doch nichts. IRRE.
W.S. schrieb:> stiller Beobachter schrieb:>> Ich bin eine faule Sau, muss ich zugeben. Deshalb schreibe ich meine>> Doku gleich in die Quellen und extrahiere das dann mit Doxy in eine>> schicke HTML.>> O ja, da haben wir wieder einen von der Sorte, die ich am liebsten mit> einem vergifteten Feudel erschlagen möchte. Dieses SCHEISS-Doxygen> erzeugt keine Dokumentation!! Wer sowas benutzt, meint daß es wohl> ausreichend sein müßte, anderen Leuten die Funktionsköpfe an den Kopf zu> werfen. Dokumentationen sind was anderes als bloße Extrakte aus einer> Quelldatei, sie sollen den SINN erklären.
Der Sinn soll sich schon aus gut gewählten Funktions- und Variblennamen
ergeben. Zusätzliche Doku kann natürlich hilfreich sein, aber was
spricht dagegen diese eben genau hier (wo sie auch hingehört) zu
platzieren und mit Doxy auszulesen?
> TQXV* perform(void,void,long,char*,BMXFS**);>> Ja, da kommt Freude auf, wenn man sowas in hübsches HTML gesetzt als> Doku lesen darf. Gelle?
Und wenn du dazu eine schöne Doku hast kommt Freude auf? Also bei mir
nicht, denn bei diesen Namen muss ich jedes mal erst die Doku suchen.
Echt toll!
> Ich gehöre offenbar zu einer extremen Minderheit, die sich zuallererst> ein Konzept ausdenkt, anschließend Formate, Schnittstellen und> Strukturen definiert und erst dann mit dem Entwickeln des Zielsystems> beginnt.
Entweder bist du ein Genie, oder du entwickelst dann einen Tunnelblick
und implementierst suboptimale Lösungen. Oft kommt man eben erst während
des Entwickelns auf die richtigen Knackpunkte, und dann sollte man auch
so flexibel sein etwas zu ändern. Natürlich sollte man sich schon vorher
Gedanken machen, aber so wie du das schreibst klingt das sehr nach
"Wasserfall".
> An dieser Stelle kann ich mir nen Seitenhieb auf die ganze> Unix/Linux-Zunft nicht verkneifen: Die sind absolut stolz darauf, daß es> für IHR Sytem kein wohldefiniertes API gibt, wie man es bei Windows> gewohnt ist. Sowas brauchen Meisterprogrammierer ja nicht, denn sie> beherrschen das Chaos.
Was heißt hier Chaos? Natürlich hat Linux ein API! Sogar ein recht
gutes, nämlich deswegen weil dieses schnell einmal überarbeitet wird
wenn es nicht passt.
> Ich gebe noch eins zu bedenken: Manche Leute - insbesondere> Programmierer - glauben, sich durch ein besonders kryptisches Benehmen> unabkömmlich machen zu können und damit sich auf ihrem Arbeitsplatz was> Gutes zu tun. Wer dann mal die Hinterlassenschaft von so einem> aufarbeiten soll, der kommt gewiß ins Fluchen.
Das stimmt, aber was hat das mit externer Dokumentation zu tun? Wenn er
will kann er auch die so schreiben, dass sie keiner mehr versteht. Ein
anderer Programmierer hingegen kann sein Programm so schreiben, dass es
sich fast wie von selbst lesen lässt, und man eigentlich keine oder nur
sehr wenig extra Dokumentation benötigt.
Gut, habe fertig.
1. Ohne Doku geht nicht
2. Mit schlechter oder alter Doku geht gar nicht.
3. Jemandem dem die Voraussetzungen fehlen die Doku zu verstehen,
sollte ein Chefposten angeboten werden.
4. TÜV meckert sowieso da dann mehr Geld fließt.
Gernot B. schrieb:> Der Sinn soll sich schon aus gut gewählten Funktions- und Variblennamen> ergeben.
Noch ein Fantasist. Aus in verschachtelten Strukten zusammen gesetzten
Namen, wenn es wenigstens 4 Schachteltiefen sind, sucht man sich über 30
Dateien hinweg den Wolf.
Wer mir sowas jemals wieder anbietet, dem nagele ich es echt mit einem
Zimmermannsnagel an die Stirn, nicht mit einem Kaugummi...
Wilhelm Ferkes schrieb:> Das glaubst du doch sicher selbst nicht, daß ein Prüfinstitut oder ein> Kunde Quellcode zu sehen bekommen.
Aber sicher kann ein Kunde Quellcode zu sehen bekommen. Machen wir oft
so. Ist eine Frage, wer an dem Produkt die Rechte besitzt, sollte vorher
vertraglich vereinbart werden.
Und damit die Soft-/Firmware dann auch Jahre später von eventuell
wechselnden Entwicklern gepflegt werden kann, ist eine saubere
Dokumentation eine notwendige Voraussetzung.
Kalter Kaffee.
Gun B. schrieb:> Ist eine Frage, wer an dem Produkt die Rechte besitzt, sollte vorher> vertraglich vereinbart werden.
Also Sonderregelung. Keinen Kommentar wert.
Wilhelm Ferkes schrieb:
> Aus in verschachtelten Strukten zusammen gesetzten> Namen, wenn es wenigstens 4 Schachteltiefen sind, sucht man sich über 30> Dateien hinweg den Wolf.
Was kennst Du für Leute? Sowas fliegt raus aus dem CVS.
W.S. schrieb:> Dieses SCHEISS-Doxygen erzeugt keine Dokumentation!!
Stimmt! Alleine ohne deine(!) Hilfe nicht. Du kannst dort allerdings
soviel Text hinterlegen in deinem Quellcode, der dann schön extrahiert
wird und dann(!) ergibt das sehr wohl eine brauchbare Dokumentation.
Wenn dein Text denn verständlich und aussagekräftig ist.
Geschenkt wird dir das aufschreiben mit Doxygen nicht.
Wilhelm Ferkes schrieb:> Gun B. schrieb:>>> Ist eine Frage, wer an dem Produkt die Rechte besitzt, sollte vorher>> vertraglich vereinbart werden.>> Also Sonderregelung. Keinen Kommentar wert.
Hä? Da iss nix sondergeregelt, das hast du in sämtlichen Unternehmen, ob
Automotive oder chemische Industrie, wo Projekte mit Kontraktoren in
Zusammenarbeit passieren.
Schon in zig Unternehmen mit vielen Projekten als Entwickler gemacht und
erlebt, keine Ausnahme, sondern die Regel.
Alleine dieses Jahr bei zwei unserer Kontraktoren wieder die Regel.
Abgesehen davon gibt's Whitebox-Tests, wo vieles offengelegt wird.
Die BAM oder der TÜV wollen manchmal auch wissen, was geht.
Geheimhaltungsvereinbarungen unter Kontraktoren sind die Regel, nicht
die Ausnahme.
So lange es nicht um IP der Kontraktoren geht, gibt es keinen Grund
Entwicklungen nicht zu dokumentieren.
@ 900ss
...genau das meine ich.
1. Man muss nicht ständig zwischen den Programmen wechseln,
sondern schreibt die Doku mit in den Code
2. Das Codebackup hat auch alle Dokuversionen
Gun B. schrieb:> Hä? Da iss nix sondergeregelt, das hast du in sämtlichen Unternehmen,
Dann kennst du halt andere Unternehmen als ich. Da ist doch nichts
schlimm dran. In meinen Code schaute bisher jedenfalls niemand, und erst
recht nicht in die Codekommentierungen. Außer mein Kollege, der sich
freute.
Wilhelm Ferkes schrieb:> Gun B. schrieb:>>> Hä? Da iss nix sondergeregelt, das hast du in sämtlichen Unternehmen,>> Dann kennst du halt andere Unternehmen als ich. Da ist doch nichts> schlimm dran. In meinen Code schaute bisher jedenfalls niemand, und erst> recht nicht in die Codekommentierungen. Außer mein Kollege, der sich> freute.
Delphi, Visteon, Ford, Saab, Mittelständler und die AG, in der ich heute
seit vielen Jahren arbeite.
Abgesehen davon habe ich die letzten Tage mit buildroot eine Toolchain
für einen Toshiba ARM aufgesetzt und das U-Boot reingeflasht. Bis alles
lief, dauerte es etwas. Wenn ich mir schon das nicht aufschreibe, ich
wette, in 3 Monaten fängt's an zu bröckeln. Drei Jahre später ist einem
nicht mehr klar, was man im Detail heute alles konfiguriert hat.
Peinlich, wenn der Kunde dann eine Änderung will und man selbst schon
nicht mehr weiss, wie man die ganze Kiste rudimentär ans Laufen gebracht
hat.
Geht nix über saubere Arbeit. Muss sicher nicht alles haarklein
dokumentiert werden, aber der Rahmen des "Wie habe ich es gemacht"
sollte da sein. Man wird es sich selbst danken.
Na, dann mal eine gute Nacht, der Grill hat mich heute Abend geschafft
;-)
Gun B. schrieb:> Delphi, Visteon, Ford, Saab, Mittelständler und die AG, in der ich heute> seit vielen Jahren arbeite.
Wir haben in Deutschland einen großen Anteil an unbekannteren kleinen
Mittelständlern. Viele Menschen haben die Namen noch nie gehört. Ich
glaube, sie machen aber fast 90% des Marktes aus.
Gun B. schrieb:> Drei Jahre später ist einem> nicht mehr klar, was man im Detail heute alles konfiguriert hat.
[..]
> Geht nix über saubere Arbeit. Muss sicher nicht alles haarklein> dokumentiert werden, aber der Rahmen des "Wie habe ich es gemacht"> sollte da sein. Man wird es sich selbst danken.
Vollste Zustimmung!
Zum Thema "Haarklein": bekam mal einen Code, da war jede(!) Zeile
kommentiert -> mühsam...
stiller Beobachter schrieb:> Ja, habe ich jetzt auch gefunden.> 150$ geht ja noch.
Die Personal Edition wirds nicht können - schon eher die Professional...
Wilhelm Ferkes schrieb:> Wir haben in Deutschland einen großen Anteil an unbekannteren kleinen> Mittelständlern. Viele Menschen haben die Namen noch nie gehört. Ich> glaube, sie machen aber fast 90% des Marktes aus.
Ohne Zweifel richtig, aber was willst du damit sagen?
Gun B. schrieb:> Ohne Zweifel richtig, aber was willst du damit sagen?
Daß viel "auf Teufel komm raus" einfach nur gewurstelt wird.
Ein Gerät muß einmal einen EMV-Test bestehen, und alles drum herum davor
und dahinter ist einfach nur "verbrannte Milch und Langeweile".
Wilhelm Ferkes schrieb:
> Ein Gerät muß einmal einen EMV-Test bestehen, und alles drum herum davor...
Fehlendes oder fehlerhaftes Grundkonzept kann ich da nur als Ursache
vermuten. Das sind vermutlich die Mittelkleinbetriebe wo drauflos
basteln und später die P-Hefte lesen. Ja, ist eine Variante. Die werden
das schon abnehmen, die brauchen das ja. Das ist unprofessionell und
sollte nicht toleriert werden.
