✅ UML - Utviklingsprosess, del 1

Innholdsfortegnelse

Når vi har bestemt oss for å bygge programvaren vi trenger, kommer vi fra begynnelsen til å støte på forskjellige elementer, takket være UML vi kan gjøre en ganske detaljert modelleringsfase som vil hjelpe utviklingsteamet.
Imidlertid er det andre faktorer som er relatert til UML Selv om de ikke har å gjøre med konstruksjonen av diagrammer, er en av disse faktorene programvareutviklingsmetoden for prosjektet som vi skal utføre.
Metoder
Når du starter et prosjekt, er det mest normale at det er teammedlemmer som ønsker å begynne å utvikle og kode løsningen fra dag én, men denne typen utålmodighet må slås av umiddelbart, ikke bare fordi det er umulig å vite hva de er skal gjøre. fokusere på utviklere, men legger også til en pressfaktor for å se "håndgripelige" resultater på kort tid.
Det som skjer i dag, har vi stort rammer arbeid som lover å redusere utviklingstiden ved bruk av verktøyene, men hvis prosjektet vårt ikke er godt fokusert, vil vi ende opp med å jobbe mer enn nødvendig med å reparere det som allerede var gjort i de første øyeblikkene.
EN metodikk Det hjelper oss å bygge trinnene vi skal ta for å utføre konstruksjonen av prosjektet som vi har utviklet, i løpet av de forskjellige fasene i den valgte metodikken, vil vi ha plass til innsamling av informasjon, modellering av løsningen , de forskjellige brukstilfellene og til slutt starten på kodingen.
Vi har to varianter på dette tidspunktet:

Gammel metode.
Nyere metode.

Hver av dem har generert nok informasjon til å kunne beskrive byggeprosessen til et prosjekt.
La oss se den første av dem.
Gammel metode
Denne metoden den gangen den gjorde, var å få stadiene til å skje etter hverandre, og dermed forenkle måten problemet ble møtt på, så hva er utført var å definere en serie etapper og etablere bortfall for å utføre hver enkelt.
På grunn av denne forenklingen, da et problem oppstod på et senere tidspunkt, men problemet ble avledet fra et tidligere stadium, var det nødvendig å praktisk talt bryte prosjektestimatene for å starte på nytt.
På grunn av at hvert trinn var atskilt, var det vanlig å finne tilfeller der utvikleren aldri jobbet med designeren eller systemmodelleren, og dermed skilte programvaren fra personen som utviklet funksjonalitetene.
La oss se følgende grafikk som beskriver en prosess laget med denne metodikken:

Dette er en kaskadeprosess, det tar navnet sitt siden hvert trinn flyter etter det andre, og for å starte et nytt trinn er det nødvendig å fullføre det nåværende, som vi nevnte tidligere, har denne tilnærmingen alvorlige ulemper.
Med dette fullfører vi denne første delen av opplæringen, vi vet allerede litt mer om hvordan metodikken for programvareutvikling fungerte i antikken, i den neste delen vil vi se nylige metoder og andre viktige aspekter av utviklingsprosessen.
Jeg forlater her del 2 av denne opplæringen