What is Process Iteration?
Software Project ကြီးကြီးတွေမှာ အပြောင်းအလဲဆိုတာ မလွဲမသွေကြုံတွေ့ရမယ့်အရာတခုဖြစ်ပါတယ်။ တကြိမ်ထဲနဲ့ပြီးသွားတဲ့အထဲ software ရေးတာမပါပါဘူး။ Business requirement ပြောင်းရင်လည်း system requirement တွေကအစပြောင်းသွားနိုင်တယ်။ Technology အသစ်တွေထွက်လာရင်လည်း design & implementation တွေပြောင်းရမှာပါပဲ။ မပြောင်းနိုင်ရင်ကျန်ခဲ့မှာပါ “old but gold” ဆိုတဲ့အထဲ software မပါဘူး။အဲ့ဒီလိုအပြောင်းအလဲတွေကြောင့် software process တွေနောက်တခါ(ထပ်ခါထပ်ခါ) ပြန်လုပ်ရတာကို process iteration လို့ခေါ်ပါတယ်။
What is software process?
(https://www.facebook.com/story.php?story_fbid=130503012425256&id=110405837768307 ) ဒီစာစုလေးမှာ အခုလိုထပ်ခါထပ်ခါပြန်ပြန်လုပ်ရမယ့် process တွေကိုကိုင်တွယ်ဖို့ အထောက်အကူပြုနိုင်မယ့် software process model နှစ်ခုကို အမြည်းသဘောလေးမိတ်ဆက်ပေးသွားပါမယ်။
ပထမ model က Incremental delivery လို့ခေါ်ပါတယ်။ သူ့အကြောင်းမပြောခင် အပိုင်း 2 ကိုနဲနဲပြန်သွားရအောင်…။( အပိုင်း 2 https://www.facebook.com/110405837768307/posts/136599951815562/ ) waterfall model ရဲ့အလုပ်လုပ်ပုံက တဆင့်ချင်းသွားတာဆိုတော့ implementation (develop) လုပ်ဖို့ design လိုတယ် ၊ design ထွက်ဖို့ကလည်း customer ဆီက requirement လိုတယ် အဲ့ဒီတော့ တခုခုကိုပြောင်းလဲမယ်ဆိုရင် အစအဆုံးပြန်လုပ်ရတော့ အချိန်ကြာတယ်… အဆင်မပြေဘူး။ဒါပေမယ့် အားသာချက်က တဆင့်ချင်းစီမှာ documentation ကောင်းကောင်းထွက်တော့ structure ကောင်းကောင်းချလို့ရတယ်…နားလည်လွယ်တယ်။ evolutionary development ကတော့ requirement & design ကိုစောင့်နေစရာမလိုတော့ မြန်မြန်ဆန်ဆန်ပြင်လို့ရတယ်။ ဒါပေမယ့် သူ့အားနည်းချက်က ကြိုပြီး frame ချချိန်မရတော့ ကြာလေ structure ကပျက်လေဖြစ်မှာ။ တထပ်တိုက်ဆောက်ဖို့ foundation ချထားတာကို 3 ထပ်လောက်ဆောက်သလိုဖြစ်တာပေါ့။ အချိန်ကြာတာလာတဲ့အမျှ တဖြည်းဖြည်းနဲ့ နားလည်ဖို့ခက်လာသလို maintain လုပ်ဖို့လဲခက်လာတယ်။ အခုရှင်းပြမယ့် incremental delivery က waterfall နဲ့ incremental ရဲ့အားသာချက်တွေကိုပေါင်းထားတဲ့ သူ့တိုနှစ်ခုကြားက model ပါပဲ။ Incremental delivery ရဲ့အလုပ်လုပ်ပုံက ပထမဆုံး client ကို ဒီ software မှာဘယ်လို service တွေပါမှာလဲသတ်မှတ်ခိုင်းရတယ် ။ ပြီးတော့ ဘယ် service တွေကအရေးအကြီးဆုံးလဲ ဘယ်ကနဲနဲအရေးကြီးတယ် ဘယ်ကအရေးမကြီးဘူး စသဖြင့် ကိုယ့်ဟာကိုယ် ခွဲခြားသတ်မှတ်လိုက်တယ်။ နောက်တဆင့်က first version မှာ မဖြစ်မနေပါသင့်ပါထိုက်တဲ့ အရေးကြီးတဲ့ service တွေရွေးရတယ်။ ရွေးလိုက်တဲ့ service တွေအတွက် requirements, design, implementation ,testing တွေကိုအဆင့်ဆင့်လုပ်သွားတယ်။waterfall လိုမျိုးပါပဲ။ အဲ့ဒါကို first increment လို့ခေါ်တယ်။ first increment ပြီးတာနဲ့ software က production release လုပ်လို့ရပြီ။ first increment လုပ်နေဆဲမှာ second increment အတွက် requirement analysis လုပ်တယ်။ ဒါပေမယ့် requirement changes တွေကိုတခုမှမပြင်သေးပါဘူး။လက်ရှိလုပ်နေတဲ့ increment ကိုပဲပြီးအောင်ဆက်လုပ်တယ်။ ပြီးမှ နောက်တခါ second increment အဖြစ် requirements, design, implementation, testing ကိုထပ်လုပ်တယ်။ အဲ့လိုနဲ့ ဒီ software ကို perfect ဖြစ်အောင် third increment, fourth increment စသဖြင့် ထပ်ခါထပ်ခါလုပ်သွားတယ်။
1.customer က software တခုလုံးပြီးတဲ့အထိစောင့်စရာမလိုဘူး… first increment မှာစသုံးလို့ရတော့ သူ့အတွက် income မြန်မြန်ရတယ်။ first increment မှာ သူစိတ်ကျေနပ်မယ့် service တွေရွေးခဲ့ဖို့တော့ သတိထားပေါ့ဗျာ။ 2.first increment က error များလို့ release လုပ်ဖို့အဆင်မပြေဘူးဆိုရင်တောင် customer က prototype အဖြစ်ကြည့်လို့ရတော့ idea ထွက်တယ်။သူဘယ်လိုထပ်လုပ်လို့ရတယ် ဘာတွေလိုနေတယ်ဆိုတာပေါ့။ ဒါက ကျနော့်အတွက်တော့ တော်တော်အကျိုးများတယ်ဗျ။ ကျနော်အမြဲတမ်းပြောနေသလိုပဲ customer က software သာအပ်သာသူ့ကိုသူဘာလိုချင်မှန်းမသိဘူးဆိုတာ။ပိုဆိုးတာက သူမသိဘူးဆိုတာကိုလက်မခံတာပဲ။ ငြင်းလို့လည်းမရ လက်ခံလို့လဲကိုယ့်ဟာကိုယ်ကြိုးကွင်းစွပ်သလိုဖြစ်မှာနဲ့တော်တော်တိုင်ပတ်ရတယ်။ 3.ပြီးတော့ risk နည်းတယ်ဗျ။ ဆိုလိုတာက product က တနှစ်လောက်နေမှပြီးမှာဆိုရင် တနှစ်ပြည့်မှ အဆင်မပြေဘူးဆိုတာသိတော့ ရင်းထားရတဲ့ အချိန်တွေငွေတွေမနည်းဘူးလေ။ first increment, second increment လောက်မှာ အနေအထားကိုခန့်မှန်းပြီး ရှေ့ဆက်သွားလို့ရတော့ အဆင်ပြောတာပေါ့။ 4.first increment မှာ အရေးအကြီးဆုံးတွေရွေးလုပ်လို့ပြောခဲ့တယ်နော်။ first increment ကတည်းကပါလာတာဆိုတော့ တနည်းအားဖြင့် testing အလုပ်အများဆုံးပေါ့။အဲ့တော့ရေးအကြီးဆုံး service တွေက user လက်ထဲ error တက်နိုင်ချေနည်းတာပေါ့။ အမြည်းကျွေးတာတော်တော်များသွားလို့ဒီလောက်နဲ့နားပြီး နောက် model တခုဖြစ်တဲ့ Spiral Development ကိုရှင်းပြပါမယ်။ Spiral Development ဆိုတာကလည်း Process Iteration ကို အထောက်အကူပေးနိုင်တဲ့ software process model တမျိုးပါပဲ။ 1986 မှာ Barry Boehm ဆိုတဲ့ software engineer တယောက်က သူ့ရဲ့ သုတေသနစာတမ်းမှာစတင်ဖော်ပြခဲ့တာပါ။ incremental delivery နဲ့တော်တော်လေးဆင် ပြီး risk analysis အတွက်ပိုအားသာပါတယ်။ risk ဆိုတာက software အောင်မြင်ဖို့အတွက်ရင်ဆိုင်ရမယ့် အခက်အခဲတွေသောကတွေဒုက္ခတွေပြဿနာတွေကိုပြောတာ။ Spiral ဆိုတဲ့အတိုင်း software process တခုကို အရစ် တရစ် အနေနဲ့သတ်မှတ်ပြီး အရစ် တွေအများကြီးနဲ့လုပ်သွားတာပါ။ ဥပမာ အတွင်းဆုံးအရစ် (innermost loop) မှာ software specification တွေသတ်မှတ်မယ်။နောက်တရစ်မှာ system design တွေလုပ်မယ် နောက်တရစ်မှာ implementation လုပ်မယ် စသဖြင့်ပေါ့။ အရစ်ဘယ်နှစ်ရစ်ရှိလဲဆိုတာတော့ဘုရားသခင်ပဲကြိုသိပါလိမ့် ။
Project risks တွေရဲ့အနေအထားအပေါ်မူတည်ပြီး project manager က သင့်တော်သလို့သတ်မှတ်သွားတာပါ။ အဲ့ဒါကြောင့် spiral development မှာ project manager ကအရေးကြီးတဲ့အခန်းကဏ္ဍမှာပါဝင်ပါတယ်။ ဒါပေမယ့် အရစ်တရစ်ချင်းစီမှာ ဒီအပိုင်း 4 ပိုင်းကိုလုပ်ဆောင်ရပါတယ်။
1.Object setting – ဒီအပိုင်းက plan ချတဲ့အပိုင်းလို့ပြောရမယ်။ဒီ အရစ်မှာ ဘာတွေလုပ်မလဲခွဲခြမ်းစိတ်ဖြာတယ်။သဘောတူညီချက်တွေသတ်မှတ်တယ်။ဖြစ်နိုင်တဲ့ အခက်အခဲ(project risk) တွေကို ဆွဲထုတ်ရတယ်။
2.Risk assessment and reduction – risk တခုချင်းစီကို အသေးစိတ် လေ့လာပြီး ဖြေရှင်းဖို့နည်းလမ်းရှာရတယ်။တခြားတမျိုးပြောင်းသုံးလို့ရမလား စသဖြင့် ဖြစ်နိုင်တဲ့ နည်းလမ်းတွေစဥ်းစားရတယ်။ ဒီအဆင့်က သင့် project ရဲ့ project risk တွေကိုတော်တော်လေးလျော့သွားစေမှာပါ။
3.Development and validation – ဖြစ်နိုင်တဲ့ ပြဿနာတွေလည်းသိနေပြီ ဆိုတော့ ဒီ အပိုင်းမှာက သင့်တော်တဲ့ development model တခုကိုရွေးချယ်ရပါမယ်။ နဲနဲရှုပ်သွားပြီလား model ထဲမှာမှာ နောက် model တခုကိုထပ်ရွေးခိုင်းနေတော့….အခုရွေးရမယ့် model က spiral development မှာလက်ရှိလုပ်နေတဲ့ အရစ်အတွက်ပါပဲ။ နောက်တရစ်ဆိုလည်း risk တွေအပေါ်မူတည်ပြီးသင့်တော်တဲ့ နောက် model တမျိုးထပ်ရွေးရဦးမှာပါ။ မြင်သာသွားအောင် ကျနော့် အတွေ့အကြုံလေးပြောပြပေးချင်ပါတယ်။ code ရေးတာက project တခုလုံးတခါတည်းရေးတာမဟုတ်ဘူး။အပိုင်းလိုက်ခွဲချပြီး တပိုင်းချင်းစီပြန်ပေါင်းကြတာ။အဲ့ချိန် sub-system တခုနဲ့တခုချိတ်ဆက်တဲ့နေရာမှာခက်ခဲ (risk များ) နိုင်တယ် ဆို documentation ကောင်းကောင်းရှိတဲ့ waterfall model သုံးသင့်ပါတယ်။ ကျနော်ဆို code ပေါင်းမယ့်ရက်မှ အဲ့အပိုင်းရေးတဲ့ developer ပျောက်လို့တိုင်ပတ်ခဲ့တဲ့နေ့ရက်တွေအများကြီးပါပဲ။ အလားတူပါပဲ risk တွေအရ UI/UX ကအရေးကြီးတဲ့အပိုင်းလား? Safety ကအရေးကြီးလား စသဖြင့် သင့်တော်တဲ့ model ကိုရွေးချယ်ပြီး develop လုပ်သွားရမှာပါ။ ရေးပြီးသားတွေရှိတယ်ဆိုရင်တော့ CBSE သုံးပေါ့ဗျာ။ Planning – ပြီးသွားတဲ့ result ကိုပြန်စီစစ်တယ်။နောက်တရစ်ကိုဆက်လုပ်ဖို့ လိုအပ်လား/မလိုအပ်လား ဆုံးဖြတ်တယ်။လိုအပ်တယ်ဆိုရင် နောက်တရစ်မှာ ဘာတွေလုပ်ကြမလဲဆိုတာ သတ်မှတ်ကြတယ်။ Spiral development နဲ့အခြား process model တွေရဲ့အဓိက ကွာခြားချက်ကတော့ risk တွေကိုစီမံနိုင်တာပါပဲ။ risk minimisation ဆိုတာလည်း project management မှာအရေးပါတဲ့ အခန်းကဏ္ဍ တခုပါပဲ။နောက်ပိုင်းမှာ software project management အပိုင်းတွေကိုလည်း ရေးသားဖို့အစီအစဥ်ရှိကြောင်းပြောရင်းနဲ့ ဒီစာစုလေးကိုဒီမှာရပ်နားပါရစေ…
BMPS Education Center မှ ကူးယူရေးသား ဖော်ပြပါသည်။
