UML - Udviklingsproces, del 1

Når vi har besluttet at bygge den software, vi har brug for, kommer vi fra begyndelsen til at støde på forskellige elementer, takket være UML vi kan lave en temmelig detaljeret modelleringsfase, der hjælper udviklingsholdet.
Der er dog andre faktorer, der er relateret til UML Selvom de ikke har at gøre med konstruktion af diagrammer, er en af ​​disse faktorer softwareudviklingsmetoden for det projekt, som vi skal udføre.
Metoder
Når man starter et projekt, er det mest normale, at der er teammedlemmer, der ønsker at begynde at udvikle og kode løsningen fra dag ét, men denne type utålmodighed skal slukkes med det samme, ikke kun fordi det er umuligt at vide, hvad de er fokus på udviklere, men tilføjer også en trykfaktor for at se "håndgribelige" resultater på kort tid.
Hvad der sker i dag, vi har stor rammer arbejde, der lover at reducere udviklingstimerne, når de bruger deres værktøjer, men hvis vores projekt ikke er godt fokuseret, ender vi med at arbejde mere end nødvendigt med at reparere det, der allerede var udført i de første øjeblikke.
EN metodik Det hjælper os med at bygge de trin, vi skal tage for at udføre konstruktionen af ​​det projekt, vi har udtænkt, i de forskellige faser af den valgte metode vil vi have plads til indsamling af information, modellering af løsningen , de forskellige anvendelsessager og endelig starten på kodning.
Vi har to varianter på dette tidspunkt:

• Gammel metode.
• Seneste metode.

Hver af dem har genereret nok information til at kunne beskrive byggeprocessen af ​​et projekt.
Lad os se den første af dem.
Gammel metode
Denne metode dengang, hvad den gjorde, var at få stadierne til at ske efter hinanden og dermed forenkle den måde, hvorpå problemet blev konfronteret, så hvad er udført var at definere en række etaper og etablere bortfald for at udføre hver enkelt.
På grund af denne forenkling, da et problem opstod på et senere tidspunkt, men problemet var afledt af et tidligere stadium, var det nødvendigt praktisk talt at bryde projektestimaterne for at starte forfra.
På grund af adskillelsen af ​​hvert trin var det almindeligt at finde tilfælde, hvor udvikleren aldrig arbejdede med designeren eller systemmodelleren, og dermed skilte softwaren fra den person, der udtænkte funktionaliteterne.
Lad os se følgende grafik, der beskriver en proces udført med denne metode:

Dette er en kaskadeproces, det tager sit navn, da hvert trin flyder efter det andet, og for at starte et nyt trin er det nødvendigt at afslutte det nuværende, som vi nævnte tidligere, har denne tilgang alvorlige ulemper.
Med dette afslutter vi denne første del af selvstudiet, vi ved allerede lidt mere om, hvordan metodologien til softwareudvikling fungerede i oldtiden, i den næste del vil vi se nylige metoder og andre vigtige aspekter af udviklingsprocessen.
Jeg forlader her del 2 af denne vejledning 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