ဆော့ဖ်၀ဲ ကုန်ကျစရိတ် ခန့်​မှန်းတွက်ချက်ခြင်း

ဆော့ဖ်၀ဲ ကုန်ကျစရိတ် ခန် မှန်းတွက်ချက်ခြင်း
ဘယ်ပရောဂျက်မှာမဆို ဖစ်တတ်တဲ့ ဘတ်ဂျက်မလုံလောက်မှု ပဿနာရဲ့ အဓိက အကြောင်းရင်းတွေထဲက တစ်ခုကတော့၊ အဲဒီပရောဂျက်ရဲ့ ကုန်ကျစရိတ် ကို ခန် မှန်းတွက်ချက်ရာမှာ အားနည်းခဲ့လို ဖစ်တဲ့အကြောင်း အမေရိကန်အစိုးရရဲ့ တာ၀န်ခံမှုဌာန Government Accountability Office (GAO) ကဆိုပါတယ်။ အဲဒီလို ကုန်ကျစရိတ်နဲ ပတ်သက်ပြီး ပဿနာဖြစ်တတ်တဲ့ အဓိကနယ်ပယ်တွေထဲမှာဆိုရင်  ဆာ့ဖ်၀ဲကတော့ ဇါတ်လိုက်ကျော်လူကြမ်းပေါ့။ မှန်ပါတယ်။ မိတ်ဆွေဟာ တကိုယ်တော်ပဲဖြစ်ဖြစ်၊ သုံးလေးရောက်စုထားတဲ့ အဖွဲ လးနဲ ပဲဖြစ်ဖြစ် အလွယ်တကူရေးသားနိုင်တဲ့၊ အလယ်အလတ် နဲ  အသေးစား ကုမ္ပဏီတွေမှာ ပုံမှန်သုံးစွဲနေကြ ဆာ့ဖ်၀ဲအမျိုးအစားတွေဖြစ်တဲ့ လက်လီအရောင်းစနစ်လိုမျိုး၊ registration တို  administration တို လို ကိစ္စရပ်တွေမှာ အဆင်ပြေ လွယ်ကူဖို  မှတ်တမ်းမှတ်ရာ နဲ အချက်အလက်တွေကို စီမံခန် ခွဲတဲ့စနစ်မျိုး စတဲ့ ဆာ့ဖ်၀ဲမျိုးတွေကတော့ မပြောပလောက်ဘူးပေါ့။
“အဲဒါမျိုး system က ငါတစ်ရောက်တည်း ဆိုရင် တစ်လ တစ်လခွဲ လာက်တော့ရေးရမယ်ထင်တယ်။ အင်း..အဲဒီတော့ ဒီခေတ်ပေါက်ဈေးနဲ  လး ငါး သိန်း တာ့ မှန်းထားလိုက်မယ်။ နာက်မှ လိုတိုး ပိုလျော့ပေါ့”
“တို က သုံးရောက်ပေါင်းရေးရမှာဆိုတော့ ခာက်သိန်းတောင်းလိုက်မယ်။ အး..ကြိတ်ကွာ။ မပေးတော့လည်း ညှိပြီး လျာ့ပေးလိုက်တာပေါ့။ အလားကားနေ အလကားပဲ”
“ကျောင်းသား project, assignment ဆိုတော့ သိပ်တောင်းလို မကောင်းပါဘူး။ ငါးသောင်း တစ်သိန်း လာက်ပဲယူလိုက်ပါ”
“ကြည့်သာ ပးပါဗျာ”….စသည်ဖြင့်ပေါ့။
ကျွန်တော်တို ဟာ ဆာ့ဖ်၀ဲရေးသားမှု ကုန်ကျစရိတ်ခန် မှန်းတွက်ချက်ခြင်းနဲ  ပတ်သက်လို တာ့ အစောပိုင်းကာလတွေတုန်းက အဲဒီလို နည်းစနစ်တွေနဲ ပဲဖြတ်သန်းလာကြတာပါ။
ဒါပေမယ့်လည်း သုံးစွဲသူစိတ်ကြိုက်ဆော့ဖ်၀ဲ (customized software) တွကိုရေးသားတဲ့အခါ အဲဒီလို နည်းစနစ်တွေက အလုပ်မဖြစ်တော့ပါဘူး။
• ကိုယ်မရေးဖူးသေးတဲ့ စနစ်မျိုးဖြစ်နေမယ်
• ဆာ့ဖ်၀ဲရှုပ်ထွေးမှု (complexity) ကလည်း corporate level, enterprise level ဖစ်နေမယ်
• ဆာ့ဖ်၀ဲ run ရမယ့် platform ကလည်း distributed system on cross platform (မတူညီတဲ့ hardware, software, operating system နဲ  communication sytems တွ ပါင်းထားတဲ့ စနစ်) ဖစ်နေပြီဟေ့ဆိုရင်
ဆော့ဖ်၀ဲရေးသားထုတ်လုပ်မှု ကုန်ကျစရိတ်ခန် မှန်းတွက်ချက်ခြင်း (software development cost estimation) လာက် ခါင်းကိုက်စရာကောင်း တဲ့ အလုပ်မျိုး မရှိနိုင်တော့ဘူးလို တာင် ဆိုချင်ပါတော့တယ်။
ကုန်ကျစရိတ်ကို လျာ့တွက်(under estimate) မိရင် ဘတ်ဂျက်မလုံမလောက်ဖြစ်ပြီး အရှုံးပေါ်မယ်။ စရိတ်ကို အရမ်းပိုတွက် (over estimate) မိပြန်လည်း ဈးများလို ဆိုပြီး ကိုယ့်ရဲ့ customer က တခြား ကိုယ့်ပြိုင်ဖက်တွေဆီ ရာက်သွားမယ်။ စာချုပ်စာတမ်း ကတိ က၀တ်နဲ လုပ်ရတာဖြစ်တဲ့အတွက် အချိန်ကို လျာ့တွက်မိလို  အချိန်မီမပြီးစီးရင်  ပဿနာပေါင်းသောင်းခြောက်ထောင်။ အချိန်ကို ပိုတွက်ထားပြန်ရင်လည်း “ကျွန်တော်တို က အဲဒီလောက်ထိ အချိန်မရဘူးဗျ” ဆိုပြီး ကိုယ့်ရဲ့ customer က တခြားရောက်သွားနိုင်ပြန်ရော။ ဒါကြောင့် enterprise_level-customized_software တွကို လက်ခံရေးပေးရတဲ့ ကုမ္ပဏီတွေရဲ့၊ စီးပွားရေးနဲ  လူမှုရေးဆိုင်ရာ အဓိက အခက်ခဲဆုံးအလုပ်ဟာ ဆာ့ဖ်၀ဲကုန်ကျစရိတ် ခန် မှန်းတွက်ချက်ခြင်းပါပဲ။
ဒီနေရာမှာ နဲနဲသတိပြုစရာ တစ်ခုရှိပါတယ်။ ဘယ်လောက်ထိကြီးမားတဲ့ ဆာ့ဖ်၀ဲကုမ္ပဏီကြီးတွေပဲဖြစ်ပါစေ (ဥပမာ Adobe Systems တို  Microsoft တို လိုမျိုး) အဆင်သင့် ၀ယ်ယူသုံးစွဲနိုင်တဲ့ အထွေထွေ အသုံးချဆော့ဖ်၀ဲ (e.g page maker, photo-shop, Words, Excel, etc) မျိုးတွေ ရးတာဆိုရင်တော့၊ နာက်ဆုံးဗျာ operating system software (e.g Windows, Linux, Mac) တွ ရးတာဖြစ်စေဦးတော့၊ ကုန်ကျစရိတ် ခန် မှန်းတွက်ချက် ရတာက သိပ် ဘးကျပ်နံကျပ် ဖစ်လေ့မရှိပါဘူး။ ကိုယ့်ကုမ္ပဏီ ကိုယ့်ဘတ်ဂျက် ကိုယ်ပိုင် Developer ကိုယ်ပိုင် သုတေသန နဲ  ဖွံ ဖိုးရေးဌာန  ဖစ်လေတော့ လိုအပ်ချက်ပေါ်မူတည်ပြီး နဲနဲပိုကြာသွားတာ ဘတ်ဂျက် ပိုကုန်သွားတာ စတာတွေ အပေါ်မှာ လိုတိုး ပိုလျော့ ညှိလို  နှိုင်းလို  လွယ်ပါတယ်။ နာက်ဆုံးမှာ ကိုယ့် ဆာ့ဖ်၀ဲက အရည်အသွေးကောင်းရင်၊ marketing ကာင်းကောင်းနဲ  ကိုယ့် product ကို promotion လုပ်လိုက်ရင်၊ ပိုကုန်ထားသမျှစရိတ်စကအတွက်၊ ပိုကြာသွားသမျှ အချိန်အတွက် အလွယ်တကူ ပန်ကာမိနိုင်ပါတယ်။ နာက်ဆုံးကုန်ကုန်ပြောရရင် ကိုယ့် product က အရည်အသွေးညံ့နေတာတို ၊ ပရောဂျက်ကို ဖျက်လိုက်ရ ရပ်လိုက်ရတာတို ဖစ်ခဲ့ရင်တောင် အခြေအနေက အဆိုးဆုံး မဖြစ်နိုင်သေးပါဘူး။ ခုနက ဆွးနွေးသလို ကိုယ့်ကုမ္ပဏီ ကိုယ့်အတွင်းရေးဖြစ်တဲ့အတွက် နာက်နောင်ပရောဂျက်တွေမှာ ပိုပြီး သသေချာချာ ကြိုးစား နိုင်ပါတယ်။ ဒါကြောင့် ပိုပြီး ရှင်းလင်း သချာအောင် ထပ်ပြောရမယ်ဆိုရင် “ဆော့ဖ်၀ဲ ရးသားမှု ကုန်ကျစရိတ် ခန် မှန်းတွက်ချက်တာနဲ ပတ်သက်ပြီး၊ အဓိက ခါင်းကိုက်ရတဲ့ ကုမ္ပဏီမျိုးတွေဟာ၊ ကာ်ပိုရေးရှင်းကြီးတွေ ဌာနကြီးတွေအတွက် သူတို စိတ်ကြိုက် သူတို လိုချင်တဲ့ပုံစံ ဆာ့ဖ်၀ဲရအောင် လက်ခံရေးသားပေးရတဲ့ ကုမ္ပဏီတွေဖြစ်တယ်” ဆိုတာပါပဲ။
ဘာကြောင့် ဒီလိုဖြစ်ရသလဲဆိုတာကို လ့လာရာမှာ၊ ပထမဆုံးအနေနဲ  ပုံမှန်သုံးစွဲနေကျ ဆာ့ဖ်၀ဲကုန်ကျစရိတ်ခန် မှန်းတွက်ချက်ခြင်း traditional software cost estimation နည်းစနစ်တွေကို စတင် လ့လာ အကဲဖြတ်ကြည့်ကြပါစို ။ စကားမစပ်ပြောရရင်တော့ အခုဆွေးနွေးမှာက ကျွန်တော်တို  academic လမ်းကြောင်းမှာ သင်ယူခဲ့ဖူးတဲ့ ကိုကိုမို (COCOMO) တို ဘာတို ဆိုတဲ့ နည်းစနစ်တွေမဟုတ်ပါဘူး။ တကယ့်လက်တွေ လာကမှာ အများဆုံး လုပ်ကိုင်ဆောင်ရွက် နတဲ့ ပုံသဏန် ကိုလေ့လာမှာပါ။
“ဟာ..ဒါဆို တို  သင်ခဲ့ရတာတွေ က အလကားဖြစ်ပြီလား ” ဆိုရင်လည်း “အဲဒီလိုတော့ မဟုတ်ပါဘူး။ အဲဒါတွေက ကျိန်းသေ အသုံး၀င်ပါတယ်။ လက်တွေ မှာလည်း တကယ် အသုံးချကြပါတယ်။” လို ပဲ ဖရမှာပါ။ ဒါပေမယ့် အဲဒီလို academic ပိုင်းက theory တွ နဲ  နည်းစနစ်တွေကို လက်တွေ လာကမှာ ဘယ်လို ဆွဲယူ အသုံးချသွားတယ်ဆိုတဲ့ အကြောင်းကတော့ အလွန်ကျယ်ပြန် တဲ့အတွက် နာက်နောင် ကြုံကြိုက်တဲ့အခါမှ သီးသန် တင်ပြပါမယ်။ အခုတော့ ဒီကနေ လက်ရှိ customized software တွ ရးပေးနေတဲ့ solutions ကုမ္ပဏီကြီးတွေမှာ software cost estimation ကို ဘယ်လိုဆောင်ရွက်ကြတယ်၊ အဲဒီလို လုပ်ရာမှာ ဘယ်လိုအားနည်းချက်တွေရှိတယ်၊ အဲဒီအားနည်းချက်တွေကို SEI (Software Engineering Institute) ရဲ့ နည်းစနစ်တွေသုံးပြီး ဘယ်လို ပုပြင်မယ် ဆိုတာတွေကို သာ အဓိက ထားတင်ပြဆွေးနွေးမှာပါ။
traditional software development cost estimation လုပ်ငန်းစဉ်မှာ၊ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှု ကုန်ကျစရိတ်ကို ခန် မှန်းတွက်ချက်မယ့် ပုဂ္ဂိုလ်တွေဟာ ပထမဦးဆုံးအနေနဲ  အာက်ပါ စာရွက်စာတမ်းတွေကို အပြန်ပြန် အလှန်လှန် အသေးစိပ် လ့လာရပါတယ်။
 user က ပးထားတဲ့ “ဒီ စနစ် အတွက်ဆော့ဖ်၀ဲရေးချင်တယ်၊ ဘယ်လောက်ကုန်ကျမလဲ၊ အသေးစိပ် ခန် မှန်းတွက်ချက်ပြီး ပန်တင်ပြပေးပါ” ဆိုတဲ့ Request For Proposal – RFP နဲ  တခြား အရေးကြီးအချက်တွေကို ထာက်ပံ့ပေးမယ့် Initial Capabilities Document - ICD (ဆော့ဖ်၀ဲရေးမယ့် ကုမ္ပဏီမှာ ဘယ်လိုပညာရှင်တွေ ရှိတယ်၊ ဘယ်လိုလိုင်းမှာ ကျွမ်းကျင်သူတွေ စုစုပေါင်း ဘယ်နှစ်ရောက်ရှိတယ်၊ ကုမ္ပဏီက ဘာတွေ လုပ်ဖူးတယ်၊ ဘာတွေလုပ်နိုင်တယ်၊ ကုမ္ပဏီမှာ ဘယ်လို Resource တွ ဘယ်လောက်အထိ ရှိထားတယ် ဆိုတဲ့ အချက်အလက် အစီရင်ခံစာ)
 User/customer က တင်ပြထားတဲ့ပြဿနာ နဲ  အဲဒီပြဿနာအတွက်  ဖစ်နိုင်ချေရှိတဲ့ ဖရှင်းနည်းတွေအပါအ၀င် အဆိုပြုထားတဲ့ ဖရှင်းချက်။ ဒါကို Analysis of Alternatives – AOA လို ခါ်ပါတယ်။ မိတ်ဆွေတို ကို လွယ်အောင်တည့်တည့် ပာရရင်တော့ ကိုယ် ရးမယ့် ဆာ့ဖ်၀ဲ နဲ ပတ်သက်တဲ့ အသေးစိပ် သုံးသပ်လေ့လာချက်တွေပေါ့ဗျာ။
 စနစ် (software + hardware + platform + communication) တည်ဆောက်မှုနဲ ဆိုင်တဲ့ အင်ဂျင်နီယာပညာရပ် (System Engineering + Software Engineering) ဆိုင်ရာအစီရင်ခံစာ ၊ အဲဒီစနစ်ကို စစ်ဆေးစမ်းသပ်ထားတဲ့ အချက်အလက်တွေနဲ  သူ ရဲ့ရလာဒ်၊ အဲဒါတွေအပေါ်မှာသုံးသပ်ချက် နဲ ၊ ဒီစနစ်ကို တည်ဆောက်တဲ့အခါ ပထမဦးဆုံး ဘာတွေ လုပ်ဆောင်ဖို လိုအပ်တယ်ဆိုတဲ့ ကနဦး အစီအစဉ် အစီရင်ခံစာ။
အဲဒါတွေ လ့လာသုံးသပ်ပြီးနောက်ပိုင်းမှာ estimator တွဟာ Cost Estimation Relationships – CERs ဆိုတာကို လုပ်ဆောင်ကြတယ်။ CERs ဆိုတာ အရင်ပြီးခဲ့တဲ့ စနစ်တွေ ပရောဂျက်တွေ ပရိုဂရမ်တွေ ဆာ့ဖ်၀ဲတွေတုန်းက ၊ ဘယ်လို နည်းပညာကိုသုံးခဲ့တယ်၊ ပရောဂျက်အရွယ်အစား ဘယ်လောက်ကြီးမားခဲ့တယ်၊ လူအင်အားဘယ်နှစ်ရောက်သုံးခဲ့တယ်၊ ဘယ်လောက်ကြာခဲ့တယ်၊ဘယ်လောက် ကုန်ကျခဲ့တယ်ဆိုတဲ့ အချက် အလက် တွ ကို ရနိုင်သလောက် စုဆောင်းပြီး အချင်းချင်း နှိုင်းယှဉ်လေ့လာတာကို ပာတာပါ။
အဲဒီလို နှိုင်းယှဉ်လေ့လာပြီးတဲ့နောက်မှာ estimator တွဟာ လက်ရှိပြဿနာနဲ  အကိုက်ညီဆုံး အနီးစပ်ဆုံး ပုံစံကို ရွးထုတ်ပြီး၊ လက်ရှိပြဿနာရဲ့ အရွယ်အစား၊ ကုန်ကျစရိတ် နဲ  အချိန်ဇယား ဆိုင်ရာ အဖြစ်နိုင်ဆုံးတန်ဘိုးတွေကို ခန် မှန်းသတ်မှတ်ပါတယ်။ ဒါကို ကျွမ်းကျင်သူရဲ့ အကဲဖြတ်ချက် (Expert Judgement) လို ခါ်ပါတယ်။ အဲဒီလိုပုံစံမျိုးနဲ  system ကြီးတစ်ခုလုံးရဲ့ အဓိကအစိပ်အပိုင်း(sub system / major module) တစ်ခုချင်းစီအတွက် ခွဲခြား ခန် မှန်းတွက်ချက် တာကို ‘Point Estimate’ လို  ခါ်လေ့ရှိပါတယ်။
Point Estimate လုပ်ပြီးတဲ့နောက် ခန် မှန်းတွက်ချက်သူတွေဟာ အနာဂတ်မှာ ကြုံတွေ ရနိုင်တဲ့ အပြောင်းအလဲတွေကို ကာမိအောင် သူတို ရဲ့ မူလ ခန် မှန်းတန်ဘိုးထဲကို နှုန်းထား ပမာဏ တစ်ခုပေါင်းထည့်ပါတယ်။ ဆိုပါစို  +/- 25 % (plus or minus 25 percent) ပါ့။ ဆိုလိုတာကဗျာ Point Estimate အရ ကုန်ကျစရိတ်ကို မူလက ဒါ်လာ ၁၀၀ မှန်းထားရင် အများဆုံးကုန်ကျစရိတ်အဖြစ် ၁၂၅ ဒါ်လာ၊ အနဲဆုံး ၇၅ ဒါ်လာဆိုပြီး range တစ်ခုသတ်မှတ် လိုက်တာပါ။
ဒီအဆင့်ဟာ ဆာ့ဖ်၀ဲရေးမယ့် ကုမ္ပဏီအတွက်တော့ အလွန်အရေးကြီးတဲ့အဆင့်ဖြစ်ပါတယ်။ ဘာလို လဲဆိုတော့ ဒီလို ခန် မှန်းတွက်ချက်ထားတာတွေကို၊ user (ဆော့ဖ်၀ဲရေးခိုင်းတဲ့ လူပုဂ္ဂိုလ် အဖွဲ အစည်း) ကို ပန် တင်ပြရတော့မှာကိုး။ user ဟာ Request For Proposal (RFP) ကို ဆာ့ဖ်၀ဲကုမ္ပဏီတွေ အများကြီးဆီကို တပြိုင်တည်း ပို ထားတာ၊ တာင်းထားတာ ဖစ်နိုင်ပါတယ်။ မှန်ပါတယ်။ ဘယ်သူကမှ တခြားတစ်နေရာမှာ မမေးမြန်း မစုံစမ်းပဲနဲ တာ့ ကိုယ်တောင်းသမျှဈေး အလွယ်ပေးမလဲဗျာ။ ကိုယ်တောင်းထားတာ ကိုယ်တွက်ထားတာ က သူများထက် သိသိသာသာ များနေရင် ပရောဂျက်ကို မရနိုင်တော့သလို၊ သိပ်နည်းနေပြန်ရင်လည်း user က ကိုယ့်အပေါ်ယုံကြည်မှုနည်းပြီး “သိပ်နည်းနေပါလား..မဟုတ်သေးပါဘူး။ အင်း..ဒီဈေးနဲ ဆိုရင်တော့ နာက်တော့မှ ပဿနာတက်လိမ့်မယ်ထင်တယ်။” လို အထင်ခံရပြီး လုပ်ငန်း လက်လွတ်ရနိုင်ပါတယ်။ “ပေါ ပီးတာပဲကွာ” ဆိုတာမျိုး စံနစ်တကျအလုပ်လုပ်တဲ့သူတွေမှာ မရှိပါဘူး။ ဒါကြောင့် ဒီအဆင့်ဟာ ဆာ့ဖ်၀ဲရေးမယ့် ကုမ္ပဏီအတွက် အမှန်တကယ် စိတ်မောရတဲ့ အချိန်ဖြစ်ပါတယ်။ ဒီအတွက်ကြောင့် စွန် စားမှုသိပ်မြင့်မားတဲ့ အလျော်အစားကြီးမားတဲ့ ဘတ်ဂျက်သိပ်များတဲ့ ပရောဂျက်အကြီးကြီးတွေအတွက် estimate လုပ်ပြီဆိုရင် Point Estimation အဆင့်ပြီးတဲ့အခါ ဆာ့ဖ်၀ဲရေးမယ့် ကုမ္ပဏီအနေနဲ ၊ သူတို တွက်ထားတဲ့ estimate ကို တခြားသီးခြားလွတ်လပ်တဲ့ ပညာရှင် အဖွဲ အစည်း တစ်ခုခုဆီကို ထပ်မံပြီး သုံးသပ်စစ်ဆေးပေးဖို  ပးပို ပါတယ်။ သူတို ရဲ့ မှတ်ချက်တွေ အကြံပြုချက်တွေအပေါ်မူတည်ပြီး estimate မှာ ပင်သင့် ပာင်းသင့်တာတွေကို ပင်ပြီးပြောင်းပြီးမှသာ user ဆီကို estimate ပို လ့ရှိပါတယ်။
တခါ user ဘက်ကလည်း ဘာတွေလုပ်ကြသလဲ လ့လာကြည့် ကြပါစို ။ ဥပမာ အမေရိကန်အစိုးရ ကာကွယ်ရေးဌာန ရဲ့ ပရောဂျက်တွေရေးတဲ့အခါ မှာဆိုရင် သက်ဆိုင်ရာ အဖွဲ အစည်းရဲ့ Cost Assessment & Performance Evaluation – CAPE ဌာနက၊ ဆာဖ့်၀ဲကုမ္ပဏီတွေ တင်ပြလာတဲ့ အဲဒီ Estimate တန်ဘိုးတွေကို နှိုင်းယှဉ်စစ်ဆေးပါတယ်။ ပီးရင် Milestone Decision Authority (MDA) က ထပ်မံပြီး သီးခြားလွတ်လပ်တဲ့ စစ်ဆေးမှုတွေလုပ်ပြီးမှ အကောင်းဆုံး estimate လုပ်ထားတဲ့ တစ်ခုကို ရွးချယ်ပြီး “ဒီကုမ္ပဏီဟာ နည်းပညာပိုင်း စတင်ပြီး အကောင်အထည်ဖေါ်လို ရတဲ့အဆင့် Technology Development Phase (TDP) ကို ရာက်ပြီ” လို  ဆုံးဖြတ်ပြီးမှ Acquisition Decision Memorandum (ADM) ကို ထုတ်ပေးပါတယ်။ အဲဒီတော့မှ software စ’ ရးပေါ့။
ဒါကြောင့် ဆာ့ဖ်၀ဲကုမ္ပဏီတွေ အနေနဲ  ပရောဂျက်ရဖို  ပိုင်ရာဆိုင်ရာနဲ  လက်၀ါးချင်းရိုက်ပြီး “လက်သင့်ရာ စားတော်ခေါ်” လို မရသလို ဆာ့ဖ်၀ဲရေးခိုင်းတဲ့ဌာနတွေ အနေနဲ လည်း ငါ့ဆွေမျိုး ငါ့ဆရာလူ ဆိုပြီး နီးစပ်ရာကို “မျက်နှာကြီးရာ ဟင်းဖတ်ပါ” လို မရပါဘူး။ ကိုယ်လုပ်မယ့်အလုပ်ကို တကယ်ကို တိကျသေချာ ကျွမ်းကျင် ပိုင်နိုင်မှ၊ ကိုယ့်ရဲ့ ဆုံးဖြတ်ချက် ရွးချယ်ချက်ဟာ အကျိုးအကြောင်း အချက်အလက် ခိုင်လုံမှ သာ ဆာ့ဖ်၀ဲပရောဂျက်ကြီးတွေ ပးပိုင်ခွင့် ရးနိုင်ခွင့် ရတာပါ။
အခုတခါ ဆက်လက်ပြီးတော့ ဒီ traditional software cost estimation လုပ်ငန်းစဉ်တွေမှာ estimator တွ ဖက်ကရော၊ user တွ ဖက်ကရော ဘယ်လို အခက်အခဲတွေ ရှိနေသလဲဆိုတာ နဲနဲ လ့လာကြည့်ကြပါစို ။ အခုဆွေးနွေးမယ့် အချက်တွေတင်တော့ မဟုတ်ဘူးပေါ့ဗျာ၊ ဒါပေမယ့် အများအားဖြင့်တော့
o Estimator တွ အနေနဲ  System/software/program ရဲ့ အသေးစိပ် လိုအပ်ချက်တွေကို မသိရသေးတဲ့အတွက် system ရဲ့ အရွယ်အစားနဲ  အချိုးအစားကို မှန်ကန်အောင် တွက်ချက်ဖို ခက်ခဲခြင်း။
o ဘယ်လို နည်းပညာကို သုံးပြီး အကောင်အထည်ဖေါ်ရမလဲဆိုတာကို estimate လုပ်တဲ့သူက သိချင်မှသိမှာ ဖစ်တဲ့အတွက်၊ အကောင်အထည်ဖေါ်ရမယ့် လုပ်ငန်းအဆင့် တွ နဲ ၊ ဒီစနစ်ကိုအောင်မြင်အောင် တခြားစနစ်တွေနဲ  ဘယ်လို ချိန်ညှိပြီး အပေးအယူလုပ်မှုတွေ လိုအပ်လာနိုင်မလဲ ဆိုတာကို သိနိုင်ဖို ခက်ခဲနိုင်ခြင်း။
o ဒါ့အပြင် program manager က ဒီ ဆာ့ဖ်၀ဲကို ဘယ်သူတွေ ပါ၀င်ရေးသားမယ်ဆိုတာ မသိနိုင်သေးတဲ့အတွက် ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်နိုင်စွမ်းကို ခန် မှန်းတွက်ချက်ဖို  ခက်ခဲခြင်း။ (မှတ်ချက်။ project manager မဟုတ်ပါ။ project manager က ဆာ့ဖ်၀ဲ developer တွကို စံနစ်တကျ စီမံခန် ခွဲပြီး ဆာဖ့်၀ဲတစ်ခု အာင်အောင်မြင်မြင် ရလာအောင် ဦးဆောင် တာ၀န်ယူရတဲ့သူဖြစ်ပြီး program manager ဆိုတာကတော့ ဘဏာ်ရေး တို  အုပ်ချုပ်ရေး တို  ၀န်ထမ်းရေးရာတို  ကို တာ၀န်ယူတဲ့ အထွေထွေမန်နေဂျာ (admin manager or general manager) ဆိုပါတော့။)
o ဒီစနစ်ကို အကောင်အထည်ဖေါ်ရာမှာ ဘယ်လိုကျွမ်းကျင်မှု အရည်အသွေးမျိုးတွေ လိုအပ်သလဲဆိုတာကို မသိနိုင်တဲ့အတွက်၊ ၀န်ထမ်းလေ့ကျင့်သင်ကြားပေးမှုအတွက် လိုအပ်ချက်တွေကို သတ်မှတ်ဖို ခက်ခဲခြင်း။
စတဲ့ မရေရာမှုတွေကို ရင်ဆိုင်ရနိုင်ပါတယ်။
အဲဒါကြောင့် SEI ရဲ့ Software Engineering Measurement & Analysis Initiative ဌာနက ဦးဆောင်ပြီး ဆာ့ဖ်၀ဲရေးသားရာမှာ အစောပိုင်းကာလ ခန် မှန်းတွက်ချက်မှုတွေကို ပိုမို တိကျသေချာစေဖို  ဘာတွေလိုအပ်သလဲဆိုတာကို လ့လာ သုတေသန လုပ်ကြည့်ပြီး အဆင့် ၆ ဆင့် ပါတဲ့ ချဉ်းကပ်ပုံနည်းစနစ်သစ်ကို တင်ပြခဲ့ပါတယ်။ အဲဒါတွေကတော့..
၁။ ကိုယ်ရေးသားမယ့် ဆာဖ့်၀ဲရဲ့ လမ်းကြောင်း အခြေအနေ အဖြေ စတဲ့ result တစ်ခုခု၊ output တစ်ခုခုကို ပာင်းလဲသွားစေနိုင်လောက်တဲ့၊ ပရိုဂရမ် (ကိုယ်လုပ်မယ့်အလုပ်) နဲ တိုက်ရိုက်သက်ဆိုင်တဲ့ စ့ဆော်ချက်တွေ တွန်းအားတွေ အချက်အလက်တွေ (drivers) ကို ဖါ်ထုတ်သတ်မှတ်ရပါမယ်။
၂။ ဒုတိယဆင့်အနေနဲ  အဲဒီ တွန်းအားတွေ အခြေအနေတွေ တစ်ခုနဲ တစ်ခု ပါင်းစပ်လိုက်ရင် ဘယ်လို အခြေအနေ သစ်မျိုး ထပ်ဖြစ်လာဦးမလဲ ဆိုတာ လ့လာဖေါ်ထုတ်ရပါမယ်။
၃။ အဲဒီနောက် အထက်မှာ ဖါ်ထုတ်ထားတဲ့ driver တွပါ၀င်တဲ့ ဖစ်နိုင်ခြေပုံစံ (probability model) တစ်ခု တည်ဆောက်ရပါမယ်။ (ဥပမာ Bayesian Belief Network – BBN လို ပုံစံမျိုး)
၄။ ပီးရင် ပုံမှန်သမားရိုးကျ estimation နည်းစနစ်တွေမှာအသုံးပြုမယ့် အချက် အလက် တွရဲ့ မသေချာမှု မတိကျမှု ကို ခန် မှန်းဖို  ခုနက တည်ဆောက်ထားတဲ့ ဖစ်နိုင်ခြေပုံစံ (e.g BBN) ကို အသုံးချရပါမယ်။
၅။ အဲဒီနောက် Monte Carlo Simulation နည်းစနစ်ကို အသုံးချပြီး အဆင့်-၄ မှာ ရှာဖွေထားတဲ့၊ မတိကျ မရေရာ တဲ့ အမျိုးမျိုးသော ဖစ်နိုင်ချေတန်ဘိုး တွကို အသုံးပြုပြီး  ဆာ့ဖ်၀ဲကုန်ကျစရိတ်ကို ခန် မှန်းတွက်ချက်ပါတယ်။
၆။ အဲဒီနောက် Monte Carlo Simulation နည်းစနစ်ကိုပဲအသုံးပြုပြီး အဆင့်-၅ မှာ ရရှိထားတဲ့ အထွေထွေ အမျိုးမျိုးသော ဖစ်နိုင်ခြေခန် မှန်းတန်ဘိုးတွေကို တစ်ခုတည်းသော နာက်ဆုံးဆင့် ခန် မှန်းတန်ဘိုးအဖြစ် ရရှိအောင် စုစည်းတွက်ချက်ယူပါတယ်။
အခုတင်ပြခဲ့တာတွေကတော့ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာသိပ္ပံ (SEI) ရဲ့ ပိုမိုတိကျသေချာတဲ့ software development cost estimation အတွက် ချဉ်းကပ်ပုံအသစ် နည်းစနစ်အသစ်တွေ ဖစ်ပါတယ်။ ဒီ အချက် ၆-ချက် ကို အသေးစိတ်မရှင်းလင်းမီမှာ မိတ်ဆွေတို အနေနဲ  မဖြစ်မနေ လ့လာထားသင့်တဲ့ အကြောင်းအရာတွေကတော့ ဘးစ် သီအိုရမ်(Bayes’ Theorem or Bayes’ Rule or Bayes’ Law)၊ သူနဲ ဆက်စပ်နေတဲ့ ဘးစ်၏ယုံကြည်မှုဆက်သွယ်ချက် (Bayesian Belief Network) နဲ မွန်တီကာလိုလက်တွေ ပုံဆောင်စမ်းသပ်ချက် (Monte Carlo Simulation) စတာတွေကိုပဲ ဖစ်ပါတယ်။ ဒါကြောင့် ဒီအကြောင်းအရာတွေကို မိတ်ဆွေတို ရဲ့ စာအုပ်စာတမ်းတွေထဲက ပန်လည်ရှာဖွေဖတ်ရှုထားလိုက်ပါဦး။ ကျွန်တော်အနေနဲ လည်း Bayes’ Theorem နဲ  Monte Carlo Simulation အကြောင်းတွေကို သီးသန် ဆာင်းပါးနဲ  ရးသားဆွေးနွေးပါမယ်။ ဒါတွေအပေါ်မှာ ကြလည်ထားမှသာ SEI ရဲ့ နည်းသစ်တွေအပေါ်မှာ ကြလည်မှာဖြစ်လို ပါ။ ရွှင်လန်းချမ်းမြေ့ပါစေ။

(InfoTherapy-2012)
၂၀၁၂ ခု နို၀င်ဘာလထုတ် ကွန်ပြူတာဂျာနယ်မှ ဆာင်းပါးကို ပန်လည်ဖေါ်ပြခြင်းဖြစ်ပါသည်။