UML - Processo di sviluppo, parte 1

Una volta deciso di costruire il software di cui abbiamo bisogno, fin dall'inizio ci imbatteremo in diversi elementi, grazie a UML possiamo fare una fase di modellazione abbastanza dettagliata che aiuterà il team di sviluppo.
Tuttavia, ci sono altri fattori che sono legati alla UML Sebbene non abbiano a che fare con la costruzione di diagrammi, uno di questi fattori è la metodologia di sviluppo software del progetto che andremo a realizzare.
Metodologie
Quando si avvia un progetto, la cosa più normale è che ci siano membri del team che desiderano iniziare a sviluppare e codificare la soluzione dal primo giorno, tuttavia questo tipo di impazienza deve essere immediatamente spento, non solo perché è impossibile sapere cosa siano concentrarsi sugli sviluppatori, ma aggiunge anche un fattore di pressione per vedere risultati "tangibili" in breve tempo.
Quello che succede oggi, abbiamo un grande quadri di lavoro che promettono di ridurre le ore di sviluppo quando si utilizzano i loro strumenti, tuttavia se il nostro progetto non è ben focalizzato finiremo per lavorare più del necessario riparando ciò che è stato già fatto nei momenti iniziali.
UN metodologia Ci aiuta a costruire i passi che andremo a compiere per realizzare la costruzione del progetto che abbiamo ideato, durante le diverse fasi della metodologia scelta, avremo spazio per la raccolta delle informazioni, la modellazione della soluzione , i diversi casi d'uso e infine l'inizio della codifica.
A questo punto abbiamo due varianti:

• Vecchio metodo.
• Metodo recente.

Ognuno di loro ha generato informazioni sufficienti per poter descrivere il processo di costruzione di un progetto.
Vediamo il primo di loro.
Vecchio metodo
Questo metodo all'epoca quello che faceva era far succedere le fasi una dopo l'altra, semplificando così il modo in cui si affrontava il problema, allora cosa è svolto è stato quello di definire una serie di tappe e stabilire le scadenze per realizzarle ciascuna.
A causa di questa semplificazione, quando un problema si verificava in una fase successiva ma il problema era derivato da una fase precedente, era necessario praticamente rompere le stime del progetto per ricominciare.
A causa della separazione di ogni fase, era comune trovare casi in cui lo sviluppatore non aveva mai lavorato con il progettista o il modellatore di sistema, separando così il software dalla persona che ha ideato le funzionalità.
Vediamo il seguente grafico che descrive un processo realizzato con questa metodologia:

Questo è un processo a cascata, prende il nome poiché ogni fase scorre dopo l'altra e per iniziare una nuova fase è necessario terminare quella attuale, come accennato in precedenza, questo approccio presenta gravi svantaggi.
Con questo concludiamo questa prima parte del tutorial, sappiamo già qualcosa in più su come funzionava la metodologia per lo sviluppo del software in tempi antichi, nella parte successiva vedremo metodologie recenti e altri aspetti importanti del processo di sviluppo.
Lascio qui la parte 2 di questo Tutorial Ti è piaciuto e hai aiutato questo Tutorial?Puoi premiare l'autore premendo questo pulsante per dargli un punto positivo