Es gibt jedoch andere Faktoren, die mit der UML zusammenhängen, obwohl sie nicht mit der Konstruktion von Diagrammen zu tun haben. Einer dieser Faktoren ist die Methodik der Softwareentwicklung des Projekts, das wir durchführen werden.
Methoden
Zu Beginn eines Projekts gibt es normalerweise Teammitglieder, die vom ersten Tag an mit der Entwicklung und Codierung der Lösung beginnen möchten. Diese Art der Ungeduld muss jedoch sofort ausgeschaltet werden, nicht nur, weil man nicht weiß, was sie tun werden Fokus Entwickler, sondern fügt auch einen Druckfaktor hinzu, um “greifbare” Ergebnisse in kurzer Zeit zu sehen.
Was heute passiert, wir haben große Arbeitsrahmen, die versprechen, die Stunden der Entwicklung zu verkürzen, um ihre Werkzeuge zu verwenden. Wenn unser Projekt jedoch nicht gut fokussiert ist, werden wir am Ende mehr als nötig daran arbeiten, das zu reparieren, was zu Beginn getan wurde.
Eine Methodik hilft uns, die Schritte zu konstruieren, die wir unternehmen werden, um die Konstruktion des Projekts durchzuführen. Während der verschiedenen Phasen der gewählten Methodik haben wir Raum für das Sammeln von Informationen, die Modellierung der Lösung und die verschiedenen Fälle der Verwendung und schließlich der Beginn der Codierung.
Wir haben an dieser Stelle zwei Varianten:
- Alte Methode
- Neueste Methode
Jeder von ihnen hat genügend Informationen generiert, um den Bauprozess eines Projekts zu beschreiben.
Schauen wir uns den ersten an.
Alte Methode
Zu dieser Zeit bestand diese Methode darin, die Phasen nacheinander ablaufen zu lassen, wodurch die Art und Weise, in der das Problem auftrat, vereinfacht wurde. Anschließend wurden eine Reihe von Phasen definiert und für jede Phase Runden festgelegt .
Aufgrund dieser Vereinfachung, wenn ein Problem zu einem späteren Zeitpunkt auftrat, das Problem jedoch von einem früheren Zeitpunkt abgeleitet wurde, musste es die Projektschätzungen praktisch brechen, um neu zu starten.
Aufgrund der Trennung der einzelnen Phasen war es üblich, Fälle zu finden, in denen der Entwickler nie mit dem Designer oder Modellierer des Systems zusammengearbeitet hatte, wodurch die Software der Person, die die Funktionen entwickelt hatte, getrennt wurde.
Sehen wir uns die folgende Grafik an, die einen mit dieser Methodik durchgeführten Prozess beschreibt:
Dies ist ein Kaskadenprozess, der seinen Namen hat, wenn jede Phase nach der anderen abläuft. Um eine neue Phase zu beginnen, müssen wir die Gegenwart beenden. Wie bereits erwähnt, bringt dieser Ansatz schwerwiegende Nachteile mit sich.
Damit beenden wir den ersten Teil des Tutorials. Wir wissen bereits ein bisschen mehr darüber, wie die Methodik für die Softwareentwicklung in der Vergangenheit funktioniert hat. Im nächsten Teil werden wir aktuelle Methodiken und andere wichtige Aspekte des Entwicklungsprozesses kennenlernen.
Ich verlasse hier Teil 2 dieses Tutorials 
