UML - kūrimo procesas, 1 dalis

Nusprendę sukurti mums reikalingą programinę įrangą, nuo pat pradžių susidursime su įvairiais elementais UML galime atlikti gana išsamų modeliavimo etapą, kuris padės kūrimo komandai.
Tačiau yra ir kitų veiksnių, susijusių su UML Nors jie nėra susiję su diagramų sudarymu, vienas iš šių veiksnių yra projekto, kurį ketiname vykdyti, programinės įrangos kūrimo metodika.
Metodikos
Pradedant projektą, normaliausia yra tai, kad yra komandos narių, kurie nori pradėti kurti ir koduoti sprendimą nuo pirmos dienos, tačiau tokio tipo nekantrumą reikia nedelsiant išjungti ne tik todėl, kad neįmanoma žinoti, kas jie yra sutelkti dėmesį į kūrėjus, bet taip pat prideda spaudimo veiksnį, kad per trumpą laiką pamatytumėte „apčiuopiamus“ rezultatus.
Kas vyksta šiandien, mes turime puikių dalykų rėmus darbų, kurie žada sutrumpinti kūrimo valandas naudojant jų įrankius, tačiau jei mūsų projektas nėra gerai sutelktas, galų gale dirbsime daugiau nei būtina, taisydami tai, kas jau buvo padaryta iš pradžių.
A metodika Tai padeda mums sukurti žingsnius, kurių imsimės, kad atliktume savo sukurto projekto statybą, skirtinguose pasirinktos metodikos etapuose turėsime erdvės rinkti informaciją, modeliuoti sprendimą , skirtingi naudojimo atvejai ir galiausiai kodavimo pradžia.
Šiuo metu turime du variantus:

• Senas metodas.
• Naujausias metodas.

Kiekvienas iš jų sukūrė pakankamai informacijos, kad galėtų apibūdinti projekto statybos procesą.
Pažiūrėkime pirmąjį iš jų.
Senas metodas
Šis metodas tuo metu buvo skirtas tam, kad etapai vyktų vienas po kito, taip supaprastinant problemos sprendimo būdą, o kas tada buvo apibrėžta etapų serija ir nustatyti trūkumai kiekvienam etapui atlikti.
Dėl šio supaprastinimo, kai problema atsirado vėlesniame etape, tačiau problema kilo iš ankstesnio etapo, reikėjo praktiškai nutraukti projekto sąmatas, kad būtų galima pradėti iš naujo.
Dėl kiekvieno etapo atskyrimo buvo įprasta rasti atvejų, kai kūrėjas niekada nedirbo su dizaineriu ar sistemos modeliuotoju, taip atskirdamas programinę įrangą nuo asmens, kuris sugalvojo funkcijas.
Pažvelkime į šią grafiką, apibūdinančią procesą, atliktą naudojant šią metodiką:

Tai yra kaskadinis procesas, jis vadinamas savo pavadinimu, nes kiekvienas etapas teka po kito, ir norint pradėti naują etapą, būtina užbaigti dabartinį, kaip minėjome anksčiau, šis metodas turi didelių trūkumų.
Baigę šią pirmąją pamokos dalį, mes jau šiek tiek daugiau žinome, kaip senovėje veikė programinės įrangos kūrimo metodika, kitoje dalyje pamatysime naujausias metodikas ir kitus svarbius kūrimo proceso aspektus.
Aš palieku čia šios pamokos 2 dalį Ar jums patiko ir padėjo ši pamoka?Galite apdovanoti autorių paspausdami šį mygtuką, kad suteiktumėte jam teigiamą tašką