vergessen hat einzupflegen und schon ist die Doku nicht mehr viel wert.
Gerrit
vergessen hat einzupflegen und schon ist die Doku nicht mehr viel wert.
Gerrit
Der letzte Satz bringt es auf den Punkt. Dieses Architekturdokument ist in sehr vielen Faellen nie erstellt worden. Eine Hazard Analysis schon gar nicht. In anderen Faellen hat man die Reihenfolge falsch gesetzt und das sind fast immer Managementfehler. Da haben sie die Leute ein interessantes Projekt durchziehen lassen und als alles lief, kam der Leiter und meinte "Habt Ihr fein gemacht, und jetzt schreiben wir die Doku". An der Stelle sinkt die Motivation des Teams auf den Nullpunkt.
-- Gruesse, Joerg http://www.analogconsultants.com/
Das geht nur ueber gruendliche Design Reviews und einen guten ECO Prozess. Fehler werden natuerlich immer gemacht, aber wertlos ist die Doku damit noch lange nicht.
Wichtig ist, den Leuten einzuimpfen, die Aenderung erst in der Doku zu machen und dann im Code. Nicht umgekehrt. Mache ich in der HW-Entwicklung auch so und dabei arbeite ich mit Checklists. Bei groesseren Projekten ist die Checklist ein Database File. Z.B. muss bei einem gerade in Arbeit befindlichen Projekt vermutlich noch eine Abschaltung fuer einen Schaltregler rein. Das kommt zuerst in den Module Spec, dann gleichzeitig auf die Checklist. Wenn der Kunde naechste Woche meint, er wolle das doch nicht und ich wuerde aus irgendeinem Grund vergessen, das umzusetzen (oder andernfalls das Einpflegen in das Schaltbild vergessen), wuerde ich spaeter ein nicht abgehaktes Kaestchen sehen. Das Teil ist ziemlich mission-critical, Luftfahrt, da darf sowas nicht schiefgehen.
-- Gruesse, Joerg http://www.analogconsultants.com/
eben nicht geht, anders hingegen schon. Also wird es funktionierend implementiert und vergessen die Doku anzupassen.
Solange die Doku nicht maschinell aus dem Code abgeleitet werden kann wird es IMMER Diskrepanzen geben, egal was du anstellst.
Gerrit
Full ACK, aber sowas von.
Ich hatte auch einen DOC-Extractor, der zog die Pseudocodes aus den Quellen raus...
Wolfgang
-- Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
Jau!
Jau2
Geht of(f)ensichlich nicht :)
Wolfgang
-- Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
spannungsversorgung. ;-)
-- mfg hdw
Der Satz davor allerdings auch!
Tja gegen Damager und deren Fehler ist halt kaum ein Kraut gewachsen.
Wolfgang
-- Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
Dann ist kurzes Burggrabentunken angesagt.
Man kann es zusaetzlich maschinell machen und dann vergleichen. Ausserdem gibt es gerade im SW-Bereich gute Hilfsmittel fuer Version Control auch in kleinen Inkrementen. Doch am Ende ist es alles eine Frage der Disziplin.
-- Gruesse, Joerg http://www.analogconsultants.com/
Ja, zusammen mit einer Z-Diode und einem Widerstand. Nennt sich
implementiert, oder?
Gerrit
:-)
Die Russen sahen das lockerer. Ein Russki-Netzteil hier hat mangels Crowbar nach dem Durchbratzen des Laengstransistors einen Prototypen mitgerissen und eine Rauchwolke produziert.
-- Gruesse, Joerg http://www.analogconsultants.com/
Es gibt nur leider Leute, die meinen, das reiche dann schon und man muesse keine weitere Doku erzeugen.
Doch. Selber einer werden und es richtig machen :-)
-- Gruesse, Joerg http://www.analogconsultants.com/
problemlos von der API Dokumentation aus auf andere Seiten verweisen.
-- > > [...] Du hast keine Buergerrechte, denn so etwas gibt es nicht. > Ach nein? Dann wirf doch mal 'Buergerrechte' in die Suchmaschine Deines > geringstens Misstrauens ein! "Buergerrechte": 543.000 Treffer, "Osterhase": 612.000 Treffer
Hallo Joerg,
Du schriebst am Sat, 20 Sep 2014 16:15:39 -0700:
...
...
[Beispiel]n man
n". Man
...
Ahso, also ganz gradeaus gemeint. (Das ist ja schon fast doppelt ironisch.)
en
r Art
tings.
...
Fleck...
ei
r nicht mehr
oren. Erst
...
wickeln.
-- -- ----------------------------------------------------------- -----------------------------------------------------------
Hallo Joerg,
Du schriebst am Sat, 20 Sep 2014 16:00:48 -0700:
lich. ...
auch
...
ist, aber
det
deren
es
en. ...
Die "heisse Nadel" trifft sicher zu, aber auch eine gute Organisation kann wichtige Vorbedingungen einfach ignorieren. Und manchmal sind die auch einfach noch unbekannt. (Letztens habe ich z.B. von einer interessanten Entwicklung gelesen, ein sog. "ReRAM", "resistive RAM". Speichert Daten durch Ausbildung von [mikro- bzw. nano-] Denriten zwischen Metallschichten in einem "Elektrolyt". Sagenhafte Speicherdichten weit jenseits von Flash, ebenso wurden damit schon enorme Lese- und Schreibgeschwindigkeiten erreicht. Auch der Datenerhalt wird optimistisch als besser als bei Flash beurteilt - aber halt unter welchen Bedingungen? Wurde da schon das thermische Verhalten
s, der auf der _ungeordneten_ Umschichtung von [Elektroden-] Material beruht,
biles
aar Monate so gefeiert wird, und ob das jemals als Produkt angeboten wird...)
...
ruiert und gebaut werden.
Ja, so ein Projekt habe ich gerade fast hinter mir. Es wurde alles sorgsam
dem Kunden durchgesprochen, alles festgelegt. Schon die Konstruktion brachte dann zutage, wie _wenig_ damit definiert
n, noch bevor irgendwas gebaut werden konnte.
auch mit der Inbetriebnahme nicht auf, weil sich die Mechanik nicht ohne weiteres an
ktion
, wie
ich
en doch
Jetzt bringst Du wieder was anderes herein. "Organisiertes Arbeiten" ist wieder eine andere Dimension als penible Dokumentation. Dokumentation kann die Organisation beschreiben, aber nicht erzeugen. Allenfalls kann die Organisation von der Dokumentation profitieren, indem sie die beschriebenen
ion"
dlich
...
Das geht sinnvoll nur zu zwei Zeitpunkten: vor Beginn und nach Ende der Entwicklung. Vor Beginn ist damit die aller Voraussicht nach zu erwartende Struktur der
stabil arbeiten, kann dann der Auslieferungsstand wieder erfasst,
bereitgestellt werden. Letzteres ist fast nochmal soviel Aufwand wie die Vorgabedokumentation.
-- -- ----------------------------------------------------------- -----------------------------------------------------------
Hallo Frank,
Du schriebst am Sun, 21 Sep 2014 06:00:15 +0200:
Na, immerhin die englische Wikipedia.
was bei
Aber gut, ich habe damit keine Erfahrung - das ist sowieso ein Verfahren
m Projekt.
Und doch habe ich Artikel gelesen, in denen genau das beschrieben war. Naja, "Papier ist geduldig"...
bt
bestehen dann aus einer Mischung von Programmcode und Beschreibung,
whlweise der reine Programmcode oder die Dokumentation extrahiert werden
eine
ausgestattet, vor allem fehlt da jede Verbindung der Kommentare (Dokumentation) zum Code (Funktion).
Das ist sowieso nochmal was ganz anderes, das hat mit dem Programmcode und
-- -- ----------------------------------------------------------- -----------------------------------------------------------
Sieghard Schicktanz schrieb:
Nein, literate programming ist noch was anderes. DAbei wird ausgehend
Schwafeldateien, eingebettet in eine Art Metasprache (wie LaTeX, HTML).
produktive Programmierarbeit aber eher nicht, weil der Code seine Struktur verliert bzw. man sie nicht zu Gesicht bekommt und der geneigte Schreiber wirklich zum Schwafeln verleitet wird. Zudem werden
dem
Metasprache eingebettet sein.
dazu, wo Kommentare im Quelltext bestimmte Tags enthalten, auf die der
dokumentieren, weil die API-Referenz nebenher entsteht. Also Kommentare im Code sind Doku nicht Code in der Doku.
Marc
[...]
Das kenne ich auch nicht.
Damit meinte ich, dass sie ueber den Lastpunkt geraten, wo die Last sie in den Stillstand zwingt. Oder auf gut Deutsch, abgewuergt.
Das hat nicht viel mit dem Luefterrad zu tun. Ein bestromter, aber stehender Asynchronmotor ist im Prinzip eine kurzgeschlossener Trafo. Irgendwann beginnt der Lack vom Kupferlackdraht rauszukommen, dampffoermig. Danach ist das Kupfer selbst dran.
-- Gruesse, Joerg http://www.analogconsultants.com/
[...]
Der Aufbau des Prototypen und dessen Tests gehoeren mit zur Entwicklung, sowas ist voellig normal. Muss mitdokumentiert werden.
Gegen nachtraeglich ist nichts zu sagen, solange es auch aufgenomen wird.
Eben, Doku erzieht zum organisierten Arbeiten.
Eben nicht. Das ist einer der Fehler, den Entwickler-Team immer wieder machen. Die Leute denken, sie koennten sich alles merken und finden alle Schmierzettel am Ende wieder. Ist fann aber nicht der Fall.
... und dies Anpassung muss dokumentiert werden.
Dann ist es zu spaet. Man findet einen Notizzettel nicht mehr, der Kollege Mueller hatte zwischenzeitlich gekuengigt und man kann ihn nicht mehr Fragen, der Kollege Schmitz hat Urlaub genommen und ist die naechsten vier Wochen im Himalaya, und so weiter.
-- Gruesse, Joerg http://www.analogconsultants.com/
Hallo Joerg,
Du schriebst am Mon, 22 Sep 2014 06:33:33 -0700:
Dann darf ich wohl "Jungspund" zu Dir sagen?
[Stall]vom
Schon klar. Ich meinte allerdings mehr das Wortspiel "Stall (e) -> Stall (d) -> stable (e) -> stabil (d)" (wobei das Englische da gar doppeldeutig ist - eins der vielen Homonyme halt mal wieder.)
nn bei
?fter nicht mehr ...
?fter
ichdrehzahl,
und kann durchaus "Indianer spielen", wie das hier manchmal genannt wird (d.h. "Rauchzeichen geben"). (ja, sorry, ich _mag_ Wortspielereien.)
Genau. Das ergibt sich ja schon aus der deutschen Bezeichnung
-- -- ----------------------------------------------------------- -----------------------------------------------------------
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.