Monday, November 12, 2012

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

ဆော့ဖ်၀ဲ ကုန်ကျစရိတ် ခန် မှန်းတွက်ချက်ခြင်း
ဘယ်ပရောဂျက်မှာမဆို ဖစ်တတ်တဲ့ ဘတ်ဂျက်မလုံလောက်မှု ပဿနာရဲ့ အဓိက အကြောင်းရင်းတွေထဲက တစ်ခုကတော့၊ အဲဒီပရောဂျက်ရဲ့ ကုန်ကျစရိတ် ကို ခန် မှန်းတွက်ချက်ရာမှာ အားနည်းခဲ့လို ဖစ်တဲ့အကြောင်း အမေရိကန်အစိုးရရဲ့ တာ၀န်ခံမှုဌာန 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)
၂၀၁၂ ခု နို၀င်ဘာလထုတ် ကွန်ပြူတာဂျာနယ်မှ ဆာင်းပါးကို ပန်လည်ဖေါ်ပြခြင်းဖြစ်ပါသည်။

ဆော့ဖ်၀ဲလုပ်ငန်းခွင်ဆိုင်ရာ ရာထူး ကဏ္ဍ နှင့် လုပ်ငန်းတာ၀န်များ

1. Computer Scientist
CS ။ ကွန်ပြူတာလောကမှာ တွ လိုက်သမျှ တကယ့်ပညာရှင် ကြီးတွေက ပာလိုက်ရင် သင်္ချာ၊ ရူပဗေဒ၊ သီအိုရီကွန်ပြူတာသိပ္ပံ ဆိုတာချည်းပဲ။ ကျွန်တော်လည်း Software လာကမှာ ကျင်လည်ခဲ့တာ နှစ်ပေါင်းမနည်းတော့ပါဘူး။ Junior programmer ဘ၀ကနေ Senior Software Architect ထိ တဆင့်ပြီးတဆင့် တက်ခဲ့တာပါ။ အဲဒီဂုရု ကြီးတွေ ပာပြောနေတဲ့ သင်္ချာတို ၊ ရူပဗေဒ ၊ သီအိုရီကွန်ပြူတာသိပ္ပံ တို  ဘာတို လည်း ဘာမှ အသုံးမချခဲ့ရပါလားဗျာ။ အဲဒါက ဘယ်လိုဖြစ်တာလဲ။
infoTherapy ။ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာပညာရပ်တို ၊ ကွန်ပြူတာသိပ္ပံပညာရပ်တို  နဲ ပတ်သက်ပြီး မိတ်ဆွေ ရဲ့ ကိုယ်ပိုင် သီအိုရီတွေ၊ ဥပဒေသတွေ၊ ပုံသေနည်းတွေ၊ ညီမျှခြင်းတွေ၊ အတွေးအခေါ် အယူအဆ အသစ်တွေ ဘာတွေ ဖါ်ထုတ် တင်ပြခဲ့ပြီးပြီလဲ။ မိတ်ဆွေ ရဲ ‘့မူပိုင်’ လို့ပြောနိုင်တဲ့၊ နိုင်ငံတကာအထိ ထိုးဖောက်အောင်မြင်နေတဲ့ software, hardware, netware, wetware စတာတွေ ဘာတွေတည်ထွင်ပြီးပြီလဲ။ ၀မ်းနည်းစရာအဖြေကတော့ ‘no, not yet’ ပါ့ဗျာ။ အကြောင်းကတော့ရှင်းပါတယ်။ ဘာလို  လဲဆိုတော့၊ မိတ်ဆွေတို  ကျွန်တော်တို ဟာ အဲဒီ သင်္ချာ၊ ရူပဗေဒ နဲ  ကွန်ပြူတာသိပ္ပံ ပညာရပ်တွေကို ပါင်းစည်းဆက်စပ်ပြီး အသုံးမချနိုင်သေးလို  ပဲဖြစ်တယ်ဗျ။ ဘာမှ သိပ်ရှုပ်ထွေးမှုမရှိတဲ့ န စဉ်သုံး အထွေထွေ အသုံးချဆော့ဖ်၀ဲတွေရေးဖို  လာက်အတွက်တော့ လိုအပ်ကောင်းမှ လိုအပ်မှာဖြစ်ပေမယ့်၊ ခုနက ကျွန်တော်တို  ဆွးနွေးတဲ့ ကိစ္စတွေအတွက်ကတော့ သင်္ချာတို ၊ ရူပဗေဒတို  ၊ သီအိုရီကွန်ပြူတာသိပ္ပံတို ဆိုတာ မသိမဖြစ် မရှိမဖြစ် ပါ့ဗျာ။
ဒီနေရာမှာ မိတ်ဆွေတို ကို၊ ကမ္ဘာ့ထိပ်တန်း အဖွဲ အစည်းတွေ နဲ  ပညာရှင်တွေက computer scientist ဆိုတာကို ဘယ်လို အဓိပ္ပါယ် ဖွင့်ဆိုသလဲဆိုတာ တင်ပြပါမယ်။
ဖွင့်ဆိုချက် ၁.၁။ ။ “ကွန်ပြူတာသိပ္ပံပညာရှင် ဆိုတာ (ကွန်ပြူတာနဲ  ပတ်သက်တဲ့) နည်းပညာအသစ်တွေကို ဒီဇိုင်းပြုသူ တည်ထွင်သူ ဖန်တီးသူဖြစ်တယ်။ သူတို ဟာ ရှုပ်ထွေးတဲ့ စီးပွားရေးဆိုင်ရာ သိပ္ပံပညာဆိုင်ရာ နဲ  အထွေထွေတွက်ချက်မှုဆိုင်ရာ ပဿနာတွေကို ဖရှင်းသူဖြစ်တယ်။”
၁.၁ - ရည်ညွှန်း။ အမေရိကန်ပြည်ထောင်စု၊ အလုပ်သမား၀န်ကြီးဌာန၊ စာရင်းအင်းအဖွဲ  ၏ ၂၀၁၀-၂၀၁၁ အလုပ်အကိုင်ဆိုင်ရာ လက်စွဲစာအုပ် (http://www.bls.gov/oco/ocos304.htm)
ဖွင့်ဆိုချက် ၁.၂။ ။ “ကွန်ပြူတာသိပ္ပံပညာရှင် ဆိုတာ ကွန်ပြူတာတွေနဲ  အဲဒီကွန်ပြူတာတွေရဲ့ လုပ်ဆောင်ပုံနဲ ပတ်သက်ပြီး၊ ဖွဲ စည်းတည်ဆောက်ပုံ အချင်းချင်း အပြန်အလှန်ဆက်သွယ်ဆောင်ရွက်ပုံ နဲ  သီအိုရီ အယူအဆ သဘောတရားရေးရာ တွကို လ့လာသူဖြစ်တယ်။”
၁.၂ - ရည်ညွှန်း။ ***အကြီးတန်း သတင်းအချက်အလက်နည်းပညာသိပ္ပံပညာရှင် ရှရီ လာရင့်စ် ဖလီဂျာ Shari Lawrence Pfleeger (BA (Math), MA (Math), MS (Planning), PhD (IT and Engineering), Doctor of Humane Letters) (၀ဲပုံ) နှင့်၊


ကနေဒါနိုင်ငံ၊ အွန်တေရီရယ်ပြည်နယ်၊ ၀ါတာလူးတက္ကသိုလ်၊ ကွန်ပြူတာသိပ္ပံပညာကျောင်း ပါမောက္ခ ဂျုန်း အမ် အက်တ်လီ
Joanne M. Atlee (Ph.D. and M.S. in Computer Science; B.S. in Computer Science and Physics) (ယာပုံ) တို  ပူးပေါင်းရေးသားသော ၊ Software Engineering: Theory and Practice 4th Edition, 2011, Chapter 1

2. Software Engineer
SE ။ ကျွန်တော် တို လို Senior Software Engineer တွအနေနဲ ကျတော့၊ Project တစ်ခုကို တခါတလေ တစ်ရောက်တည်းနဲ  ၁-လ လာက်အတွင်း အပြတ်ရေး ပး ရတယ်ဗျ။ ကိုယ်က Senior SE အဆင့် ဆိုတော့ လွယ်ပါတယ်ဗျာ။ သိတဲ့အတိုင်း Visual Studio 2010 သုံးတော့ မန်တယ်လေ။ နှစ်ပတ် သုံးပတ်ဆို ပီးပြီ။ သူဌေးရှေ  မှာတော့ တစ်လလောက်ထိ နဲနဲဆွဲ ရတာပေါ့ဗျာ။ ကိုယ်က Senior SE အဆင့်ဆိုတော့ ဒါတွေ ကျွမ်းနေပါပြီ။
infoTherapy ။ အကြိုလေ့လာသုံးသပ်မှု (Preliminary Analysis) နဲ  System Documentation တွ ဖစ်တဲ့၊ Business Requirement Specification, Sytem Requirement Specification, Detailed Design Specification, Testing Report, User Manual… စတာတွေ ပါ၀င်တဲ့၊ ဆာ့ဖ်၀ဲ လို  အဓိပ္ပါယ် သတ်မှတ်နိုင်မယ့် solution တစ်ခုလုံးကို၊ လူတစ်ရောက်တည်းက နှစ်ပတ်သုံးပတ်နဲ  အပြီးရေးနိုင်တယ်ဆိုတော့… ။
အလွန်ထူးချွန်ထင်ရှားတဲ့ ကမ္ဘာ့ထိပ်တန်း ပညာရှင်တွေ နဲ  အဖွဲ အစည်းတွေက “ဆော့ဖ်၀ဲအင်ဂျင်နီယာ” ဆိုတာကို ဘယ်လိုအဓိပ္ပါယ်သတ်မှတ် ထားသလဲဆိုတာ  လ့လာကြည့်ကြပါစို ။
ဖွင့်ဆိုချက် ၂.၁။ ။ “ဆော့ဖ်၀ဲအင်ဂျင်နီယာပညာရပ်ဆိုတာ ကွန်ပြူတာသိပ္ပံ ပညာရပ်ရဲ့ အစိပ်အပိုင်းတစ်ခုဖြစ်ပြီး၊ ဆာဖ့်၀ဲအင်ဂျင်နီယာတွေဟာ သူတို  customer တွလိုချင်တဲ့ software တွရရှိအောင် လုပ်ဖို  လိုအပ်တဲ့ ကရိယာတန်ဆာပလာ နည်းစနစ်.. စတာတွေကို ၊ ကွန်ပြူတာသိပ္ပံပညာရှင်တွေ ရဲ့ လ့လာတွေ ရှိမှူ ရလာဒ်တွေကို အသုံးချပြီး ဖန်တီးတည်ဆောက်ယူသူတွေဖြစ်တယ်။”
၂.၁ - ရည်ညွှန်း။ *** Software Engineering: Theory and Practice 4th Edition, 2011, Chapter 1
ဖွင့်ဆိုချက် ၂.၂။ ။“ဆော့ဖ်၀ဲအင်ဂျင်နီယာပညာရပ်ဆိုတာ ၊ ဆာ့ဖ်၀ဲကို အစောပိုင်းကာလ အဓိပ္ပါယ် တိတိကျကျ ဖါ်ပြ သတ်မှတ်တဲ့ အဆင့်ကစ၊ အဲဒီကနေ ရးသားပြီးစီးတဲ့ အဆင့် ၊ နာက်ပိုင်း သုံးစွဲနေစဉ် ကာလတလျောက်လုံး နဲ  အဲဒီဆော့ဖ်၀ဲကို ပင်ဆင် မွန်းမံ ချဲ ထွင် တဲ့ အဆင့်တွေအထိပါ၀င်တဲ့၊ ဆာ့ဖ်၀ဲ ရးသားထုတ်လုပ်မှူ ဖစ်စဉ်အားလုံးကို လ့လာတဲ့၊ အင်ဂျင်နီယာပိုင်းဆိုင်ရာ ဘာသာရပ်တစ်ခုဖြစ်တယ်။
ဒီ အဓိပ္ပါယ်သတ်မှတ်ချက်ရဲ့ အဓိက စကားလုံး နှစ်လုံးကို ထပ်ရှင်းရမယ်ဆိုရင်။
က။ အင်ဂျင်နီယာပိုင်းဆိုင်ရာ ဘာသာရပ်/ပညာရပ်
အင်ဂျင်နီယာဆိုတာက သီအိုရီသဘောတရားတွေ၊ နည်းနာနိဿယတွေ၊ လိုအပ်တဲ့ ကရိယာတန်ဆာပလာကို သင့်လျော်သလို အသုံးပြုပြီး၊ (တစုံတခုကို) အလုပ်လုပ်အောင် ဖစ်မြောက်အောင်မြင်အောင် လုပ်တဲ့သူတွေဖြစ်တယ်။ ဒါ့အပြင် အင်ဂျင်နီယာဆိုတာ သူတို  ပါ၀င် လုပ်ကိုင် ဆာင်ရွက် ပးနေတဲ့ အဖွဲ အစည်းက ချမှတ်ထားတဲ့ ကန် သန်  ချက် (အချိန်၊ ငွကြေး၊ နည်းပညာ၊ လူအင်အား၊ စည်းမျည်း စည်းကမ်း၊ စံ၊ အရည်အသွေး.. စတဲ့) ဘာင်အတွင်းကနေ၊ အာင်မြင်အောင် ဆာင်ရွက်ရမယ်ဆိုတာ၊ သိရှိနားလည်ထားသူတွေဖြစ်တယ်။
ခ။ ဆာ့ဖ်၀ဲ ရးသားထုတ်လုပ်မှူ ဖစ်စဉ်အားလုံး
ဆော့ဖ်၀ဲအင်ဂျင်နီယာ ဘာသာရပ် (ပညာရပ်) ဆိုတာ၊ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှူနဲ  ဆိုင်တဲ့ နည်းပညာပိုင်း နည်းစနစ်ပိုင်းတွေကို သာ လ့လာတာမဟုတ်ဘူး။ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှူ ဖစ်စဉ်မှာ ပါ၀င်သူတွေကို ဘယ်လို စီမံခန် ခွဲ အုပ်ချုပ်ရ မလဲဆိုတာတွေ အပါအ၀င်၊ ဆာ့ဖ်၀ဲရေးသားရာမှာ အထောက်အကူဖြစ်စေမယ့်၊ လိုအပ်တဲ့ ကရိယာတန်ဆာပလာတွေ၊ နည်းနာနိဿယတွေ၊ တွးခေါ်ယူဆချက်တွေကို ပါ လ့လာတဲ့ ပညာရပ်ဖြစ်တယ်။”
၂.၂ - ရည်ညွှန်း။ စကော့တလန်နိုင်ငံ၊ စိန် အင်ဒရူးတက္ကသိုလ်၊ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာပညာဌာန ၏ ပါမောက္ခ အီယန် ဆွမ်မာဗွီးလ် Ian Sommerville (ပုံ) ရးသားသော၊ Software Engineering (8th Ed.) Harlow, England: Pearson Education.pp.7. ISBN 0-321-31379-8

ဖွင့်ဆိုချက် ၂.၃။ ။ “ကွန်ပြူတာဆော့ဖ်၀ဲ အင်ဂျင်နီယာဆိုတာ ဆာ့ဖ်၀ဲကို ဒီဇိုင်းပြု တည်ဆောက်သူတွေ ဖစ်တယ်။ သူတို ဟာ ကွန်ပြူတာစနစ်တွေကို မာင်းနှင်လည်ပတ် အလုပ်လုပ်စေမယ့် အသုံးချ ဆာ့ဖ်၀ဲတွေကို၊ ဖန်တီး စမ်းသပ် စစ်ဆေး အကဲဖြတ် ဖို ၊ ကွန်ပြူတာသိပ္ပံပညာရဲ့ သီအိုရီ စည်းမျဉ်းစည်းကမ်းတွေ နဲ  သင်္ချာပညာဆိုင်ရာ သရုပ်ခွဲလေ့လာမှု တွကို အသုံးချကြသူတွေဖြစ်တယ်။”
“ဆော့ဖ်၀ဲအင်ဂျင်နီယာတွေဟာ ကွန်ပြူတာဂိမ်းတွေ၊ စီးပွားရေးလုပ်ငန်းသုံး ဆာ့ဖ်၀ဲတွေ၊ ကွန်ပြူတာကို မာင်းနှင်လည်ပတ်စေတဲ့ စနစ်တွေ၊ ကွန်ပြူတာ ကွန်ယက်ကို ထိန်းချုပ်တဲ့စနစ်တွေ၊ အမျိုးအစားမတူညီတဲ့ ကွန်ပြူတာဆိုင်ရာ ဆက်စပ်ပစ္စည်းတွေ အချင်းချင်း၊ အပြန်အလှန် ဆက်သွယ် ဆာင်ရွက် နိုင်စေဖို  လိုအပ်တဲ့ ကြားခံဆော့ဖ်၀ဲတွေ…စတဲ့ အထွေထွေ အမျိုးမျိုးသော ဆာ့ဖ်၀ဲတွေကို ဒီဇိုင်းပြု  ရးသားတည်ဆောက်သူတွေဖြစ်တယ်။ ဒီအတွက် သူတို ဟာ ဆာ့ဖ်၀ဲတစ်ခု စနစ်တကျ ပုံမှန်အလုပ်နိုင်ဖို အတွက် လိုအပ်တဲ့၊ တွက်ချက်မှုစနစ်ဆိုင်ရာ သီအိုရီ၊ ဆာ့ဖ်၀ဲရဲ့ ဖွဲ စည်းတည်ဆောက်ပုံ၊ ဆာ့ဖ်၀ဲကို သုံးမယ့် စက် (hardware / platform) ရဲ့ သဘောသဘာ၀နဲ  အကန်  အသတ် စတာတွေကို အထူးကျွမ်းကျင် နားလည်ထားရမှာဖြစ်တယ်။”
၂.၃ - ရည်ညွှန်း။ အမေရိကန်ပြည်ထောင်စု၊ အလုပ်သမား၀န်ကြီးဌာန၊ စာရင်းအင်းအဖွဲ  ၏ ၂၀၁၀-၂၀၁၁ အလုပ်အကိုင်ဆိုင်ရာ လက်စွဲစာအုပ် (http://www.bls.gov/oco/ocos303.htm)

3. System Analyst
SA ။ ကျမ ကတော့ SA လုပ်နေတယ်။ ရှင်တို သိတယ်မို လား ကိုယ်ကလည်း SA လိုင်းပဲ ကျွမ်း တာလေ။ ဟိုတုန်းတည်းက SA ပဲ စိတ်၀င်စားခဲ့တာကိုး။ ကိုယ်က..SA သမားဆိုတော့..။ SA က နဲနဲတော့ ခါင်းစားတာပေါ့…။ SA Bla.. SA ဘာညာ SA ..။
nfoTherapy ။ နပါဦး SA ဆိုတာ System Architect ကိုပြောတာလား။ Software Architect ကိုပြောတာလား။ Solution Architect လား။ System Analyst လား ။ System Administrator လား ဘာကိုရည် ညွှန်းတာလဲဗျ။
SE ။ ရှင်ပြောတာတွေက SA လို  ခါ် မခေါ် တာ့ ကျမ မသိဘူး။ ကျမက System Analyst ကိုပြောတာပါ။ ကျန်တာတွေလည်း စိတ်မ၀င်စားပါဘူး။ ရှင်တို  သိတဲ့အတိုင်း ကျမကတော့ ever SA ပဲ။
infoTherapy ။ ဟုတ်ပါတယ်ဗျာ။ ဒါနဲ  ဘယ်လို System တွ ကို Analysis လုပ်ရလဲ။ ငွကြေးစနစ်လား။ သယ်ယူပို  ဆာင်ရေးစနစ်လား။ ပညာရေးစနစ်လား။ ဒါမှ မဟုတ် အသက်ရှူလမ်းကြောင်းစနစ် တို ၊ အစာခြေအဖွဲ အစည်းစနစ် တို  ဘာတို လား။ အဆင့်မြင့်  ရဒါစနစ် တို ၊ ပဲ့ထိန်းဒုံးစနစ် တို  အာကာသယာဉ် ထိန်းချုပ်ရေးစနစ် တို  ဘာတို လား။
SA ။ အစုံပါပဲ။ Point of Sales System (လက်လီရောင်းစနစ်) တွကတော့ အများစုပေါ့။ တခါတစ်လေ Education System (ပညာရေးစနစ်) လး ဘာလေး လည်း ကိုင်ရပါတယ်။ ‘ဟို’ ကျာင်းရဲ့ Web site က ကျမတို  J2EE နဲ  ရးထားတာလေ။ သိတယ်ဟုတ်။
infoTherapy ။ J2EE နဲ ပဲဖြစ်ဖြစ် K3FF နဲ  ပဲဖြစ်ဖြစ်၊ ကျာင်းတကျောင်းရဲ့ ကြာ်ငြာဆန်ဆန် web site တစ်ခုရေးတာကို Education System (ပညာရေးစနစ်) ကို Analysis လုပ်တယ်လို  ပာလို မရပါဘူး။ တကယ်တော့ အဲဒီကျောင်းရဲ့ Registration, Administration, Advertisement စတာတွေ ဘယ်လို လုပ်ကိုင်ဆောင်ရွက်နေသလဲ ဆိုတာကို Analysis လုပ်တာသာ ဖစ်ပါတယ်။
အလားတူပဲ ဘဏ်တစ်ခုအတွက် web site ၊ software တစ်ခုရေးပေးတာဟာ Finicial System (ငွေကြေးဆိုင်ရာစနစ်) ကို analysis လုပ်တာ မဟုတ်ဘူး။ အဲဒီ ဘဏ် ဘယ်လို ဘယ်ပုံ လည်ပတ်လုပ်ကိုင်နေသလဲ ဆိုတာကို (လိုအပ်မယ့် ဆာ့ဖ်၀ဲတွေ၊ web site တွ ရးပေးနိုင်ဖို  အတွက်) အသေးစိပ် လ့လာတာ (analysis လုပ်) တာသာဖြစ်ပါတယ်။ ပီးတော့လည်း ဘဏ် A အတွက် ဆာ့ဖ်၀ဲ ရးပေးဖူးလို ၊ ဘဏ် B အတွက်လည်း ဒီလိုပဲ ဖစ်ရမယ်လို  ပာလို  မရပါဘူး။ တဘဏ်နဲ တဘဏ် အခြေခံ အချက်တွေ တူနိုင်ပေမယ့် တခြား အသေးစိပ် အချက်တွေဟာ သူ လိုအပ်ချက်နဲ  သူ ကွဲပြားမှာ အသေအချာပါ။
သို ပမယ့် ဘဏ်ပေါင်းများစွာ ၊ငွေကြေးဆိုင်ရာ အဖွဲ  အစည်းပေါင်းများစွာအတွက် ဆာ့ဖ်၀ဲတွေ၊ web site တွရေးပေးနိုင်ဖို အတွက်၊ အသေးစိပ် လ့လာရင်းက၊ တွဲဖက်ကောင်းကျိုးအနေနဲ ၊ ငွကြေးဆိုင်ရာစနစ် (Finicial System) အကြောင်းကို တဖြည်းဖြည်း အသေးစိပ် ကျွမ်း၀င်နားလည် လာနိုင်ပါတယ်။ (ကိုယ်ကလည်း နက်နက် နဲနဲ စိတ်၀င်စားရင်ပေါ့။) အဲဒီလို အဆင့်မျိုးရောက်လာမှသာ System Analyst လို  သတ်မှတ်သင့်ပါတယ်။ တခြားစနစ်တွေအတွက်လည်း ဒီသဘောတရားအတိုင်းပဲ အလားတူ မှတ်ယူနိုင်ပါတယ်။ ဒီ SA နဲ ပတ်သက်လို  မိတ်ဆွေတို ကို အကိုးအကားတချို  တင်ပြလိုပါတယ်။
ဖွင့်ဆိုချက် ၃.၁။ ။customer တွရဲ့ စီးပွားရေးဆိုင်ရာ ဒါမှမဟုတ် အခြားလိုအပ်ချက်တွေကို ဖည့်ဆည်းပေးဖို ၊ (customer တွရဲ့) ပဿနာ နဲ  လိုအပ်ချက်ကို အသေးစိပ်လေ့လာ၊ ဖရှင်းလို  ရမယ့်နည်းလမ်းကိုအစီအစဉ်ချ၊ ပီးရင် လိုအပ်မယ့် software နဲ  hardware စနစ် တွကို ထာက်ခံတင်ပြ ပီး နာက်ဆုံး ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှုဖြစ်စဉ်မှာပါ ပူးပေါင်းပါ၀င်ဆောင်ရွက်သူဟာ system analyst ဖစ်တယ်။
System Analyst တွဟာ ပရိုဂရမ်ဘာသာစကားအမျိုးမျိုး၊ OS(ကွန်ပြူတာကို မာင်းနှင်လည်ပတ်စေတဲ့ ဆာ့ဖ်၀ဲစနစ်) အမျိုးမျိုး နဲ  hardware platform အမျိုးမျိုး တို ကို ကျွမ်း၀င်မှု ရှိသူတွေဖြစ်တယ်။ ဘာလို  ဒါတွေကို ကျွမ်း၀င်မှုရှိဖို  လိုအပ်တာလဲဆိုတော့၊ သူတို (SA) ဟာ၊ ဆာ့ဖ်၀ဲရေးသားခိုင်းတဲ့သူ (customer) တွ နဲ  သတင်းအချက်အလက်နည်းပညာ ဆိုင်ရာ ပညာသယ်တွေကြားမှာ၊ ဆက်သွယ်ပေါင်းကူးပေးရတဲ့အလုပ်မျိုးဖြစ်တဲ့၊ customer ရဲ့ တာင်းဆိုချက်တွေကို နည်းပညာပိုင်းဆိုင်ရာ အချက်အလက်တွေဖြစ်အောင် ပာင်းလဲရေးသားပေးရလေ ရှိလို  ပဲဖြစ်တယ်။
- ဒါ့အပြင် System Aanlyst ဟာ၊ ကုန်ကျစရိတ်နဲ  အကျိုးကျေးဇူး ကာမိမှုရှိ မရှိ လ့လာတာ၊ ဒီဇိုင်းပုံစံ (software + hardware + platform) စဉ်းစားတာ တွအပြင်၊ ပုံဖေါ်တည်ဆောက်မှုဆိုင်ရာ အချိန်ဇယားတွေကို ပါ တာ၀န်ယူရလေ့ရှိတယ်။
- System Analyst ဆိုတာ၊ သူတို ပါ၀င် လုပ်ကိုင်တဲ့ အဖွဲ အစည်း ရဲ့ အမျိုးအစားပေါ်မူတည်ပြီး၊ သက်ဆိုင်ရာ အထူးပြု သီးသန် ကွန်ပြူတာစနစ်မျိုးတွေနဲ  လုပ်ကိုင်လေ့ရှိသူတယ်။ ဥပမာ ပာရရင် စီးပွားရေးလုပ်ငန်းစနစ်၊ စာရင်းဇယား နဲ  စာရင်းအင်းစစ်ဆေးမှုလုပ်ငန်းစနစ်၊ ငွကြေးဆိုင်ရာစနစ်၊ သိပ္ပံပညာရပ် နဲ  အင်ဂျင်နီယာပညာရပ်ဆိုင်ရာ စနစ်..စတာတွေဖြစ်တယ်။
- အဖွဲ အစည်းတစ်ခုအတွက် သင့်တော်ကောင်းမွန်တဲ့ စနစ် (software, hardware နဲ  platform စတာတွေ) ကို ရွးချယ်ပေးဖို  အထူးကျွမ်းကျင်တဲ့ analyst ကိုတော့၊ “System Architect” သို မဟုတ် “System Desinger” လို ခါ်လေ့ရှိတယ်။
- စနစ်တစ်ခုကို တည်ဆောက် ပီး အဲဒီစနစ်ကို (ကောင်းမွန်ပြည့်စုံအောင်) ချိန်ညှိ ပးတဲ့ အလုပ်မျိုးမှာ၊ အထူးပြုလေ့လာထားတဲ့ ကျွမ်းကျင်တဲ့ Analyst မျိုးကို၊ ယဘုယျ ခုံငုံပြီး system analyst လို  ခါ်နိုင်တယ်။
၂.၃ - ရည်ညွှန်း။
က။ အမေရိကန်ပြည်ထောင်စု၊ အလုပ်သမား၀န်ကြီးဌာန၊ စာရင်းအင်းအဖွဲ  ၏ ၂၀၁၀-၂၀၁၁ အလုပ်အကိုင်ဆိုင်ရာ လက်စွဲစာအုပ် (http://www.bls.gov/oco/ocos287.htm)
ခ။ http://en.wikipedia.org/wiki/Systems_analyst

4. Business Analyst
ဖွင့်ဆိုချက် ၄.၁။ ။ စီးပွားရေး လုပ်ငန်းမှာ ပိုမိုတိုးတက်ကောင်းမွန်အောင် အပြောင်းအလဲတွေလုပ်ဖို ၊ လိုအပ်ချက်တွေ မူ၀ါဒလမ်းစဉ်တွေ နဲ  သတင်းအချက်အလက်ဆိုင်ရာ စနစ် တွကိုု ခွဲခြမ်းစိတ်ဖြာလေ့လာစိစစ်ပြီး၊ ကုမ္ပဏီရဲ့ ရှယ်ရာရှင်တွေ ငွကြေးစိုက်ထုတ်ရင်းနှီးသူတွေ အချင်းချင်းကြားမှာ အဖြေတစ်ခုထွက်အောင် ရလာဒ်တစ်ခုရအောင်၊ ဆက်သွယ်ပေါင်းကူး ဆာင်ရွက်ပေးသူကို BA လို ခါ်တယ်။
BA ဆိုတာ စီးပွားရေးဆိုင်ရာ ပဿနာတွေကို သဘောပေါက်နားလည်ထားပြီး၊ လိုအပ်ချက်အကြောင်းရင်း ကြာင့် ဖစ်ပေါ်လာမယ့် အခွင့်အလမ်းတွေ နဲ ၊ အဖွဲ  အစည်းရဲ့ ရည်မှန်းချက် ပါက်မြောက်အောင်မြင်နိုင်ဖို  ပဿနာဖြေရှင်းပုံ နည်းစနစ်တွေကို ထာက်ခံတင်ပြပေးသူဖြစ်တယ်။
ရည်ညွှန်း။ Body of Knowledge V1.6. Accessed January 10, 2007, International Institute of Business Analysis, Toronto, Ontario, Canada http://www.theiiba.org/

5. Team Leader
အေ။ ကျွန်တော်လို master တစ်ရောက်အနေနဲ ၊ ပရိုဂရမ်မာ အဆင့်နဲ တာ့ အလုပ် ‘စ’ မ၀င်ချင်ဘူး။ သူတို  offer လုပ်တာ အရမ်း နိမ့်တယ်။
နုပ်။ ဘာ နိမ့် တာတုန်း။ လစာကိုပြောတာလား၊ ရာထူးလား။
အေ။ လစာကိုတော့ ဂရုမစိုက်ပါဘူးဗျာ။ ဒါပေမယ့် ကျွန်တော်က Master ပီး ပီးသားဆိုတော့ ကျွန်တော့အဆင့်နဲ  ဆို အနည်းဆုံး Team Leader လာက်တော့ ပးသင့်တာပေါ့။ ပီးတော့ ကျွန်တော်က ပရိုဂရမ်ရေးတာကို သိပ် စိတ်မ၀င်စားဘူး။
နုပ်။ team leader ဆိုတာ ဘယ်လို team ကို ပာတာလဲ။ analyzing team လား။ design လုပ်တဲ့ team လား။ development (implementation လုပ်တဲ့ / programming ရးတဲ့) team လား။ database administration team လား။ source (code) control team လား။ testing team (system quality assurance team) လား။ deployment team လား။ customer support team လား။ မိတ်ဆွေကရော ဘယ်လိုင်းမှာ အားသန်တုန်း ကျွမ်းကျင်တုန်း။
အေ။ ခင်ဗျားပြောတဲ့ အဲဒီ team အသေးလေးတွေ ကျွန်တော်မသိဘူး။ ကျွန်တော်ပြောတာက software development team ကို ဆိုလိုတာ။ ကျွမ်းကျင်မှုနဲ  ပတ်သက်လို ကတော့ ကျွန်တော်က Computer Science နဲ  Master ပီးထားတာတဲ့သူ ဆိုတော့ အားလုံး ကျွမ်းတယ်ဗျ။
နုပ်။ ကျွန်တော် ခုနကပြောခဲ့တာတွေက မိတ်ဆွေပြောသလို team အသေးလေးတွေ မဟုတ်ပါဘူး။ နိုင်ငံစုံကော်ပိုရေးရှင်း (multi-national corporation) အဆင့် ကုမ္ပဏီကြီးတွေမှာဆို၊ Enterprise Application တွ၊ Distributed Application တွ ၊ Operating System တွ၊ တစ်ကမ္ဘာလုံးသုံးနေတဲ့ နာမည်ကြီး ဆာ့ဖ်၀ဲမျိုးတွေ ရးသားတဲ့အခါ၊ ကျွန်တော်ပြောသလို team တွ သပ်သပ်ခွဲထားရတယ်။ တတယ်တော့ software development team ဆို ခုနက team တွ အားလုံးပေါင်းစု ပါ၀င်တဲ့၊ တကယ့် အဓိက အဖွဲ အစည်းကြီးကို ရည်ညွှန်းတာပါ။
ဒါ့အပြင် Multi-National Corporation ကြီးတွေရဲ့ Software Development Team ဆိုတာကို လူတစ်ယောက်ထဲက ဦးဆောင်တယ်ဆိုတာမျိုးဟာ အလွန်  အလွန် ရှားတယ်။ chief technical officer, project manager အပါအ၀င် အကြီးတန်းအဆင့် architect တွ, engineer တွနဲ  analyst တွ အားလုံး ပူးပေါင်းပြီး team leaders တွ အဖြစ် ဦးဆောင်ကြတာဖြစ်တယ်။ ဘာလို လဲဆိုတော့ လူတစ်ချို  ဟာ တာ်တော်များများကို အကြမ်းဖျဉ်းသိနေနိုင်ပေမယ့် အားလုံးကို ချချေမြစ်မြစ် ကျွမ်းကျင်ဖို  ဆိုတာတော့ ဘယ်သူမှ မဖြစ်နိုင်ဘူး။ ဒါကြောင့် ဆာ့ဖ်၀ဲရေးသားရာမှာ ပါ၀င်တဲ့ developer တွရဲ့ အထူးပြု ကျွမ်းကျင်မှု အရည်အချင်း နဲ  အတွေ အကြုံ အလိုက် သူ ကဏ္ဌ နဲ သူ ဦးဆောင်ပြီး တာ၀န်ယူနိုင် တာ၀န်ခံနိုင်တဲ့ ပုဂ္ဂိုလ်မျိုးကို သက်ဆိုင်ရာ team ရဲ့ team leader အဖြစ် တာ၀န်ပေးလေ့ရှိတယ်။
လူဆယ်ရောက် ဆယ့်ငါးရောက်လောက်နဲ  လည်ပတ်နေတဲ့ ကုမ္ပဏီ အသေးစားလေးတွေမှာဆိုရင်တော့၊ အဲဒီလို ကဏ္ဍအလိုက် အဖွဲ ခွဲတွေ ရှိချင်မှရှိမယ်။ သူတို မှာတော့ ယဘုယျ software development team ပါ့။ အဲဒီလို ကုမ္ပဏီမှာ team leader အဖြစ်တာ၀န်ယူမယ့်သူဟာ၊ အခန်းကဏ္ဍ အနည်းဆုံး လး ငါး ခု တာ၀န်ယူရတယ် တာ၀န်ခံရတယ်။ ဆိုလိုတာက team leader ဟာ Analysis ထဲမှာလည်း ပါရတယ်။ Design ပိုင်းမှာလည်း လက်စွမ်းပြရတယ်။ Implementation / Programming ဆိုလည်း ၀င်ရေးလိုက်ရတာပဲ။ Testing / Defect fixing မှာလည်းပါ၊ Documentation ဆိုတာမှာလည်း သူမလွတ်..ဆိုတဲ့ ပုံစံမျိုးနဲ  software development process ရဲ့ အဆင့်တိုင်း ကဏ္ဍတိုင်းမှာ ပါ၀င်ရတယ်။
ဒါကြောင့် ကုမ္ပဏီ အကြီးမှာဖြစ်ဖြစ် အသေးမှာဖြစ်ဖြစ် team leader အဖြစ် တာ၀န်ယူမယ့် ပုဂ္ဂိုလ်ဟာ၊ ပညာရေး ခိုင်ခိုင်မာမာ ရှိထားရမယ့်အပြင် ကျွမ်းကျင်မှု နဲ  လက်တွေ  လုပ်ငန်းခွင်အတွေ  အကြုံတွေလည်း အများကြီးလိုတယ်။ ဒါကြောင့် မိတ်ဆွေ ဟာ လုပ်ငန်းခွင်အတွေ အကြုံမရှိသေးဘူးဆိုရင်တော့ ပရိုဂရမ်မာအဆင့်နဲ  အလုပ်စ၀င်မယ်ဆိုလည်း မမှားနိုင်ဘူးလို  ထင်ပါတယ်။

6. Developer
ဘီ။ Developer ဘ၀က တက်လမ်းမရှိဘူးဗျ။ အများဆုံးဖြစ်ရင် Senior Developer ပဲ။ ကျွန်တော်က Project Manager ဖစ်ချင်တာ။ PM ဆိုရင် လစာ အရမ်းကောင်းတယ်လေ။
နုပ်။ ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှုဖြစ်စဉ် Software Development Process(SDP) အဆင့်ဆင့်မှာ ပါ၀င်တဲ့သူတွေအားလုံးကို ယဘုယျ ခုံ ငုံပြီး Developer လို  ခါ်တာပါ။ software developer, web developer, application developer စတဲ့ စကားလုံးတွေဟာ၊ SDP မှာ ကိုယ်ဘာလုပ်တယ် ဘယ်နေရာမှာ အဓိကတာ၀န်ယူထားတယ် ဆိုတဲ့ တိကျရှင်းလင်းတဲ့ အခန်းကဏ္ဍ ကို မရည်ညွှန်းနိုင်ဘူး။
ဒီနေရာမှာ ခက်နေတာက တခါတလေမှာ ကုမ္ပဏီတွေ ကိုယ်တိုင်က လူတစ်ရောက်ကို အလုပ်ခန် တဲ့ အခါ၊ ရာထူး (post/position) ၊ အခန်းကဏ္ဍ (role) နဲ  လုပ်ငန်းတာ၀န် (duty and responsibility) တို နဲ ပတ်သက်ပြီး၊ ကွဲကွဲပြားပြား ရှင်းရှင်းလင်းလင်း မရှိတာပဲ။ software engineer တို  ၊ system analyst တို ဆိုတဲ့ ရာထူး တွနဲ  အလုပ် လုပ်နေပြီး programming သက်သက်ပဲရေးနေရတဲ့ သူတွေရှိသလို၊ Programmer ဆိုတဲ့ ရာထူးနဲ  တင် ကိုယ့် database ကိုဆောက်၊ ကိုယ့်ဒီဇိုင်းကိုယ်ဆွဲ၊ ကိုယ့်ဟာကို program ရး၊ ကိုယ် ဘာသာကိုယ် testing လုပ်နေရတဲ့ သူတွေလည်းရှိတာပဲ။ ဒါတွေဟာ တကယ်တော့ ကိုယ်အလုပ်၀င်တဲ့ company, corporation, organization တွရဲ့ အမျိုးအစားနဲ  IT ဆိုင်ရာ မူ၀ါဒ စည်းမျဉ်းစည်းကမ်း အဓိပ္ပါယ်သတ်မှတ်ချက် တွပေါ်မှာ မူတည်နေတယ်။ ဒါကြောင့် မိတ်ဆွေကို Developer ရာထူးပေးပြီး ခန် ထားတဲ့ ကုမ္ပဏီဟာ ဘယ်လို ကုမ္ပဏီအမျိုးအစားလဲ ဆိုတာ အရင် ဆုံးဆန်းစစ်ကြည့်သင့်ပါတယ်။ Developer ရာထူးမို လို  senior developer ပဲဖြစ်လာမယ်ဆိုတာ လုံး၀ မဟုတ်ပါဘူး။
ကိုယ့်မှာ ပညာရေးခိုင်ခိုင်မာမာ အခြေခံရှိထားရင်၊ Software Project ပါင်းစုံ Software System ပါင်းစုံ လုပ်ဖူးပြီး အတွေ  အကြုံများလာရင် ၊ တဖြည်းဖြည်းနဲ  ကိုယ်လိုချင်တဲ့ ROLE ကို တဆင့်ချင်း ပာင်းသွားရင်ရပါတယ်။ ဥပမာ..
-Analysis တို design တို မှာ အားသန်ရင် System Analyst
-user requirement တွကို နက်နက်နဲနဲ စူးစမ်းလေ့လာတာ အားသန်ရင်၊ ကိုယ့်မှာ တခြား စီးပွားရေးနယ်ပယ်ရဲ့ knowledge တွရှိထားရင် Business/Requirement Analyst
-programming နဲ  ဆိုင်တဲ့၊ software development နဲ ဆိုင်တဲ့ အထွေထွေ သီအိုရီ သဘောတရား၊ လက်တွေ ဆာင်ရွက်ပုံ စတဲ့ အင်ဂျင်နီယာပညာရပ်ဆိုင်ရာ တွမှာ အားသန်ရင် software engineer
-လူ အချိန် ငွ စတာတွေကို စီမံခန် ခွဲအုပ်ချုပ်ရတာမျိုး၊ public relation ကိစ္စရပ်တွေမှာ စိတ်ထားထက်သန်တာမျိုး၊ ဦးဆောင် နိုင်တဲ့ တာ၀န်ယူနိုင်တဲ့ အရည်အချင်းမျိုး..စတာတွေရှိထားရင် team leader, project manager
စတဲ့ လိုင်း(field) ရာထူး(post) ကဏ္ဍ(role) တွကို တဆင့်ခြင်း ပာင်းသွားလို  ရပါတယ်။ ဒါကြောင့် ကိုယ်တကယ် ၀ါသနာပါတဲ့လိုင်း၊ ကျွမ်းကျင်တဲ့လိုင်း ကို ရရှည်အတွက် ရွးချယ်ပါ။ လစာ တစ်ခုတည်းကို ဦးတည်ပြီး မရွေးချယ်သင့်ပါဘူး။
နောက်နောင် ကြုံကြိုက်တဲ့အခါမှာ software architect တို  system architect တို  အကြောင်း ဆက်လက်ဆွေးနွေးပါဦးမယ်။
ရွှင်လန်းချမ်းမြေ့ပါစေ။


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