Software Engineering မိတ်ဆက် (အပိုင်း-၃)

Glossary

Requirement specification- software project တည်ဆောက်ရာတွင် မပါမဖြစ်လိုအပ်သည့် အရာများကို သတ်မှတ်ခြင်း။

Implementation- software programကို အကောင်အထည်ဖော် ရေးသားတည်ဆောက်ခြင်း။

Testing- Software program၏ functionများကို စစ်ဆေးခြင်းနှင့် errorများကို ရှာဖွေခြင်း။

Validation- customerများ၏ လိုအပ်သည်များ နှင့် မျှော်လင့်ထားသည်များကို software systemသည် ဖြည့်စည်းပေး/မပေး စစ်ဆေးခြင်း။

1.1.6 Software process modelဆိုတာဘာလဲ။

Software process model ဆိုသည်မှာ processတစ်ခု၏ သဘော သဘာဝ ထင်မြင်ယူဆချက်ကို ပြသသော software processတစ်ခု၏ ရိုးရှင်းသော ဖော်ပြချက်ကို ဆိုလိုပါသည်။ ထို process modelများတွင် software process, software productများ နှင့် develop လုပ်ရာတွင် ပါဝင်သည့် လူများ၏ တာဝန်ကဏ္ဍ များ နှင့် သက်ဆိုင်သော activity များပါဝင်ပါသည်။

Software process model ဥပမာ တစ်ချို့ မှာ-

1. A workflow model: processတစ်ခု၏ input, outputနှင့် မှီခိုမှု အခြေအနေများ(dependencies) ပါဝင်သော activityများကို ဖော်ပြသည့် modelဖြစ်ပါသည်။ ထို activityများသည် လူတို့၏ လုပ်ဆောင်ချက်များ (human actions) ကို ကိုယ်စားပြုပါသည်။

2. A dataflow or activity model: input data မှ output dataများ ပြောင်းလဲခြင်း(data transformation)ကို လုပ်ဆောင်သော activity များကို ဖော်ပြခြင်း ဖြစ်ပါသည်။ Processတွင် မည်ကဲ့သို့ specification ကိုinput အဖြစ်လက်ခံပြီး မည်ကဲ့သို့သော designမျိုးဖြင့် outputထုတ်ပေး မည်ဆိုတာကို ဖော်ပြသော modelဖြစ်ပါသည်။ လူ သို့မဟုတ် computerမှ လုပ်ဆောင်သော data transformation များကို ကိုယ်စားပြုသည့် ‌activity များပါဝင်သော modelဖြစ်ပါသည်။

3. A role/action model: software process တွင် ပါဝင်သော လူများ၏ တာဝန်နှင့် သက်ဆိုင်သော အခန်းကဏ္ဍ ကို ဖော်ပြသော activity များကို ကိုယ်စားပြုသည့် modelဖြစ်ပါသည်။

Software process model အများစုသည် အောက်တွင် ဖော်ပြထားသော စံနမူနာပြ model သုံးခု အပေါ် အခြေခံထားပါသည်။

1. The waterfall approach: အထက်ပါ model သုံးခု၏ activityများကို ပိုင်းခြားကာ သီးခြားအဆင့် (separate process phases) များအနေဖြင့် လုပ် ဆောင်ပါသည်။ Requirement specification, software design, implementation, testing စသည့်ဖြင့် ပိုင်းခြားသတ်မှတ်ကာ အလုပ်များ လုပ်ဆောင်ပါသည်။

2. Iterative development: specification, development နှင့် validation activityများကို ကြားညှပ်ကာ ထပ်ခါထပ်ခါ လုပ်ဆောင်သော နည်းလမ်း ဖြစ်သည်။ Development၏အစပိုင်းတွင် ယေဘုယျ သဘောဆောင်သော၊ စိတ်ကူးသက်သက်သာ ဖြစ်သော(abstract) specificationများ နှင့်သာ developလုပ်ပြီး နောက်ပိုင်းမှသာ customerလိုအပ်သော အရာများနှင့် ပြန်လည်မွမ်းမံ တည်ဆောက်ပါသည်။ လိုအပ်သည်များကို ထပ်ခါထပ်ခါ ဖြည့်စွက်ရသဖြင့် specification, development နှင့် validation activityများကို ထပ်တလဲလဲ လုပ်ဆောင်ရခြင်း ဖြစ်ပါသည်။ တနည်းအားဖြင့် ပြောရလျှင် development၏ နောက်ပိုင်းမှသာ ပိုမို စနစ်ကျသော နည်းလမ်းများသုံးကာ ပိုမို အကြမ်းခံပြီး ထိန်းချုပ်ရလွယ်ကူသည့် systemများ တည်ဆောက် ကြခြင်း ဖြစ်သည်။

3. Component-based software engineering (CBSE): ဤ နည်းလမ်းဖြင့် developmentပြုလုပ်ရာတွင် အသင့်သုံး systemအစိတ်အပိုင်းများကို အသုံးပြု ကြပါသည်။ system developmentအပိုင်းတွင် အသုံးပြုမည့် software componentsများကို အစီအစဉ်တကျ ပေါင်းစပ်အသုံးပြု(integration)ကာ တည်ဆောက် ကြပါသည်။

1.1.7 Costs of software engineering က ဘာတွေလဲ။

အသုံးပြုမည့် software engineering နည်းလမ်း များအပေါ် မူတည်ကာ ကုန်ကျစရိတ် များလည်း ကွဲပြားကြပါသည်။ ခြုံငုံကြည့်လျှင် ကုန်ကျစရိတ်၏ ၆၀ ရာခိုင်နှုန်းသည် development costများဖြစ်ပြီး testing cost သည် ၄၀ရာခိုင်နှုန်း ရှိ ပါသည်။ Custom softwareများတွင်မူ evolution cost သည် development costထက် ပိုမိုကုန်ကျလေ့ ရှိပါသည်။ ဤအပိုင်းကို အထက်တွင် ဖော်ပြခဲ့သော နည်းလမ်းများ ဖြင့် ဆက်စပ်ဖတ်ရှုလျှင် ပိုမိုသဘော ပေါက် နိုင်ပါသည်။

Waterfall model

The waterfall approach အရ specification, design, implementation နှင့် integration ကုန်ကျစရိတ်များကို သီးခြား သတ်မှတ်ကာ develop လုပ်ပါသည်။ ပုံပါအတိုင်း integration နှင့် testing ကုန်ကျစရိတ်သည် အများဆုံး ဖြစ်ပါသည်။ သာမန်အားဖြင့် ယင်း integration နှင့် testing costများသည် ၄၀ ရာခိုင်နှုန်း ခန့်ရှိတတ်ပြီး အချို့သော အရေးပါသည့် system (critical system) များတွင်မူ ၅၀ ရာခိုင်နှုန်း အထိ ရှိနေနိုင်ပါသည်။

Iterative development

Iterative approach တွင် specification, design နှင့် development ကုန်ကျစရိတ်များကို တိကျစွာ တွက်ချက်၍ မရပါ။ ၎င်း activityများကို system develop လုပ်နေသည့် အချိန်အတွင်း ထပ်တလဲလဲ လုပ်ဆောင်ရမည် ဖြစ်သောကြောင့် ဖြစ်သည်။ ဤ နည်းလမ်းကို အသုံးပြုသော development များသည် system testingကို ဂရုတစိုက် လုပ်ဆောင်ကြရပါသည်။

Component-based software engineering

Componet-based software engineering နည်းလမ်းကို ရေတို development များတွင် ကျယ်ပြန့်စွာ အသုံးပြုကြပါသည်။ ပုံပါအတိုင်း development costသည် integration and testing costထက် နည်းပါသည်။ အဘယ်ကြောင့်ဆိုသော developmentအတွင်း ပေါင်းစပ် စီစဉ်ထားသည့် componentများသည် အမှန်တကယ် ရော မျှော်လင့်ထားသည့် specificationများကို လုပ်ဆောင်ပေးနိုင် မလား ဆိုတာကို integration and testing အပိုင်းတွင် သေချာစွာ စစ်ဆေး လုပ်ဆောင် ရသောကြောင့် ဖြစ်ပါသည်။

Development and evolution costs for long-lifetime

Development and evolution costs for long-lifetime ဆိုတဲ့ အပိုင်းကတော့ ရေရှည် software systemများအတွက် ရည်ရွယ်ပါသည်။ ဉပမာ ၁၀ နှစ်နှင့် အထက် ကြာမြင့်ပြီး အချက်အလက် အသစ်များ ပြင်ဆင် developလုပ်ရမည့် software များ၏ evolution cost သည် development costထက် သိသိသာသာ များနိုင်ပါသည်။

အများသောအားဖြင့် software system များသည် evolution costကနေ ပြေးမလွတ်နိုင်ပါ။ ပြင်ဆင် develop လုပ်ရသော ကာလ များလေလေ evolution costများလေဖြစ်ပါသည်။