UML - Proces de dezvoltare, partea 1

Odată ce am decis să construim software-ul de care avem nevoie, de la început vom întâlni diferite elemente, datorită UML putem face o fază de modelare destul de detaliată, care va ajuta echipa de dezvoltare.
Cu toate acestea, există și alți factori care sunt legați de UML Deși nu au legătură cu construirea diagramelor, unul dintre acești factori este metodologia de dezvoltare software a proiectului pe care urmează să îl realizăm.
Metodologii
Când începeți un proiect, cel mai normal lucru este că există membri ai echipei care doresc să înceapă să dezvolte și să codeze soluția încă din prima zi, totuși acest tip de nerăbdare trebuie oprit imediat, nu numai pentru că este imposibil să știți care sunt acestea se va concentra asupra dezvoltatorilor, dar adaugă și un factor de presiune pentru a vedea rezultate „tangibile” într-un timp scurt.
Ce se întâmplă astăzi, avem mare cadre de muncă care promite să reducă orele de dezvoltare atunci când se utilizează instrumentele lor, cu toate acestea, dacă proiectul nostru nu este bine concentrat, vom ajunge să lucrăm mai mult decât este necesar, reparând ceea ce a fost deja făcut în momentele inițiale.
A metodologie Ne ajută să construim pașii pe care îi vom face pentru a realiza construcția proiectului pe care l-am conceput, pe parcursul diferitelor faze ale metodologiei alese, vom avea spațiu pentru colectarea informațiilor, modelarea soluției , diferitele cazuri de utilizare și în cele din urmă începutul codării.
Avem două variante în acest moment:

• Metoda veche.
• Metoda recentă.

Fiecare dintre ele a generat suficiente informații pentru a putea descrie procesul de construcție al unui proiect.
Să vedem primul dintre ei.
Metoda veche
Această metodă la momentul respectiv a făcut ca etapele să se întâmple una după alta, simplificând astfel modul în care a fost confruntată problema, atunci ce este realizat a fost să definească o serie de etape și să stabilească cadouri pentru a le realiza pe fiecare.
Datorită acestei simplificări, atunci când a apărut o problemă într-o etapă ulterioară, dar problema a fost derivată dintr-o etapă anterioară, a fost necesar să se rupă practic estimările proiectului pentru a o lua de la capăt.
Datorită separării fiecărei etape, a fost obișnuit să se găsească cazuri în care dezvoltatorul nu a lucrat niciodată cu proiectantul sau cu modelatorul de sistem, divorțând astfel software-ul de persoana care a conceput funcționalitățile.
Să vedem următorul grafic care descrie un proces realizat cu această metodologie:

Acesta este un proces în cascadă, își ia numele, deoarece fiecare etapă curge după alta și pentru a începe o nouă etapă este necesar să o finalizați pe cea actuală, așa cum am menționat mai devreme, această abordare are dezavantaje severe.
Cu aceasta încheiem această primă parte a tutorialului, știm deja puțin mai multe despre modul în care a funcționat metodologia pentru dezvoltarea software-ului în vremurile străvechi, în partea următoare vom vedea metodologiile recente și alte aspecte importante ale procesului de dezvoltare.
Las aici partea 2 a acestui tutorial V-a plăcut și ați ajutat acest tutorial?Puteți recompensa autorul apăsând acest buton pentru a-i oferi un punct pozitiv