Badral's personal blog

Анх VS-2003 Architect дээр бичигдсэн, жилийн өмнө VS-2005 дээр шилжүүлэгдэн ажиллаж байсан програмыг VS-2008 руу шилжүүлтэл өгөгдлийн заагчийг нааш цааш (forward, backward) гүйлгэдэг функцүүд ажиллахгүй болчихов. Шинжээч (debugger) ямарч алдаа өгөхгүй, өвөрмөц боловсруулагчид (exception handler) ямар ч зүйл мэдэгдэхгүй байсан тул эх кодыг дэмий шахуу маш удаан ширтэж байж дараах асуудал байсныг олж асуудлыг арилгав.
Өгөгдөл ба хэрэглэгчийн гадаргуун холболтыг BindingManagerBase ашиглаж хийсэн байв. Түүнд контролуудын холболт нэмэхдээ тухайн контролын DataBindings.Add методыг хэрэглэдэг. Жишээ нь DateTimePicker1 функцын хувьд

Me.DateTimePicker1.DataBindings.Add(New Binding(“Value”, Me.dsPerson, “expert_person.birthday”)) ‘failed

Дээр бичигдсэн мөрийг дараах байдлаар нэг параметер нэмж асуудлыг арилгав.

Me.DateTimePicker1.DataBindings.Add(New Binding(“Value”, Me.dsPerson, “expert_person.birthday”, true)) ‘works

Уг нь програм улам сайжран хөгждөг байтал Visual Studio-гийн чанар лав муудаад байх юм. Шинэ боломж нэмэгдэж, томорч мундаг болж байгааг би хэлээгүй. Тухайн хөгжүүлэгч хэрэгслийн кодын чанар муудаад байх шиг санагдав. Уг нь дээрх тохиолдолд ямар (тухайн фунцэд форматлах эсэхийг заагч сайн дурын параметер нэмэгдсэн бололтой юм) нэг сануулга Visual Studio Debugger өгөх ёстой. Эс бөгөөс программист хүн ийм алдааг олно гэдэг үнэхээр цаг идсэн далайд зүү эрхтэй адил асуудал.
Мөн MSSQL Server 2008 Server Management Studio дээр хүснэгтийн дизайн өөрчлөх үед нэг маш сонин утгатай алдаа (тухайн хүснэгтийг устган дахин шинээр үүсгэхэд эрх тань хүрэхгүй байна гэсэн утгатай) алдаа өгч байсан нь серверийн хэрэглэгчийн эрх болон өгөгдлийн сангийн эрхэд асуудал байгаа мэт ойлгогдох нь ямар ч программист хүнд илэрхий. Гэтэл Server Management Studio дээрх тохиргооны асуудал байсныг олох гэж бас хөөрхөн хэдэн минут алдчихав.
Майкрософтод овоо гайгүй програмистууд ажилладаг гэж боддог байсан чинь сүүлийн үед оюутнууд голдуу ажиллуулдаг болсон юм байх даа гэмээр алдаанууд харагдаад байх чинь юу вэ?

Javascript бол миний бичих хамгийн дургүй скрипт хэл. Яагаад гэдгийг нь энэ скрипттэй эсвэл ajax-тай ноцолдож байсан хүмүүс сайн мэдэж байгаа байх. Гэвч хичнээн зугтаасан ч энэ бичих хэрэг гарчих юм даа. Кирилл гар байхгүй тохиолдолд Болор толийн оруулах талбар дээр кириллээр бичдэг боломжтой болгоод өгөөч гэж гадаад, монгол нийлсэн 10 гаруй имэйл ирсэн тул өнөөдөр дор нь хийчье гэж бодоод суутал хөөрхий нэлээн цаг авчихлаа. (www.bolor-toli.com дээр хийгээд суурилуулчихсан байгаа)
Түүчээний байрлалыг textarea дээр авахдаа дараах кодыг нэлээн удаан сууж байж бичив.

field нь document.getElementById -р авсан textarea юмуу Input text объект.
function processCursor() {
if (document.selection) { // IE…
field.focus();
var sel = document.selection.createRange();
sel.collapse();
var selBefore = sel.duplicate();
var selAfter = sel.duplicate();
sel.moveToElementText(field);
selBefore.setEndPoint(‘StartToStart’,sel);
selAfter.setEndPoint(‘EndToEnd’,sel);
startPos = selBefore.text.length;
endPos = field.value.length – selAfter.text.length;
textBefore = selBefore.text;
textAfter = selAfter.text;
} else { //FF, etc… others are not handled
if (field.selectionStart < field.textLength) {
startPos = field.selectionStart;
endPos = field.selectionEnd;
textBefore = field.value.substring(0,startPos);
textAfter = field.value.substring(endPos);
} else {
startPos = field.selectionEnd;
endPos = field.selectionEnd;
textBefore = field.value;
textAfter = '';
}
}
}

дээрх функц нь түүчээний байрлалыг авч доторхи бичвэрийг өмнөх болон ардахаар нь 2 хуваачихаж байгаа юм.
Гэтэл энэ нь IE7 дээр лав input box-ын хувьд ажилладаггүй. Алдаа нь Invalid argument selBefore.setEndPoint(‘StartToStart’,sel); агуулж байгаа мөрөн дээр байлаа. Гэтэл энэ нь байх үндэсгүй ба харин өмнөх мөр болох sel.moveToElementText(field); сэжигтэй санагдлаа. IE угаасаа алдааны мөрийг ихэнхдээ буруу тодорхойлдог муу програм. За ингээд сэжиг маань батлагдаж энэ мөрийг тайлбар болгоод үзтэл ажиллаж байв. Гэвч буруу ажиллах нь тодорхой. Ингээд нэлээн сууж байж дээр функцыг

function processCursor() {
if (document.selection) { // IE…
field.focus();
var sel = document.selection.createRange();
var selLength = document.selection.createRange().text.length;
sel.moveStart (‘character’, -field.value.length);
startPos = sel.text.length- selLength;
endPos = sel.text.length;
textBefore = field.value.substring(0,startPos);
textAfter = field.value.substring(endPos);
} else { //FF, etc…
if (field.selectionStart < field.textLength) {
startPos = field.selectionStart;
endPos = field.selectionEnd;
textBefore = field.value.substring(0,startPos);
textAfter = field.value.substring(endPos);
} else {
startPos = field.selectionEnd;
endPos = field.selectionEnd;
textBefore = field.value;
textAfter = '';
}
}
}

болгон өөрчилж Input text болон textarea 2 хоёулан дээр нь ажилладаг болголоо. Энэ асуудлын талаар Гүүглээр нэлээн хайгаад олоогүй тул блогтоо оруулчихлаа. Хэн нэгэнд хэрэг болж юуны магад.

За өмнө амлаж байсанчлан Системийн тодорхойлолт гаргах талаар ажлын цагаасаа хулгайлаад нэг бүдүүвч гаргая. Энэ талаар нилээн удаан ам хамхичихсан чинь зарим нөхдийг чилээсэн бололтой. Ойрд ажил ихтэй энэ муу блогтоо юм тэмдэглэх зав гардаггүй дээ.
За юуны өмнө тэр “Зорилгын дэвтэр” гэж өмнө би нэрлээд байсан зүйлээ бүгдийг Системийн тодорхойлолт болгоод зассан шүү. Цаашид Үүргийн дэвтэр, Системийн тодорхойлолт гээд явна.
За жишээ болон хэвийг хийж тавих зав байхгүй тул яг ямар загвараар явахыг л жагсаая. Програм хангамжийн төслийн шинжилгээ бичлэгт тодорхойлсон болон Үүргийн дэвтэр хольж нухаад гаргасан болно.

1. Зорилгын тодорхойлолт
   • Зайлшгүй болзол

   • Хүсэлт болзол
   • Хязгаарлалт болзол
2. Бүтээгдэхүүний хэрэглээ
   • Хэрэглээний хүрээ

   • Товлосон хэрэглэгчид
   • Үйл ажиллагааны нөхцөл
3. Дэд системийн зохион байгуулалт (зөвхөн том системүүдийн хувьд)
4. Бүтээгдэхүүний техникийн орчин
   • Програм хангамж

   • Техник хангамж
   • Байгууллага
   • Бүтээгдэхүүний интерфейс
   • Хөгжүүллийн орчин
5. Бүтээгдэхүүний тойм
6. Бизнес процессын загвар (Засвар: 2008 оны 7 сарын 8 нэмэв!)
7. Бүтээгдэхүүний үйл ажиллагаа
8. Бүтээгдэхүүний өгөгдөлүүд
9. Чанарын шаардлагууд
10. Тусгай шаардлагууд
11. Хэрэглэгчийн график гадаргуу
12. Нэмэлт

За ТОЙМ нэг иймэрхүү байдалтай. Жишээ болон хэвийг тэгж байгаад завтай болохоороо хийж үзүүлье. Нэмж засахаар зүйл байгаа санагдвал сэтгэгдэлд үлдээнэ үү.

За сүүлийн 2 сард 4-5 залуус хувийн имэйл хаягаар “програм хангамжийн инженер болохын тулд юу юуг давуу үзэж судлах вэ?” гэсэн асуулт тавьж зөвлөгөө хүсчээ. Ер нь сүүлийн үед сардаа бараг нэг ийм хүсэлт ирж байгаа тул энэ тухай блог дээрээ нэг бичээд тавьчихъя гэж бодлоо. За би өөрийн бодол, өөрийн туршлага, амьдрал дээрээ тулгуурлан бичье. Энэхүү бичлэгийг бичихийнхээ өмнө би ер нь зөвлөгөө өгөх хэмжээнд хүн мөн үү биш үү гэж удтал бодсоны эцэст КТМС-ыг төгсөөд монголд ажиллаж байгаа нэгэн залуугийн надтай ярилцаж байхдаа “их сургуульд сурч байхад, эсвэл ядаж төгсөөд гарах үед эргэлзээгүй чиглүүлээд өгөх хүн алга байна даа” гэж байсан санаанд ороод ямар ч гэсэн өөрийн хэмжээнд байгаа зүйлээ бичье гэж бодлоо.
За эхлээд та бүхэн энэ блогийг эхлэж байхад бичсэн Програм хангамжийн инженер гэж хэн бэ? гэсэн бичлэгийг уншсан байх гэж бодож байна. Үгүй бол эхлээд нэг гүйлгээд харна уу. Юуны өмнө хэн болох гэж байгаагаа мэдэх нь чухал!
Тэнд дурдсан гол санаа нь программист болон програм хангамжийн инженер 2 ялгаатай шүү гэдэг ойлголт. Нэг нь математик талыг барьж хийсвэр загвар гаргаж, програмчлалын код бичдэг бол нөгөөх нь (энэ сэдвийн гол баатар) инженерчлэлийг барьж амьдрал дээр буй бодит зүйлс ба өрнөж буй процесс, үйл ажиллагаа зэргийг загварчлан компьютерт системчлэн оруулдаг гэх үү дээ. Энэ утгаараа програм хангамжийн инженерчлэл нь компьютерын шинжлэх ухааны хамгийн хүнд салбарт ордог шинэхэн салбар. Үнэхээр дэлхий дээрх бодит үйл явц нь нэгэн утгатай бус, янз бүрийн олон талт, бяцханаас эхлээд нүсэр, үргэлжилсэн том ч байдаг тул түүнийг загварчилж компьютерын хэл дээр буулгана гэдэг амаргүй л дээ. Мөн нэг ялгаа нь программист хүн аливаа зүйлийг хурдан хүлээж авч ойлгоод, онолын мэдлэгээ аль болох их ашиглан оновчтой кодчилол, сайн алгоритм бичиж чаддаг байх ёстой бол програм хангамжийн инженер нь түүний хийх зүйлийг системийн нэг хэсэг (implementation) гэж үзээд бүхий л системийн загварыг гаргаж системчлэх болон холбох чадвартай байх ёстой. Үүний тулд та ямар ч программистын бичсэн кодыг хэд гүйлгэж хараад аль болох түргэн ойлгочих чадвартай байхгүй бол горьгүй.
Инженер болон инженерчлэл (уг нь инженерийн шинжлэх ухаан гэхдээ хэрэглэхэд арай л урт байсан юм) гэдэг гадаад үг манай зарим хүнд нилээн учир битүүлэг сонсогддог тул нэг өгүүлбэрээр тайлбарлая.

Инженер нь шинжлэх ухааны онолын хэрэглээн дээр суурилсан бөгөөд амьдрал дээр техникийн мэдлэг болон аргачлалал, туршлагаар батлагдсан, системтэй мэдлэгээр тодорхойлогдох мэргэжил юм.

Инженерчлэл нь хэрэглээнд хандан, амьдралд хэрэгжүүлэхээр судалж шинжилсэн, байгалийн шинжлэх ухааны мэдлэгийг ашиглан техникийн судалгаа болон хөгжүүлэл эсвэл байгууламж болон үйлдвэрлэлийн аргачлалыг хийдэг шинжлэх ухаан юм.

Програм хангамжийн инженер хүний авьяас нь загварчлах бол, хамгийн сайн барих ёстой зүйл нь маш системтэй (цэгцтэй), зарчимч журамтай байх явдал.
Нэгэнт хэрэглээний талын ухаан тул та өөрийн гэсэн арга барилыг ихэвчлэн туршлагаараа өөрөө олж авдаг.
За оршил дууслаа. Гарчигт өгсөн гол сэдэвтээ оръё.
Хэрэв та програм хангамжийн инженер болох гэж байгаа бол юуны өмнө

1. Addison-Wesley -с гаргасан ном бол ядаж шагайгаад гараараа имрээд харчихад ер нь илүүдэггүй. Хамаа замбараагүй ялангуяа америк номууд унших хэрэггүй.
   Жинхэнэ шинжлэх ухааны, сайхан эмх цэгцтэй бичигдсэн ном л унших хэрэгтэй. Англи хэл дээр бол
   1. I. Sommerville: Software-Engineering, Addison-Wesley
   2. C. Ghezzi, M. Jazayeri, D. Mandrioli: Fundamentals of Software Engineering, Prentice Hall
   3. Ian Bray. An Introduction to Requirements Engineering, Addison-Wesley
   4. Roger S. Pressman. Software Engineering: a beginner’s guide, McGraw Hill New York, (эхлэгчдэд дажгүй)
   Герман хэл дээр бол
   1. M. Nagl: Softwaretechnik: Methodisches Programmieren im Großen, Springer
   2. H. Balzert: Lehrbuch der Software-Technik 1, 2 Spektrum Akadem. Verlag
   Харамсалтай нь монгол хэл дээр зөвлөчих ном мэдэхгүй юм. Зав зай маань хүрдэг бол нэг сайн ном бичих (муу болчихвол гаргаж хүн хорлох хэрэггүй) мөрөөдөл төдий зүйл надад байдаг боловч бараг л амжихгүй биз ээ.
2. Янз бүрийн сайн дурын төслүүдэд оролцох. http://sourceforge.net дээр олон мянган төсөл бий. Хэлний бэрхшээлтэй байвал ОпенМН янз бүрийн олон төсөл эхлүүлсэн боловч хүн хүч дутаад байж л байгаа.
   Энэ бол бараг зөвхөн манай мэргэжлийнхэнд л олддог алт шиг сайхан боломж! Хамгийн сайн арга гэж би боддог! GNU, FSF, Unix/Linux, GPL, BSD, Berkeley болон Massachusetts институтууд, SUN, Novell, IBM -д БАЯРЛАЛАА.
3. Янз бүрийн технологи, програмчлал руу хошууран яаран дайрах хэрэггүй. Мэдээж таны өргөн тархаж хурдан хөгжиж байгаа технологиудыг харах, судлах хэрэгтэй. Гэхдээ эхлээд яагаад энэ амжилт олоод байгааг нь эргэцүүлэн бодож харьцуулах хэрэгтэй. Walther Rathenau -н хэлсэн “БОДОХ ГЭДЭГ БОЛ ХАРЬЦУУЛАХ ЮМ” гэдэг үнэн шүү!
   Аливаа технологи бүр өөрийн гэсэн сайн талтай боловч түүнээ дагаад заавал сул тал байдаг.
   Хөгжлийн араас бүү гүй!
   Та өөрөө л эхлүүлээгүй бол гүйцэхгүй.
   Харин ажиглаж байгаад товчилж алх!
   Өөрөө сэтгэсэн тул гүйцэгдэхгүй.
4. Амьдралд тааралдаж байгаа зүйлс үйл явдлыг яаж загварчилж болохыг нь дотроо хаяа ядаж бодож байх хэрэгтэй. Амархан зүйлс ч бас их байдаг тул ядаж урам орно.
5. Хэрэв ямар зүйл сурах гэж байгаа бол төсөлд оролцохдоо заавал менежерийн дүрд тоглох хэрэггүй. Харин сайн менежертэй төслийн туслахаар юм уу ажиглагчаар ороод үзэхэд их зүйл сураад авна.

Дээрх зүйлс нь арга барилаа олж авахад тань туслах болов уу. Ямар ч мэргэжилийнх байсан ялгаагүй аливаа хүн ажлын багаж хэрэгсэлгүй бол хөдөлмөрийн бүтээмж яаж олигтой байх билээ. Програм хангамжийн инженерийг дараах зүйлсгүйгээр төсөөлөх аргагүй. Хэрэв тэдгээрийн ядаж нэгийг нь гаргуун эзэмшиж чадаагүй бол програм хангамжийн инженер биш гээд хэлчихэд буруудахгүй болов уу.

• Объект хандалтат технологийн хувь UML -гүйгээр төсөөлөх аргагүй. Хамгийн сайн мэддэг, чаддаг байх ёстой зүйл тань энэ. Барилгын инженерийн техникийн зураг зүйтэй л төстэй. Төстэй гэдгийн учир нь зөвхөн физик объект загварчлах бус процесс үйл ажиллагааг нэмж загварчлах ёстой. Барилгын инженер хүн хөдөлгөөнгүй физик объектуудыг загварчилдаг бол програм хангамжийн инженер хүн ихэвчлэн процесс үйл явцийг хөдөлгөөнгүй объекттой холбон загварчилдаг. Харин объект хандалтат бус технологийн хувьд SA (structured analysis) DFD, ERD зэргийг багтаагаад шүү эзэмших хэрэгтэй.
  UML загварчлалын хэрэгслүүд болох ArgoUML, Fujaba, Poseidon, MagicDraw, Objecteering зэргийн аль нэгийг сайн эзэмших. Онцлох нь үнэгүйгээс Fujaba, үнэтэйгээс Poseidon.
• Юу болохыг нь нарийн мэдэхгүй байж болохгүй хэдэн түлхүүр үгс бичье. Prototyping, Design pattern, MDA, FMC, RDBMS, ODBMS, OO, Agile
  за нилээн олон л байх ёстой. Яг одоо толгойд илүү орж ирсэнгүй.
• Өгөгдлийн баазын ерөнхий загварчлал хийж сурах. Oracle, SAPDB, MSSQL, MYSQL, PostgreSQL гээд юу байх нь хамаагүй.
• Та сайн инженер байя гэж бодож байвал олон талт байх хэрэгтэй. Та eclipse, .NET platform-ууд, CVS, SVN -г гарын хуруу шигээ ашиглаж чаддаг болох хэрэгтэй.

Ер нь програм хангамжийн инженер хүний хийдэг ажил нь ихэвчлэн Програм хангамжийн инженер гэж хэн бэ? бичлэгт байгаа диаграмын дагуу явдаг ба эхний үе шатанд асуудлын анализ хийж зорилгоо аль болох бүрэн тодорхой тогтоож чаддаг болох. (Энэ тал дээр би өөрийгөө сул гэж боддог) Үүний тулд та RE буюу Requirements Engineering -г судлах хэрэгтэй.
хоёрдугаар үё шатанд програм хангамжийн архитектур загвар гаргах хэрэгтэй болдог. (энэ дээр өөрийгөө муугүй гэж боддог) Архитектур гаргахдаа та ихэвчлэн дээр дурдсан UML, SA, DB designer ашиглан үндсэн загвар гаргах ба зөвхөн програм хангамжийн загвар бус яаж цааш арчлах концепт, хөгжүүлэх стратегийг гаргах ёстой. Жишээлбэл Control of version, Variant, Configuration management (SVN, CVS хэрэглэгдэнэ. Eclipse-ийн хувьд би дээр нэг Eclipse SVN тэй ажиллах гээд нэг яаж суулгах тухай маш товч юм бичсэн.
Төслийн удирдагчтайгаа ярьж нэг нэгнээ сайн ойлгож авч нэгдсэн нэг ойлголттой болсон байх ёстой. Кодын стандартаа тогтоох хэрэгтэй. Архитектурын загвар тухайн системийн онцлог ч юумуу, хүнд хөнгөнөөс шалтгаалан яаж ч гарч болох ба уламжилалт (SA), Object Oriented (UML) эсвэл Modular (Programming in the Large) гээд янз бүр байж болно. Аль алинаар нь хийх чадвартай болох хэрэгтэй.
Гуравдугаар үе шатанд та ямар ч програмчлалын хэлээр сайхан код бичдэг байх шаардлага гарна. Программ хангамжийн инженер сайн програмист байх хэрэгтэй.
Дөрөвдүгээр шатанд маш сайн багаар ажиллах чадвартай байх хэрэгтэй бөгөөд бусдынхаа хийж байгаа зүйлсийг нь ядаж багцаалдаж чаддаг байх. Холболт хийхэд асар хэрэгтэй.
Тавдугаар үе шатанд сайн тестлэгч байх хэрэгтэй ба Blackbox, Whitebox, Graybox concept-уудыг ядаж эзэмшсэн байх хэрэгтэй. Энэ тухай интернет багшаас л мэдээд авчихна бизээ.
Зургаа буюу сүүлийн шат таны архитектур хэр гаргасанаас шалгаална даа. Арай ахин шинэ загвар гаргахдаа тулахгүй л байх хэрэгтэй.
За шөнийн 3 өнгөрчихлөө. Нойр хүрээд энэ бичлэгийг сүүлдээ дуусгахын түүс болоод сүүлийн хэдийг нь ч баахан формалдчихав уу даа. Ойлгоно буй за. Юу судлах хийх талаараа жаахан ч гэсэн чиг авсан гэж найдъя.

Бадаа

Өнөөдөр өдрийн цайны цагаараа Монгол википедиа дээрээ ганц бичлэг нэмэрлэв. Програм хангамжийн инженерчлэл хуудас хоосон байсныг нөхөв. Цаашид зав чөлөөндөө баяжуулаад байхыг хичээе.
Та бүхнийг ч мөн зав чөлөөндөө монгол википедиагаа ганц ч болсон бичлэгээр баяжуулж байхыг урайлж байна.

Төслийн удирдлага чухал гэдгийг хэн бүхэн ярьдаг, мэддэг гэхэд хилсдэхгүй бизээ. Харин ямар концептоор яаж хэрэгжүүлэх арга барилын тухай бид бага ярьдаг юм шиг санагдлаа. Янз бүрийн төслийн удирдлагын програмууд ч олон янзаар зохиогдсон байдаг. Амьдрал дээр жирийн бидний ихээхэн хэрэглэдэг програм бол MS Project байдаг. Харин энэ програм линукс дээр байдаггүй билээ. Гэтэл би виндовсыг гэртээ нилээн эртнээс огт хэрэглэхээ больсон байдаг. Ингээд ертөнцөөр (интернэтээр) дэмий тэнэж яваад MS Project ийг орлож чадах OpenProj төслийг олсон юм.
Энэ нь MS project төслүүдийг оруулж ирж чадахаас гадна MS Project 2003 (XML) форматаар хадгалж болж байна лээ. Энэ програм нь Жава хэл дээр бичигдсэн тул бүх үйдлийн системүүд дээр чөлөөтэй ажиллана.
Эхний удаагийн шалгалтаар энэ програм нилээн их таалагдлаа. MS Project ийг функцын хүрээг гүйцэхгүй боловч, цэвэрхэн, эмх цэгцтэй юм. Үндсэн бүх функцүүд эмх цэгцтэй байхад, бараг хэрэглэгдээд байдаггүй баахан новш холилдсон байхаас дээр дээ. Тийм л бараг хэрэггүй зүйлс нь байхгүй байна лээ. Хамгийн их таалагдсан зүйл нь нөөцийн даац хуваарилалтын автомат харуулалт, бүтцийн төлөвлөлтийн схем байлаа.
Ямар ч гэсэн жижиг болон дунд хэмжээний төслүүд дээр бүрэн хүрэлцээтэй програм санагдлаа. Та бүхэн ч бас үүнийг өөрийн хэрэглэдэг програм болгоод авчихвал зүгээр байх гэж бодов. Энэхүү үнэгүй, нээлттэй эх бүхий програмыг эндээс татаж аваарай.

Та програм хангамжийн инженерчилэлийн шинжлэх ухаанд “Mongolian Horde Concept” гэж байдгийг мэдэх үү? Хэрэв үгүй бол цааш уншаарай.
Програм хангамжийн инженерчилэлийн үе шатуудаас хамгийн хялбар нь програмчилах, хамгийн төвөгтэй нь төлөвлөлт байдаг билээ. Тиймээс програм хангамжийн инженерчилэлийн тулах/туслах нэгэн чухал процесс болох төслийн удирдлага ба төлөлөвлөгөөний талаар маш товч дурдая. Энэ нь тухайн төслийн зардлыг үндсэнд нь тодорхойлж өгдөг тул хамгийн чухалд тооцогддог. Төслийн зардал тооцох тухай би ноднин монголд програм хангамжийн инженерчлэл лекц уншиж байхдаа цухас дурдаж байсан. Boem-ын тэгштгэлийг санана уу.
Z = aP^m
Z – Зардал
a – Тогтмол фактор
P – Бүтээгдэхүүний хэмжээ
m – Экспонент [1.05 – 1.2]
Энэхүү тэгштгэл дээр холболтын зардлын тухай яригддаг. 2 хүний хувьд 1 (хэрчимийг санана уу), 3 хүний хувьд 3 (гурвалжинг санана уу), 4 хүний хувьд 6, n хүний хувьд n(n − 1) / 2 гэх мэтээр хурдтай өсөж байна. Олон хөгжүүлэгч бүхий том төслийн хувьд түүнийг зохион байгуулах зардал ямар хурдтай өсөж байгааг та харж байна.
Үүнээс улбаалан IBM -н OS/360 (Operating System/360) төслийн ахлагч Brooks “Adding manpower to a late software project makes it later” (Програм хангамжийн төсөлд хүний хүч хожуу оруулбал түүнийг дуусгах хугацааг удаашруулна) гэж тодорхойлсон байдгийг түүний The Mythical Man Month гэсэн номноос олж болно. Энэ нь төслийн удирдагч эсвэл програм хангамжийн инженерүүдийн заавал уншсан байвал зохих сайн номны нэг болов уу. Түүний үндсэн санаа нь тун ойлгомжтой. Шинэ хүн ялангуяа хөгжүүлэх үйл явцын сүүлийн шатуудад орж ирэхэд түүнд хэлж ойлгуулах, заах зардал хуучин гишүүдийн боломжтой чадварлаг хөгжүүлэгчидэд өгөөд хийлгэчих зардлаас илүү гардаг гэдгийг л харуулсан явдал.
Тиймээс цөөхөн бөгөөд чадварлаг хөгжүүлэгчидтэй баг нь олон чадвар муутай хөгжүүлэгчтэй багаас хавьгүй илүү. Сайн програмист нь жирийн програмистаас 5-10 дахин үр бүтээмжтэй байдгийг Броукс мөн онцолсон байдаг. Монголчууд яагаад тийм цөөхүүлээ байгаад дэлхийг эзэлж чадсан билээ? Чингис хааны арга ухаан чадварлаг удирдлагын ачаар л тэгж чадсан. Тэр чадварлаг удирдлага нь юу байв? Түүний 10 -тын систем гэчихвэл буруудахгүй биз.
Броуксын дэвшүүлсэн санаа нь их эзэн Чингис хааны маань энэхүү агуу системийн санаа байсан тул ингэж нэрлэгдсэн юм болов уу. Програмистууд хамгийн анхны зохиогчийг хэзээ ч мартдаггүйн нэг жишээ энэ буюу.
Програм хангамжийн төслийн багийг бүрдүүлэхдээ тухайн төслийн хэмжээнээс хамааруулан төслийн багаа бүрдүүлэх хэрэгтэй ба энэ заавал 10-т биш 5-т, 8-т гээд хувааж ч болно. Ингээд хэсгүүдийн ахлагчаар заавал нэг хүн томилох хэрэгтэй. (crux = гол бай) Тэр хүн тухайн даалгаварыг ерөнхийд нь бүрэн мэдэж байх хэрэгтэй бөгөөд доороо байгаа гишүүддээ хувааж өгч хийлгээд өөрөө холбох ёстой. Түүний дараа хэсгийн ахлагчууд нийлж нийт програм хангамжийг холбож босгож ирнэ.
Ямар нэг хэсгийн ахлагч байхгүй юмуу чадвар сул бол төсөл босч ирэхэд их хүндрэлтэй эсвэл бүр босч ирж ч чадахгүй нурна гэсэн үг. Тест болон чанар шалгалтын багийг маш чадварлаг хөгжүүлэгчидээр бүрдүүлэх нь бүтээгдэхүүний чанарыг өндөрт өргөнө.
Чингисийн үр сад бид түүний босгосон системийг хамгийн сайн хэрэглэж, сайжруулж чадах учиртай бөгөөд үүнийг бид өөрсдийн салбартаа хэрэглэж чадсан хойно програмчилалаар дэлхийг байлдан дагуулнаа гэсэн үг бусуу…

Өмнө Үүргийн дэвтэр гээч зүйл хийж байхдаа би системийн тодорхойлолт (Зорилгын дэвтэр байсныг солив) гээч зүйл хийх тухай дурдсан. Одоогоор өөрийнхөө төслийнхийг хийж дуусаагүй л байгаа.
Өнөөдөр ганц нэг стандарт харж суугаад өмнө дурьдаж байсан Шаардлагын тодорхойлолтод хамаатай нэгэн зүйлийг зайлшгүй тэмдэглэх нь зүйтэй мэт санагдлаа.
Германы DIN 69 905 стандартад “Үүргийн дэвтэр” англиар Requirements specification гэж аваад даалгавар олгогчийн даалгавар хүлээн авагчид тавьсан шаардлагуудыг тодорхойлсон байна гэжээ. Юу хийхэв юунд хүрэхийг тодорхойлно гэсэн үг. Харин “Системийн тодорхойлолт”-ийг англиар System specification гэж аваад бүтээгдэхүүний хэрэгжүүлэлт болон хүчин чадлыг даалгавар хүлээн авагчийн зүгээс тодорхойлон бичнэ гэжээ. Яаж хэрэгжүүлэх вэ гэдгийг тодорхойлно гэсэн үг.
Гэтэл энэ нь Sommerville -ын (түүний Software Engineering гэж маш сайн ном байдаг) тодорхойлсон “Системийн тодорхойлолт” нь загварын баримт биш ба аль болох ЯАЖ хийхийг биш систем ЮУ хийхийг тогтоох хэрэгтэй гэсэн байдагтай жаахан зөрчилдөөд байх шиг. Хий гаргадаггүй аричууд стандарт дээрээ алдаагүй л байлгүй дээ.
Нэг хэрэгтэй гэмээр зүйлийг Rombach тэмдэглэсэн байдаг. Системийн тодорхойлолтын хамгийн чухал зүйл нь 4 С гээд: Clarity, Completeness, Consistency, Correctness гэж тодорхойлсон байдаг.
Германы DIN 66901 нормоор Үүргийн дэвтэрийг
1. Зорилгын тодорхойлолт
1.1 Зайлшгүй – Болзол
1.2 Хүсэлт – Болзол
1.3 Хязгаарлалт Болзол
2. Бүтээгдхүүний хэрэглээ
2.1 Хэрэглээний хүрээ
2.2 Хэрэглэх бүлгүүд
2.3 Хөдөлгөх нөхцлүүд
3. Бүтээгдхүүний нөхцлүүд
3.1 Програм хангамж
3.2 Техник хангамж
3.3 Байгууллага
3.4 Бүтээгдэхүүний интерфейсүүд
4. Бүтээгдхүүний функц
5. Бүтээгдхүүний хүчин чадал
6. Хэрэглэгчийн интерфейс
7. Чанарын тодорхойлолт
8. Глобал тестүүд
9. Нөхөлтүүд
гэж тодорхойлжээ.
Програм хангамжийн инженерчилэлд Үүргийн дэвтэр ба Системийн тодорхойлолт харилцан эргэх холбоотой байна гэж үздэг, заадаг, тодорхойлдог.
Аричууд Нэр томъёо (Terminology) гэдэг маш чухал гээд Anforderungserhebung – RE, Anforderungsanalyse – RA, Anforderungsmanagement -RM, Anforderungsspezification – RS гэх мэтээр авч явъя гэж тогтоод үүнийгээ хэрэглэж ярьдаг. Бидэнд ч бас энэ чухал.
За яагаад би ийм утга учиргүй баахан юм холиод бичээд байгаад та гайхаж байгаа байх.
Би эдгээрээс санаа авч байгаад монгол хэл дээрээ өөрсдийн баримтлаж явах Системийн тодорхойлолтыг л зохиочих санаатай ингэж мунгинав. Бид эртхэн дээр нь нэг стандарт маягтай хэрэглэчихдэг баримттай байвал ирээдүй хойчид хэрэгтэй болов уу.
Дээрх буруу, зөв янз бүрийн тодорхойлолтуудаас миний хамгийн үнэн бөгөөд зөв гэж үзэж байгаа нь Үүргийн дэвтэр ба Системийн тодорхойлолт эргэх холбоотой гэсэн тодорхойлолт.
Тиймээс энийг сууриа болгож авъя. Өмнө гаргасан Үүргийн дэвтэрээ барих эсвэл түүнийг өөрчилөх гэсэн замаар Системийн тодорхойлолт тодорхойлогдох боллоо.
DIN 66901 стандартыг харж байхад миний өмнө хийсэн Үүргийн дэвтэрээс илүү гарах зүйл байхгүй байна. Харин энд авууштай нь өмнө миний үүргийн дэвтэрт бүтээгдхүүний шинж чанар дотор тодорхойлсон Систем ба системийн орчин гэсэн дэд бүлгийг тусад нь бүлэг болгож авсан байна.
Энэ нь сэтгэл зүйн талаасаа зүгээр санагдлаа. Учир нь систем болон системийн орчинг системийн үйл ажиллагаа болон өгөгдлийг тодорхойлохоос өмнө тодорхойлох гээд дайрчихдаг. Тиймээс үүргийн дэвтэрт үүнийгээ өөрчилж болох юм. Гэхдээ бас функцүүдийг тодорхойлж байхад түүнээс хамааран өөр орчин гарч ирэх үе ч байдаг. Бусдаар бол Системийн тодорхойлолт Үүргийн дэвтэртэйгээ дүйцүүлэн гаргая.
Нэр томъёоны хувьд
Anforderung (de) – Requirement (en) гэдгийг Шаардлага гэж авъя.
Тэгэхээр шаардлагын анализ, менежмент гэх мэтээр явна гэсэн үг. Энд харин тодруулах шаардлагатай зүйл бол Specification гэсэн үг. Энийг зарим үед тодорхойлолт, зарим үед загварчилалын баримт гэсэн утгаар авдаг. Бидний мэргэжлийн хувьд ихэнхдээ загварчилал гэдгээр нь авч явах нь зүйтэй. Specify гэхээрээ тодорхойлох гэхээсээ илүү загварчилах гэж авбал зөв гэсэн үг. Нөгөө миний харьцуулах дуртай барилгын архитектурчтай харьцуулбал Specification гэдэг нөгөө л скиз, техникийн зураг зүй нь шүү дээ. Тэд техникийн зураг зүйнхээ дагуу зурдаг бол бид UML -р зурдаг л гэсэн үг.
За та бүхнийг чилээж эхлэх шиг байна. Хариуд нь нэг зураг тавъя. Төсөл доторх холбоог Dr. Karsten Hoffmann дараах байдлаар үзүүлсэнийг хавсрагалаа. Сайн шинжлэхгүй бол ч . . .

Сүүлийн үед CVS -с SVN рүү ихэнх төслүүд нүүх болов. Албан бус боловч яалт ч үгүй SVN нь CVS-ыг залгамжилан, түүнийг түрж гарч ирж байгааг хөгжүүлэгчид бид харж байна. Өнгөрсөн жил ОпенМН багийнхаа CVS ыг ч би SVN рүү шилжүүлж орхисон билээ.
CVS нь Eclipse дээр стандартаар хамт суучихсан байдаг тул CVS проектуудыг шууд үүсгээд хэрэглэхэд амар байдаг. Харин SVN-ийг хэрэглэхийн тулд та Subclipse суулгах хэрэгтэй болно. Энэ нь Eclipse-н нэг плагин юм. Нэг хэсэг shell дээр гараараа SVN checkout хийж явдаг байгаад залхуу хүрээд Eclipse CVS шиг амар боломж хайсаар Subclipse -г олсон юм.
Суулгахад плагин яаж суулгадаг билээ тэр зарчимаар маш амархан суулгана. Help -> Software Updates -> Find and Install гэж ороод Search for new features to install гэдгийг сонгоно. Тэндээ new Remote Site гэдэг товчийг дараад гарч ирсэн цонхонд Subclipse гэсэн гарчиг өгөөд http://subclipse.tigris.org/update хаягийг оруулна. Ингээд суулгах процесс автоматаар үргэлжлэх ба эцэст нь Eclipse шинээр эхлүүлэхийг асууна. Түүнийг зөвшөөрч эхлүүлсэнээр суух процесс дуусна. Суулгах явцад асуудал гарвал http://subclipse.tigris.org/install.html хаягаас дэлгэрүүлэн харж болно.
Харин яаж хэрэглэхийг одоо дурдая.
Window->Show View -р ороод Other гэдгийг сонгоно. Дараах цонх гарч ирэх ба SVN Repository -г сонгон нээнэ.
Үүний дараа гарч ирэх цонхонд баруун товшилт хийгээд дараах зургийн дагуу SVN repository зааж өгнө.
Жишээлбэл https://mngl.net/openmn/gnome/ гээд өгчихөж болно. Энд ОпенМНыхэний хийсэн Гномын монгол орчуулгын сүүлийн хувилбар байгаа. Энэ холбоосын тохиргоог цаашид хийхдээ Window -> Preferences-> Team -> SVN рүү ороод хийнэ.
Шинэ проект SVN-с авч үүсгэх хэрэгтэй болбол одоо File -> New -> Project гээд ороход дараах байдлаар нэмэгдсэн байх болно.

Repository-тойгоо ажиллах болбол оруулж ирсэн тухайн төслийнхөө нэрэн дээр баруун товшилт хийгээд Team рүү орж, доорхи зурган дээр харагдаж байгаагийн дагуу ажиллана. Яг л CVS -тэй ажиллаж байгаатай ижил.

ОпенМН -ы вэб хуудсан дээр Commit, Checkout гэх мэт Repository-тай ажилладаг үйлдлүүдийн тухай дэлгэрэнгүй тайлбарласан байгаа.
Нуршаад байлгүй тодорхой бичихийг оролдов.

Програм хангамжийн инженерчилэлийн эхний үе шат болох асуудлын анализын эхэнд (төлөвлөлт хийх үед) “Үүргийн дэвтэр” болон “Системийн тодорхойлолт” бэлтгэх хэрэгтэйг өмнө дурьдсан билээ. Энэ үүргийн дэвтэр нь

• Зорилгын тодорхойлолт
• Бүтээгдэхүүний хэрэглээ
• Бүтээгдэхүүний үйл ажиллагаа (functional requirement)
• Бүтээгдэхүүний өгөгдөлүүд
• Бүтээгдэхүүний шинж чанар
• Чанарын шаардлагууд
• Нэмэлт

гэсэн 7 хэсгээс тогтоно.

Зорилгын тодорхойлолт

Энэ хэсэгт үндсэн даалгаварыг тодорхойлон бичнэ. Үүнийг ихэнх тохиолдолд даалгавар олгогч бэлтгэчихсэн байдаг тул хуулаад тавихад хангалттай.
Энэ хэсэгт та өөрийн зүгээс системд хэн хэн оролцохыг тодорхойлчих хэрэгтэй. Хэн
хэн энэ системийг хэрэглэх юм? Тэд хэр зэрэг туршлагатай вэ? гэх мэт.
Энэ хэсэгт “Энэ програм хангамжийг хэрэглэсэнээр ямар зорилгод хүрэх ёстой вэ?” гэсэн асуулт хариулагдсан байх ёстой.

Бүтээгдэхүүний хэрэглээнд

Энэ хэсэгт хөгжүүлэх системийн хэрэглээний хүрээ хязгаарыг тодорхойлох хэрэгтэй
байдаг. Тухайн газрын мэргэжилийн ухагдахуунуудыг оруулан ихэнх тохиолдолд зураг
оруулж ирж дүрсэлбэл зохимжтой харагддаг. Байгууллагын бизнес процессийг
тодорхойлон хаана төслын ямар хэсэг тохирохыг тоочих хэрэгтэй.
Энэ хэсэгт “Энэ програм хангамж ямар хэрэглээний хүрээ болон хэнд зориулагдсан бэ?” гэсэн асуулт хариулагдсан байх ёстой.

Бүтээгдэхүүний үйл ажиллагаа

Энэ хэсэгт хөгжүүлэх системийн үндсэн функц, үйл ажиллагааг нарийвчилан
тодорхойлох хэрэгтэй. Функционал шаардлага гэж англи литературууд дээр
тэмдэглэсэн байгаа. Энэ хэсэгт ерөнхий Use Case диаграмыг оруулж ирж болно.
Мөн нээлттэй, бүрхэг асуултуудыг энд оруулах хэрэгтэй бөгөөд эцсийн хувилбар
дээр хоосон байх хэрэгтэй. Харин завсарын хувилбарууд дээр маш их утга учиртай,
хэрэгтэй байдаг.
Энэ хэсэгт “Бүтээгдэхүүний үндсэн функц үйл ажиллагаа даалгавар өгөгчийн зүгээс юу юу
вэ?” гэсэн асуулт хариулагдсан байх ёстой.

Бүтээгдэхүүний өгөгдөлүүд

Энд програм хангамжийн ажиллах үндсэн өгөгдөлүүд оруулж ирнэ. Хэв файлыг харна уу!
Энэ хэсэгт “Бүтээгдэхүүний үндсэн өгөгдөлүүд даалгавар өгөгчийн зүгээс юу юу вэ?” гэсэн асуулт хариулагдсан байх ёстой.

Бүтээгдэхүүний шинж чанар

Энэ хэсэгт хөгжүүлэх системийн өмнөх хэсэгт заагдсан үйл ажиллагаанд хамаараагүй
шинж чанаруудыг оруулна. Үүнд бүтээгдэхүүний хэрэглэгдэх системийн орчин болон
функционал бус шаардлагууд орно. Энэ хэсэг хэдийчинээ тодорхой байна бүтээгдэхүүнийг тестлэх орчинг бүрдүүлэхэд төдийчинээ сайн байдаг.
Энэ хэсэг “Бүтээгдэхүүний бусад шинж чанарууд юу вэ? Ямар нэг функц дээр хугацаа, өгөгдөл, нарийвчилалаас хамааран онцгой зүйлс шаардагдах уу?” гэсэн асуултанд хариулт өгсөн байх ёстой.
Хэв файлд жишээ бий.

Чанарын шаардлагууд

Тухайн даалгавар өгөгч ямар ямар эрсдэлийг хүлээж авах чадвараас хамааруулан тодорхойлно. (Найдвартай байдал, бат бэх, хэрэглэгчид таатай орчин, үр ашигтай байдал,…)
Энэ хэсэгт “Ямар ямар чанарын шаардлагуудыг ямар төвшинд хангах ёстой вэ?” гэсэн асуулт хариулагдсан байх ёстой.

Нэмэлт

Өөр ямар онцгой шаардлагууд байна вэ? Та юу ажиглав. Бүгдийг нь энд тэмдэглэх хэрэгтэй.

Үүргийн (Зорилгын биш шүү! андуураад бичсэн байснаа заслаа) дэвтрийн Латекс эхийг эндээс татаж аваад өөртөө хэрэглэж болно.
Виндовс дээр MikTex ашиглан хөрвүүлсэн PDF энд бий.
Убунту дээр texlive ашиглан хөрвүүлсэн хувилбар PDF энд бий.
За нилээн яаруу бичсэн тул алдаа мадагтай зүйлс орсон байж болох юм. Санал сэтгэгдэлээ хэлнэ буй за. Удахгүй Системийн тодорхойлолтоо бэлтгэж дуусаад иймэрхүү нэг юм мутарлая. Би өөрийн зүйлсээ герман хэл дээр хийгээд монгол хэл рүү хөрвүүлж тавьж байгаа тул зав чөлөөнөөс шалтгаалж жаахан удаж байгааг болгооно уу.