Hallo, also zuerst mal ein paar INfos von mir. Ingenieur E-Technik 16 Jahre in der Entwicklung in 4 verschiedenen Firmen gearbeitet, viele kennengelernt. alle Firmen im Bereich 20....200 Mitarbeiter, also Mittelstand. Probleme auf die ich immer wieder komme: --------------------------------------------- - keine oder fast keine Projektpläne, - kein Tracking und Info System zu Projekten - überhaupt keine Planung in der embedded Software - kein vernünftiges Informationssystem für Entwicklungskosten/ Zeiten - keine sauberen definierten Prozesse und Milestones Ich finde gerade im kleinen bis mittleren Mittelstand gibt es in den o.g. Bereichen große Lücken. Im Großunternehmen, oder im großen Mittelstand dagegen habe ich gerade in den organisatorischen Bereichen und im Prozess klare Pluspunkte gefunden. Gut, die haben natürlich auch Geld um sich entsprechende Tools und auch Schulungen zu leisten. Aus meiner Sicht und meinen Recherchen wäre hier auf jeden Fall Potential für eine entsprechendes Softwarepaket, natürlich bezahlbar für kleine Unternehmen. Es gibt unendlich viele Ingenieurbüros!!! bitte das ganze Thema nicht verwechseln mit - Bugtracking (z.B. Redmine) - Versionserwaltung - und ERP Systemen, da gibt es genügend und auch gute Sachen. Ich sehe das Tool in Bereich Prozessmanagement und die Vernetzung verschiedener Standardlösungen. Wie seht Ihr das ganze Thema? Gibt es Interessenten / mögliche Partner umso ein Thema anzugehen. Im ersten Schritt in einer Community/Forum oder Verein. Was sich vielleicht daraus ergibt wird man sehen. Gruss Karl-Heinz
"Im Großunternehmen, oder im großen Mittelstand dagegen habe ich gerade in den organisatorischen Bereichen und im Prozess klare Pluspunkte gefunden." So kann man es auch ausdrücken. Tatsächlich dürfte die Wahrheit schon irgendwo in der Mitte liegen. Wenn man vor lauter Planung keine Änderungen mehr machen kann, weil das die Planung über den Haufen werfen würde, hat man nichts gewonnen. Das Leben ist nun mal chaotisch. Gruss Axel
vielfach wäre man ja schon froh, wenn am anfang eines projektes, der umfange, oder das ziel halbwegs definiert wäre :-)
Ich kann das nur so bestaetigen... Die letzten zwei Firmen (ca. 50 Leute) hatten all das nicht... Hardware ist durch Zuruf am Telefon erstellt worden... kein Pflichtenheft... Software genauso... obwohl der Proframmierer ein guter ist und wusste was gefragt und zu tun ist... dann noch eine PC Software mit Datenbankinterface, GUI und Grafik... keine Doku vorhanden... auch alles auf Zuruf...
Oh, Gott, was ich schon alles bei Entwicklern gesehen habe. *Überhaupt keine Systemdokumente obwohl umfangreiche Projekte (ganz zu schweigen von übersichtlicher Plannung bzw. Milestones etc.) *Nur ein ausgedruckter Bestückungsplan mit markierten Bauteilen, das ist schon alles an Dokumentation *Wenn irgendwo Widerstand getausch wird, weiß keiner zwei Wochen später warum *Da werden Bauteile im Schaltplan ausgetauscht weil billige Alternative da ist, keiner prüft die Kompabilität genau: weitere Probleme die Zeit kosten *Ein Oszilloskop für 20 Entwickler *Keine Dokumentierung der Fehler: die haben alles irgendwie im Kopf...lol *Keine Meetings: keiner weiß was der Andere macht oder beide machen das Gleiche Unsere moderne Raubtieirtschaft bietet da eine ganze Bandbreite an Perversitäten an
Nichts Dokumentieren so macht man sich unentbährlich in der Firma. Zur Doku bei Software: Read The Source Code.
Hallo, ich arbeite auch in einer Fa. < 50 Mitarbeiter und muss sagen dass es bei uns sehr strukturiert zu geht. Wir entwicklen hauptsächlich für die Automobilindustrie. Evtl. steigert das Anwendungsgebiet der SW/HW auch die Ansprüche. Könnte mir vorstellen, dass es in der Medizintechnik und Luftfahrt noch strenger zu geht. Aus welchen Branchen stammen deine Erkenntnisse? @Axel: Muss dir recht geben. Zu viel Dokumentation und nur Meetings sind auch nicht optimal! @Helmut Lenzen: Manchmal stimmt das. Ein gut kommentierter Quellcode ist manchmal aufschlussreicher als eine Doku. Aber gerade bei großen Projekten und zum schnellen Einstieg kann die Doku sehr hilfreich sein.
Kleine Firmen haben die Tools nicht weil sie kein Geld dafür haben, sondern weil die Leute dort unstrukturiert arbeiten wollen. Wenn man in so einer Firma solche tools einführen will, bricht sofort ein Aufstand los. Egal wie gut das ist. Und wenn man mal Struktur hineingebracht hat wird so gearbeitet, daß diese sofort wieder Makulatur ist. Meine Erfahrung. White
karl-heinz schrieb: > Probleme auf die ich immer wieder komme: > --------------------------------------------- > - keine oder fast keine Projektpläne, > - kein Tracking und Info System zu Projekten > - überhaupt keine Planung in der embedded Software > - kein vernünftiges Informationssystem für Entwicklungskosten/ Zeiten > - keine sauberen definierten Prozesse und Milestones Na sowas. Das kenn ich doch. Aber wir bei Fraunhofer dürfen das ja auch. :-P Das kreative Chaos halt.
Das Genie beherrscht das Chaos der normale Dokumentiert.
Bin in einem großen Konzern, habe aber auch das Gefühl, dass in den vielen kleineren und mittleren Projekten vieles kreuz und quer und ziemlich unorganisiert läuft. Weiter oben werden natürlich auf Gemeinkosten bis ins kleinste Detail Standardprozesse kreiert, optimiert etc. Bis das alte jedoch mal halbwegs in der Basisarbeit implementiert ist, steht schon wieder was komplett neues auf dem Programm. Was unten dann ankommt sind eine Hand voll zentraler Milestones, die dann in MS Project schön ausgeschmückt werden, um die Führungskräfte zufriedenzustellen.
Kann mal jemand der weiß wie man dokumentiert sagen wie man es denn richtig bzw besser machen könnte? Ein wenig erkenne ich mich selbst hier wieder(habe zwar noch nicht mit vielen Leuten an einem Projekt gearbeitet) aber das leidige Thema Dokumentation macht mir auch immer zu schaffen(Das eine gute Doku für einen selbst wichtig sein kann habe ich auch schon gemerkt wenn man Quellcode mal ne Weile liegen läßt und sich dann wieder reeinfuchsen muss) Gibts für sowas Standardsoftware? Oder bedeutet Doku einen Text in Word zusammenzuhacken
"Oder bedeutet Doku einen Text in Word zusammenzuhacken" Vorher (also bevor Code geschrieben wird) schon. Danach finde ich aber, dass der Code sauber dokumentiert sein muss. Und es gibt natürlich ein paar Grundregeln. Habe mich gerade wieder durch zwei Dutzend Dateien VHDl schlagen dürfen, bei der die Signalnamen durch die verschiedenen Module gewechselt haben und kein Signal beschrieben war. Darf der Lieferant jetzt nachbessern. Habe die Schnautze voll. Gruss Axel
Für die Dokumentation des Codes selbst gibt es Tools wie Doxygen und Javadoc. Natürlich muss man seine Module und Funktionen auch mit vernünftigen /** Quelltext-Kommentaren */ versehen - dazu sind viele Programmierer bekanntlich zu faul ;-) Dann gibt es da noch die schriftliche Doku (z.B. als PDF) über das, was die Software macht und wie sie zum Beispiel mit Gegenstellen Daten austauscht. Also u.a. Beschreibung der Datenformate, vielleicht ein Sequenzdiagramm um Abläufe zu verdeutlichen (UML ist halt schon zu was gut). Wenn man sich fragt: "Welche Infos wollte ich haben, wenn ich selbst mich neu in diese Software einarbeiten wollte?" - dann kommt man schon dahinter, was da reingehört.
> Für die Dokumentation des Codes selbst gibt es Tools wie Doxygen und
Javadoc.
Und Zitronenfalter falten Zitronen.
MaWin schrieb: >> Für die Dokumentation des Codes selbst gibt es Tools wie Doxygen und > Javadoc. > > Und Zitronenfalter falten Zitronen. "Natürlich muss man seine Module und Funktionen auch mit vernünftigen /** Quelltext-Kommentaren */ versehen - dazu sind viele Programmierer bekanntlich zu faul" Was an dem Satz war nicht zu verstehen? ;-)
Plan- Was ist das? Dokumentation- Hahahahaahaahahaaha- Der war gut! Firma: etwa oehh 3000 Leutchen weltweit.
Bei Software meinte ich ja noch nicht mal runter bis zum Source Code... Wir haben ein Benutzerinterface welches schon erklaerungbeduerftig ist. Seit kurzem gibt es ein Handbuch welches oberflaechlich das Program beschreibt. Jedoch gibt es zur Zeit noch keine Erklaerungen warum welche Einstellung zu taetigen ist und welchen Effekt das hat. Geschweige denn das es ein ordentliches Lastenheft gibt... Jedoch muss ich sagen das das Chaos oft auch einfach Jobs hervorbringt. Eigentlich koennte unsere Firma mit ca. 30% weniger Leute auskommen...
OOOOH JAAA! Das Thema kenne ich auch seit Jahren. Als Entwickler muss ich jedesmal wieder fluchend feststellen, dass man einen Haufen Zeit und Ressourcen sparen könnte, wenn man denn nur einmal anständig ein paar Tage in ein Pflichtenheft oder eine Dokumentation stecken würde. Am Ende kostet der Verzicht darauf oft viele Wochen an Zeit, die man sinnvoller verwenden könnte und Nerven, die man mit unnötigem Krach belastet, weil am Ende das nicht mehr gilt, was am Anfang so alles in den Raum geworfen wurde. Da kann man sich ja dann auch viel einfacher vorwerfen lassen "..da haben wir doch drüber gesprochen!", weil schriftlich nichts festgehalten wurde! Es geht hier nicht um Softwaretools, die man zur Projektverwaltung nutzt, auch ist der Kostenfaktor seit Linux nicht mehr so das Problem, ein SVN oder Apache usw. kann heute jede Fa. einsetzten. Nöö, es geht einfach darum, dass Manager immer noch glauben, dass eine anständige Projektplanung am Anfang eines jeden Projekts zu viel Zeit und Geld kostet, die sie dann während und am Ende des Projekts drauflegen müssen, weil man dann feststellt, dass es doch sinnvoller gewesen wäre. Jedes Grundlagenkapitel über Software Engineering sagt natürlich, dass eine gründliche Spezifikation und der Design Entwurf mehr Zeit kostet als die Implementierung. Aber: WER WILL DAS DENN SCHON HÖREN? Ich kann nur sagen, dass ich in den letzten Jahren oft genug Krach mit meinem Vorgesetzten hatte - GENAU DESWEGEN - und am Ende trotzdem jedesmal recht hatte. Ändert nix, als Entwickler ist man halt -sorry- der Arsch, oder "das Kamel, auf dem die Kaufleute reiten"! So, genug gejammert, Hautpsache die eigentliche Entwicklerarbeit macht Spass! Deshalb mein Mitgefühl und mein Credo: "Wehrt euch! - anständig" Gruss Gunb
Daniel Duesentrieb schrieb: > Jedoch muss ich sagen das das Chaos oft auch einfach Jobs hervorbringt. > Eigentlich koennte unsere Firma mit ca. 30% weniger Leute auskommen... Na ich weiß nicht - sobald die Kaufleute mal anfangen, ihre "Prozesse" einzuführen und zu pflegen, gehen diese 30% locker für den Verwaltungs-Wasserkopf drauf. ;-)
funky schrieb: > Kann mal jemand der weiß wie man dokumentiert sagen wie man es denn > richtig bzw besser machen könnte? [...] > Gibts für sowas Standardsoftware? Oder bedeutet Doku einen Text in Word > zusammenzuhacken Software gibts für jeden Furz. Eine gute Entwicklerdoku erkennt man daran daß sich ein projektfremder Entwickler kurz einlesen kann und das ganze betreuen/weiterentwickeln kann.
Damian schrieb: > vielfach wäre man ja schon froh, wenn am anfang eines projektes, der > umfange, oder das ziel halbwegs definiert wäre :-) Kann ich nur zustimmen. Kein Pflichtenheft, was das Gerät können soll wurde "mal eben telefonisch" geklärt, 5 Monate später kommt noch ne größere Änderung, dazu Verwaltungschaos. Unser Entwickler würde manchmal schon gerne in der Firmenzentrale etwas aufräumen...
> Was an dem Satz war nicht zu verstehen?
Och, verstanden haben wir die gnadenlose Naivität schon, in der er
offenbar geschrieben wurde.
Du bist schon (d|t)rollig.
>Kann ich nur zustimmen. Kein Pflichtenheft, was das Gerät können soll >wurde "mal eben telefonisch" geklärt, 5 Monate später kommt noch ne >größere Änderung, dazu Verwaltungschaos. Da gäbe es noch die Unterscheidung zwischen Lasten- und Pflichtenheft. Normalerweise erstellt das Produktmanagement das Lastenheft. Im Lastenheft stehen alle für's Produktmanagment wichtigen Eigenschaften des Produktes. Der Entwickler schreibt als Antwort auf das Lastenheft das Pflichtenheft in dem er sich zur Umsetzung zu den aus dem Lastenheft gewünschten Eigenschaften "verpflichtet", die technisch auch machbar sind. Eselsbrücke: - Das Lastenheft ist dem Entwickler eine Last. - Er antwortet darauf mit dem Pflichtenheft ( wenn er schlau ist, mit der kleinst möglichen Pflicht )
Wenn man mal von Produktion, Banken und Versicherungen absieht - viele Software ist gar nicht lange genug im Einsatz, als daß man das Gefühl bekäme, ein ordentliches Projekt hätte sich gelohnt.. Namche wird auch nie fertig und wieder verworfen.. :-) Wenn schon wenig Doku, dann macht ein gutes Design (best things are always simple) - die Fehler am Projektanfang sind die teuersten in der Behebung.
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.