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?
:
Verschoben durch Admin
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.
@ Falk Brunner. Ist ja alles richtig, was Du schreibst. Aber ehrlich, wie sieht die Realität aus? PS.: Laß Dir mal die Doku zu MS-DOS kommen ;-)
@ 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.
Deswegen wird ja die Dokumentation geprüft, nicht unbedingt der Quellcode.
@ 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.
Stefan schrieb:
> Ich meinte eine echte Zertifizierung
Ja, welche ISO/EN?
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?
Der Artikel beschreibt doch ziemlich gut, was der TÜV fordert.
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?
Bernhard schrieb:
> FEHLERHAFTE Dokumentation ist schlimmer als keine.
Schwierig, denn Fehler können korrigiert werden.
stiller Beobachter schrieb: > BOUML http://bouml.free.fr/ oder andre UML Sachen? Ich kenne keine kostenfreie und wirklich Gute Lösung - leider. stiller Beobachter schrieb: > Welche machen aus Code Flussdiagramme? > Das tät' mich ja mal interessieren, wegen meiner Faulheit. Kleine Übersicht: http://www.jeckle.de/umltools.htm MagicDraw ist einen Blick Wert IMO ;).
Bernhard schrieb:
> MagicDraw ist einen Blick Wert IMO ;).
Schade ich mache hauptsächlich C/C++ und Assembler :-(
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.
Ja, habe ich jetzt auch gefunden. 150$ geht ja noch.
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:
> Aus in verschachtelten Strukten zusammen gesetzten Namen,
An welche Programmiersprache denkst Du dabei?
Stefan L. schrieb: > Deswegen wird ja die Dokumentation geprüft, nicht unbedingt der > Quellcode. Absolut richtig.
Schaltungswächter schrieb: > An welche Programmiersprache denkst Du dabei? Was ist denn so weit verbreitet und üblich? Vielleicht C?
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.
Schaltungswächter schrieb: > Was kennst Du für Leute? Nu ja, man hat eben mal irgendwo gearbeitet...
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.
Wilhelm Ferkes schrieb: > Daß viel "auf Teufel komm raus" einfach nur gewurstelt wird. Da stimme ich dir zu. Ist leider wahr.
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.