UML - Udviklingsproces, del 2

Når vi ved, hvordan udviklingsmetoderne for et projekt eller system fungerede i oldtiden, kan vi tage højde for de forskellige fejl og farlige punkter for teamet, der var haft.
Da vi er evolutionære væsener, der har så mange problemer med de begrænsninger, der allerede er rejst i den første del af selvstudiet, begynder det at ændre metodikken, Der er ikke længere en streng adskillelse af stadierne, men der søges snarere teamets samarbejde, hvor hvert medlem deltager i udviklingen af ​​stadierne, for eksempel hjælper udviklerne med at indsamle oplysninger, designere og modellerere i udvikling mv.
Seneste metode
Som vi forventede i begyndelsen af ​​selvstudiet, tillader den nylige metode os at implementere samarbejde på alle trin i udviklingenNår vi hjælper dette med at øge forståelsen af ​​projektet som helhed i teamet, til større forståelse og forståelse, får vi bedre løsninger, der kræver mindre justeringer, når softwaren kodes.
Selvom alt kan virke som et bevis på punkter imod, skal vi fremhæve nogle problemer, der kan være til stede i vores udviklingsproces, så vi kan se, at vi stadig er langt fra en perfekt måde at lave et projekt på.
En af de første problemer Hvad vi kan finde er den manglende deltagelse af teammedlemmerne, selvom dette er mindre og mindre, kan vi stadig finde genert mennesker, der er bange for at give deres mening til kende, så de bliver ladt til side, hvilket svækker tilstanden af ​​kollektiv viden.
Et andet punkt er, at mange projektledere skal give projektets fremskridt til klienter eller brugere, så det er svært at sige, at analysen allerede er ved at blive afsluttet, og udviklingen er startet; At sætte disse typer grænser kan være kontraproduktivt, da det kan generere forkerte forventninger og lægge pres på teamet.
RAD3
Dette metodik får sit navn fra akronymet for "Hurtig applikationsdesignudvikling og distribution”, Som vil forblive som designudvikling og hurtig distribution af applikationer.

Som vi ser i den foregående graf, giver denne metode os mulighed for at integrere 3 udførelsesområder På denne måde er de vigtige stadier i projektudviklingen ikke isoleret, så en udvikler kan få adgang til vigtige projektdata på det tidspunkt, det genereres, ligesom en analytiker kan gribe ind i andre faser.
Når alt er i overensstemmelse med projektets første levering, med dette vil vi opnå den nødvendige feedback på kortere tid end ved hjælp af den gamle metode, og med dette kan rettelser og forbedringer foreslået af slutbrugeren indarbejdes.
Som vi kan se, på trods af de forskellige faser, giver denne metodiske tilgang os plads til at generere UML -diagrammer dermed fokusere ideerne i et rum med et forståeligt sprog for alle parter.
Hermed afslutter vi denne anden del af selvstudiet, hvor vi har lært, hvordan vi kan indarbejde metodologi i vores udvikling og også hjælpe os med UML.
Del 1 af denne vejledning

UML -udviklingsproces del 1

Kan du lide og hjælpe denne vejledning?Du kan belønne forfatteren ved at trykke på denne knap for at give ham et positivt punkt