UML - izstrādes process, 1. daļa

Kad esam nolēmuši izveidot nepieciešamo programmatūru, jau no paša sākuma mēs saskarsimies ar dažādiem elementiem, pateicoties UML mēs varam veikt diezgan detalizētu modelēšanas posmu, kas palīdzēs izstrādes komandai.
Tomēr ir arī citi faktori, kas saistīti ar UML Lai gan tie nav saistīti ar diagrammu veidošanu, viens no šiem faktoriem ir tā projekta programmatūras izstrādes metodika, kuru mēs gatavojamies īstenot.
Metodoloģijas
Uzsākot projektu, visparastākais ir tas, ka ir komandas locekļi, kuri vēlas sākt izstrādāt un kodēt risinājumu jau no pirmās dienas, tomēr šāda veida nepacietība ir nekavējoties jāizslēdz ne tikai tāpēc, ka nav iespējams zināt, kas viņi ir koncentrēties uz izstrādātājiem, bet arī pievienot spiediena faktoru, lai īsā laikā redzētu "taustāmus" rezultātus.
Kas notiek šodien, mums ir lieliski ietvari darbu, kas sola samazināt izstrādes stundas, izmantojot viņu rīkus, tomēr, ja mūsu projekts nav pietiekami koncentrēts, mēs galu galā strādāsim vairāk nekā nepieciešams, lai labotu to, kas jau tika izdarīts sākotnējos brīžos.
A metodoloģija Tas palīdz mums izveidot pasākumus, ko mēs veiksim, lai veiktu mūsu izstrādātā projekta būvniecību, dažādās izvēlētās metodikas fāzēs mums būs vieta informācijas vākšanai, risinājuma modelēšanai , dažādi lietošanas gadījumi un visbeidzot kodēšanas sākums.
Šobrīd mums ir divi varianti:

• Vecā metode.
• Jaunākā metode.

Katrs no tiem ir radījis pietiekami daudz informācijas, lai varētu aprakstīt projekta būvniecības procesu.
Apskatīsim pirmo no tiem.
Vecā metode
Šī metode tajā laikā darīja to, lai posmi notiktu viens pēc otra, tādējādi vienkāršojot problēmas risināšanas veidu, tad kas ir bija jānosaka virkne posmu un jānosaka trūkumi katra posma veikšanai.
Šīs vienkāršošanas dēļ, kad problēma radās vēlāk, bet problēma tika iegūta no agrākas stadijas, bija nepieciešams praktiski lauzt projekta aplēses, lai sāktu no jauna.
Sakarā ar katra posma nošķiršanu, bija bieži sastopami gadījumi, kad izstrādātājs nekad nav strādājis ar dizaineru vai sistēmas modelētāju, tādējādi šķirot programmatūru no personas, kas izstrādājusi funkcionalitāti.
Apskatīsim šādu grafiku, kurā aprakstīts process, kas veikts, izmantojot šo metodiku:

Šis ir kaskādes process, tam ir nosaukums, jo katrs posms plūst pēc otra, un, lai sāktu jaunu posmu, ir jāpabeidz pašreizējais, kā minēts iepriekš, šai pieejai ir nopietni trūkumi.
Ar to mēs pabeidzam šo apmācības pirmo daļu, mēs jau zinām nedaudz vairāk par to, kā programmatūras izstrādes metodika darbojās senos laikos, nākamajā daļā mēs redzēsim jaunākās metodoloģijas un citus svarīgus izstrādes procesa aspektus.
Es atstāju šeit šīs apmācības otro daļu Vai jums patika šī apmācība un palīdzējāt tai?Jūs varat apbalvot autoru, nospiežot šo pogu, lai sniegtu viņam pozitīvu punktu