ဆော့ဖ်ဝဲ၏ ဆင့်ကဲဖြစ်စဉ်များ

မိတ်ဆက်
ကျွန်တော်တို ဟာ “ဆင့်ကဲဖြစ်စဉ်” လို ကြားလိုက်တာနဲ  “လူသည် မျာက်က ဆင်းသက်၏” ဆိုတဲ့ စကားကို ပးသတိရမိလေ့ရှိပါတယ်။ အဲဒီစကားဟာ ဗိတိသျှ သဘာ၀တ္ထပညာရှင်ကြီး (Naturalist - အပင်နဲ  တိရိစၦာန် တွကို လ့လာသူ) ချားလ်စ် ဒါ၀င် (Charles Robert Darwin, 12 February 1809 – 19 April 1882) ရဲ့ ဆင့်ကဲဖြစ်စဉ်သီအိုရီ (Evolutionary Theory) ကို မပြည့်မစုံ ကာက်ချက်ချထားတဲ့ စကားတခွန်းဖြစ်ပါတယ်။ “အကြမ်းထည်အဆင့် ရုပ်လက္ခဏာသွင်ပြင်နဲ  မပြည့်စုံသေးတဲ့ အသိဉာဏ်အဆင့်အတန်းသာရှိတဲ့ မျာက်တွေအဖြစ်က၊ ဒီကနေ မှာ မင်တွေ နရတဲ့ သွင်ပြင်လက္ခဏာ အသိဉာဏ်အဆင့်အတန်းမျိုးရှိတဲ့ လူတွေအဖြစ်မျိုးကို အချိန်ကာလနဲ အမျှ တဖြည်းဖြည်း တဆင့်ပြီးတဆင့် တိုးတက်ပြောင်းလဲလာကြတယ်” လို  ဆိုလိုတာဖြစ်ပါတယ်။ အဲဒီ သီအိုရီကတော့ ဒီဆောင်းပါးရဲ့ နယ်နမိတ်အပြင်ဖက်က အကြောင်းအရာပါ။ ဒါပေမယ့်လည်း ခု ကျွန်တော်တို ဆွးနွေးမယ့် ဆာ့ဖ်၀ဲဆင့်ကဲဖြစ်စဉ် (software evolution) နဲ  ပတ်သက်ပြီး evolution ဆိုတဲ့ ၀ါဟာရသုံးစွဲမှုအကြောင်းကို မိတ်ဆွေတို အနေနဲ  နှိုင်းယှဉ် ဆင်ခြင် သုံးသပ် နိုင်အောင်တင်ပြတာပါ။ ဘာလို လဲဆိုတော့ “ဆော့ဖ်၀ဲဆိုတာဟာလည်း အမှားများတဲ့အခြေအနေ သုံးစွဲသူ သိပ်စိတ်တိုင်းမကျသေးတဲ့ အခြေအနေမျိုးကနေ၊ ပိုမိုပြည့်စုံကောင်းမွန်လာတဲ့ အမှားအယွင်းနည်းလာတဲ့ သုံးစွဲသူတွေ ပိုပြီးကျေနပ်နှစ်သက်မှုရှိလာတဲ့ အခြေအနေ အဆင့်အတန်းမျိုးကို တဖြည်းဖြည်း တိုးတက်ပြောင်းလဲလာတတ်တဲ့ သဘောသဘာ၀ ရှိလို ပါပဲ”။ အဲဒီလို တိုးတက်ပြောင်းလဲမှုဟာ သူ အလိုလို ဖစ်လာတာတော့မဟုတ်ဘူးပေါ့။ လက်တွေ လာကရဲ့ လိုအပ်ချက်တွေပြောင်းလာလို ၊ သုံးစွဲသူတွေက တစုံတခု ပာင်းလဲချင်လို ၊ ဆာ့ဖ်၀ဲ ကိုယ်တိုင်မှာက အမှားအယွင်းအားနည်းချက်တချို  ရှိနေလို  စတဲ့အကြောင်းကြောင်းတွေကြောင့် ဆာ့ဖ်၀ဲရေးသားထုတ်လုပ်မှု လုပ်ငန်းစဉ် (software development process) ရဲ့ အဆင့်တဆင့်ဖြစ်တဲ့ maintenance အဆင့်မှာ၊ ဆာ့ဖ်၀ဲကို ပင်ဆင်ရင်း ချဲ့ထွင်ရင်း မွန်းမံရင်းနဲ ပဲ ဆာ့ဖ်၀ဲဆင့်ကဲဖြစ်စဉ် အစပြုလာတယ်ဆိုပါတော့။ တကယ်တော့ အဲဒီ ပင်ဆင် ချဲ ထွင် မွန်းမံ တဲ့အဆင့်ကို သိပ္ပံနည်းကျကျ နဲ  အင်ဂျင်နီယာပညာရပ်ဆန်ဆန် အသေးစိပ် လ့လာတာဟာ ဆာ့ဖ်၀ဲဆင့်ကဲဖြစ်စဉ် ကို လ့လာတာပါပဲ။
Maintenance ဘာလဲ ဘာကြောင့်လဲ
Maintenance ဆိုတာ စနစ် (system) တခု စတင်လည်ပတ်အသုံးပြုပြီး ကာလကနောက်ပိုင်း အဲဒီ စနစ်အပေါ်မှာလုပ်ဆောင်တဲ့ ဘယ်လိုအပြောင်းအလဲ မျိုးကိုမဆို ရည်ညွှန်းတာဖြစ်တယ်။ ဒါထက် စကားမစပ်ပြောရရင်တော့ တချို တချို သာ ကွန်ပြူတာသိပ္ပံပညာရှင်တွေနဲ  ဆာ့ဖ်၀ဲပညာရှင်တွေက ဒီ maintenance ဆိုတဲ့ စကားလုံးကို သိပ်မကြိုက်ကြဘူးဗျ။ ဘာလို တုန်းဆိုတော့ တခြား ရုပ်ပိုင်းဆိုင်ရာ အင်ဂျင်နီယာပညာရပ် နယ်ပယ်တွေမှာ သုံးတဲ့ maintenance အဓိပ္ပါယ်နဲ ၊ ဆာ့ဖ်၀ဲအင်ဂျင်နီယာ နယ်ပယ်မှာသုံးတဲ့ maintenance အဓိပ္ပါယ်က ကွာခြားတာကိုး။ ဒါပေမယ့်လည်း ခက်တာက ဒီစကားလုံးဟာ ဆာ့ဖ်၀ဲလောကမှာ ကပ်ငြိ တွင်ကျယ် အတည်ဖြစ်နေပြီ ဆိုတော့လည်း ဒီအတိုင်းပဲ ဆက်သုံးကြတာပေါ့။ ကျွန်တော်တို ရဲ့ ဆာ့ဖ်၀ဲနယ်ပယ်မှာတော့ maintenance ကို ဟာဒီလို အမျိုးအစားလေးမျိုး ခွဲထားတယ်..။
၁. Corrective maintenance:  ဆာ့ဖ်၀ဲအသုံးပြုပြီးဆောင်ရွက်နေတဲ့ န စဉ်လုပ်ငန်းဆောင်တာတွေ မှန်ကန်မှု တိကျမှု ရှိအောင် လုပ်တာ။ ကိုယ့်ဆော့ဖ်၀ဲမှာ ရှိနေတဲ့ အားချက်တွေ အမှားတွေကို ပင်တာ။
၂. Adaptive maintenance: တခြား system တွ(software, hardware, netware) နဲ  လိုက်လျောညီထွေ အဆင်ပြေမှုရှိအောင် ပူးပေါင်းဆောင်ရွက်နိုင်အောင် ကိုယ့် system ကိုယ့်ဆော့ဖ်၀ဲကို ပင်ဆင်ပြောင်းလဲမှုတွေလုပ်တာ။
၃. Perfective maintenance: system ထဲက လက်ရှိ လုပ်ကိုင်ဆောင်ရွက်နေတဲ့ function တွကိုပဲ၊ ပိုပြီးပြည့်စုံတဲ့ အဆင့်ရောက်လာအောင် ကာင်းသထက်ကောင်းလာအောင် ဆာင်ရွက်တာ။
၄. Preventive maintenance: ကိုယ့် system ရဲ့ လုပ်ကိုင်ဆောင်ရွက်နိုင်မှုစွမ်းရည်တို  အမြန်နှုန်းတို  (performance/productivity) လက်မခံနိုင်လောက်တဲ့ အဆင့်ထိ ကျမသွားအောင် ဆာင်ရွက်တာ။ .. ဆိုပြီး maintenance လုပ်ရတဲ့ အကြောင်းရင်းပေါ်မူတည်ပြီး အုပ်စုလေးစု ခွဲထားပါတယ်။
Maintenance ကို ဘယ်သူတွေလုပ်သလဲ
ဆော့ဖ်၀ဲကို ပင်ဆင် ချဲ့ထွင် ထိမ်းသိမ်းသူ (software maintainter) တွဟာ ဆာဖ့်၀ဲရေးသားတည်ဆောက်သူ (software developers) တွ လုပ်ရတဲ့ အလုပ်တွေအပြင် တခြားအလုပ်ပေါင်းများစွာကိုပါ လုပ်ဆောင်ရတဲ့သူတွေဖြစ်တယ်။ customer တွ၊ business analysis, requirement analysis တွ၊ marketing အဖွဲ တွ၊ testing team, development team စတာတွေ အပြင် higher management person တွ နဲ  ပါ အမြဲမပြတ် ထိတွေ ဆက်ဆံ တွ ဆုံ ဆွးနွေးရတဲ့ အလုပ်တွေကိုပါ လုပ်ရတာကိုး။ ဒါကြောင့် အလွန်အတွေ အကြုံများပြီး ရင့်ကျက်ကျွမ်းကျင်တဲ့ software developer တွကသာ software maintainer တွအဖြစ် လုပ်ကိုင်လေ့ရှိတယ်။ ဒီလို system တစ်ခုကို တိုးချဲ့ ပင်ဆင် ထိမ်းသိမ်းမှု လုပ်တဲ့အခါ အဲဒီ system ကို တည်ဆောက် ရးသားခဲ့တဲ့ developer တွကိုပဲ ပန်အသုံးပြုတာနဲ ၊ ကျွမ်းကျင် developer တွပါ၀င်တဲ့ တခြားသီးသန်  အဖွဲ ကို အသုံးပြုတာ ဆိုပြီး software maintainer တွနဲ  ပတ်သက်ပြီး အကြမ်းဖျဉ်း အုပ်စုနှစ်မျိုးခွဲနိုင်ပါတယ်။
software system တခုကို တခြားသီးသန် အဖွဲ က maintenance လုပ်တယ်ဆိုရင်
• ဆာ့ဖ်၀ဲရဲ့ အားနည်းချက်တွေနဲ ပတ်သက်လို  ပိုပြီး ဓမ္မဓိဌာန်ကျကျ ကိုယ်တိုင်သုံးစွဲသူရဲ့ အမြင်ရှုထောင့်ကနေ ကြည့်ရှုဆင်ခြင် စဉ်းစားနိုင်တယ်။
• System တခု ဘယ်လိုအလုပ်လုပ်နေသလဲ ဆိုတာကိုကြည့်ပြီး အဲဒီ system ဘယ်လို အလုပ်လုပ်သင့်တယ်ဆိုတာကို ပိုပြီး အလွယ်တကူ ခွဲခြားနိုင်တယ်။
…ဆိုတဲ့အားသာချက်တွေ ရရှိနိုင်ပါတယ်။
Development team ထဲက ပုဂ္ဂိုလ်တွေကပဲ maintenance လုပ်တာဆိုရင်တော့ ကာင်းကျိုးအနေနဲ
• ကိုယ်တည်ဆောက်ထားတဲ့ system ဖစ်တဲ့အတွက် maintenance လုပ်ရတာ လွယ်ကူတယ်။ ဒါကြောင့် အချိန်/ငွေ ပိုသက်တာတယ်။
ဒါပေမယ့် အားနည်းချက်ကတော့
• Developer တွ အနေနဲ  ကိုယ့်ကိုယ်ကို ယုံကြည်မှု ပိုကဲလွန်းသွားနိုင်ပြီး maintenance အလုပ်ကို (နောက်နောင်မှာ တချိန်မှာ) အများကြီး အထောက်အကူပြုမယ့် documentation တွဘက်မှာ အလေးထား အားစိုက်မှု လျာ့နည်းသွားနိုင်တယ်။
“ဒါ..ဒို ရးထားတာ ဒို သိတာပေါ့။ ဘာ documentation မှ မလိုပါဘူး” ဆိုပြီး  ဆာ့ဖ်၀ဲနဲ  ပတ်သက်တဲ့ မှတ်တမ်းမှတ်ရာ တွကို ကာင်းကောင်းမလုပ်ပဲ ဥပေက္ခာ ပုတတ်ကြပါတယ်။ တကယ်တော့ software team ဆိုတာ အမြဲတန်း အ၀င်အထွက် အပြောင်းအရွှေ ရှိမြဲဖြစ်ပါတယ်။ လူဟောင်းတွေ ပာင်းရွှေ သွားတဲ့အခါ ဒါမှမဟုတ် အလုပ်ထွက်သွားတဲ့အခါ အသစ်၀င်ရောက်လာတဲ့ developer တွ အနေနဲ  documentation ကာင်းကောင်းမရှိတဲ့ ဆာ့ဖ်၀ဲကို maintenance လုပ်ရတာဟာ မပုံမရှိ လမ်းညွှန်မရှိ သံလိုက်အိမ်မြှောင်မရှိပဲ သငေ်္ဘာကြီးတစင်းကို သမုဒ္ဒရာခရီးနှင်ရသလို ဖစ်နေပါလိမ့်မယ်။

တည်ဆောက် ပင်ထိမ်း အချိုး (development vs. maintenance)
1970 မှာတင်ပြခဲ့တဲ့ Royce ရဲ့“Water Fall Model” အရဆိုရင် ပရောဂျက် စုစုပေါင်းကုန်ကျစရိတ်ရဲ့ ၇၅% ကနေ ၉၅% ထိဟာ maintenance အလုပ်တွေအတွက် အသုံးပြုရတယ်ဆိုပါတယ်။
တခါ Fjedstad နဲ  Hamlen တို  1979 မှာ ပုလုပ်ခဲ့တဲ့ လ့လာမှုအရ ပရောဂျက်တခုအတွက် ရင်းနှီးစိုက်ထုတ်မှု (အချိန်၊ လူ၊ ငွ၊ နည်းပညာ၊ ကျွမ်းကျင်မှု စတာတွေ) စုစုပေါင်းရဲ့ 39% ဟာ ဆာဖ့်၀ဲ ရးသားတည်ဆောက်တဲ့အဆင့်မှာ အသုံးပြုရပြီး၊ ဆာ့ဖ်၀ဲပြင်ဆင်ချဲ့ထွင်မွန်းမံမှုအတွက် 61% အသုံးပြုရတယ်ဆိုပါတယ်။
ဒါ့အပြင် Parikh နဲ  Zvegintzov တို  1983 မှာ ပုလုပ်ခဲ့တဲ့ လ့လာမှုအရ software development time က ၂-နှစ် ကြာရင် အဲဒီ system ရဲ့ maintenance time က ၅-နှစ် ကနေ ၆-နှစ် ထိ ကြာတယ်လို  ဆိုပါတယ်။
ဒါကြောင့် ဆာ့ဖ်၀ဲအင်ဂျင်နီယာလောကမှာ ဆာ့ဖ်၀ဲပြင်တာ-ရေးတာ နဲ  ပတ်သက်ပြီး ၈၀-၂၀ စည်းမျဉ်း (80-20 rule) ကို အကြမ်းဖျဉ်းလက်ခံကျင့်သုံးလေ့ရှိပါတယ်။ အဓိပ္ပါယ်က development အတွက် ၂၀% အားစိုက်ရပြီး၊ maintenance အတွက် 80% အားစိုက်ရတယ်လို  ဆိုလိုတာပါ။
ကဲ. . ဒီလောက်ဆိုရင်ပဲ maintenance လုပ်ငန်းစဉ်ဟာ ဘယ်လောက်အရေးကြီးကြောင်း မိတ်ဆွေတို ရိပ်စားမိလောက်ပါပြီ။ အမှားတစ်ခုကို ပင်ဆင်ဖို  တခါတရံမှာ ဘယ်လောက်ထိ အရင်းအနှီး ကြီးမားသလဲဆိုတာရဲ့ တခြား လက်တွေ ထင်ရှားတဲ့ ဥပမာကတော့ လတ်တလောကပဲဖြစ်ခဲ့တဲ့ Toyota ကုမ္ပဏီက သူ ရဲ့ Prius ကားပေါင်း တသိန်းခြောက်သောင်းကျော် ပန်သိမ်းရတဲ့ အဖြစ်အပျက်ကိုသာ ကြည့်လိုက်ပါတော့။
ဒီနေရာမှာ မးစရာမေးခွန်းတခုရှိလာတာက “ဆော့၀ဲမှန်သမျှကို အဲဒီလို ဘတ်ဂျက်တွေ အကြီးအကျယ်သုံးပြီး maintenance လုပ်နေ ဖို  လိုအပ် လို လားဗျ” ဆိုတာပါပဲ။ အဖြေကရှင်းပါတယ် “နိုး” ပါ့။ ဒါဆိုရင် ဘယ်လိုဆော့ဖ်၀ဲစနစ်တွေက evolution ဖစ်ဖို  maintenance လုပ်ဖို  ဘယ်လောက်အထိလိုအပ်သလဲဆိုတာ ဆက်လက် လ့လာကြည့်ကြပါစို ။

ဆော့ဖ်၀ဲစနစ်အမျိုးအစားများ
ကွန်ပြူတာသိပ္ပံပညာရှင် လးမဲန်း (Meir Manny Lehman, January 24 1925 – December 29 2010) က maintenance နဲ  evolution ပါ်အခြေပြုပြီး ဆာ့ဖ်၀ဲစနစ်တွေကို အဓိကအုပ်စုကြီး သုံးစု ခွဲပြထားပါတယ်။
၁. S-System (Specifiable) အဓိပ္ပါယ်သတ်မှတ်ထားတဲ့အတိုင်း တိတိကျကျ နဲ  ပုံစံတကျ ရးသားအကောင်အထည်ဖေါ်ထားတဲ့ စနစ်၊ ပာင်းလဲမှုမလိုအပ်တဲ့စနစ်။ ဥပမာ မိတ်ဆွေတို  ကျာင်းသားဘ၀မှာ လုပ်ခဲ့တဲ့ software/program assignment တွလိုမျိုးပေါ့။ ပးထားတဲ့ specification အတိုင်း ပုစၦာအတိုင်း တိတိကျကျ ဘာင်၀င်အောင် ရးလိုက်ရင်ပြီးပြီ။ အသုံး၀င်တာ မ၀င်တာ၊ ချဲ ထွင် ပင်ဆင်လို ရတာ မရတာတွေ မစဉ်းစားဘူး။ ခိုင်းထားတဲ့ (specification) အတိုင်း ရးထားတယ်ဆိုရင်ပဲ ဆရာတွေကလက်ခံမယ်။ မိတ်ဆွေလည်း အမှတ်ကောင်းကောင်းရမယ်။ ဒါလောက်ပဲ။
၂. P-System (Problem-solving) ပင်ပလက်တွေ လာကရဲ့ ပဿနာနဲ အဖြေက ရှင်းရှင်းလင်းလင်း နဲ  တည်ငြိမ်မှုရှိပြီးသား ဖစ်ကောင်းဖြစ်နိုင်ပေမယ့်၊ တကယ် program/software ရးတဲ့အခါ ပဿနာရဲ့ အနီးစပ်ဆုံး အဖြေကိုသာ အခြေပြု ရးသားထားတဲ့စနစ်။ ဒီလိုစနစ်မျိုးတွေဟာ တဆင့်ခြင်း တဆင့်ခြင်း တိုးတက်ပြောင်းလဲသွားဖို လုပ်ဆောင်မယ်ဆိုရင် လုပ်ဆောင်လို ရတယ်။ ဥပမာ စစ်တုရင် ကစားတဲ့ ဂိမ်းလိုမျိုးပေါ့။ ပင်ပလောကမှာ တိကျရှင်းလင်းတဲ့ ဥပဒေသတွေ နည်းစနစ်တွေ ရှိပြီးဖြစ်ပေမယ့် ဂိမ်းရဲ့ စကားပုံစကားနည်းတွေ ရလာဒ်တွေ အဖြေတွေကတော့ အမြဲဲ ဆန်းသစ်ပြောင်းလဲ နတဲ့ သဘောရှိတာကိုး။ ဒါကြောင့် အဲ့ဒီလို စနစ်မျိုးတွေကို ဆာ့ဖ်၀ဲရေးတဲ့အခါ ဘယ်တော့မှ တခါတည်းနဲ  (version တခုတည်းနဲ ) ၁၀၀% ပည့်စုံသွားအောင် ရးလို မရဘူး။ အသစ် အသစ်သော logic တွ နဲ ၊ တခြား တခြားသော ဖစ်နိုင်ခြေတွေ ထပ်ဖြည့်ပြီး ကိုယ့် ဆာ့ဖ်၀ဲကို (version အသစ်တွေအဖြစ်) အမြဲ ချဲ ထွင် မွန်းမံနေလို ရတယ်။
၃. E-System(Embedded) တကယ့်လက်တွေ ပင်ပလောကထဲမှာ တိုက်ရိုက် ထည့်သွင်းလည်ပတ်နေတဲ့ စနစ်မျိုးတွေ။ ပင်ပလောက က အချိန်နဲ အမျှပြောင်းလဲနေသလို၊ ကိုယ့်ရဲ့ ဆာ့ဖ်၀ဲစနစ် ကလည်း ပင်ပလောကနဲ အတူ အချိန်နဲ အမျှ လိုက်ပြောင်းနေဖို မဖြစ်မနေလိုအပ်တဲ့ စနစ်မျိုး။ ဥပမာတွေကတော့ အများကြီးပါ။ ဒီလို e-type စနစ်မျိုးတွေကမှ maintenance ကို heavy လုပ်ရတဲ့ စနစ်မျိုးတွေပေါ့။

ဆောဖ့်၀ဲ ဆင့်ကဲဖြစ်စဉ် ဥပဒေသများ
M M. Lehman က သူ အတွေ အကြုံကို အခြေခံပြီး ဆာ့ဖ်၀ဲဆင့်ကဲဖြစ်စဉ် ဥပဒေသ (Laws of Software Evolution) ၈-ခုကို ဖါ်ထုတ်တင်ပြခဲ့ပါတယ်။ အဲဒီလို တင်ပြခဲ့တဲ့နေရာမှာ စိတ်ကူးစိတ်သန်းသက်သက်နဲ  တထိုင်တည်းနဲ  ၈-ချက်လုံး တင်ပြခဲ့တာမဟုတ်ပါဘူး။ e-type ဆာ့ဖ်၀ဲစနစ်ပေါင်းများစွာကို လ့လာပြီးမှ၊ အထူးသဖြင့် IBM ရဲ့ OS/360, OS/370 တို ကို အသေးစိပ်လေ့လာပြီး၊ ၁၉၇၄ ခုနှစ်ကနေ ၁၉၉၆ ခုနှစ်အထိ နှစ်ပေါင်း ၂၀ ကျာ် ကာလအတွင်းမှာ တချက်ပြီးတချက် တဖြည်းဖြည်း ချဲ့ထွင်တင်ပြခဲ့တာပါ။ ဒီအချက်တွေဟာ ဥပဒေသ Law ဆိုတာထက်၊ တကယ်တော့ တွးခေါ်ယူဆချက် Hypothesis တွပါပဲ။ ကျွန်တော်ရဲ့ ဒီဆောင်းပါးမှာတော့ (ကျမ်းလေးအံ့စိုးရ်ု :-) အချက်နှစ်ချက်ကိုသာ ဆွးနွေးမှာဖြစ်ပါတယ်။ မိတ်ဆွေတို  ဆက်လက် လ့လာချင်တယ်ဆိုရင် ရည်ညွှန်းစာအုပ်စာတမ်းတွေမှာ ရှာဖွေဖတ်ရှုကြပါ။
၁ ဆက်လက်ပြောင်းလဲနေခြင်း(Continuing Change)
E-Type system တွဟာ အဆက်မပြတ် တိုးတက်ပြောင်းလဲနေဖို  လိုအပ်ပါတယ်။ ပင်ပကမ္ဘာမှာ တိုးတက်လာသလောက် လိုအပ်လာသလောက်ကို ရာင်ပြန်ဟပ် ဆာင်ရွက်နိုင်စွမ်းရှိရပါမယ်။ အဲဒီလိုမှမဟုတ်ရင် သုံးစွဲသူတွေရဲ့ စိတ်ကျေနပ်မှုနဲ  လိုအပ်ချက်ကို ဖည့်ဆည်းပေးနိုင်မှာ မဟုတ်တော့ဘူး။ ထင်ရှားတဲ့ ဥပမာတခုကတော့ သူ ခတ်သူ အခါက ၀က်၀က်ကွဲအောင်မြင်ခဲ့တဲ့ Windows98 ကို ဒီကနေ မှာ ဘယ်သူမှမသုံးတော့ပါဘူး။ 98 ကနေ လက်ရှိအောင်မြင်နေတဲ့ Windows 7 တို  8 တို ကို upgrade လုပ်လို လည်းမရပါဘူး။ ဒါဟာ Windows98 ရဲ့ ထပ်မံ တိုးချဲ  မွန်းမံ ပင်ဆင် နိုင်စွမ်း ဂိတ်ဆုံးသွားလို ပဲ ဖစ်ပါတယ်။
ဒီနေရာမှာ မိတ်ဆွေတို  သတိပြုစရာကတော့ system တခုဟာ maintenance လုပ်တိုင်းလည်း ဆင့်ကဲတိုးတက်မလာတော့ဘူးဆိုတာပါပဲ။ သူ မှာလည်း ယိုယွင်းပျက်သုဉ်းမှု (Decay) ဖစ်တဲ့အဆင့်တဆင့်ရှိပါတယ်။ ဒီလိုအဆင့်ရောက်လာပြီဆိုရင် စနစ်သစ်ကိုပြောင်းသုံးမလား (migration) ဒါမှမဟုတ် အစအဆုံး အသစ်ပြန်ရေးမလား (re-engineering) ဆိုတာ စတင်စဉ်းစားရပါတော့တယ်။ အဲဒီလို maintenance လုပ်ဆောင်မှု ရပ်တန် သင့်တဲ့ အခြေအနေတွေကို နာက်ပိုင်းမှာ သီးသန် ဆွးနွေးပါမယ်။
၂ ရှုပ်ထွေးမှု တိုးမြင့်လာခြင်း (Increasing Complexity)
ဆော့ဖ်၀ဲတခုကို maintenance လုပ်လေလေ အဲဒီဆော့ဖ်၀ဲရဲ့ရှုပ်ထွေးမှု (complexity) မင့်မားလာလေလေဖြစ်ပါတယ်။ ရှုပ်ထွေးမှုမြင့်မားတဲ့အတွက် ပင်ဆင်ရတာပိုပြီးခက်ခဲလာသလို ထပ်ပြီး ဆင့်ကဲတိုးတက်ဖို အတွက်လည်း တဖြည်းဖြည်း ပိုပြီးခက်ခဲလာပါတယ်။ ဒါကြောင့် ဆာ့ဖ်၀ဲရဲ့ ရှုပ်ထွေးမှုကို သိပ်မြင့်မားမလာအောင်ထိန်းထားဖို  ဒါမှမဟုတ် ရှုပ်ထွေးမှုလျော့ကျသွားအောင်လုပ်ဖို  မဖြစ်မနေလိုအပ်ပါတယ်။ ဆာ့ဖ်၀ဲစနစ်မှာပါတဲ့ moduleတွေ functionတွေ classတွေ libraryတွေ အချင်းချင်း အပြန်အလှန် ဘယ်လောက်ထိမှီခိုနေကြသလဲ၊ source code တွ ကိုယ်တိုင်မှာက ဘယ်လို ဘယ်လောက်ထိ ရှုပ်ထွေးမှုရှိနေသလဲဆိုတာတွေကို၊ မျက်မြင်လက်တွေ စစ်ဆေးတဲ့နည်း (visual inspection) နဲ  အချက်အလက် စာရင်းဇယားတွေကို သရုပ်ခွဲဆန်းစစ်လေ့လာတဲ့နည်း (statistical analysis) တွကို အသုံးပြုပြီး ဆာ့ဖ်၀ဲရှုပ်ထွေးမှုအတိုင်းအတာကို သိရှိအောင် ထာက်လှမ်းရပါတယ်။ ပီးမှ refactoring, re-structuring, re-documenting, re-engineering စတဲ့ နည်းစနစ်တွေသုံးပြီး ဆာ့ဖ်၀ဲရှုပ်ထွေးမှုလျော့ကျအောင် ဆာင်ရွက်ရပါမယ်။ ဒါက ဆာ့ဖ်၀ဲဆင့်ကဲဖြစ်စဉ်မှာ မဖြစ်မနေကြုံရတဲ့ ဆာ့ဖ်၀ဲရှုပ်ထွေးမှုအကြောင်းပါ။ တခြားကျန်တဲ့ ဥပဒေသ ခာက်ချက်ကတော့ Self Regulation, Conservation of Organizational Stability, Conservation of Familiarity, Continuing Growth, Declining Quality နဲ  Feedback System တို ပဲဖြစ်ပါတယ်။ မိတ်ဆွေတို  စိတ်၀င်စားတယ်ဆိုရင် ရည်ညွန်းစာအုပ်စာတမ်းတွေမှာ ဆက်လက်လေ့လာ ဖတ်ရှုကြပါလို  ပန်ကြားလိုပါတယ်။

Maintenance ရပ်သင့်တဲ့အချိန်
• ပင်ဆင်ထိမ်းသိမ်းစရိတ် (maintenance cost) မင့်မားလွန်းနေရင်
• system ရဲ့ စိတ်ချယုံကြည်ရမှု(reliability) အဆင့်က လက်ခံနိုင်စရာအဆင့် မရှိတော့ရင်
• ကိုယ့်ရဲ့ system ဟာ နာက်ထပ်လာမယ့်အပြောင်းအလဲတွေကို သင့်လျော်တဲ့ အချိန်ကာလတခုအတွင်းမှာ လက်ခံနိုင်စွမ်း(adaptability) မရှိတော့ရင်
• System ရဲ့ အမြန်နှုန်းစွမ်းရည် (performance) ဟာ သတ်မှတ်ထားတဲ့ဘောင်ကို ကျာ်လွန် ကျဆင်းနေရင်
• System ရဲ့ လုပ်ဆောင်ချက် (function) တွဟာ အကန် အသတ်နဲ ပဲ အသုံး၀င်မှုရှိတော့တဲ့ အနေအထားမျိုးရောက်လာရင်
• တခြား system တွက ကိုယ့် system နဲ ယှဉ်လိုက်ရင် ပိုပြီး ကာင်းကောင်း မန်မြန် နဲ  ကုန်ကျစရိတ်သက်သက်သာသာ လုပ်နိုင်နေပြီဆိုရင်
• ပိုသက်သာပြီး ပိုမိုသစ်လွင်တဲ့ ပိုစွမ်းရည်မြင့်တဲ့ hardware နဲ  အစားထိုးလဲလှယ် နိုင်လောက်တဲ့အထိ၊ ကိုယ့် system ရဲ့ (old) hardware တွကို ပင်ဆင် ထိမ်းသိမ်းရတဲ့ စရိတ်က မင့်မားနေပြီ..
စတဲ့ အခြေအနေတွေ ရှိနေပြီဆိုရင် ကိုယ့်ရဲ့လက်ရှိ စနစ်ဟာ ထပ်မံ တိုးတက်ဖို  မဖြစ်နိုင်တော့သလောက်အခြေအနေရောက်နေပြီ၊ လက်ရှိစနစ်ဟာ ယိုယွင်းပျက်သုဉ်းစပြုနေပြီ၊ ဒါကြောင့် လက်ရှိ စနစ်ကို maintenance လုပ်နေမယ့်အစား စနစ်သစ်တခုကို migration လုပ်ဖို  ဒါမှမဟုတ် တခြား system အသစ်တစ်ခုကို ပာင်းသုံးဖို  လိုအပ်နေပြီလို  သိနိုင်ပါတယ်။

နိဂုံးအမှာ
“ဟုတ်ပါပြီ ခင်ဗျားပြောတဲ့ p-type တို  e-type တို ၊ ဆာ့ဖ်၀ဲဆင့်ကဲဖြစ်စဉ်တို  ဘာတို  ညာတို .. ထားပါတော့ ။ ဒါတွေ လ့လာနေတော့ သိတော့ကော ကျုပ်တို အတွက် ဘာအကျိုးရှိမှာမို လဲ။ ဒီ စာအုပ်ကြီးထဲက ခပ်ကြောင်ကြောင် သဘောတရားတွေဟာ လက်တွေ  ပင်ပလောကမှာ တကယ်ရော အသုံးကျလို လား။” လို  မိတ်ဆွေတို  မးကောင်း မးနိုင်ပါတယ်။ ကျွန်တော်ကိုယ်တိုင်လည်း ပရိုဂရမ်ရေးတာ ဆာ့ဖ်၀ဲရေးတာ သင်ကာစက၊ analysis တို  design တို  ဆာ့ဖ်၀ဲအင်ဂျင်နီယာပညာရပ်နဲ  သက်ဆိုင်တဲ့ သိီအိုရီ အယူအဆ သဘောတရားရေးရာတို  အဲဒါတွေ လ့လာနေရတာထက်၊ coding တွ တဖြောင်းဖြောင်း ရးလိုက်တာကို ရးနိုင်တာကို မှ တကယ့်အလုပ်ကြီးလို  ထင်မြင်ယူဆခဲ့ဖူးပါတယ်။ တကယ်တော့ ဒီ ဆာ့ဖ်၀ဲဆင့်ကဲဖြစ်စဉ် အယူအဆ သဘောတရားတွေဟာလည်း အများစုသောကျွန်တော်တို  န တဓူ၀ ရးနေတဲ့ န မင် ညပျောက် မည်ကာမတ္တ ထမင်းစားဆော့ဖ်၀ဲတွေ (တကယ်တော့ ဆာ့ဖ်၀ဲလို  ပာဖို တာင်ခပ်ခက်ခက် coding တွ) အတွက် တာ့အသုံးချလို ရမယ်မထင််ပါဘူး။ နှစ်ပေါင်းများစွာ ကာလရှည်ကြာ ခိုင်ခိုင်မာမာ ရပ်တည်နေတဲ့ Linux တို လို Windows တို လို operating system software တွ၊ Adobe Systems ရဲ့ photoshop တို လို reader တို လို အသုံးချဆော့ဖ်၀ဲ တွလိုမျိုး versionတွေ တစ်ခုပြီးတခု တိုးတက်ပြောင်းလဲလာတဲ့၊ လက်ရှိလည်း ဆက်လက်ပြီး တိုးတက်ပြောင်းလဲနေတဲ့ တကယ့်ဆော့ဖ်၀ဲကြီးတွေ မှာမှသာ သိမြင်ခံစားနိုင်တဲ့ သဘောတရားတွေပါ။ ဒါ့အပြင် နိုင်ငံစုံကော်ပိုရေးရှင်းကြီးတွေ၊ ကမ္ဘာ့ သုတေသနဌာနကြီးတွေ နဲ  အစိုးရဌာနကြီးတွေ မှာ လည်ပတ်သုံးစွဲနေတဲ့ ၊ ဘတ်ချက် သန်းပေါင်းများစွာ အကုန်အကျခံရေးထားတာတဲ့ enterprise level customized software တွ မှာဆိုရင်လည်း ဒီသဘောတရားတွေကို ခံစားသိမြင်နိုင်ပါတယ်။ မိတ်ဆွေဟာ အဲဒီလိုအဖွဲ အစည်းကြီးတွေမှာ အဲဒီလိုဆော့ဖ်၀ဲမျိုးတွေကို ပါ၀င်ရေးသားရပြီဆိုရင် အနည်းဆုံးတော့ ““ဩ..လက်စသတ်တော့ ဒီလိုကိုး” လို  ရရွတ်နိုင်မှာ အပြင် မိတ်ဆွေအနေနဲ  ဒါရိုက်တာအဖွဲ  ဘုတ်အဖွဲ တို  budget sponsor တို  ကို အစည်းအဝေးတွေ ဘာတွေမှာ ‘ကိုယ့်ရဲ့ လက်ရှိ software စနစ်က ဘယ်လိုအပိုင်းတွေကို ချဲ ထွင်မွန်းမံရမယ်၊ ဘာကြောင့်လုပ်ရတယ်၊ ဘယ်လိုလုပ်ကြမယ်၊ ဘယ်သူတွေလုပ်ကြမယ်၊ ဘယ်လောက်ကြာနိုင်တယ်၊ ဘယ်လောက်ကုန်ကျနိုင်တယ်’၊ ဒါမှမဟုတ်လဲ ချဲ့ထွင်မွန်းမံမှုတွေ ဆက်လုပ်သင့် မလုပ်သင့် ဆိုတာတွေကို ပညာရှင်ဆန်ဆန် စနစ်တကျ အချက်အလက် အကျိုးအပြစ်နဲ  တင်ပြနိုင်စွမ်းရှိလာမှာပါ။ ဒါ့အပြင် ဘယ်ပညာရပ်မှာမဆို အဲဒီပညာရပ် နဲ  ပညာရှင်တွေ တိုးတက်ရေးအတွက် အဓိက အသက်သွေးကြောကတော့ သုတေသန လုပ်ငန်းတွေပါ။ သုတေသနအသစ်အဆန်းတွေကို တွးခေါ်ကြံစည်စဉ်းစားနိုင်ဖို အတွက်ကြတော့ (ရုပ်ဝတ္တုပိုင်းဆိုင်ရာ အခြေခံအဆောက်အဦးတွေ လိုအပ်သလို) ခိုင်မာကျယ်ပြန် တဲ့ သီအိုရီ အယူအဆ သဘောရေးရာတွေ လိုအပ်ပါတယ်။ တချိန်မှာ သိသင့်သိထိုက်တဲ့ သိမှဖြစ်မယ့်အရာတွေကို အခုကတည်းက ကြားဖူးနားဝ တီးမိခေါက်မိရှိနေရင် ပိုမကောင်းပေဘူးလားဗျာ။ (ဟေ့..ဘာမှမကောင်းဘူးကွ။ ကြီးကြီးကျယ်ကျယ်ကွာ။ သုတေသန နနေသာသာ မင်းပြောတဲ့ ထမင်းစားဆော့ဖ်ဝဲတောင် ပုံမှန်မရေးရလို ညစ်နေတာကွ။ မန်မာငွေ ၅၀၀၀ ရဖို  on-call ခါ်ထားတဲ့ဆီကို ၀င်းဒိုးပြန်တင်ပေးဖို  သွားလိုက်ဦးမယ်ဟေ့။;-)


ရွှင်လန်းချမ်းမြေ့ပါစေ။
infoTherapy-2013
References:
1. M.M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution,” Proc. IEEE, IEEE Press, vol. 68, no. 9, 1980, pp. 1060–1076
2. Chapter 11: Maintaining the System From “Software Engineering: Theory and Practice” 3rd Edition, 2006, By Shari Lawrence Pfleeger and Joanne M. Atlee