Software Development (Software တည်ဆောက်ခြင်း)
Software တည်ဆောက်တဲ့အခါ လူတွေ ဘာလိုအပ်လဲ နားလည်ဖို့၊ ဖြေရှင်းချက်ကို စီစဉ်ဖို့၊ code ရေးပြီး စမ်းစစ်ဖို့၊ ဘယ်လို အလုပ်လုပ်လဲ ဆိုတာကို မှတ်တမ်းတင် ရေးသားဖို့နဲ့ လူတွေ တကယ် သုံးနိုင်မနိုင် စစ်ဖို့ လိုပါတယ်။ ဒီလုပ်ငန်းတွေက project တစ်ခုလုံး တစ်လျှောက်မှာ ဆုံးဖြတ်ချက်တွေ ချဖို့ ကူညီပါတယ်။
ဒီစာမျက်နှာတွေက စာမေးပွဲ တစ်ခုတည်းအတွက် မဟုတ်ပါဘူး။ ဒီမှာ သင်ပေးတဲ့ အလေ့အထတွေ (ကိုယ့် user တွေနဲ့ စကားပြောပါ၊ code မရေးခင် ဒီဇိုင်းဆွဲပါ၊ ပုံမှန် မဟုတ်တဲ့ ခက်ခက်ခဲခဲ အခြေအနေတွေကိုပါ စမ်းစစ်ပါ၊ တခြားသူ ဖတ်ပြီး လိုက်လုပ်နိုင်တဲ့ documentation (program ကို ရှင်းပြတဲ့ စာရွက်စာတမ်း) ကို ရေးပါ) က ကျောင်းမှာဖြစ်ဖြစ်၊ အလုပ်မှာဖြစ်ဖြစ် ဘယ် software project မှာမဆို သုံးလို့ရပါတယ်။ စာမျက်နှာ တစ်ခုစီမှာ ကိုယ်ပိုင် software ကို စီစဉ်ပြီး တည်ဆောက်တဲ့အခါ သုံးနိုင်တဲ့ ဥပမာတွေနဲ့ လေ့ကျင့်ခန်းတွေ ပါပါတယ်။
IB CS သင်တန်း တက်နေသူတွေအတွက် မှတ်ချက်: ဒါတွေက Internal Assessment (IA၊ IB သင်တန်းမှာ ကျောင်းသားတစ်ယောက်ချင်း ကိုယ်တိုင် တည်ဆောက်ရပြီး ကျောင်းက ဆရာက အမှတ်ပေးတဲ့ အပိုင်း) မှာ သုံးရတဲ့ ကျွမ်းကျင်မှုတွေပါ။ စာမျက်နှာ တစ်ခုစီက သူ ထောက်ကူပေးတဲ့ IA criterion (အမှတ်ပေး စံနှုန်း) ဒါမှမဟုတ် IA လမ်းညွှန်ချက်ကို ဖော်ပြထားပါတယ်: တိုင်ပင် မေးမြန်းခြင်း (consultation)၊ ဒီဇိုင်း၊ testing (program မှန်မမှန် စမ်းစစ်ခြင်း)၊ documentation နဲ့ interface (user မြင်ပြီး သုံးရတဲ့ မျက်နှာပြင်) တို့ ပါပါတယ်။ ဒီအပိုင်းက သီးခြား syllabus ခေါင်းစဉ် တစ်ခု မဟုတ်ပါဘူး: ကိုယ့် project ကို တည်ဆောက်နေစဉ် သုံးရတဲ့ လုပ်ငန်းစဉ် ဆိုင်ရာ အသိပညာတွေကို ဖော်ပြထားတာပါ။
ဒီအပိုင်းမှာ ပါဝင်တာများ
| # | ခေါင်းစဉ် | ပါဝင်တဲ့ အကြောင်းအရာ | အထူး အသုံးဝင်တဲ့ နေရာ |
|---|---|---|---|
| 1 | Requirements Gathering (requirement တွေ စုဆောင်းခြင်း) | Client (software ဖန်တီးပေးဖို့ မှာတဲ့သူ) နဲ့ စကားပြောခြင်း၊ သူ လိုချင်တာတွေကို ရှင်းလင်းတဲ့ requirement (software က ဘာလုပ်ရမလဲ ဆိုတဲ့ သတ်မှတ်ချက်) တွေအဖြစ် ပြောင်းခြင်း၊ functional (စနစ်က လုပ်ရမယ့် အလုပ်ကို ဖော်ပြတဲ့) နဲ့ non-functional (စနစ်မှာ ရှိရမယ့် အရည်အသွေး ဒါမှမဟုတ် ကန့်သတ်ချက်ကို ဖော်ပြတဲ့) requirement ကွာခြားချက်၊ success criteria (အောင်မြင်မှု စံနှုန်းများ) နဲ့ project တစ်ခုကို တည်ဆောက်ဖို့ တန်မတန် ဆုံးဖြတ်ခြင်း: feasibility (လက်တွေ့ ဖြစ်နိုင်ခြေ) နဲ့ TELOS | Problem specification (ပြဿနာကို တိတိကျကျ ဖော်ပြချက်၊ IA Criterion A) |
| 2 | Design Representations (ဒီဇိုင်းကို ဖော်ပြတဲ့ နည်းလမ်းများ) | Flowchart (လုပ်ငန်းစဉ်ကို သင်္ကေတတွေနဲ့ ဆွဲပြတဲ့ ပုံ)၊ data flow diagram (စနစ်ထဲမှာ ဒေတာ စီးဆင်းပုံကို ပြတဲ့ ပုံ)၊ structure chart (program ကို အပိုင်းငယ်တွေ အဆင့်ဆင့် ခွဲထားပုံ ပြတဲ့ ပုံ)၊ data dictionary (ဒေတာ item တစ်ခုချင်းရဲ့ type နဲ့ စည်းမျဉ်းတွေကို စာရင်းပြုစုထားတဲ့ ဇယား)၊ UML class diagram (class တစ်ခုကို အကွက် သုံးကွက်နဲ့ ပြတဲ့ ပုံ)၊ pseudocode (program ပုံစံ ရိုးရိုးစာနဲ့ ရေးတဲ့ algorithm) နဲ့ interface sketch (screen ပုံကြမ်း) တို့: တစ်ခုစီက ဘာကို ပြလဲ၊ သင့်တော်တဲ့ တစ်ခုကို ဘယ်လို ရွေးမလဲ | System overview (စနစ်ရဲ့ ခြုံငုံ ဖော်ပြချက်၊ IA Criterion C) |
| 3 | Testing Strategy (စမ်းသပ်ပုံ အစီအစဉ်) | Testing အမျိုးအစားများ၊ test data (စမ်းစစ်တဲ့အခါ ထည့်ပေးတဲ့ တန်ဖိုးများ) ရွေးခြင်း: normal (ပုံမှန်)၊ boundary (အစွန်း) နဲ့ invalid (လက်မခံရမယ့်) data၊ ပြီးတော့ ကိုယ့် ဖြေရှင်းချက်ကို သူ့ success criteria နဲ့ တိုက်စစ်တဲ့ test plan (ဘာကို ဘယ်လို စမ်းစစ်မလဲ ကြိုရေးထားတဲ့ အစီအစဉ်) ရေးခြင်း | Testing strategy (စမ်းသပ်ပုံ အစီအစဉ်)၊ system overview ရဲ့ အစိတ်အပိုင်း (IA Criterion C) |
| 4 | Documentation and User Guides (documentation နဲ့ အသုံးပြုနည်း လမ်းညွှန်များ) | README (project အကြောင်း ပထမဆုံး ဖတ်ရမယ့် file) တွေ၊ user guide (အသုံးပြုနည်း လမ်းညွှန်) တွေ၊ အသုံးဝင်တဲ့ code comment (code ထဲမှာ ရေးထားတဲ့ ရှင်းပြချက်) တွေနဲ့ ကိုယ် ယူသုံးခဲ့တဲ့ ရင်းမြစ်တွေကို ကိုးကား ဖော်ပြခြင်း | Documentation (IA guidelines၊ IA ရဲ့ လမ်းညွှန်ချက်များ) |
| 5 | UI/UX and Accessibility (user interface၊ user experience နဲ့ လူတိုင်း သုံးနိုင်မှု) | Usability (သုံးရလွယ်ခြင်း) ရဲ့ အခြေခံများ၊ accessibility (လူတိုင်း သုံးနိုင်အောင် လုပ်ပေးထားမှု) အတွက် ဒီဇိုင်းဆွဲခြင်းနဲ့ ergonomics (လူ့ ခန္ဓာကိုယ်နဲ့ အဆင်ပြေအောင် ဒီဇိုင်းဆွဲခြင်း) တို့ပါ၊ ဒါမှ လိုအပ်ချက် ပိုမျိုးစုံတဲ့ လူတွေအတွက် software က အလုပ်လုပ်ပါတယ် | User interface design (user interface ဒီဇိုင်း)၊ system overview ရဲ့ အစိတ်အပိုင်း (IA Criterion C) |
Project တစ်ခုရဲ့ ပုံစံ
အဖွဲ့ တစ်ခုက သူ့ လုပ်ငန်းစဉ်ကို ဘယ်လို နာမည်ပဲ ပေးပေး software project အများစုက ကျယ်ကျယ်ပြန့်ပြန့် တူညီတဲ့ အဆင့်တွေကို ဖြတ်သန်းပါတယ်:
- ပြဿနာနဲ့ အဲဒီ ပြဿနာ ရှိနေတဲ့ လူတွေကို နားလည်ပါ (Requirements)။
- Code မရေးခင် ဖြေရှင်းချက်ကို စာရွက်ပေါ်မှာ ဒီဇိုင်းဆွဲပါ (Design Representations၊ UI/UX)။
- ဖြေရှင်းချက်ကို တည်ဆောက်ပါ (ဒါက ဒီ site ရဲ့ ကျန်တဲ့ အပိုင်းပါ: Programming Layer)။
- မှားသွားနိုင်တဲ့ အခြေအနေတွေကို တမင် ရွေးပြီး ဖြေရှင်းချက်ကို စမ်းစစ်ပါ (Testing Strategy)။
- တခြားသူတွေ သုံးနိုင်အောင်နဲ့ ဖြေရှင်းချက် အောင်မြင်မအောင်မြင် ကိုယ်တိုင် ဆုံးဖြတ်နိုင်အောင် မှတ်တမ်းတင် ရေးသားပြီး အကဲဖြတ်ပါ (Documentation)။
လက်တွေ့မှာ ဒီအဆင့်တွေက တစ်ခုနဲ့ တစ်ခု ထပ်နေတတ်ပြီး ရှေ့အဆင့်တွေဆီ ပြန်ပြန် လှည့်လာတတ်ပါတယ်။ Testing လုပ်နေရင်း ဒီဇိုင်းကို ပြန်ပြင်ရမယ့် အချက်တစ်ခုခု သိလာတတ်ပြီး အဲဒါက ပုံမှန်ပါပဲ၊ ကျရှုံးတာ မဟုတ်ပါဘူး။ အဆင့်တွေကို နာမည်ပေးထားရတဲ့ ရည်ရွယ်ချက်က တစ်ကြိမ်တည်း အစဉ်လိုက် ဖြတ်သွားဖို့ မဟုတ်ဘဲ ဘယ်အဆင့်ကိုမှ မကျော်မိအောင် သေချာစေဖို့ပါ။