အခန်း ၂ :: Process

Waterfall ကို မစခင်မှာ Software Engineering တစ်ယောက် အနေနဲ့ ဦးစွာ သိသင့်တာကတော့ Software Development Life Cycle (SDLC) ပါ။ Waterfall ကတော့ ရှေး အကျဆုံး နဲ့ လူ အသိများဆုံး နည်းစနစ် တစ်ခုပါ။ Waterfall မစခင်မှာ SDLC အပိုင်းကို ဦးစွာ နားလည် ဖို့ လိုပါတယ်။

၂.၁ Software Development Life Cycle

Software Development Life Cycle (SDLC) ဆိုသည်မှာ software တစ်ခု ကို ဖန်တီးသည့် အခါမှာ လိုက်နာဆောင်ရွက် ရသည့် လုပ်ငန်းစဥ် framework တစ်ခု လို့ ဆိုရပါမယ်။ ဥပမာ အိမ် တစ်လုံး မဆောက်မီ အင်ဂျင်နီယာက Plan ချခြင်း ၊ လိုအပ်သည့် ပစဏ်ညးများ ကို တွက်ချက်ခြင်း ၊ အိမ်အုတ်မြစ်ချခြင်း ၊ တည်ဆောက်ခြင်း ၊ အပြီးသတ် ဆေးသုတ်ခြင်း ၊ ပြုပြင်ထိန်းသိမ်းခြင်း စသည် တို့ကို အဆင့်ဆင့် လုပ်ဆောင်ရ သလို ပဲ Software ရေးသားရာတွင် စိတ်ကူးရှိရာ ရေးသားခြင်း မဟုတ်ပဲ စနစ်တက် အစီအစဥ်များ ချမှတ်ပြီး ဆောင်ရွက်ရပါတယ်။ ဤ သို့ လုပ်ဆောင့် သည် ့အဆင့်ဆင့် ကို Software Development Life Cycle ဟု ခေါ်ပါသည်။

SLDC ရဲ့ အဓိက ရည်ရွယ် ချက် က Software ဖန်တီး မှု လုပ်ငန်း တစ်ခုလုံး ရှင်းရှင်း မြင်သာစေရန် ၊ ပါဝင် သူ အားလုံး (project manager, developer, designer, client) တို့ က မိမိ ရဲ့ တာဝန် နှင့် လုပ်ဆောင်ရမည့် အရာများများကို တိတိကျကျ ရှင်းရှင်းလင်းလင်း သိစေရန် ၊ သုံးစွဲသူ End User ၏ လိုအပ်ချက် နှင့် ကိုက်ညီသည့် အမှားအယွင်း နည်းသည့် software တစ်ခု ထုတ်လုပ်နိုင်ရန် ဖြစ်သည်။

SDLC တွင် အောက်ပါ အဆင့်များ ပါဝင်သည်။

စီမံကိန်း ရေးဆွဲခြင်း (Planning)

ပထမဆုံး အရေးကြီးဆုံး အခြေခံ အဆင့် ဖြစ်သည်။ မည်သည့် Software ကို ဘာအတွက် လုပ်မည် ၊ မည်သူ တွေ သုံးစွဲမည် ၊ အရင်းအနှီး နှင့် အချိန် ဘယ်လောက် သုံးမည်၊ နည်းပညာ ပိုင်း အရ ငွေကြေးပိုင်း အရ ပါ ဖြစ်နိုင်ချေ ရှိ မရှိ စသည် တို့ကို လေ့လာသုံးသပ်ပြီး project တစ်ခုလုံး၏ Road Map (လမ်းပြမြေပုံ) ကို ရေးဆွဲရန် ဖြစ်သည်။

လိုအပ်ချက်များ စုဆောင်းခြင်း (Requirement Analysis)

Project သုံးစွဲသူ (Client) နှင့် သက်ဆိုင်သူများ (Stakeholder) တို့ ဆီကနေ ပါဝင်မည့် feature များ လုပ်ဆောင်ရမည့် function များ အသေးစိတ် ကို စုဆောင်းရပါတယ်။ ဒီအဆင့်မှာ client က ဘာလိုချင်တာလဲ တကယ်လိုအပ်တာ က ဘာလဲ။ အဓိက ပြဿနာ က ဘာလဲ ။ နောက်ပြီး တကယ် အသုံးပြုသူတွေက ဘယ်သူတွေလဲ။ သူတို့ ရဲ့ လက်ရှိ အသုံးပြုနေသည့် စနစ် က ဘာလဲ ဆိုတာ ကို နားလည် ဖို့ လိုပါတယ်။ ဒီအဆင့် က ကိုယ် ရေးဆွဲမည့် စနစ် ရဲ့ domain knowledge , client ဖန်တီးခြင်သည့် စနစ် ဒါတွေကို နားလည် အောင် လုပ်ပြီး အချက်အလက်တွေကို စိစစ်သုံးသပ်ရပါမယ်။ ပြီးရင်တော့ “Software Requirement Specification (SRS)” လို့ ခေါ်သည့် document ကို ဖန်တီး ဖို့ လိုပါတယ်။ SRS က အရေးပါပါတယ်။ နောက်အဆင့် အတွက် အဓိက လမ်းညွှန်ချက် လို့ ဆိုရပါမယ်။ နောက်ပြီး client နဲ့ software ဖန်တီးမည့် developer သို့မဟုတ် company နဲ့ သဘောတူ ညီ မှု ရှိပြီး နှစ်ဘက်လုံး နားလည် ထားသည့် Requirement ဆိုတာ ရှင်းလင်း ဖို့ အတွက်ပါ။

ဒီဇိုင်း ရေးဆွဲခြင်း (Design)

SRS ကို အခြေခံပြီး Software Architecture တစ်ခုလုံး ရေးဆွဲဖို့ လိုအပ်ပါသည်။ မည်သည့် programming language, database , framework စသည်တို့ ကို အသုံးပြုမယ် ဆိုတာကို ဆုံးဖြတ်ဖို့ လိုအပ်ပါသည်။ Software မှာ ပါဝင်သည့် Modules များ နှင့် Modules အချင်းချင်း ဘယ်လို ချိတ်ဆက် အလုပ်လုပ်မယ် ဆိုတာ ကို ပုံစံချ ဖို့ လိုအပ်ပါတယ်။ User Interface (UI) , User Expereince (UX) တို့ ကို ဒီ အဆင့်မှာ ရေးဆွဲသင့်ပါတယ်။

အကောင်အထည်ဖော်ခြင်း (Development)

သေချာသည့် Requirement , ရေးဆွဲမည့် UI , System Architecture တွေ ပြည့်စုံ ပြီ ဆိုရင် coding စရေးသားဖို့ အဆင်သင့် ဖြစ်ပါပြီ။ ဤအဆင့်ဟာ software development ၏ လုပ်ငန်းစဥ် ရဲ့ အဓိက အပိုင်း ဖြစ်ပြီး အချိန် အများဆုံး ယူရပါတယ်။

စမ်းသပ်စစ်ဆေးခြင်း (Testing)

ရေးသားပြီးစီးသွားသည့် Software များကို သတ်မှတ်ထားသည့် လိုအပ်များ နဲ့ ကိုက်ညီမှု ရှိမရှိ ၊ requirement အတိုင်း အလုပ် လုပ် မလုပ် ၊ လက်ရှိ ရေးဆွဲထားသည့် Software မှာ အမှား အယွင်းများ ရှိမရှိ (bugs) ရှိမရှိ တို့ကို Quality Assurance (QA) team က စနစ်တကျ စစ်ဆေး ဖို့ လိုအပ်ပါတယ်။ တွေ့ရှိထားသည့် bugs တွေကို developer တွေကို ပြန်ပြောပြီး developer များကို ပြန်ပြင် ရေးဆွဲရပါတယ်။

ထိန်းသမ်းပြုပြင်ခြင်း (Maintenance)

Software တွေဟာ ဘယ်တော့မှ ပြီးဆုံးသွားတယ် မရှိပါဘူး။ သုံးနေသည့် အချိန်မှာပဲ bugs တွေ ပေါ်လာတာ တစ်ခါမှ ထည့်မစဥ်းစားထားသည့် user story တွေ ပေါ်လာသည့် ပြဿနာတွေ ဖြေရှင်းရသလို security အားနည်းချက်ကြောင့် ဖြစ်လာသည့် ပြဿနာ တွေလည်း ဖြေရှင်းရပါတယ်။ တစ်ခါတစ်လေ အသုံးပြုသူ သုံးစွဲသည့် OS နဲ့ မကိုက်ညီ တာ device နဲ့ မကိုက်ညီ တာ တွေကြောင့် ဖြစ်သည့် ပြဿနာ အသစ်တွေကို ထပ်ဖြေရှင်း ရတာ ပုံမှန် ပါပဲ။ ခေတ်နှင့် အညီ feature တွေ ပြောင်းလဲတာ OS ပြောင်းလဲ မှု ကြောင့် ပြန်ပြင်ရတာ အသုံးပြုသည့် framework, language version အသစ်ကြောင့် ခေတ်နဲ့ အမှီ ဖြစ်အောင် ပြန်ပြင်ရတာ တွေ ရှိပါတယ်။ ဒီ အဆင့်မှာ software သုံးနေသည့် သက်တမ်း တစ်လျှောက်လုံး ဆက်လက် တည်ရှိနေမှာပါ။

၂.၁ Waterfall

SDLC နဲ့ Water fall ဟာ ရုတ်တရက် ကြည့်ရင် တူသလို ရှိပေမယ့် မတူညီ ကြပါဘူး။ SDLC က Software တစ်ခု ဖန်တီးသည့် အခါ ဘယ်အဆင့်တွေ ပါမယ် ဘယ်လို ဆောင်ရွက်သင့် သလဲ ဆိုတာကို ဖော်ပြထားတာပါ။ Waterfall Model ကတော့ အသေးစိတ် အချက်အလက်တွေ ပါဝင်ပါတယ်။ ဘယ် အဆင့် ကို ဘယ်လို ဖန်တီး မယ် ဘာတွေလုပ်ရမယ်ဆိုတာ ပါဝင်ပါတယ်။Waterfall အပြင် အခြား Agile , Spiral , Iterative စသည် တို့ ကို သုံးဆွဲသည့် အခါမှာလည်း SDLC က ပါဝင်နေပါတယ်။

Waterfall မှာ အဆင့် ၅ ဆင့် ကနေ ၇ ဆင့် ထိ ပါဝင်ပါတယ်။ အခြေခံကျ ပြီး အသုံးပြုလေ့ ရှိသည့် အဆင့်တွေကို သာ ဒီ စာအုပ်မှာ ဖော်ပြထားပါတယ်။

၁။ လိုအပ်ချက်များ စုဆောင်းခြင်း (Requirement Gathering and Analysis)

Project Team က သုံးစွဲသူ (client) ၊ project နှင့် သက် ဆိုင်သူများ (Stakeholders) နှင့် တွေ့ဆုံးပြီး Software က ဘာတွေ လုပ်ဆောင်ပေးမယ် ၊ ဘယ် feature တွေ ပါဝင်ရမည် စသည့် အသေးစိတ် requirement အားလုံး ကို စုဆောင်းရပါတယ်။ စုဆောင်းရရှိလာသည့် အချက်အလက်များကို သေချာစွာ စိစစ် သုံးသပ်ပြီး “Sofware Requirement Specificatio (SRS)” လို့ ခေါ်သည့် Document ကို ဖန်တီးရပါတယ်။ SRS ဟာ အရမ်းအရေးပါပါတယ်။ နောက်တချိန် client နဲ့ စကားပြော သည့် အခါမှာ SRS ထဲမှာ ပါ မပါ အချက်အလက် နဲ့ ကိုင်ပြီး နှစ်ဦး နှစ် ဖက် ဆွေး နွေးရပါတယ်။ အကယ်၍ ကိုယ်တိုင် ဦးဆောင်ပြီး Software တစ်ခုကို client အတွက် ရေးဆွဲပေးမယ့် ဆိုရင် မည်သည့် စနစ် ပဲ သုံးပြီး development လုပ်လုပ် SRS ကို ကိုင်ထားဖို့ လိုပါတယ်။ ပုံမှန် အားဖြင့် client တွေက လိုအပ်သည့် feature တွေကို နောက်ပိုင်းမှ သတိရပြီး ထည့်သွင်းဖို့ ကြိုးစားတတ်ပြီး dead line နဲ့ မမှီ ဖြစ်တတ်ပါတယ်။ SRS ကို အသုံးပြုခြင်းအားဖြင့် SRS အသစ် ပြန်လည် ရေးဆွဲခြင်းဖြင့် dead line ကို ပြန်ပြီး သက်တမ်း တိုး သင့်ပါတယ်။ ဒီ အဆင့်မှာ Client နဲ့ Software ရေးဆွဲ သူ အသေအချာ အသေးစိတ် ဆွေးနွေး ထားဖို့ လိုပါတယ်။ ပုံမှန် development လုပ်သည့် အခါမှာ SRS document မဖန်တီး ပဲ လုပ်သည့် အခါမှာ မပြီးဆုံးနိုင်သည့် software project ပေါင်းမြောက်မြားစွာ ပေါ်ပေါက်လာ စေပါတယ်။ ဒီ အဆင့်ပြီး ဆုံးသွားပြီဆိုရင် waterfall မှာ ပြန်လည် ပြောင်းလဲ ရန် အရမ်းကို ခက်ခဲ ပါတယ်။

၂။ စနစ် ဒီဇိုင်း ရေးဆွဲခြင်း (System Desing)

Requirement အဆင့် မှ ရရှိလာသည့် SRS Document ကို အခြေခံပြီး System Architect များနှင့် Developer များက Software တည်ဆောက်ပုံ တစ်ခုလုံးကို Design ရေးဆွဲ ပါတယ်။ ဒီ အဆင့်မှာ အပိုင်း နှစ်ပိုင်း ဆွဲခြား နိုင်ပါတယ်။

High Level Design (HLD)

Software ရဲ့ အဓိက အစိတ် အပိုင်း များ (Modules) ၊ Module တစ်ခု နှင့် အတစ်ခု အပြန်အလန် ဆက်သွယ် လုပ်ဆောင်ပုံ (Architecture) နှင့် Database Design လိုမျိုး diagram design တွေကို High Level Design လို့ သတ်မှတ်ပါတယ်။ ကြည့်လိုက်တာနဲ့ ဘယ်လို ဖန်တီးမယ် ဆိုတာကို အပေါ်ယံ နားလည် သဘောပေါက် စေသည့် ပုံစံမျိုးတွေပေါ့။

Low-Level Design (LLD)

Module တစ်ခု ချင်းစီရဲ့ အတွင်းပိုင်း အသေးစိတ် လုပ်ဆောင်ပုံ (Logic) , Function , Alogrithm များနှင့် Data Structure များကို အသေးစိတ် ရေးဆွဲထားခြင်းပါ။

ဒီလိုရေးဆွဲထားသည့် Design ပုံစံ များ အသုံးပြုမည့် Technology သတ်မှတ်ချက်များ ပါဝင်သည့် နောက်ထပ် Document တစ်ခု ထပ်လုပ်ပါတယ်။ Design Document လို့ ခေါ်ပါတယ်။ စနစ် တစ်ခုလုံး လုပ်ဆောင်ပုံ ကို နောင်တချိန် အသေးစိတ် စနစ် ထဲ ဝင်မကြည့်ပဲ Design Document ကို ကြည့်ပြီး နားလည် နိုင်ပါတယ်။ ဥပမာ Storage ကို Local Storage သုံးထားလား S3 သုံးထားလား ။ Cache ကို Redis လား Memecache လား ၊ Queue service ကို redis သုံးထားလား RabbitMQ သုံးလား စသည် တို့ကို နားလည် စေနိုင်ပါတယ်။

၃။ အကောင်အထည်ဖော်ခြင်း (Implementation / Coding)

Design အဆင့်ပြီးဆုံးသွားသည့် အခါ Developer များက Design Document ကို လမ်းညွှန် အဖြစ် အသုံးပြုပြီး Program Code များကို စတင်ရေးသားပါတယ်။ Project မှာ ပါဝင်သည့် Modules များ Feature များကို ခွဲခြမ်းပြီး Developer တစ်ဦးခြင်း သို့မဟုတ် Team တစ်ခု စီ က တာဝန်ယူပြီး ရေးသားကြပါတယ်။ ဒီအဆင့်က အချိန် အများဆုံး ပေးရသည့် အဆင့်တစ်ခုပါ။

၄။ စမ်းသပ်ခြင်း (Testing)

Coding ရေးသားပြီးသည့် အခါမှာတော့ Quality Assurance (QA) Team က စမ်းသပ် စစ်ဆေးရပါတယ်။ Software များသည် သတ်မှတ်ထားသည့် requirement များ အတိုင်း ကိုက်ညီမှု ရှိမရှိ SRS အတိုင်းလိုက်နာ ထားမှု ရှိမရှိ စသည် တို့ ကို စစ်ဆေးရပါတယ်။ တွေ့ရှိသည့် bugs နှင့် error များကို development team ကို ပြန်လည် ပေးပို့ပြီး ပြင်ဆင်စေရပါတယ်။ ပြင်ဆင်ပြီးသည့် အခါ နောက်တကြိမ် test လုပ်ပြီး bugs များ ရှင်းလင်း မှသာ ဒီ အဆင့် ပြီးဆုံးပါတယ်။ Testing အမျိုးအစားများမှာ

Unit Testing , Module တစ်ခုခြင်းဆီ ကို စစ်ဆေးခြင်း , Module များအတွက် Test Case များကို ဖန်တီးထားပြီး ပုံမှန် အားဖြင့် Developer များက ထို Test Case များကို ရေးသားပါတယ်
Integration Testing: Module များကို ပေါင်းစပ်ပြီး အခြင်းခြင်း အပြန်အလှန် ချိတ်ဆက်ပြီး လုပ်ဆောင်လား မှန်ကန်မှု ရှိလား စစ်ဆေးခြင်း
System Testing : Software တစ်ခုလုံး ပေါင်းစမ်းပြီး System တစ်ခုလုံး အနေဖြင့် စစ်ဆေးခြင်း
User Acceptance Testing : သုံးစွဲသူ (Client) ကိုယ်တိုင် အသုံးပြုစမ်းသပ်စေပြီး ၎င်းတို့၏ လိုအပ်ချက်နှင့် ကိုက်ညီမှုရှိမရှိ အတည်ပြုချက်ရယူခြင်း

၅။ ထုတ်ဝေ အသုံးပြုခြင်း (Deployment/ Installation)

Testing အဆင့်ကို အောင်မြင်စွာ ကျော်ဖြတ်နိုင်ခဲ့ပြီးနောက် Software ကို သုံးစွဲသူ များ အသုံးပြုနိုင်ရန် Production Server ပေါ်သို့ တင်ခြင်း သို့မဟုတ် User များ၏ device ထဲ သို့ ရောက်အောင် App Store, Play Store တို့ ပေါ်တွင် တင်ခြင်း စသည်တို့ ကို လုပ်ဆောင်ပြီး User များ အသုံးပြုနိုင်အောင် ဖန်တီးရသည်။

၆။ ထိန်းသိမ်းပြုပြင်ခြင်း (Maintenance)

Software ကို အသုံးပြုသူများ ထံ ဖြန့်ချီ ပြီးနောက် ပေါ်ပေါက်လာနိုင်သော ပြဿနာ များကို ဖြေရှင်း ပေးခြင်း လုပ်ဆောင်ချက် အသစ်များ ကို ထည့်သွင်းခြင်း OS များ update ဖြစ်တာ နှင့် အညီ ပြန်လည် ပြင်ဆင်ခြင်း စသည် ဖြင့် ထိန်းသိမ်း ပြုပြင် အဆင်မြှင့်ခြင်းကို Software သုံးစွဲနေသမျှ ဆက်လက်ပြီး လုပ်ဆောင်နေရပါတယ်။

အားသာချက်

ရိုးရှင်း လွယ်ကူပြီး နားလည် လွယ်ခြင်း
ခိုင်မာသည့် ဖွဲ့စည်းပုံရှိခြင်း
ပြီးပြည့်စုံသည့် Documenation များ ရှိခြင်း
ကြာမည် အချိန် ကုန်ကျငွေ တို့ ကို ခန့်မှန်း ရလွယ်ကူခြင်း

အားနည်းချက်

ပြောင်းလွယ် ပြင်လွယ်မရှိခြင်း
အကုန်ပြီးမှ ရလဒ်ကို မြင်ရခြင်း
Development လုပ်နေချိန်တွင် သုံးစွဲ သူ ၊ Customer များဖြင့် အချိတ်အဆက် ပြတ်တောက်ခြင်း
Risk များခြင်း

Water fall ကို တိကျ ခိုင်မာပြီး ပြုပြင်ပြောင်းလဲခြင်း မရှိသည့် အစိုး ဌာနများ Corporation များ တွင် ယနေ့ တိုင် အသုံးပြုနေဆဲ ဖြစ်သည်။ ထို့အပြင် သေးငယ်သည့် project များ အတွက်လည်း သင့်တော်ပါသည်။ ထို့အပြင် ပြောင်းလဲမှု မရှိသည့် စနစ် များ တွင်လည်း အသုံးပြုနိုင်ပါသည်။ တနည်းဆိုလည်း Waterfall သည် ခေတ်နောက်ကျ နေသည့် နည်းစနစ်ဖြစ်သောလည်း ယနေ့ တိုင် အသုံးပြုနေသည့် နေရာများစွာ ရှိသကဲ့သို့ အသုံးဝင်သည့် နေရာများလည်း ရှိနေသေးသည်။

၂.၃ Iterative and incremental development

Iterative and Incremental Development ဆိုသည်မှာ Waterfall Model လို မဟုတ်တော့ပဲ project အကြီး ကို အပိုင်းငယ်လေးတွေ ခွဲခြမ်းပြီး ထပ်ခါ ထပ်ခါ တည်ဆောက် ပြုပြင် တိုးချဲ့ သွာသည့် နည်းလမ်း ဖြစ်ပါတယ်။ သတိထားရမှာက Iterative Model က Agile မတိုင်ခင် က တည်း က တည်ရှိနေခြင်း ဖြစ်ပါသည်။ Agile က IID ရဲ့ အခြေခံ နည်းလမ်း ကို ယူသုံးပြီး ပိုမိုကောင်းမွန် အောင် ပုံဖော်ထားသည့် ဘဘောပါ။ Agile ရဲ့ အခြေခံ အုတ်မြစ် လို့ ဆိုရမှာပေါ့။

ဒီနည်းလမ်းမှာ အယူအ နှစ် ခု ရှိပါတယ်။

၁။ Incremental Development (အပိုင်းလိုက် တိုးမြင့်တည်ဆောက်ခြင်း)

Software တစ်ခုလုံးကို Waterfall ကဲ့သို့ အစအဆုံး မတည်ဆောက်ပဲ အလုပ်လုပ်နိုင်သည့် အပိုင်းငယ်များ (increment) လေးများ အဖြစ် ခွဲထုတ်ပြီး တစ်ခုပြီး တစ်ခု ထပ်ပေါင်းကာ တည်ဆောက်ခြင်းဖြစ်သည်။

ဥပမာ

Increment 1 : User Login နှင့် Register လုပ်ဆောင်ချက်ကို အပြီးသတ် တည်ဆောက်သည်
Increment 2: Increment 1 တွင် News Feed ပြသည့် အချက်အလက် ထပ်ပေါင်းထည့်သည်
Increment 3: Increment 2 တွင် Comment ရေးသည့် လုပ်ဆောင်ချက် ထပ်ပေါင်းထည့်သည်

Increment တစ်ခုပြီး တိုင်း သုံးစွဲသူ အမှန်တကယ် အသုံးပြုနိုင်သည့် Software အပိုင်း တစ်ခု ထွက်ပေါ်လာသည််။ ဒီအချက်က အရေးပါပါတယ်။ Increment တစ်ခု တိုင်းဟာ သုံးစွဲ အနေ တကယ် သုံးစွဲလို့ ရသည့် အပိုင်း ဖြစ်နေဖို့ လိုပါတယ်။

၂။ Iterative Development (ထပ်ခါထပ်ခါ ပြုပြင်ပြောင်းလဲခြင်း)

Software ကို အကြမ်းထည် ပုံစံ ကနေ စတင်ပြီး သုံးစွဲသူ သို့မဟုတ် team ထံ ကနေ အကြံပြုချက်များ ကို ရယူပါတယ်။ ရလာသည့် feedback အကြံပြုချက်တွေကို ပြန်လည် မွန်းမံ ပြီး တည်ဆောက်ပါတယ်။ တနည်းပြောရင် ဖန်တီး → စမ်းသပ် → အကြံပြုချက် → ပြုပြင် ဆိုသည့် လုပ်ငန်းစဥ် cycle ကို Software ၏ အရည်အသွေး သတ်မှတ်ချက် မှီသည် အထိ အကြိမ်ကြိမ် ထပ်ခါထပ်ခါ လုပ်ဆောင်ခြင်း ဖြစ်ပါသည်။

ဥပမာ အားဖြင့် Increment 2 လုပ်ဆောင်နေစဥ် မှာ Increment 1 ၏ feedback များ ဝင်ရောက်လာသည့် အခါ တစ်ခါတည်း ထည့်သွင်းပြင်ဆင် လုပ်ဆောင်ခြင်း မျိုးပါ။ ဥပမာ News Feed ရေးနေသည့် အချိန်မှာ Login , Register အပြင် Google Login ပါလိုသည့် feedback အတွက် တစ်ခါတည်း ထည့်သွင်း ဖန်တီးခြင်း မျိုးပါ။

၂.၄ Spiral Model

Barry Boehm က ၁၉၈၆ ခုနှစ် မှာ စတင်မိတ်ဆက်ခဲ့သည့် Model ပါ။ အဓိက Risk Analsis ကို အလေးပေးထားခြင်း ဖြစ်ပါသည်။ Waterfall Model နှင့် Iterative Model ၏ ထပ်ခါတစ်လဲလဲ ပြန်လည် တည်ဆောက်မှု ကို ပေါင်းစပ်ထားသည့် နည်းလမ်း တစ်ခုပါ။

အလုပ်လုပ်ပုံ

ပုံပါ အတိုင်း ခရုပတ် ပုံစံ သို့မဟုတ် ဝက်အူရစ် (Sprial) ပုံစံ အတိုင်း အလုပ်လုပ်ပါသည်။ Project က အလယ်ဗဟိုမှ စတင်ပြီး ခရုပတ် ပုံစံဖြင့် တဖြည်းဖြည်း တိုးချဲ့ သွားသည့် ပုံပါ။ တစ်ပတ် စီတိုင်းမှာ အဆင့် ၄ ဆင့် ကို ထပ်ခါ ထပ်ခါ လုပ်ဆောင်ပါတယ်။

၁. Planning

ဒီအဆင့်မှာ objectives များ requirement များ နှင့် အခြား ရွယ်ချယ်စရာ လမ်းကြောင်းများကို သတ်မှတ် ပါသည်။

၂. Risk Analysis

ဒီအဆင့်က အရေးကြီး ဆုံး အပိုင်း ဖြစ်ပါသည်။ သတ်မှတ်ထားသည် objective များအတွက် နည်းပညာဆိုင်ရာ သို့မဟုတ် စီမံခန့်ခွဲ မှု ပိုင်းဆိုင်ရာ Risk တွေကို ရှာဖွေ ခြင်း သုံးသပ်ခြင်း ဖြေရှင်း ရန် နည်းလမ်းများ ရှာဖွေ ပြင်ဆင်ခြင်း တို့ကို လုပ်ဆောင်ရပါတယ်။

၃. Engineering (တည်ဆောက်ခြင်း)

Software ကို အမှန်တကယ် တည်ဆောက် (Develop) ပြီး စမ်းသပ် စစ်ဆေး (Test) လုပ်ဆောင်ပါသည်။ အစောပိုင်း ခရုပတ် ပုံစံ တွင် Prototype သို့မဟုတ် Proof Of Concept ကို တည်ဆောက် ကြပါတယ်။

၄. Evaluation (သုံးသပ် အကဲဖြတ်ခြင်း)

သုံးစွဲသူ က ရရှိလာသည့် product ကို စမ်းသပ် သုံးစွဲ ပြီး feedback များ ပြန်လည်ပေးပါတယ်။ ရလာသည့် feedback ပေါ်မှာ မူတည်ပြီး နောက်အပတ် လုပ်ဆောင် ရမည့် Next Iteration အတွက် Planning ပြန်လည် စတင်ပါတယ်။

ဒီ အဆင့် ၄ ဆင့် ကို Project ပြီးဆုံးသည် အထိ အကြိမ်ကြိမ် ထပ်ခါ ထပ်ခါ လုပ်ဆောင် ပါတယ်။

Spiral Model မှာ ပြဿနာ မဖြစ်လာခင် Risk များကို စောစီးစွာ ရှာဖွေပြီး ဖြေရှင်းထားခြင်း ဖြစ်ပါတယ်။ Compelx ဖြစ်သည့် project များ risk များသည့် project များ အတွက် အဆင်ပြေသော်လည်း လုပ်ငန်းစဥ်က ရှုပ်ထွေးပြီး Risk Analysis အတွက် ကျွမ်းကျင်သူများ လိုအပ်ပါတယ်။ Risk Analysis က ကောင်းမွန်သောလည်း အချိန် နှင့် ငွေ ကုန်ကျ မှု ရှိနိုင်တာ ကို သတိထားသင့်ပါတယ်။ နောက်ပြီး Project အသေးလေးတွေ အတွက် လုံးဝ သင့်တော်မှု မရှိပါဘူး။

၂.၅ V-Model

Waterfall Model ကို တိုးချဲ့ထားသည့် ပုံစံ တစ်ခု လို့ ဆိုနိုင်ပါတယ်။ Waterfall မှာ အဓိက အားနည်းချက် ဖြစ်သည့် Testing ကို Development ပြီးမှ လုပ်ဆောင်ခြင်း အစား V-Modal က Development အဆင့်တိုင်း မှာ သက်ဆိုင်ရာ Testing အဆင့်တစ်ခု ကို တစ်ပါတည်း ယှဥ်တွဲ သတ်မှတ်ထားပါတယ်။

အလုပ်လုပ်ပုံ

V ပုံစံ ၏ ဘယ်ဘက် မှာ Verification သို့မဟုတ် Development အဆင့် များကို ကိုယ်စားပြုပြီး ညာဘက် ခြမ်း ကတော့ Validation သို့မဟုတ် Testing အဆင့် များကို ကိုယ်စားပြုပါတယ်။

Verification & Development (ဘယ်ဘက်အခြမ်း အပေါ်မှ အောက်)

၁။ Concept Of Operations

Customer ၏ လိုအပ်ချက်များကို သတ်မှတ်ပါသည်။ Business Need က ဘာလဲ။ ဘာတွေကို အဓိက သတ်မှတ်သည့် အဆင့်ပါ

၂။ Requirements and Architecture

ရလာသည့် Requirement ပေါ် မူတည်ပြီး Software တစ်ခုလုံး ၏ တည်ဆောက်ပုံ Architecture ကို ရေးဆွဲပါတယ်

၃။ Detail Design

Architecture ကြီးထဲမှ Module တစ်ခုချင်းစီ ရဲ့ အသေးစိတ် design ကို ရေးဆွဲပါတယ်

၄။ Implementation

နောက်ဆုံး အဆင့် Code ကို စတင်ရေးသားပါတယ်။

Validation & Testing (အောက်မှ အပေါ်)

Coding ပြီးသွားသည့် အခါမှာတော့ အောက်မှ အပေါ်သို့ ပြန်တက်လာပြီး အောက်ပါ အဆင့်များကို လုပ်ဆောင်ပါတယ်။

၁။ Integration, Testing and Verification

Module တစ်ခု ခြင်းစီ မှန်ကန် စွာ အလုပ်လုပ်ရဲ့ လား Module တိုင်း က အလုပ်လုပ်ရဲ့လား စစ်ဆေးပါတယ်။ Module တိုင်းရဲ့ Unit Testing အလုပ်လုပ်ရဲ့လား စစ်ဆေးပါတယ်။

**

**

၂။ System Verification and Validation

စနစ် တစ်ခုလုံး စစ်ဆေးသည့် အဆင့်ပါ။ Architecture Design အတိုင်း အလုပ်လုပ်ရဲ့လား Detail Design အတိုင်း အလုပ်လုပ် ရဲ့လား , Function တွေ ပြည့်စုံ မှု ရှိရဲ့လား စစ်ဆေးခြင်းပါ။ Software ကို တကယ် သုံးစွဲ သူ တွေကို ပေးပြီး အဆင်ပြေမပြေ အတည်ပြုစစ်ဆေးတာပါ

**

**

၃။ Operation Maintenance

သုံးစွဲသူ ဆီ ကို Software (Product) ရောက်သွားပြီး နောက်ပိုင်း (Post Deployment) မှာ လုပ်ဆောင်ရတဲ့ အဆင့်ပါ။ Software အသုံးပြုနေစဥ် မှာ ပေါ်ပေါက်လာသည့် ပြဿနာတွေကို ပြုပြင်ထိန်းသိမ်း တာပါ။

V-Model ရဲ့ အဓိက အားသာချက်က Testing ကို အစောကြီး လုပ်ခြင်းပါ။ Development အဆင့် စပြီ ဆိုတာ နှင့် သက်ဆိုင်သည့် Testing , Test Plan များကို ကြိုတင်ရေးဆွဲ ထားနိုင်ပါတယ်။

ဒါပေမယ့် Waterfall Model အတိုင်း အဆင့်တစ်ခု ပြီးပါက နောက်ပြန်လှည့် လို့ မရပါဘူး။ Requirement တွေ ပြောင်းလဲ ဖို့ အလွန်ခက်ခဲပါတယ်။