Benutzt ihr UML in größeren Projekten?
-
Das wird doch irgendwann total unübersichtlich, wenn 100 oder mehr Objekte vorhanden sind. Setzt ihr UML in irgend einem größeren Project sinnvoll ein?
-
Im Design und in der Planung ja, und später auch zur Dokumentation.
Im Design/Planung beschränkt es sich jedoch häufig auf Handskizzen.
-
Mit UML bildest Du nicht dein kopmplettes System in einem Modell ab - das geht natürlich nicht.
UML ist in vielen Bereichen der Projektabwicklung wichtig und nötig. In der Anforderungsanalyse/Analyse erstellst Du für die konrekten Anforderungen Use-Cases um diese wiederum mit dem Auftraggeber zu diskutieren(Use-Cases versteht jeder). Später wenn Dein Projekt in die Design Phase kommt, modellierst Du Deine Software. Natürlich modellierst Du nicht Dein ganzes System in einem Klassendiagramm, sondern je nach komplexität in beliebig vielen. Zum Beispiel bei einem Warenwirtschaftssystem ensteht ein Klassendiagramm für die Persistentzschicht und eins für die Geschäftslogik der Materialverwaltung. Später designst Du ganz genau einzelne Prozessabläufe mit Sequenzdiagrammen.
-
Macht jemand das wirklich so in seiner Firma? Der Code Ändert sich doch sowieso schneller, wie jede Doku die nicht im Code steht. Wenns dann ein paar neue Funktionen oder Klassen gibt, dann stimmt das UML Diagramm schon wieder nciht mehr und müsste nachträglich geändert werden...
-
Frager schrieb:
Macht jemand das wirklich so in seiner Firma? Der Code Ändert sich doch sowieso schneller, wie jede Doku die nicht im Code steht. Wenns dann ein paar neue Funktionen oder Klassen gibt, dann stimmt das UML Diagramm schon wieder nciht mehr und müsste nachträglich geändert werden...
Du erzeugst z. B. Code aus Deinem Modell - MDA. Allgemein kann man sagen, je kleiner das Projekt desto unwichtiger ist die Modellierung. Hast Du ein Projekt mit zeitgleich > 20 Entwickler und mehr als einem Jahr Laufzeit, dann muss man das Projekt vernünftig planen, sonst geht das wie die meisten Großprojekte in die Hose. Du redest auch nur von Klassendiagrammen. In einem Projekt gibt viele weitere wichtige Diagrammtypen.
Das klassische sequentielle Pflichtenheft ist out - heutzutage nutzt man den Unified Process.
-
Software Engineer schrieb:
...Das klassische sequentielle Pflichtenheft ist out - heutzutage nutzt man den Unified Process.
Eigentlich ist UP auch schon lange out!
Danach kam der OEP (Objekt Engineering Process) füs SW Eng.
Dann kam PLM (Product Lifecycle Management) unter Prozess Reifegradmodellen (CMMI, SPICE, V-Modell-XT) für SYS Eng.
Jetzt ist der State-of-Art - Requirements Engineering, Feature Modeling, Middleware und Reifegradmodelle fürs Sys Eng.
-
Software Engineer schrieb:
Frager schrieb:
Macht jemand das wirklich so in seiner Firma? Der Code Ändert sich doch sowieso schneller, wie jede Doku die nicht im Code steht. Wenns dann ein paar neue Funktionen oder Klassen gibt, dann stimmt das UML Diagramm schon wieder nciht mehr und müsste nachträglich geändert werden...
Du erzeugst z. B. Code aus Deinem Modell - MDA. Allgemein kann man sagen, je kleiner das Projekt desto unwichtiger ist die Modellierung. Hast Du ein Projekt mit zeitgleich > 20 Entwickler und mehr als einem Jahr Laufzeit, dann muss man das Projekt vernünftig planen, sonst geht das wie die meisten Großprojekte in die Hose. Du redest auch nur von Klassendiagrammen. In einem Projekt gibt viele weitere wichtige Diagrammtypen.
Machst du das in deinem Job so, oder hast du gelernt, dass man es so machen soll?
Prof84 schrieb:
Eigentlich ist UP auch schon lange out!
Danach kam der OEP (Objekt Engineering Process) füs SW Eng.
Dann kam PLM (Product Lifecycle Management) unter Prozess Reifegradmodellen (CMMI, SPICE, V-Modell-XT) für SYS Eng.
Jetzt ist der State-of-Art - Requirements Engineering, Feature Modeling, Middleware und Reifegradmodelle fürs Sys Eng.
Spricht für Qualität
-
Sollte man auch IACRM einsetzen, wenn die HLEEM nicht zu hoch ist, oder besser RHAH?
-
Das Design ist die Lösung ohne Implementierung
Implementieren kann jeder gerade das Designen ist das spannende. Umso komplexer das Projekt umso weniger möglich ohne Architektur...
-
Prof84 schrieb:
Software Engineer schrieb:
...Das klassische sequentielle Pflichtenheft ist out - heutzutage nutzt man den Unified Process.
Eigentlich ist UP auch schon lange out!
Danach kam der OEP (Objekt Engineering Process) füs SW Eng.
Dann kam PLM (Product Lifecycle Management) unter Prozess Reifegradmodellen (CMMI, SPICE, V-Modell-XT) für SYS Eng.
Jetzt ist der State-of-Art - Requirements Engineering, Feature Modeling, Middleware und Reifegradmodelle fürs Sys Eng.BINGO!!!
-
Prof84 schrieb:
Software Engineer schrieb:
...Das klassische sequentielle Pflichtenheft ist out - heutzutage nutzt man den Unified Process.
Eigentlich ist UP auch schon lange out!
Danach kam der OEP (Objekt Engineering Process) füs SW Eng.
Dann kam PLM (Product Lifecycle Management) unter Prozess Reifegradmodellen (CMMI, SPICE, V-Modell-XT) für SYS Eng.
Jetzt ist der State-of-Art - Requirements Engineering, Feature Modeling, Middleware und Reifegradmodelle fürs Sys Eng.Wow, wieviel Zuschlag müssen deine Kunden denn pro Schlagwort zuzahlen. Ich kenne
einige Vertriebler die üben das zutexten von Kunden mit Phrasen richtiggehend.