Mal ne Frage an die Architekten unter euch...

[bulla]

Da in 6 Stunden meine SoftwareTechnik-Klausur ansteht und ich aufgrund des Semesterferienlags mal wieder nicht schlafen kann, überkam mich im Zuge des Powerlernens folgende Frage:

Inwieweit wird der SWT-Vorlesungsstoff in der realen Welt angewandt?
Prof`s vermitteln natürlich immer nur ideale Szenarien, beste Lösungen usw. (Aus diesem Grund hasse ich BWL, nix anwendbar und trotzdem brauch ich nen Schein, grml).

In den Vorlesungen kamen z.b. Sachen dran wie:
CRC-Karten
Statecharts
Uml und alles was damit zusammenhängt
Use-Cases usw. usf.

Ist das alles auch nur Bockmist, den man nicht unbedingt weiter vertiefen muss, oder ist da eine Menge dran?

Auch würde mich in diesem Zuge interessieren, welche Mittel z.b. für ein kleines/mittleres/grosses Projekt mit wenig/etwas mehr/ganz viel Personal eingesetzt werden.

Nächtliche Grüsse wünscht
bulla :)

[Trap]

Ich glaub da hängt die Antwort mehr davon ab wen du fragst, als davon was die Sachen richtig eingesetzt wert sind.

UML ist keine Methode, sondern reine Notation. Sie ist kaum weniger kompliziert als die entsprechende Notation in den Programmiersprachen und meiner Meinung nach nur geringfügig übersichtlicher.
Das ganze sind eigentlich nur Arbeitsmittel, solange man keine Softwareentwicklungsmethode gelernt hat in der diese Mittel sinnvoll eingesetzt werden, ist das ganze Wissen darüber ziemlich nutzlos.

Wenn du mal ein Konstrastprogramm dazu haben willst mach dich über extreme programming schlau. Ich halte von den ganzen zusätzlichen Notationen, Formalitäten und Regeln nicht soviel.
Was nicht automatisch vom Computer kontrolliert wird, wird von den Programmierern irgendwann nicht beachtet und schon hat man einen Bug. Außerdem hat man mit den getrennten Notationen für Design und Implementation (und Dokumentation bildet eine 3.) das Problem das man extrem viel Aufwand darauf verwenden muss alles konsistent zu erhalten, oder was öfter passiert, der Code ist die einzige verlässliche Dokumentation, Design- und Doku-Zeug sind nur zusätzlicher Aufwand ohne Nutzen.

[Trap]

Noch ein Link zu ein paar anderen Meinungen:
http://c2.com/cgi/wiki?UnifiedModelingLanguage

[Crushinator]

Original geschrieben von Trap
(...) Wenn du mal ein Konstrastprogramm dazu haben willst mach dich über extreme programming schlau. Ich halte von den ganzen zusätzlichen Notationen, Formalitäten und Regeln nicht soviel. (...)
Das Ärgerliche an extreme programming ist, daß es nur solange gut funktioniert, bis ein paar von den Architekten des Projektes nicht mehr da sind. Dann entsteht nämlich ein nicht zu unterschätzender Bedarf an Einarbeitung von ggf. neu dazu gekommenen Leuten, die u.U. Monate bis Jahre dauert und während dieser Zeit oft zu Fehlentscheidungen und Bugs aufgrund mangelnder Kenntnis von Zusammenhängen führen kann, wenn diese Neulinge das Projekt auch noch während der Einarbeitung pflegen sollen. Durch die Angst vor Letzterem entstehen dabei oft solche Situationen, in denen Anwendungen bloß nicht mehr gepflegt werden bzw. von keinen Innovationen profitieren, weil es ja "Never touch a running system" heißt. Desweiteren kann man mit Notationen eindeutig besser in einer Runde über anstehende Erweiterungen oder Beseitigung von Bugs diskutieren, weil eben nicht zwangsläufig alle diskutierenden auch Programmierer sein müssen, und sie deshalb einwenig Schwierigkeiten hätten anhand des Quellcodes eine(n) implementierte(n) Logik/Aufbau zu verstehen.

Ich selbst bin seit dem ich mich an kommerziellen Projekten erinnern kann am Extrem-Programm0ring, und das müßten ca. 10 oder 11 Jahre sein. Inzwischen entscheide ich mich bei Projekten, die nicht von einem Mann allein realisiert werden können, ganz klar für saubere technische Dokumentation/Notation ganz ohne Case-Tools und sonstigem Teulfelswerkzeug, noch bevor eine einzige Zeile implementiert würde. Die Implementation selbst findet dann auch noch auf alle Fälle eigenhändig statt, um einfach das Handwerk nicht zu verlernen. Zugegebenermaßen kann man diese immense Zeitaufwendung nicht bei allen relevanten (Mehrmann-) Projekten aufbringen, weil das manch Release-Termin einfach nicht hergibt.

[Trap]

Vor 10-11 Jahren ein extreme programming Projekt? Gibt es das überhaupt schon so lange? Populär und mit Tool-Unterstützung gibt es das doch eigentlich nur in der Java-Community, oder?

Für mich gibt es bei anderen Notationen als Programmcode nur eine sinnvolle Möglichkeit: Sie wird automatisch aus dem Programmcode erzeugt und Veränderungen in der anderen Notation automatisch in den Programmcode zurückgeführt. Alles andere bedeutet, dass die andere Notation potentiell falsch ist und das man Arbeitszeit mit langweiliger und sehr monotoner Arbeit füllen muss.

Wenn man aus dem Programmcode alle Details löscht, die in der UML auch nicht vorkommen, unterscheiden sich beide eigentlich nurnoch durch ein paar Kästchen und Pfeile.

[Crushinator]

Original geschrieben von Trap
Vor 10-11 Jahren ein extreme programming Projekt? Gibt es das überhaupt schon so lange? Populär und mit Tool-Unterstützung gibt es das doch eigentlich nur in der Java-Community, oder?
Den Begriff, die XP-Community und die Orietierungshilfen, die man auch als Richtlinien bezeichnen kann, gibt's ja auch erst seit ein paar Jahren. Was aber nicht heißt, daß es - besonders in kleineren Teams - nicht schon vorher ähnlich verfahren wurde, weil unklare Kundenvorstellungen und böse Release-Termine es anders gar nicht erlaubt hätten.

[bulla]

Also mein Prof. ist Verfechter der XP-Theorie und hat seiner Meinung nach auch etwas zur Verbreitung beigetragen. :)

Allerdings schreibt er auch, dass XP sinnvoll nur in kleinen Teams (ein gutes Dutzend Leute) zufriedenstellend funktioniert.

Wie gross ist denn ein Softwareprojekt-Team so im Schnitt?


edit: Ach so, kann mir jemand gute Seiten oder Literatur nennen, die sich ausführlich mit Hierarchischer Anordnung von Graphen befasst? Also planare Graphen, Springembedder, Treelayouter, GO TO usw. usf.?

Das ist nämlich mein Thema dieses Semester...
http://www.cs.tu-bs.de/ips/tmuecke/sep/layout/index.html