UML - Ontwikkelingsproces, deel 1

Zodra we hebben besloten om de software te bouwen die we nodig hebben, zullen we vanaf het begin verschillende elementen tegenkomen, dankzij UML we kunnen een vrij gedetailleerde modelleringsfase uitvoeren die het ontwikkelingsteam zal helpen.
Er zijn echter nog andere factoren die verband houden met de UML Hoewel ze niet te maken hebben met het maken van diagrammen, is een van deze factoren de softwareontwikkelingsmethodologie van het project dat we gaan uitvoeren.
Methoden
Bij het starten van een project is het normaal dat er teamleden zijn die vanaf de eerste dag willen beginnen met het ontwikkelen en coderen van de oplossing, maar dit soort ongeduld moet onmiddellijk worden uitgeschakeld, niet alleen omdat het onmogelijk is om te weten wat ze zijn focus op ontwikkelaars, maar voegt ook een drukfactor toe om in korte tijd "tastbare" resultaten te zien.
Wat er vandaag gebeurt, hebben we geweldig kaders van werk dat beloven ontwikkelingsuren te verkorten bij het gebruik van hun tools, maar als ons project niet goed gefocust is, zullen we uiteindelijk meer dan nodig werken om te repareren wat al in de eerste momenten was gedaan.
EEN methodologie Het helpt ons om de stappen te bouwen die we gaan nemen om de constructie van het project uit te voeren dat we hebben bedacht, tijdens de verschillende fasen van de gekozen methodologie zullen we ruimte hebben voor het verzamelen van informatie, het modelleren van de oplossing , de verschillende gebruiksscenario's en tot slot het begin van het coderen.
We hebben op dit moment twee varianten:

• Oude methode.
• Recente methode.

Elk van hen heeft voldoende informatie gegenereerd om het bouwproces van een project te kunnen beschrijven.
Laten we de eerste ervan bekijken.
Oude methode
Deze methode deed destijds wat het deed om de fasen na elkaar te laten plaatsvinden, waardoor de manier waarop het probleem werd aangepakt werd vereenvoudigd. uitgevoerd was het definiëren van een reeks fasen en het vaststellen van fouten om elke fase uit te voeren.
Door deze vereenvoudiging was het, wanneer een probleem zich in een later stadium voordeed, maar het probleem was afgeleid van een eerder stadium, noodzakelijk om de projectramingen praktisch te breken om opnieuw te beginnen.
Door de scheiding van elke fase was het gebruikelijk om gevallen te vinden waarin de ontwikkelaar nooit met de ontwerper of de systeemmodelleur werkte, waardoor de software werd gescheiden van de persoon die de functionaliteiten bedacht.
Laten we de volgende afbeelding bekijken die een proces beschrijft dat met deze methode is gemaakt:

Dit is een cascadeproces, het ontleent zijn naam aan het feit dat elke fase na de andere stroomt en om een ​​nieuwe fase te starten is het noodzakelijk om de huidige te beëindigen, zoals we eerder vermeldden, deze aanpak heeft ernstige nadelen.
Hiermee ronden we dit eerste deel van de tutorial af, we weten al iets meer over hoe de methodologie voor softwareontwikkeling in de oudheid werkte, in het volgende deel zullen we recente methodologieën en andere belangrijke aspecten van het ontwikkelingsproces zien.
Ik laat hier deel 2 van deze tutorial achter Vond je deze Tutorial leuk en heb je eraan geholpen?Je kunt de auteur belonen door op deze knop te drukken om hem een ​​positief punt te geven