Archiv verlassen und diese Seite im Standarddesign anzeigen : Moderne Softwareentwicklung Java / C
Hallo,
aus gegebenen Anlass (Berufseinstieg, Diskussion mit betreuendem Professor) interessieren mich die zwei folgenden Fragen:
Wie wird heute in der Praxis (größeres Unternehmen, Programmierung von Mikrocontrollern für Automobilsensorik (Parkassistenzsysteme, Videoüberwachung, usw) ein C - Projekt verwirklicht? Folgende Punkte sind dabei besoners interessant:
- Anfertigen von Software-Requirements
- Design und Implementierung
- Durchführung von Softwaretests
- Softwarearchitektur
Man beachte hierbei, es geht um C und Mikrocontroller und entsprechende Sensoren.
Sind diese Punkte mit einem V-Modell vollständig abgedeckt? Welche Tools kann man dafür einsetzen und in welcher Phase? Wie geht man vor? Softwarearchitektur unter C und Mikrocontrollern???? wtf? Bitte gebt eure Erfahrungen / Kenntnisse wieder, so dass ich im Bezug darauf ein paar Anhaltspunkte zur Weiterbildung finden kann. (Gerne darf auch Literatur angegeben werden...)
************
Selbe Frage, nur gehts es dieses mal um Java und KEINE Mikrocontroller.
Ist der Einsatz von OOA/OOD/OOP und dann Testing noch von Relevanz, in der heutigen Zeit? Oder muss es immer RUP o.ä. sein?
Mein Prof. meint, OOA und OOD haben ausgedient, es spielt NUR noch UML eine Rolle! (?!?!????) Auf meine Bemerkung hin, dass UML als Modellierungssprache zur Beschreibung der Ergebnisse der OOA/OOD-Vorgänge genutzt wird und somit *alles miteinander im Einklang steht*, ist er daraufhin energisch ausgewichen und wollte halt von OOA/OOD nichts wissen...
Vielen Dank euch Allen im Voraus,
mfg.ts
Selbe Frage, nur gehts es dieses mal um Java und KEINE Mikrocontroller.
Ist der Einsatz von OOA/OOD/OOP und dann Testing noch von Relevanz, in der heutigen Zeit? Oder muss es immer RUP o.ä. sein?
Mein Prof. meint, OOA und OOD haben ausgedient, es spielt NUR noch UML eine Rolle! (?!?!????) Auf meine Bemerkung hin, dass UML als Modellierungssprache zur Beschreibung der Ergebnisse der OOA/OOD-Vorgänge genutzt wird und somit *alles miteinander im Einklang steht*, ist er daraufhin energisch ausgewichen und wollte halt von OOA/OOD nichts wissen...
Vielen Dank euch Allen im Voraus,
mfg.ts
Halte ich für Schwachsinn Oo
UML ist eine tolle sache... (man zeichnet lustig kästchen und pfeilchen haut das ganze dann in einen converter und herauskommen 300 ordner und dateien... und hier wirds dann wieder effizient mit rm -r * und man coded wieder von hand) (wobei man dagen muss das es schon wirklich "funktioniert" aus UML automatisiert in Java Code zu erzeugen)
Ich persöhnich halte UML für überbewertet , sicherlicht um grobe abläufe dem team oder dem kunden zu erklären ists super aber je genauer es wird desto mehr nähert man sich schon wieder an Prorammlogig zu schreiben und damit auch OOA und vorallem OOD (ist UML nicht sogar inzwischen V2.1 Turing komplett?)
Monger
2008-01-19, 00:11:51
Edit: hier stand Bullshit.
@Monger äh UML sollte eigentlich vor dem projektstart gemacht werden und nicht im nachhinein(obwohl das zum parkinschonschen gesetz passen würd falls das wer kennt[allways look busy])
Monger
2008-01-19, 12:20:08
@Monger äh UML sollte eigentlich vor dem projektstart gemacht werden und nicht im nachhinein(obwohl das zum parkinschonschen gesetz passen würd falls das wer kennt[allways look busy])
Das Problem ist nur: dass man bei Projektstart wirklich weiß wie die Software aussehen soll, passiert äußerst selten. Oft genug wird an jedem Feature dreimal rumgefeilt, oder man merkt halt, dass man eben doch nicht jede Kleinigkeit schon voraus bedacht hat, was dann auf das Klassenkonstrukt irgendwelche Auswirkungen hat. Und wenn erstmal die heiße Phase anfängt, zieht garantiert niemand mehr die Änderungen im UML Diagramm nach.
UML macht Sinn, wenn man mal schnell irgendeinen Zusammenhang am Flipchart illustrieren will, oder eben als Ergänzung zur Codedokumentation, damit man bei Folgeprojekten eine gewisse Übersicht hat, was man beachten muss. Aber als Entwicklungswerkzeug halte ich UML für arg überschätzt.
Und wenn erstmal die heiße Phase anfängt, zieht garantiert niemand mehr die Änderungen im UML Diagramm nach.
Das sollte man aber machen. UML Dokumentation ist ein stetiger Prozess. Deswegen ist es auch recht sinnvoll, das System wirklich in viele kleine Teil Aspekte zu zerlegen, die dokumentiert werden. Dann ist es nämlich einfacher, neue Dinge hinzuzufügen bzw. abzuändern.
Aber ich sehe das wie du, UML dient in erster Linie zur Dokumentation bzw. Kommunikation.
Das Problem ist nur: dass man bei Projektstart wirklich weiß wie die Software aussehen soll, passiert äußerst selten. Oft genug wird an jedem Feature dreimal rumgefeilt, oder man merkt halt, dass man eben doch nicht jede Kleinigkeit schon voraus bedacht hat, was dann auf das Klassenkonstrukt irgendwelche Auswirkungen hat. Und wenn erstmal die heiße Phase anfängt, zieht garantiert niemand mehr die Änderungen im UML Diagramm nach.
UML macht Sinn, wenn man mal schnell irgendeinen Zusammenhang am Flipchart illustrieren will, oder eben als Ergänzung zur Codedokumentation, damit man bei Folgeprojekten eine gewisse Übersicht hat, was man beachten muss. Aber als Entwicklungswerkzeug halte ich UML für arg überschätzt.
dafür gibt es die vorprojektpahse in welcher mit dem kunden erarbeitet werden muss was er will und wie er es will.... wie willst du sonst ein verbindliches angebot stellen wenn du nicht weißt wo probleme auftreten können und wie es geht? in der vorprojektphase werden natürlich auch zahlreiche probleme im vorhinein behandelt
weiters ist es auch der sinn agiler programmierung dass die dokumente im laufe der arbeiten angepasst werden falls sich etwas ändert (ja sogar beim XP wird die doku angepasst)... sonst könnte man ja garkein changemanagement fahren außer einen andauernden neustart des projektes mit den neuen erfahrungen (wird z.B. beim V Modell so gemacht, und hat auch seinen sinn und vorteile aber für "normale" software viel zu teuer)
Monger
2008-01-19, 15:30:20
dafür gibt es die vorprojektpahse in welcher mit dem kunden erarbeitet werden muss was er will und wie er es will.... wie willst du sonst ein verbindliches angebot stellen wenn du nicht weißt wo probleme auftreten können und wie es geht?
Tja, die Frage stellen sich die meisten Projektleiter auch. Wieso verspäten sich wohl die allermeisten Softwareprojekte?
Das Problem an Software ist: wenn man schon eine ganz präzise Vorstellung davon hätte wie das Produkt am Ende aussehen soll, hat es vermutlich schon jemand vorher gemacht.
Software ist immer auch ein gutes Stück weit Forschung, man steht ständig vor Problemen die einem völlig unbekannt sind. Wäre es nicht so, läge eine passende Musterlösung mit Sicherheit schon in irgendeiner Bibliothek rum. Der Kunde hilft einem meistens auch nicht weiter. Wenn der genau wüsste was er will, würde er es selber machen.
ein Kunde weiß zwar was er will aber nicht wie er es umsetzen will und kann. weiters ist es sinn der vorprojektphase alles zu erfragen was der kunde will und was einem unklar ist. wenn der kunde nicht weiß was er will dasnn sind wir experten dazu da ihm zu sagen was er "braucht" (z.b. bei webprojekten oft nötig)!
das verspäten der meisten softwareprojekte kommt von fehlerhaften projektmanagement in der vorprojektphase wie z.B: telling, gussing and accepting, weiters sind bisherige projektmangament verfahren welche nicht agil interagieren nicht dafür gedacht änderungen einzupflegen sodass änderungen nur mit großen aufwand möglich sind. die meisten softwareprojekte verspäten sich auch durch zu lange entscheidungszeiten beim kunden warte zeiten von mehreren monaten bis man ein ok bekommt sind normal. auch dient die vorprojektphase ja daszu die schwierigkeiten zu erkennen und einen zeitplan festzulegen. wie will man sonst ein kostendeckendes angebot erstellen? es werden die einzellnen arbeitspaktet des projektes erdacht und diese werden dann von den zuständigen geschätzt und auch risiken evaluiert. je höher der faktor der unsicherheit ist desto mehr sicherheiten müssen eingeplant werden. dass viele projekte scheitern liegt aber auch daran dass trotz erkennung von problemen einfach weitergemacht wird ohne änderungen und man so irgendwann auf der schnautze landet und mehrere millionen einfach eingestampft werden (yellow lights prinzip) das eine solche vorprojektpahse lange dauert ist wohl auch verständlich kann bis zu 50% der projektdurchlaufzeit betragen (vorallem bei großen firmen wo die wünsche von manchmal bis zu 50 entscheidungsträgern vereint werden müssen)
Monger
2008-01-19, 16:01:28
Wie gesagt: soweit die Theorie. Hab ich in der Praxis noch nicht erlebt, auch nicht vom hörensagen. In aller Regel sitzt einem die Firmenleitung im Nacken, und lässt einem keine Zeit, mal zwei Jahre nur über die Grundlagen zu brüten.
Und die Aufwandsabschätzungen sind meistens auch eher Pi mal Daumen als sonstwas.
Die Ausgangsfrage war ja: wie relevant sind solche Prozesse in der Praxis?
Soweit ich das eben beurteilen kann, eher wenig. Kleinere Projekte, die auf der grünen Wiese anfangen können sich das eher leisten, bei größeren Projekten in größeren Firmen schlägt man sich mit ganz anderen Problemen rum als der Softwarearchitektur selbst.
wo arbeitest du denn? T-Systems? ^^
Monger
2008-01-19, 17:48:01
wo arbeitest du denn? T-Systems? ^^
Ich glaube, das werde ich im Interesse meines Arbeitgebers besser verschweigen! ;)
Aber wir sind kein Einzelfall. Jede große Firma hat da die selben Schwierigkeiten, selbst Microsoft - und du kannst dir sicher sein: wenn irgendjemand äußerst akribisch in der Projektplanung ist, dann MS. Die reinen Softwarehäuser sind da in aller Regel schon deutlich weiter wie Firmen, die Software eher für den eigenen Gebrauch fabrizieren.
malte.c
2008-01-19, 23:49:14
Ist der Einsatz von OOA/OOD/OOP und dann Testing noch von Relevanz, in der heutigen Zeit? Oder muss es immer RUP o.ä. sein?
Weder noch. Es gibt auch eine ganze Reihe Prozesse (z.B. Extreme Programming), die sich dadurch auszeichnen, dass sie andere Werte zugrunde legen: http://agilemanifesto.org/
tokugawa
2008-01-20, 00:07:15
Welcher Prozeß funkioniert, hängt immer auch von den Leuten ab, die damit arbeiten, sowie die Branche und der Fachbereich, in dem es passiert.
Z.B. kann man Prozesse der Business-Software sicher nicht 1:1 übertragen etwa auf Unterhaltungs-Software/Spiele.
Es ist auch total vom Firmenklima abhängig. Ich weiß dass die Handvoll Spieleentwicklerstudios in Wien alle komplett andere Firmenkulturen haben und ihre Prozesse entsprechend unterschiedlich sind.
Vielen Dank für die zahlreichen Antworten und "Einblicke" hinter die Kulissen... :)
Mir tun sich weiterhin gewisse Fragen auf:
1) Viele von euch meinen, UML sei nur zur Kommunikations- und Präsentationszwecken geeignet usw... Sinn ist klar, sehe ich auch so. Aufstellen des ersten Konzeptes zur Diskussion, dann bissel Design (Patterns usw) ... schon klar. ABER(!), was wird denn nun in der Praxis bei größeren Firmen eingesetzt, wenn es um die komplette Softwareentwicklung geht? XP, wie jmd. hier sagte...?
Ergo: V-Modell, RUP usw für den "leitenten" Prozess der Entwicklung und Projektierung, UML als Hilfsmittel zur Kommunikation und Konzeption und Dokumentation? Oder wie läuft in der Praxis ein echtes Projekt (bereich Siemens, Daimler, Bosch)
2) Wie schaut es denn bei Siemens, Daimler, Bosch im Bereich Softwareentwicklung aus? V-Modell wird dort massiv genutzt - (Fakt), aber wie sieht es im Detail aus? Auf was wird besonders geschaut? Wo liegen die Eckpfeiler?
!!!UND!!! Wie sieht es im Bezug dazu mit der C- Programmierung aus? Welche Prozesse zur Projektierung, Tools zur Entwicklung usw werden eingesetzt?
(Ich komme aus der Java-Ecke, habe aber evtl. bald Chancen auf einen Job mit Schwerpunkt Softwareentwicklung in C für Mikrocontroller. Requierements, Testing und Coding als Stichwort im Telefoninterview sind gefallen - aber wie und mit welchen Tools wird dabei vorgegangen? Möchte mich gern intensiv vorbereiten, brauche dazu Anhaltspunkte...)
malte.c
2008-01-20, 05:11:09
ABER(!), was wird denn nun in der Praxis bei größeren Firmen eingesetzt, wenn es um die komplette Softwareentwicklung geht? XP, wie jmd. hier sagte...?
Falls Du meine Antwort meinst: Das bezog sich mehr darauf, dass es mehr Möglichkeiten bei der Prozessauswahl gibt, und dass nicht automatisch ein schlechtes Gewissen als Projektleiter haben muss, wenn man kein RUP oder V-Modell einsetzt. Ob große Firmen diese Flexibilität nutzen, kann ich nicht beurteilen. In den mir bekannten kleineren Teams (bis vielleicht 20, 30 Entwickler) ist es aber nicht unüblich, sich an agilen Methoden zu orientieren. Allerdings gibt es leider auch genug Teams, die das als Ausrede nutzen, um Cowboy Coding zu betreiben...
es kommt denke ich auch sher darauf an wie man seine mitarbeiter einschätzt, je nach qulität der mitarbeiter kann man ihnen auch sehr viel freiraum geben wie z.B. design by contract
Shink
2008-01-21, 08:53:50
Das schöne am RUP ist ja, dass so viele der beschriebenen Schritte/Iteration optional sind, dass selbst Extreme Programming darunter fällt.
Und wie sieht es in C - Projekten aus?
Ich meine die Sprache ist zwar alt, aber eben dennoch aktuell und aus den genannten Aufgabenfeldern des ThreadS. nicht wegzudenken (Mikrochips usw).
Wie wird denn da vorgegangen? Ich mein, es gibt viele Leute die C beherschen, und das bisschen V-Modell lernt man ja auch relativ zügig... was bleibt dann noch?
Ist dar gar nichts mehr? Bei modernen Java- bzw. .NET - Projekten kommen ja noch tausend Tools, Verfahren, Pattern zum Einsatz.
Testing: JUnit z.B.
EclipseUML als Designwerkzeug z.B.
JavaDOC als Doku-Tool z.B.
RUP, OOA/OOD als projektbegleitendes Verfahren z.B.
JBoss, Tomcat, Hibernate, Seam, Struts, usw...
Da gibt es sooo viel Zeugs. Aber was ist bei C und Mirkocontrollern? Kann das nun jeder Quereinsteiger, oder was zum Geier ist da noch????
Shink
2008-01-21, 11:38:35
cUnit gibt es; UML ist natürlich relativ lustlos bei einer nicht OO-Sprache. OOA/OOD kann man theoretisch ja auch bei einer nicht-OO Sprache machen, aber sagen wirs mal so: Modern programmieren mit C ist nicht so schön wie man es in der C#/Java-Welt kennt.
Da C eben bewusst auf einen kleinen Standardisierungsumfang reduziert ist, hält man sich meist an gewisse Hersteller um eine vollständige Programmierumgebung zu erhalten.
Mikrocontroller bringen ja meist ihren eigenen Compiler und oft auch ihre eigenen Test/Emulations/Entwicklungstools mit - oder auch nicht. Man darf aber auch nicht vergessen dass die Möglichkeiten eines Mikrocontrollers so etwas wie JBoss oder Hibernate nicht zuließen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.