Innholdsfortegnelse
Når vi vet hvordan utviklingsmetodikkene til et prosjekt eller system fungerte i eldgamle tider, kan vi ta hensyn til de forskjellige feilene og farlige punktene for teamet vi hadde.Siden vi er evolusjonære vesener, som har så mange problemer med begrensningene som allerede er reist i den første delen av opplæringen, begynner det å endre metodikken, Det er ikke lenger en streng adskillelse av trinnene, men det er snarere et samarbeid mellom teamet, hvor hvert medlem deltar i utviklingen av trinnene, for eksempel utviklerne hjelper til med innsamling av informasjon, designere og modellerere i utvikling osv.
Nylig metode
Som vi forventet i begynnelsen av opplæringen, lar den nylige metoden oss implementere samarbeid på alle trinn i utviklingenNår vi hjelper dette med å øke forståelsen for prosjektet som helhet i teamet, til større forståelse og forståelse, vil vi ha bedre løsninger som trenger mindre justeringer når vi programmerer programvaren.
Selv om alt kan virke som et bevis på poeng mot, må vi fremheve noen problemer som kan være tilstede i utviklingsprosessen, slik at vi ser at vi fremdeles er langt fra en perfekt måte å gjøre et prosjekt på.
En av første problemer Det vi kan finne er mangelen på deltakelse fra teammedlemmene, selv om dette er mindre og mindre, kan vi fortsatt finne sjenerte mennesker som er redde for å gi sin mening, så de blir stående til side, noe som svekker tilstanden til kollektiv kunnskap.
Et annet poeng er at mange prosjektledere må gi prosjektet fremgang til klienter eller brukere, så det er vanskelig å si at analysen allerede er ferdig og utviklingen startet; Å sette denne typen grenser kan være kontraproduktivt, da det kan generere feil forventninger og legge press på laget.
RAD3
Dette metodikk får navnet sitt fra akronymet for "Rask applikasjonsdesignutvikling og distribusjon”, Som vil forbli som designutvikling og rask distribusjon av applikasjoner.
Når alt er i samsvar med den første leveransen av prosjektet, med dette vil vi få nødvendig tilbakemelding på kortere tid enn å bruke den gamle metoden, og med dette kan korrigeringer og forbedringer foreslått av sluttbrukeren inkorporeres.
Som vi kan se, til tross for de forskjellige stadiene, gir denne metodiske tilnærmingen oss plass til å generere UML -diagrammer dermed fokusere ideene i et rom med en forståelig språk for alle parter.
Med dette avslutter vi denne andre delen av opplæringen, hvor vi har lært hvordan vi kan inkorporere metodikk i utviklingen vår og også hjelpe oss med UML.
Del 1 av denne opplæringen
UML utviklingsprosess del 1
Likte og hjalp du denne opplæringen?Du kan belønne forfatteren ved å trykke på denne knappen for å gi ham et positivt poeng
