UML - Utvecklingsprocess, del 1

När vi väl har bestämt oss för att bygga den programvara vi behöver, kommer vi från början att stöta på olika element, tack vare UML vi kan göra en ganska detaljerad modelleringsfas som hjälper utvecklingsteamet.
Det finns dock andra faktorer som är relaterade till UML Även om de inte har att göra med konstruktion av diagram, är en av dessa faktorer mjukvaruutvecklingsmetodiken för projektet som vi ska genomföra.
Metoder
När du startar ett projekt är det mest normala att det finns teammedlemmar som vill börja utveckla och koda lösningen från dag ett, men denna typ av otålighet måste stängas av omedelbart, inte bara för att det är omöjligt att veta vad de är kommer att göra. fokusera på utvecklare, men lägger också till en tryckfaktor för att se "konkreta" resultat på kort tid.
Vad som händer idag har vi jättebra ramar arbete som lovar att minska utvecklingstiden när de använder sina verktyg, men om vårt projekt inte är väl fokuserat kommer vi att sluta arbeta mer än nödvändigt med att reparera det som redan gjordes i de första stunderna.
A metodik Det hjälper oss att bygga de steg som vi kommer att vidta för att genomföra konstruktionen av projektet som vi har tagit fram, under de olika faserna av den valda metodiken kommer vi att ha utrymme för insamling av information, modellering av lösningen , de olika användningsfallen och slutligen början på kodningen.
Vi har två varianter vid denna tidpunkt:

• Gammal metod.
• Senaste metoden.

Var och en av dem har genererat tillräckligt med information för att kunna beskriva byggprocessen för ett projekt.
Låt oss se den första av dem.
Gammal metod
Denna metod vid den tiden vad den gjorde var att få stadierna att hända efter varandra och på så sätt förenkla hur problemet möttes, vad är då genomfördes var att definiera en serie etapper och fastställa avbrott för att utföra var och en.
På grund av denna förenkling, när ett problem uppstod i ett senare skede men problemet härstammade från ett tidigare skede, var det nödvändigt att praktiskt taget bryta projektuppskattningarna för att börja om.
På grund av separationen av varje steg var det vanligt att hitta fall där utvecklaren aldrig arbetade med designern eller systemmodelleraren, och därmed skilde programvaran från den som utformade funktionaliteterna.
Låt oss se följande grafik som beskriver en process gjord med denna metod:

Detta är en kaskadprocess, det tar sitt namn eftersom varje steg flödar efter det andra och för att starta ett nytt steg är det nödvändigt att avsluta det nuvarande, som vi nämnde tidigare har detta tillvägagångssätt allvarliga nackdelar.
Med detta avslutar vi den första delen av handledningen, vi vet redan lite mer om hur metodiken för mjukvaruutveckling fungerade i antiken, i nästa del kommer vi att se de senaste metoderna och andra viktiga aspekter av utvecklingsprocessen.
Jag lämnar här del 2 av denna handledning Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng