UML - Proces de dezvoltare, partea 2

Odată ce știm cum au funcționat metodologiile de dezvoltare ale unui proiect sau sistem în cele mai vechi timpuri, putem lua în considerare diferitele erori și puncte periculoase pentru echipă care au avut.
Pe măsură ce suntem ființe evolutive, având atâtea probleme cu limitările deja ridicate în prima parte a tutorialului, începe modificați metodologia, Nu mai există o separare strictă a etapelor, ci mai degrabă se caută colaborarea echipei, unde fiecare membru participă la dezvoltarea etapelor, de exemplu, dezvoltatorii ajută la colectarea informațiilor, proiectanții și modelatorii din dezvoltare etc.
Metoda recentă
Așa cum am anticipat la începutul tutorialului, metoda recentă ne permite să implementăm colaborare în fiecare etapă a dezvoltării, ajutând acest lucru să crească înțelegerea proiectului în ansamblu în cadrul echipei, pentru o mai bună înțelegere și înțelegere, vom avea soluții mai bune care vor avea nevoie de mai puține ajustări atunci când codificăm software-ul.
Deși totul poate părea o dovadă a punctelor contra, trebuie să evidențiem unele probleme care pot fi prezente în procesul nostru de dezvoltare, astfel încât să vedem că suntem încă departe de un mod perfect de a face un proiect.
Unul dintre primele probleme Ceea ce putem constata este lipsa de participare a membrilor echipei, deși aceasta este din ce în ce mai puțin, putem găsi totuși oameni timizi cărora le este frică să-și ofere părerea, așa că sunt lăsați deoparte, slăbind starea cunoștințelor colective.
Un alt punct este că mulți manageri de proiect trebuie să ofere progresul proiectului clienților sau utilizatorilor, astfel încât este dificil de spus că analiza este deja finalizată și că dezvoltarea a început; Stabilirea acestor tipuri de limite poate fi contraproductivă, deoarece poate genera așteptări incorecte și poate pune presiune pe echipă.
RAD3
Acest metodologie își ia numele de la acronimul pentru „Dezvoltare și distribuție rapidă a proiectării aplicațiilor”, Care ar rămâne ca dezvoltare de proiectare și distribuție rapidă a aplicațiilor.

După cum vedem în graficul anterior, această metodologie ne permite să integrăm 3 zone de execuție În acest fel, etapele importante ale dezvoltării proiectului nu sunt izolate, astfel încât un dezvoltator poate accesa date importante ale proiectului în momentul în care acestea sunt generate, la fel cum un analist poate interveni în alte etape.
Odată ce totul este în conformitate cu prima livrare a proiectului, cu aceasta vom obține feedback-ul necesar într-un timp mai scurt decât folosind vechea metodologie și cu aceasta, pot fi încorporate corecțiile și îmbunătățirile sugerate de utilizatorul final.
După cum putem vedea, în ciuda diferitelor etape, această abordare metodologică ne oferă spațiu pentru a genera Diagramele UML concentrând astfel ideile într-un spațiu cu un limbaj de înțeles pentru toate părțile.
Cu aceasta terminăm această a doua parte a tutorialului, unde am învățat cum să încorporăm metodologia în dezvoltările noastre și, de asemenea, să ne ajute cu UML.
Partea 1 a acestui tutorial

Procesul de dezvoltare UML Partea 1

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