“Software process model is an abstract representation of a software process” လို့ကျောင်းတွေမှာသင်ခဲ့ရပါတယ်။ ကျနော်ကတော့ Software process model ကို software development team တခုရဲ့ လုပ်ထုံးလုပ်နည်းလို့အနက်အဓိပ္ပါယ်ဖွင့်ဆိုချင်ပါတယ်။ Software တခုရေးပုံရေးနည်းက software ရဲ့ပုံစံ , client ရဲ့လိုအပ်ချက်, developer တွေရဲ့ skill အလိုက် software တခုနဲ့တခု မတူညီကြပါဘူး။ကျနော်ဒီ ဆောင်းပါးမှာ အခြေခံအကျဆုံး နဲ့ အသုံးအများဆုံး software process model 3ခု ကို ဆွေးနွေးတင်ပြသွားချင်ပါတယ်။
ပထမဆုံးတခုက The waterfall model ပါ။ သူ့ကို software life cycle လို့လည်းပြောကြပါတယ်။ သူကဘယ်လိုလုပ်လဲဆိုရင် project တခုလုံးကို အဆင့်တွေသပ်သပ်စီခွဲချလိုက်ပြီးတော့ တဆင့်စီလုပ်သွားတာ။ waterfall ဆိုတဲ့အတိုင်းပဲ အပေါ်ကနေအောက်ကိုပဲသွားရတာ လက်ရှိလုပ်နေတာက step 4 ဆိုပါတော့ step 1 မှာမှားခဲ့လို့သွားပြင်လိုက်ဦးမယ် မင်းတို့ ဆက်ရေးသွားလိုက်ဆိုပြီးမရဘူး။step 1 ကိုသွားလိုက်ရင် 1,2,3,4 အစဥ်လိုက်ပြန်လုပ်ရတာ။ step တဆင့်ချင်းစီက အမှားမခံဘူးပေါ့ဗျာ။ မှားရင် မှားတဲ့နေရာကနေပြန်လုပ်ပဲ။ သူ့ကိုဘယ်လိုအနေအထားမှာသုံးကြလဲဆိုတော့ ကိုယ်အရင်ကလုပ်ဖူးပြီးသား software တွေရေးတဲ့အခါသုံးတယ်။အားသာချက်က တဆင့်စီသွားတာဆိုတော့အမှားနည်းတယ်… ။ developer skill ဂျွတ်ထော်နေအောင်မလိုဘူး။သင့်ရဲ့ project က small size ဖြစ်တယ် requirement လည်းငြိမ်တယ် team member တွေကလည်း junior တွေပဲဆိုရင်တော့ သေချာတယ် waterfall သုံးသင့်ပါတယ်။requirement အပြောင်းအလဲများတဲ့ project တွေဆိုရင်တော့မသုံးသင့်ပါဘူး။ ခွဲမယ့်အဆင့်တွေကကိုယ့်စိတ်ကြိုက်ခွဲလို့ရပါတယ်။ ကျနော်ကတော့ နမူနာအနေနဲ့ အဆင့် 5 ဆင့်ခွဲပြီးရှင်းပြပေးသွားပါမယ်။
1.Requirement analysis and definition
ဒီအဆင့်က Client နဲ့ ခေါင်းချင်းဆိုင်ဆွေးနွေးရတဲ့အဆင့်ပါ ။ဘာတွေဆွေးနွေးရလဲဆိုတော့ Software မှာ ဘာ services တွေပါမှာလဲ? အခက်အခဲတွေကဘာတွေလဲ? ဘယ်အနေအထားထိလိုချင်တာလဲ ? စသဖြင့်အဲ့လိုမျိုးတွေကို အသေးစိတ်သတ်မှတ်ရတယ်။ ကျနော့်အတွေ့အကြုံအရ ဆိုရင် “ဘယ်အနေအထားထိလိုချင်တာလဲ” ဆိုတာက အသက်ပါပဲ။ Software goal ပေါ့။ မဟုတ်ရင် အဲ့ software က ရေးလို့ကိုမပြီးတော့ဘူး။ပြီးဆုံးသွားတဲ့ software ရယ်လိုတော့မရှိဘူးပေါ့ version 1 ကဘယ်ထိ version 2 ကဘယ်ထိ အဲ့လိုမျိုးပြောတာ။
2.System and software design
အရင်ပတ်က အပိုင်း ၁ မှာပြောခဲ့သလိုပဲ System architecture တခုလုံးကို design ချတာ ။ UI/UX design, Database Design, Server Architecture,တချို့ဆို Code ရေးဖို့အတွက် Object Orient Software Design ပါချတယ်… class name ဘာပေးရမယ် ဘယ် method ကနေ ဘယ် method ကိုခေါ်မယ်ကအစအဲ့ထဲပါတယ်။
3.Implementation and unit testing
ဒီအဆင့်မှာတော့ ဆွဲထားတဲ့ software design တွေကို ကြည့်ပြီး code ရေးကြပါတယ်။ရေးတဲ့အခါမှာအားလုံးတခါတည်းမရေးပါဘူး တပိုင်းရေးပြီးတာနဲ့တပိုင်းပြန်စစ်တာပါ။ step 1 မှာ သတ်မှတ်ထားတဲ့ အတိုင်းဖြစ်လားမဖြစ်လား ပြန်စစ်ဆေးတာပေါ့။အဲ့လိုတပိုင်းစီစစ်ဆေးတာကို unit testing လို့ခေါ်ပါတယ်။အဲ့လိုနဲ့တပိုင်းစီရေးလိုက်စစ်လိုက်လုပ်ပါတယ်။
4.Integration and system testing
တပိုင်းစီရေးထားတဲ့ဟာတွေပေါင်းပါတယ်။ Software တခုလုံးပြီးတဲ့အခါ။client နဲ့သတ်မှတ်ထားခဲ့တဲ့ requirement တွေ အတိုင်းဟုတ်မဟုတ်ပြန်စစ်ပါတယ်။ ဒီအဆင့်ပြီးရင် software က client လက်ထဲအပ်ဖို့ အဆင့်သင့်ဖြစ်နေပါပြီ။
5.Operation and maintenance
ဒီအဆင့်ကဘယ်ကစလဲဆိုရင် software ကို user တွေလက်ထဲရောက်ပြီးစသုံးတဲ့အချိန်ကနေစပါတယ်။ အားလုံးထဲမှာ အကြာဆုံးအဆင့်ပါပဲ။ ဘယ်လောက်ကြာလဲဆိုရင် သုံးတဲ့ user တွေရှိနေသမျှကြာပါတယ်။ ဒီအဆင့်မှာ ဘာတွေလုပ်ရလဲဆိုရင် အရင်အဆင့်တွေမှာ မတွေ့ခဲ့တဲ့ bug တွေကိုရှင်းရပါတယ်။user တွေရဲ့ feedback တွေကနေ ပြင်သင့်တာပြင် services အသစ်တွေထပ်ထည့်တာတွေလုပ်ရပါတယ်။
ဒီလောက်ဆို waterfall model ရဲ့အလုပ်လုပ်ပုံကိုသဘောပေါက်လောက်မှာပါ။
ဒုတိယ မြောက်ပြောပြချင်တဲ့ software process model က Evolutionary Development လို့ခေါ်ပါတယ်။ software တခုရေးရတာဟာတကယ်ရေးရင် အင်မတန်ရှုပ်ထွေးပါတယ်။ programming language ကို မိုးပျံအောင်ကျွမ်းကျင်နေတိုင်းလည်း စနစ်ကျတဲ့ software တခုဖြစ်လာမယ်လို့မှတ်ယူလို့မရပါဘူး။ အပိုင်း ၁ နဲ့ waterfall model ကိုဖတ်ပြီးတဲ့အချိန်မှာ software တခုဘယ်လိုရေးကြလဲအနည်းငယ်တော့သိလာမှာပါ။ မိတ်ဆွေတို့ programming language တခုခုတတ်ထားရင် software တခုစရေးလို့ရပြီလို့ထင်ကောင်းထင်ပါလိမ့်မယ်။ တချို့ project တွေဟာအဆင်ပြေနိုင်ပေမယ့်…အများစုက တကယ်တန်း လက်တွေ့မှာတော့ တိကျတဲ့ requirement ရဖို့ဆိုတာအင်မတန်ခက်သလို အပြောင်းအလဲဟာလည်းအင်မတန်များပါတယ်။ client တွေကသူ့တို့ဘာလိုချင်မှန်းရေရေရာရာမပြောပြနိုင်သလို… output ထွက်မှ idea အသစ်တွေထွက်လာပြီး feature အသစ်တွေထပ်ထည့် ချင်တာမျိုး ကြုံတွေ့ဖို့ဆိုတာ သေချာလုနီးပါး ပါပဲ။ Evolutionary Development ဟာဒီလိုပြဿနာတွေကိုဖြေရှင်းဖို့ပေါ်ပေါက်လာတာပါ။သူ့ရဲ့အလုပ်လုပ်ပုံက software မှာပါတဲ့ လုပ်ဆောင်ချက်တွေကို အစိတ်စိတ်အမွာမွာ ခွဲချလိုက်တယ်။ပြီးတော့တခုစီကို ပြီးအောင်အမြန်ရေးပြီး တပိုင်းပြီးတာနဲ့ တပိုင်းကို user လက်ထဲထည့်တယ်။ ပြီးမှ user comment တွေကိုကြည့်ပြီး ပြင်စရာပြင်တယ် ထပ်ထည့်စရာထည့်တယ်။နောက် version ထုတ်တယ်။ အဲ့လိုနဲ့ သူတို့ စိတ်ကြိုက်အနေအထားမရောက်မချင်း version တွေအများကြီးခွဲပြီးရေးသွားတာ။ အဲ့တော့ software အားလုံးပြီးတဲ့အချိန်ထိစောင့်စရာမလိုပဲသုံးလို့ရတယ်။စိတ်ကြိုက်ပြင်လို့ပြောင်းလို့ရတယ်။ Specification, development, validation က သီးသန့်စီလုပ်တာမဟုတ်တော့ဘူး။ တခါတည်းရောပြီးလုပ်တာ specification လုပ်နေစဥ်မှာပဲ ပြီးတဲ့အပိုင်းကို development စလုပ်တယ်။ development လုပ်နေဆဲပြီးတဲ့အပိုင်းကို validation စလုပ်နေပြီ … အဲ့လိုတွေလုပ်တော့ တော်ရုံ skill တွေနဲ့မရဘူး။ code တွေကို ရေးကတည်းနဲ့ flexible (ပြောင်းလွယ်ပြင်လွယ်) ဖြစ်အောင်ရေးထားရတယ်။အဲ့ဒါကြောင့် ကိုယ့်ရဲ့ team က junior တွေများတယ်ဆိုရင် ဒီ model ကိုလုံးဝမသုံးသင့်ပါဘူးလို့ကျနော်အကြံပေးချင်ပါတယ်။Evolutionary development က အမျိုးအစားနှစ်မျိုးရှိပါတယ်။ပထမတမျိုးကတော့ Exploratory development ။ သူက development ကို နားလည်တဲ့အပိုင်းကနေစရေးတယ်။ဘယ်လိုလဲဆိုတော့ မင်းက ပင်လယ်ကူး သင်္ဘာကြီးတစီးဆောက်ဖို့နားမလည်ဘူးလား…ကိစ္စမရှိဘူး ငါးဖမ်းလှေလေးတစီးအရင်ဆောက်လိုက်ပါ။ မလုပ်တတ်သေးဘူးလား စက္ကူလှေလေးတော့ လုပ်တတ်မှာပဲ… အဲ့ကနေစလုပ်ပါ။ ဒီ model မှာက client က သူ့ဟာသူ သူလုပ်ချင်တာဘာလဲ နောက်ဆုံးဘယ်အနေအထားထိလုပ်ရမှာလဲသိတယ်။ သူကနေ feature အသစ်တွေထပ်ရေးခိုင်းပြီး တဖြည်းဖြည်းနဲ့ စက္ကူလှေကနေ ပင်လယ်ကူးသင်္ဘောကြီးဖြစ်လာတာပေါ့။နောက်တမျိုးက Throwaway prototyping လို့ခေါ်တယ်။ သူက customer ရဲ့ requirement ကိုနားလည်ဖို့အဓိကရည်ရွယ်ပြီးလုပ်ဆောင်တယ်။နားလည်ပြီးဆိုတာနဲ့ ပိုကောင်းတဲ့ requirement တွေပြန်သတ်မှတ်ပြီး develop လုပ်လုပ်သွားတာ။prototype ကိုလုပ်တဲ့အခါမှာ client ကသူဘာလိုချင်လဲသူ့ဟာသူသိအောင် လုပ်ပေးရတယ်။အဲ့ဟာက ဒီ model မှာအသက်ပဲလေ။အဲ့တော့ကိုယ့် client ကဘယ်လိုလူစားလဲဆိုတာကြည့်ပြီးဘယ်ဟာသုံးသင့်လဲစဥ်းစားကြပေါ့ဗျာ။
Component-based software engineering ကိုကျနော်ကတော့ အတိုကောက်အနေနဲ့ CBSE လိုခေါ်ပါတယ်။component-based development(DBD) လို့လည်းခေါ်ကြပါတယ်။ ကြုံဖူးကြမှာပါ ဒီ software က အရင်က ရေးပြီးသား design တွေ code တွေနဲ့ ခပ်ဆင်ဆင်ဖြစ်နေတာမျိုး ။ ဒီလိုရှိပြီးသား system တွေကိုပြန်သုံးရမယ့်အနေအထားဆိုရင် CBSE model ကိုသုံးကြပါတယ်။သူကတော့ဒီအဆင့်တွေကိုအစဥ်အတိုင်းလုပ်ပါတယ်။
1.Requirements specification2.Component analysis3.Requirementss modification4.System design with reuse5.Development and integration6.System validation
Requirements specification နဲ့ system validation ကတော့အရင်ပြောထားသလိုတွေပါပဲကွာခြားမှုမရှိလို့ ကြားကအဆင့်တွေကိုပဲပြောပြပါတော့မယ်။
Component analysis – client requirement က ကိုယ့်သုံးမယ့် component နဲ့အဆင်ပြေ/မပြေ လေ့လာရတဲ့အပိုင်းပါ။component ဆိုတာက ရှိပြီးသား code/design ကိုပြောတာ။လုံးဝထပ်တူကျ ယူသုံးလို့တော့မရဘူးပေါ့ နည်းနည်းပါးပါးတော့ပြင်ရမှာပဲလေ။
Requirement modification – component ကိုကြည့်ပြီးပြီဆိုတော့ requirement ကိုပြန်ကြည့်တယ်။ component နဲ့ကိုက်အောင်ပြန်ညှိလို့ရတာပြန်ညှိတာပေါ့။requirement modification လုပ်ဖို့ဘယ်လိုမှမဖြစ်နိုင်ဘူး….ဒါမှဒါပဲလိုချင်ရင် component analysis ကိုပြန်သွားအဖြေရအောင်ရှာ။
System design and reuse – code တွေကို component တွေပြန်သုံးလို့ရမယ့် design ချရတာပေါ့။ component မရှိတဲ့ feature တွေဆိုလည်းရေးရမှာတွေရေးကြတဲ့အပိုင်း။
Development and integration – ဒါကတော့ရှင်းပါတယ်…. component တွေသုံးပြီး software ကို development စလုပ်တာပေါ့။
Software တခုဘယ်လိုရေးလဲခေါင်းစဥ်နဲ့ software engineering အကြောင်းကိုအလျဥ်းသင့်သလို ဖတ်သူရှိနေသမျှ အပတ်တိုင်းမှာမျှဝေသွားမှာပါ။ beginner တွေအတွက် software engineering ဆိုတာ လေ့လာရတာဟာ လေထဲတိုက်အိမ်ဆောက်ရသလိုပါပဲ မျက်စိထဲမမြင်တော့ အလွန်ပျင်းစရာကောင်းပါတယ်။ IT အကြောင်းလုံးဝမသိတဲ့သူတွေပါနားလည်အောင်အတတ်နိုင်ဆုံးရှင်းပြပေးထားပါတယ်။
BMPS Education Center facebook page မှ ကူးယူရေးသား ဖော်ပြပါသည်။