www.mikrocontroller.net

Forum: Ausbildung, Studium & Beruf .in jeder Entwicklungsabteilung das gleich Chaos.oder bin ich das Problem?


Autor: karl-heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Damian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielfach wäre man ja schon froh, wenn am anfang eines projektes, der 
umfange, oder das ziel halbwegs definiert wäre :-)

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nichts Dokumentieren so macht man sich unentbährlich in der Firma.
Zur Doku bei Software: Read The Source Code.

Autor: gehheim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: White (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Genie beherrscht das Chaos der normale Dokumentiert.

Autor: Flash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: funky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für die Dokumentation des Codes selbst gibt es Tools wie Doxygen und
Javadoc.

Und Zitronenfalter falten Zitronen.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? ;-)

Autor: Haribohunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Plan- Was ist das?
Dokumentation- Hahahahaahaahahaaha- Der war gut!

Firma: etwa oehh 3000 Leutchen weltweit.

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Gunb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sowas?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was an dem Satz war nicht zu verstehen?

Och, verstanden haben wir die gnadenlose Naivität schon, in der er 
offenbar geschrieben wurde.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du bist schon (d|t)rollig.

Autor: fast core (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 )

Autor: ok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.