Системийн инженер гэж хэн бэ?

No one lives long enough to learn everything they need to
learn starting from scratch. To be successful, we absolutely,
positively have to find people who have already paid
the price to learn the things that we need to learn
to achieve our goals.

Brian Tracy

Буга хөөсөн хүн туулай анзаардаггүй.

өмнөх

гуравдугаар хэсэг

Нэгэн удаа хэсэг эрдэмтэд анх удаа тугалласан үнээнээс тугалыг нь харууллалгүйгээр авч яван цааш нь юу болохыг ажиглах тун өвөрмөц туршилт явуулжээ. Хэд хоног өнгөрсний дараа эх нь тугалаа санагалзан ихэд гиеүүрсэн байдалтай байхыг ажаад сүрлээр чихмэл тугал үйлдэн өмнө нь авчирч тавихад эх үнээ ихэд баярлан тугалаа долоон хайр энэрлээ харамгүй үзүүлжээ. Гэнэт гай газар дороос гэгчээр чихмэл тугалын оёдол хэсэг газраараа ханзран дотроос нь сүрэл гарч ирэх нь тэр. Үнээ хэсэг зуур зогтусан сүрлийг амтархан зажилснаа удалгүй бүхэл бүтэн тугалыг залгиж орхисон байна. Ингээд түүний хувьд тугал, улмаар эхийн хайр гэдэг зүйл байхгүй болжээ. Энэ бол маш сургамжтай түүх. Мэдээж, олон хүний хувьд энэ бол элэг хөшөөм хөгжилтэй явдал. Сүрэл, тугал хоёрыг ялгахгүй холион бантан хутгаж буй үхэр бол яах аргагүй тэнэг, харалган, сохор амьтан. Өөрсдийгөө үхэр хэмээн төсөөлөөд ийм үхрээс ямар авир гарч болохыг цааш ургуулан бодъё. Хамгийн наад зах нь тугал бол сүрэл хэмээн бат итгэсэн үхрийн хувьд тугалыг арчлан хамгаалах, сүүгээр тэжээх, бэлчээрт гаргах, цагаар хариулах тухай яриад ямар ч нэмэр байхгүй. Надад цаг бага байна, наад тэнэг яриагаа даруй зогсоож чанартай, амтлаг, тэжээллэг тугал хэрхэн гаргах талаар наад толгойгоо ажиллуул, юун яасан сүү, ямар юмны чинь бэлчээр вэ, ямар ч хамаагүй асуудлыг тугалтай битгий холбож яриад асуудлыг хүндрүүлээд бай, бүх зүйл тодорхой байна, энд ямар ч хэцүү юм алга, олон юм бодолгүй явж ажлаа үргэлжлүүл хэмээн ихэнхи үхэр хариулна. Харамсалтай нь энэ бол зүгээр нэг үлгэр биш, ихэнхи хүмүүс программын систем бүтээх ажлыг яг ингэж ойлгодогт хамаг хэрэг оршино. Бүр тодруулбал, захиалагч тал аливаа асуудлыг зөвхөн өөрийн өнцгөөс харж, бүхнийг заавал өөрийнхөөрөө хийлгэх гэж зүтгэснээр системийг тал, талаас нь сэглэн сийчэж эцэст нь юу ч биш болгон үгүй хийж залгидаг. Өдгөө дэлхий дээр хийгдэж буй бүх программын системийн 70 хувь нь хорвоогийн нар үзэлгүй нүд анидаг гэсэн гашуун мэдээ байдаг нь нэг талаасаа захиалагчийн буруу мэт боловч нөгөө талаасаа гүйцэтгэгч талын буруу бас бий.

Захиалагч бол хаан, хэрэглэгч бол эзэн гэсэн хорвоогийн хамгийн тэнэг үг байдаг. Магадгүй, ингэж хэлэхэд олон хүн гайхна. Гэхдээ л энэ бол үнэн, тэр тусмаа программын систем бүтээх ажлын хувьд бол туйлын үнэн үг. Ихэнхи компаниуд захиалагчтай гэрээ, хэлцэл хийн төсөл батлуулахдаа хамгийн бага хугацаанд хамгийн чанартай бүтээгдэхүүн хийнэ хэмээн ёс мэт амалдаг. Хэрвээ нээлттэй тендер зарлаад төсөл хэрэгжүүлэхээр саналаа өгсөн компаниудын танилцуулгыг гүйлгэж харвал сэжигтэй компани ганц ч илрэхгүй гэдэгт мөрийцөхөд ч бэлэн байна. Бүгд л өөрсдийгөө танилцуулахдаа ажлын арвин туршлагатай, ямар нэгэн гаж буруу зүйл хийж байгаагүй, хийсэн төсөл нь цаг ямагт амжилттай өндөрлөж байсан гэх мэтчилэнгээр өөрсдийгөө тэнгэрийн элч болгон дүрсэлдэг. Захиалагч тал иймэрхүү танилцуулгыг хараад бүх зүйл сайн сайхан, ямар ч саад бэрхшээл алга, ерөөс хамгийн бага зардлаар хамгийн сайн программ бүтээлгэх нь хамгийн оновчтой шийдэл мөн гэдэг өөдрөг үзлээр асуудалд ханддаг. Товчоор хэлэхэд, захиалагч тал өөрийгөө хаан хэмээн сэтгэж үүлгүй, цэлмэг тэнгэрт нисэж эхэлдэг. Хамгийн ноцтой нь ийм хийсвэр сэтгэлгээнд хэт автсан хүмүүс хамгийн санаанд оромгүй, хэний ч биелүүлж үл чадах шаардлагуудыг аажим, аажмаар, алхам, алхамаар тавьж эхэлдэг. Үүнийгээ тэд маш ухаалаг, зөв мэргэн шаардлага хэмээн хардаг. Үнэндээ тэд газарт буухыг огтхон ч хүсдэггүй. Ердөө л үүнийг өөрчлөхийг хүссэн, харахад ямар ч хэцүү зүйл алга, би яарч байна, юундаа удаж цаг үрээд байна хэмээн шахалт үзүүлэх нь тэдний нийтлэг араншин. Хажуугаар нь ерөнхийдөө ажил гайгүй, боломжийн явж байна, энэ мэтчилэнгээр засвар, өөрчлөлт хийгээд яваад байвал, ажил тун удахгүй дууслаа хэмээн тал засахаа бас мартахгүй. Гүйцэтгэгч тал ч захиалагч талаас оноо алдахгүйн тулд аль болох хүсэл болгоныг нь биелүүлэхийг чармайна. Өнгөц харахад, бүх зүйл хэвийн. Программын систем гэдэг нь хэрэглэгчийн хүссэн бүх үйлдлүүдийг хийдэг, долоо, арав хоног туршиж үзэхэд ямар ч алдаа мадаггүй ажиллаж байна гэдэг нь бүх зүйл амжилттай болжээ гэж үзсэн тохиолдолд шүү дээ. Үнэндээ энэ бол маш том төөрөгдөл.

Программын системийн амьдралын мөчлөг гэсэн маш чухал ойлголт байдаг. Энэ ойлголтоор, программын системийг хоёр тал хүлээлгэн өгч авалцсанаар асуудал дуусдаггүй, харин жинхэнэ асуудал эндээс эхэлдэг. Анхандаа захиалагч тал ямар асуудал гарах талаар ямар ч ойлголтгүй, бас ямар ч бэлтгэлгүй байдаг. Аажмаар асуудал бага багаар хуримтлагдан бөөгнөрсөөр эцсийн дүндээ асар хүчтэй тэсрэлт болон хувирдаг. Ийм жижигхэн энгийн системийн ашиглалтын зардал гэж юу шалих вэ дээ, бараг бүх ажлыг нь гараараа хийсэн ч ядах юмгүй хялбархан зүйл хэмээн бодож байсан хүний хувьд ашиглалтын зардал хяналтаас гарч эхэлмэгц цэлмэг тэнгэрээс хүчит аянга ниргэх мэт маш хүчтэй гэнэтийн цохилт болон бууна. Эхний удаад гүйцэтгэгч тал захиалагчийн хүсэлтийн дагуу үүссэн аливаа асуудлыг уриалгахнаар шийдэж эхлэнэ. Гэвч удалгүй байдал бишдэж хийсэн засвар бүр нь араасаа илүү олон асуудал үүсгэсээр богино хугацааны дотор зардал хяналтаас эрчимтэй гарна. Ингээд дуусашгүй урт маргаан эхлэнэ. Олонхи тохиолдолд захиалагчийн саналаар хийгдсэн "багахан" өөрчлөлтүүд системийн тогтворгүй байдлын үндсэн гол шалтгаан болдог. Энд захиалагч тал өөрийн бурууг огтхон ч хүлээн зөвшөөрөхгүй. Зөвшөөрлөө гэхэд асуудлыг шал өөр өнцгөөр тайлбарладаг. Хамгийн түгээмэл тайлбар гэвэл явцын дунд гарсан өөрчлөлтийг тооцохгүй, бид системд өөрчлөлт оруулна гэж анхнаасаа тохиролцоогүй, хэрвээ манай саналаар өөрчлөлт оруулсан бол энэ нь танай талын буруу, бид ийм зүйл болно гэдгийг төсөөлөөгүй хэмээн зүтгэнэ. Үнэн хэрэгтээ, хэрэглэгч бол хаан гэсэн дэврүүн бодол нь тэднийг бусдын өмнө ямар нэгэн буулт хийх, тохироцлоо хийхэд нь ямагт саад, тогтгор болсон том хар бул чулуу болон хөндөлсөж байдаг.

Олон жил программ бичсэн хүмүүс иймэрхүү гунигтай түүхийг хангалттай сайн мэднэ. Гэсэн ч үүний эсрэг хэн ч, юу ч хийж чаддаггүй. Хүмүүсийн ганц чадах зүйл гэвэл ажлаа орхих, өөр улс орон руу дүрвэн дайжих, компаниа дампууруулж өвдөг сөхрөх - үүнээс дээр ирээдүйтэй зам байдаггүй. Хамгийн тэвчээртэй хүмүүс л бууриа сахиж үлдэнэ. Ийм хүмүүс нь нэг бол бусдын дохио, зангаагаар ажилладаг, өөрийн ямар ч эрх мэдэлгүй хүмүүс байдаг. Тэдний хувьд цалин аваад, бусдад харуулах ямар нэгэн систем үзүүлж байвал л болох нь тэр. Уг систем нь цаашаа ажиллана уу, үгүй юу гэдэг огтхон ч сонин биш. Хамгийн гол нь хүнд үзүүлэх үзмэр байхад л болоо. Энд системийн чанарын талаар, ашиглалтын зардлын талаар дурсахын ч хэрэггүй. Үнэхээр ажил, мэргэжилдээ дур сонирхолтой хүмүүс ажлаа орхидоггүй, харин багш, зөвлөгч, судлаач гэх мэтийн хүмүүстэй муудалцаад, сайн, муугаараа дуудалцаад байдаггүй осол, бэрхшээл багатай замыг сонгож авдаг. Ингэснээр тэд бодит амьдралаас тасардаг, үүний дээр хүмүүст буруу ойлголт үлдээдэг. Мэдээллийн технологи гайхалтай түргэн хөгжиж байгаа, программ бичих маш амархан болж байгаа гэх мэт үнэнд нийцэхгүй домог ингэж төрдөг. Гэтэл өнөө цагт программ бичих нь улам бүр түвэгтэй болоод байгаа нь үнэн билээ. Хэдийгээр өнөөдөр мэдээллийн технологийг хөгжүүлэх, сайржуулах талаар илүү их ярьдаг болсон ч ихэнхи программ зохиогчид болон программын компаниуд ирээдүйдээ тун итгэл муутай, гутранги үзэл давамгай байдаг нь хэнд ч нууц биш билээ. Зарим хүмүүс аутсорсингийн бизнес хийх нь ашигтай, энэ л мухардлаас гаргах сүүлчийн гэрэл гэгээ, итгэл найдвар гэж үздэг. Нэг талаасаа үнэн, гэхдээ ямар ч баталгаа байхгүй. Үүгээр ямар ч асуудал шийдэгдэхгүй. Энэ бол өөрөө өөрийгөө хуурсан, өөрөө өөрийгөө аргацаасан түр зуурын л алхам. Бид асуудлыг шал өөр өнцгөөс харах хэрэгтэй. Зөвхөн ингэж чадсан нөхцөлд л бид нийгмэд өөрийн эзлэх ёстой байр сууриа жинхэнэ ёсоор нь эзэлж өөрсөддөө ч, нийгэмдээ ч томоохон тус хүргэх үүд хаалгыг нээх болно. Энэ бол амар хялбар ажил биш гэдэг нь хэнд ч ойлгомжтой.

Туршлагатай төслийн зохицуулагч хүн ажилд орох ярилцлага өгөхдөө ямар ч ажлыг амар, хялбар гэж хэзээ ч хэлж зүрхэлдэггүй. Амжилттай хэрэгжүүлсэн төсөл гэхээсээ илүү амжилтгүй өндөрлөсөн төслийн талаар арвин баялаг туршлага хуримтлуулсан байдаг. Ерөнхийдөө бусдын нүдэнд харагдахдаа гутранги үзэл давамгайлсан мэт сэтгэгдэл төрүүлдэг. Гэтэл олонхи хүн ярилцлага өгөхдөө өөрийгөө ямар ч ажлыг түвэггүй нугалж чадах юунд ч дийлдэшгүй баатар мэтээр танилцуулдаг. Хувийн хэргийг нь сөхөж үзвэл амжилттай хэрэгжүүлсэн төслийн хангалттай урт жагсаалтыг тоочин бичсэн байдаг. Энд үндсэн хоёр л хариулт байдаг. Нэг бол энэ нөхөр худлаа ярьж байна, эсвэл энэ хүн юу ч мэддэггүй хүн. Яагаад гэдгийг тайлбарлая.

Нэг үеээ бодоход хүмүүс компьютерийг ахуй, амьдралдаа өргөн хэрэглэдэг болжээ. Албан өрөөндөө Word, Excel, PowerPoint, Outlook Express, Internet Explorer, Windows гэх мэт программуудыг хэрэглэдэггүй хүн ч ховор болж. Олон хүн эдгээр программгүйгээр ажлаа төсөөлж чадахгүй. Албан бичиг, захиа даалгавар бичих, хүснэгт тооцоо бодох, хөдөлгөөнт танилцуулга, сурталчилгаа үйлдэх, дуу аялгуу сонсох, кино, зураг үзэх гээд маш олон төрлийн ажлыг компьютер ашиглан программын тусламжтайгаар тун түвэггүй, хурдан шуурхай, алдаа мадаг багатайгаар хийж гүйцэтгэх нь манай өнөөгийн ердийн дүр зураг. Харин энэ бүх хөгжил дэвшлийн цаана ямар их хүч хөдөлмөр, зардал, ур ухаан шингэсэн байдаг талаар олонхи хүн ямар ч төсөөлөлгүй байх нь элбэг. Хамгийн наад зах нь гэхэд олон байгууллагын хувьд программын мэргэжилтэн хүн айлын шоовдор, илүүдэл хүүхэд мэт харагддаг. Ерөөс бүх ажлыг компьютер хийчихнэ, чамд хийгээд байх ажил алга гэдэг байдлаар аливаа асуудалд хандана. Видео клип, СД, ДВД гээд олон гайхамшгийн дэргэд хоёр, гурван ширхэг электрон маягт бөглөх вэб программ бичих юу байсан юм, даруй түргэн хийж дуусга хэмээн лүндэн буулгах нь жирийн үзэгдэл. Заримдаа гаднын байгууллагад хандах тохиолдол байх хэдий ч хандлага нь огт өөрчлөгдөхгүй. Ухаандаа, хамгийн энгийн вэб программ бичихэд хамгийн хэцүү видео клип хийхээс хэд дахин их хүч хөдөлмөр орно гэж тэдний ухаан санаанд огт буухгүй. Тэр тусмаа арван жилийн өмнө программ бичиж байсан хүмүүс ингэж үзэх нь элбэг байдаг. Урьд бүх зүйл хэцүү байсан, одоо бүх зүйл хялбархан болсон гэдэг. Асуудал юунд байна?

Ганц хүн суугаад юу хүссэнээ хийж болдог персонал буюу ахуйн компьютер, харин олон хүн нэгэн зэрэг холбогдон ажиллах зориулалттай вэб орчин бол тэнгэр, газар мэт хоорондоо ялгаатай. Ганц хүн ганц компьютер дээр суугаад ямар ч алдаа, эндэгдэл гаргалаа гэхэд энэ нь хэнд ч гай болохгүй. Word, Excel эсвэл PhotoShop программаа нээгээд гаргасан алдаагаа дор нь засна. Одоо үгүй юмаа гэхэд хожим засаж болно. Хэрэв программ дотор алдаа гарвал программаа унтраагаад асаах юм уу компьютераа унтраагаад асаахад л хангалттай. Харин олон хэрэглэгчийн систем бол огт өөр. Жишээ нь вэбийг унтраагаад асаана гэсэн ойлголт огт байхгүй. Элдэв төрлийн нян, гаднын халдлага, дайралтаас зугтана гэж байхгүй. Хэрвээ та ямар нэгэн алдаа гаргах юмуу эсвэл программын алдаа гарлаа гэхэд энэ нь бусад хүмүүст халдварлан тархаж нөлөөлөхгүй гэсэн ямар ч баталгаа байхгүй. Иймэрхүү баталгаа хийх ажлыг программ зохиогчид өөрсдөө л шийднэ. Энд ямар ч багаж, технологи туслахгүй.

Нэг жишээ авъя. Жава бол бичил орчин гэж өмнө дурдсан. Товчхондоо энэ бол mp3 дуу тоглуулдаг тоглуулагчийн нэгэн адил жава программ тоглуулдаг тоглуулагч программ гэсэн үг. mp3 тоглуулагчтай гар утас, флеш диск, цаг гэж байдгийн адил жава тоглуулагчтай гар утас, өврийн дэвтэр, зурагт, тэр ч бүү хэл шарах шүүгээ, автомашин хүртэл байж болно. Онолын хувьд, жава хэлээр программ бичихийн тулд гар утас, зурагт, эсвэл шарах шүүгээ хэрхэн ажилладагийг судлах шаардлагагүй. Тоглуулагч нь л байвал хаана бол хаана ажиллана. Тэгэхлээр маш уян хатан, нарийн систем гэсэн үг. Яг өнөөдрийн байдлаар Жава орчны тав дахь үе буюу Java 1.5 хувилбар ашиглалтынхаа ид дунд үедээ явна. Удахгүй Java 1.6 гэсэн шинэ хувилбар гарах боловч энэ нь төлөвштлөө нэг, хоёр жил лавтайяа болно. Жава 1.5 төлөвштлөө ямар замыг туулав гэдгийг хамтдаа сонирхцгооё.

java 1.5 Update 8 - 234 алдаа

java 1.5 Update 7 - 229 алдаа

java 1.5 Update 6 -131 алдаа

java 1.5 Update 5 - 83 алдаа

java 1.5 Update 4 - 142 алдаа

java 1.5 Update 3 -118 алдаа

java 1.5 Update 2 - 175 алдаа

java 1.5 Update 1 - 170 алдаа

эх сурвалж: http://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_08

Эндээс харахад найман шат дамжихдаа нийт 1282 алдаа илрүүлж зассан байна. Энэ нь Windows үйлдлийн системийн алдаатай харьцуулбал бараг алдаагүй, цэвэр цэмцгэр гэсэн үг. Хичнээн сайхан дуу, хичнээн сайхан видео бичээд тоглуулагч нь ганцхан удаа, эсвэл хоёрхон удаа тоглуулаад хуурцагаа зураад зарцуулсан хамаг хөдөлмөрийг баллаад байвал сайн бүтээл гаргах гэж чармайх хэрэг байна уу? Хамгийн гол нь юунаас болоод яагаад хуурцгийг зураад байна гэдгийг хэн ч хэлж мэдэхгүй. Өнөөг хүртэл 1282 алдаа илрүүлж зассан байна, дахиад хэдийг илрүүлж засах вэ гэдэг нь оньсого. Чухам үүнд л асуудал оршино.

Өнөөдөр шинжлэх ухаан техник эрчимтэй хөгжөөд мэдэхгүй, чадахгүй зүйл алга болж байна гэж ярьдаг. Гэтэл урьд өмнө огт дуулдаж байгаагүй цоо шинэ аюулт өвчнүүд ар араасаа төрөн гарч тэдний өмнө хүн төрөлхтөн илт хүчин мөхөсдсөөр байгаа билээ. Ийм өвчнүүд нь улам аюултай, улам хөнөөлтэй, улам чадалтай болон хувирч байна. Бүхэл бүтэн улс, тив, дэлхий дахиныг хамарсан ДОХ, шувууны томуу гэх мэт өвчний зах зухаас бид мэднэ. Өнөөгийн программын системд тулгараад буй бэрхшээлийг эдгээр аюулт өвчнүүдтэй зүйрлэхэд болохгүй гэх газаргүй. Энд том, бага гэлтгүй бүх систем адилхан нэрвэгдэнэ. Компьютерын систем хөгжин, улам боловсронгуй болохын хэрээр алдаа ч улам боловсронгуй, улам түвэгтэй болж байдаг.

Алдаа илрүүлж засна гэдгийг олон хүн маш хялбарханаар төсөөлдөг. Нэг алдаа засаад л тухайн асуудал дууслаа гэж боддог. Гэтэл зассан нэг алдааны цаана дахиад тав, арав, магадгүй хорь, гучин алдаа цоо шинээр мэндэлж байдаг. Хэдийчинээ алдаа засна, төдийчинээ алдаа шинээр үүснэ. Хэсэг анзаарагдахгүй байснаа гэнэт л хоорондоо үгсэж тохирсон аятай бөөн, бөөнөөр илэрч асуудал үүсгэж эхэлнэ. Тэгэхлээр алдаа бүрийг засах гэж зүтгэх хэрэггүй. Системийн аливаа шийдэл нь зүүний үзүүр дээр тогтсон өндөгтэй адил гэж зүйрлээд байдаг нь ийм учиртай. Ялигүй хазгай гишгэхэд л бүх систем нуран унана, өөрөөр хэлбэл алдаа хяналтаас бүрэн гарна. Алдааг хамгийн оновчтой, зохистой түвшинд тогтоон барих асуудлыг шийдэхэд бидэнд математик аргачлал тусалдаг. Яг ямар алдаанууд үүсэхийг хэлж чадахгүй боловч хэзээ, хичнээн хэмжээний алдаа гарахыг багцаалан хэлж зардал, цаг хугацаагаа маш өндөр нарийвчлалтайгаар урьдчилан харах боломжийг математик аргууд хэлж чаддаг. Хэрэвзээ дээрхи жишээг анхааралтай ажиглабал анхандаа алдааны тоо буурч явснаа дахиад өссөн дүр зураг харагдана. Маш гярхай хүн энд ямар нэгэн зүй тогтол байгааг олж харж бас болно. Яг нарийндаа бол энд ямар ч санамсаргүй үзэгдэл байхгүй. Бүх зүйлийг урьдаас төлөвлөсний дагуу хийнэ. Гүйцэтгэлийн явцад бага сага хазайлт үүсэх нь үнэн боловч тухай бүр нь урьдаас төлөвлөсний дагуу залруулга хийж явсаар ажлаа төлөвлөсний дагуу дуусгана. Дахин давтан хэлэхэд, ямар ч асуудалгүй, ямар ч өө сэвгүй, ямарч алдаагүй систем гэж хаана ч байхгүй гэдгийг гүнээ ухамсарлан ойлгох хэрэгтэй.

Тариа газарт ургадаг гэж олон хүн боддог. Нэг талаасаа үнэн, нөгөө талаасаа худал. Мэдээж тариа газарт ургана гэдэг нь хэнд ч ойлгомжтой. Гэхдээ энэ нь тарианы үрийг газарт булаад л ажил дууслаа, бусад нь тэнгэр, хангайн шийдэх асуудал гээд орхих үндэс болохгүй. Ихэнхи хүмүүсийн бодлоор, ялангуяа хуурай, сэрүүвтэр, тэр тусмаа эрс тэс уур амьсгалтай газар нутагт үр тариа ургуулах нь асар өндөр эрсдэлтэй, бараг боломжгүй зүйл. Ялангуяа газар тариалангийн үйлдвэрлэл эрхэлж буй компаниудын өнөөгийн дүр төрхийг харсан хүн бүхэн ингэж бодно. Гэтэл сайны хажуугаар саар гэж нэг үг байдгийн адилаар олон муу үр дүнгийн зэрэгцээ байнгын тогтвортой, өндөр ургац авч буй цөөн ч гэсэн компани, хувь хүмүүс мэр сэр бий. Адилхан л хуурайшил, адилхан л хүйтрэл, адилхан л техник, адилхан л хүмүүс. Асуудал юунд байна? Хариулт нь маш энгийн. Энэ бол технологи, өөр юу ч биш. Гүйцээ. Энд ямар нэгэн ид шид, лус савдгийн тухай яриа байхгүй.

Газар тариалангийн үйлдвэрлэлийг амжилттай эрхлэхэд тус дэм болохуйц хангалттай олон төрлийн технологи байдаг. Хэрэв эдгээр агро технологийн талаар газар тариаланчдаас асуувал бүгд л мэддэг, бүгд л тэр тухай ярьдаг. Жишээ нь уриншыг аваад үзье. Үр тариа ургахад гол нөлөө үзүүлдэг 3 хүчин зүйл байдаг нь ус чийг, агаар дулаан хийгээд шим тэжээл байдаг. Хамгийн энгийнээр хэлэхэд, уриншын боловсруулалт хийнэ гэдэг нь хөрсийг үе шаттайгаар, зарим тохиолдолд хэсэгчилсэн байдлаар гүн болон өнгөц хагалах гэх мэтчилэнгээр хоолны гурлыг тарыг нь гартал элддэг шиг элдэж нэг жил өнжөөн амраахыг хэлдэг. Энэ нь хур бороо, хөрсний чийгийг газрын гүнд нуур, далай болгон хуримтлуулах, зэрлэг ургамлыг уг үндсээр нь тасдах замаар ургах нөхцлийг нь боон хөрсний шим тэжээлийг арвижуулах, хөрсийг сийрэгжүүлэн дотор нь буй элдэв бичил, микро организмуудыг идэвхижүүлэн агаарын солилцоо, амьсгалыг сайжруулах зэрэг олон чухал ач холбогдолтой. Хоолны гурилыг хэтэрхий их нухвал хатуурах, хэтэрхий их амраавал нялцаах гэх мэт таагүй зүйл олон тохиолддог. Мэдээж үүнд тухайн гурилын өөрийнх нь шинж чанар, гэрт гадаа гээд орчны онцлог, тогоочийн ур чадвар гэхчлэн өөр олон хүчин зүйл бас давхар нөлөөлнө. Нэгэнт гурлыг гартаа оруулан номхотгосны дараа түүнийг яаж л бол яаж, хүссэнээрээ ашиглаж болох бөгөөд үүнийг ямар ч тогооч хүн эрхэмлэнэ.

Уринш боловсруулах нь гурил элдэхтэй олон талаараа төстэй. Тухайлбал тухайн жилийн онцлогоос хамааран талбай дээр ургах зэрлэг ургамлын нэр төрөл, тоо хэмжээ, хугацаа байнга өөрчлөгдөнө. Хөрсийг хэтэрхий их нухвал хөрсний бүтэц эвдэрч цөлжих үйл явц эрчимжинэ. Тэгвэл хөрсний бүтцийг бэхжүүлэн барьцалдуулдаг гол эм тариа нь зэрлэг ургамлууд байдаг. Энэ үүднээсээ зэрлэг ургамлыг ургуулах хэрэгтэй. Гэхдээ хэтэрхий удаан ургуулбал талбайгаар дүүрэн үр цацаж, цацсан үр нь ирэх жилийн толгойн өвчин болно. Түүнээс гадна зэрлэг ургамлын үндэс нь газар доор асар хүчтэй сүлжээ үүсгэн ямар ч хүчтэй техникийг өвдөг сөхрүүлэн шатахуун тосны жинхэнэ эрлэг болох аюул байдаг. Зарим зэрлэг эрт боловсордог байхад, зарим нь орой боловсроно гээд олон ялгаа байх боловч цагийг нь зөв олбол нэг явалтаар бүх зэрлэгээс ангижрах боломж бас бий. Мэдээж ингэснээр зардал хэмнэх, үгүйдээ гэхэд илүү ашигтай зүйлд зарцуулах боломж олгоно.

Хөрс боловсруулна гэдэг нэг ажил, харин тарина гэдэг нь бас нэг өөр ажил. Зүгээр л хөрсний гүнд үр булахыг үр тарилаа гэж хэлэхгүй. Яг тухайн талбай дээр, яг тухайн сортын үрийг, талбайн аль хэсэгт ямар гүнд булах вэ гэсэн том асуудал гарна. Учир нь талбай бүхэн шугамдаад индүүдчихсэн юм шиг адилхан байдаггүй. Уулын ар, өвөр, хотгор, гүдгэр, нөмөр нөөлөг, энгэр задгай гээд бүгд өөр, өөр. Үр тарианы үр нь сортоосоо хамааран хэмжээ нь том, жижиг, соёлолт нь хурдан, түргэн, үндэс нь урт, богино, иддэг хоолных нь хэр хэмжээ их, бага гээд олон янз. Зарим нь хүйтэнд тэсвэртэй байхад, зарим нь ганд тэсвэртэй, эсвэл өвчин, зовлонд өртөмтгий гээд энэ жагсаалтыг цааш үргэлжлүүлж бас болно. Булах үрийн гүнийг тодорхойлно гэдэг маш чухал. Хэтэрхий гүн бол соёолох гэж ядсаар байтал талбай зэрлэгтээ баригдана. Талбайг хичнээн сайн боловсруулсан ч зэрлэгээс ангижрана гэж байдаггүй, гол нь зэрлэгээс өрсөж ургах ёстой. Хэтэрхий ойр бол хурдан соёолоод хүйтэнд цохиулах, мөн үндэс нь газрын гүн дэхь чийгэнд оройтож хүрэх аюул нүүрлэнэ. Энэ бол маш ноцтой асуудал.

Ганц, хоёрхон хуруу зайны хооронд асар том ялгаа бий. Ургамлын хувьд энэ нь хэдэн мянган бээрийн зайтай тэнцэнэ. Учир нь ургамлын соёолох үйл явц цаг, минут, дойлоор хэмжигддэг. Соёололт нь долоо хоног орчим үргэлжлэнэ, гэхдээ энэ бол зөвхөн өнгөц тал. Соёололтыг залгуулаад бутлалт гэж үйл явц газрын гүнд өрнөнө. Үүнд ойролцоогоор хоёроос, гурван долоо хоног зарцуулна. Хэрвээ бутлалтын үед хангалттай ус чийгээр хангаж өгвөл нэг үрнээс тав, арав, бүр хорин ч иш буюу бут салаалан ургах боломжтой. Бут бүр дээр ядаж хорь, тэр бүү хэл дал, наян будаа ургаж болно. Тэгэхлээр бид гаргасан зардлаа хэд нугалсан ашиг олно гэсэн үг. Хэрвээ бутлалтын үе өнгөрвөл хичнээн сайн ус чийгээр хангаад ч дахин бутлалт явагдахгүй, явагдлаа гэхэд ургацын жинхэнэ дайсан төрнө. Тариалах гүнээс гадна нэгж талбайд цацах үрийн хэмжээ, хоорондын зай гэж чухал хүчин зүйл бий. Хоорондоо хэтэрхий хол юмуу хэтэрхий ойр, эсвэл хэтэрхий нягт юмуу хэтэрхий сийрэг байж болохгүй. Энэ нь зэрлэг ургамалтай тэмцэхэд чухал ач холбогдолтой төдийгүй бутлалт явагдахад ч бас нөлөөлнө. Эцэст нь тарих хугацаа маш чухал. Эрт тарих, орой тарих нь зарчмын ялгаатай.

Тариалалтын гүн, үрийн норм хэмжээ, мөрийн зай, тарих хугацаа гэх мэт шийдлүүдийг стратегийн шийдвэр гэдэг. Нэгэнт шийдээд тариалалтаа явуулсан бол хожим засаж залруулна гэсэн ойлголт байхгүй. Үүнийг ганц хүн мэдээд шийднэ гэж байхгүй бөгөөд маш олон төрлийн мэргэжилтнүүд хоорондоо зөвлөлдөн, санаа оноогоо уралдуулан байж дундаас нь эцсийн шийдийг гаргадаг. Гэхдээ энэ нь зөвхөн өнөөдрийн шийдвэр гэж ойлгож болохгүй. Тухайлбал уринш боловсруулалт хийхдээ дараа, дараагийн /ганцхан жил биш/ жилүүдэд хийх технологи ажлуудаа давхар тооцдог. Тэгэхлээр арвин их ургац авахын тулд хүний хүсэл сэтгэл, шунал тэмүүлэл хангалттай биш. Мөнгө зарж үр булна гэдэг нь ажил эрхэлнэ, тэр тусмаа тариа тарина гэсэн үг огт биш.

Тариа тархинд ургана. Энэ бол маш чухал дүгнэлт, бараг нээлт гэж хэлж болно. Гэхдээ л олон хүн ингэж яриад амжилт олдоггүй. Асуудал юунд байна? Технологи бол мэдлэгийн багц, бүр тодруулбал ажил явуулах зүгширсэн сэтгэлгээ гэж хэлэхэд амархан. Харин үүний цаана тэвчээр гэж маш чухал зүйл бий. Магадгүй, технологи бол тэвчээр гэж хэлэхэд ч буруудахгүй. Хүмүүсийн хамгийн гол алддаг алдаа бол энэ. Хүмүүс яагаад тэвчээргүй байдаг вэ? Бүх асуудлын зангилаа цэг бол зардал. Нэгж ажилд хичнээн их зардал зарна, бүтээмж төдийчинээ өснө гэсэн энгийн дүрэм байдаг. Мэдээж, хязгааргүй их зардлын тухай энд яриагүй. Гэтэл хүмүүс үүний яг эсрэгээр нь сэтгэдэг. Бүр тодруулбал, нэгж ажлын зардлаа бууруулаад нийт ажлын хэмжээгээ өсгөхийг чармайна. Ингэснээр эрсдэл буурна гэж ойлгодог. Маш их ажил хийснээр орлого нэмэгддэггүй, харин чанартай цөөн ажил хийснээр орлого өсдөг гэдгийг сайн ойлгодоггүйгээс чанаргүй ажлын хэмжээ нэмэгдэж алдагдал хүлээх магадлал өсдөг. Ингээд байдал урвуугаар эргээд эхэлмэгц зардал руу бүх бурууг чихдэг. Технологийн дагуу чанартай ажилламаар байна, даан ч зардал хүрэлцэхгүй байна гэсэн гоморхол ингэж төрдөг.

Ажлын чанарыг дээшлүүлэхэд хүний хүчин зүйл, зарим хүний хэлэх дуртай хариуцлага чухал гэдэгтэй маргахгүй. Гэхдээ хариуцлага гэдэг нь үүрэг, амлалт аваад, гэрээ хэлцэл хийгээд шийдчихдэг хий хоосон зүйл огт биш. Хариуцлага бол зардлын нөгөө тал. Тухайн асуудалд хэдийчинээ зардал төлөвлөнө, ач холбогдол нь төдийчинээ өсч хариуцлага төдийчинээгээр нэмэгдэнэ. Аливаа компанийн зардлын бүтцийг хараад хариуцлагын тогтолцоог нь мэдэж болно. Жишээ нь хүмүүс дор бүрнээ ажлаа хийгээд нийтийн зорилго дээрээ нэгдэж чаддаггүй тал элбэг ажиглагддаг. Тухайлбал, тариалалтын стратегийн шийдлүүдийг гаргахад хүн бүрийн биш юм аа гэхэд чухал, чухал мэргэжлийн хүмүүсийн саналыг тодорхой хэмжээгээр тусгадаг. Гэсэн ч ажил урагштай явдаггүй.

Цэргийн нэрт жанжин Наполеоны хэлсэн "миний хамгийн заналт дайсан бол би өөрөө" гэсэн үгийг сонсоогүй хүмүүс олон байж мэднэ. Энэ бол үхэхийнхээ өмнө гэр хорионд байхдаа бүх амьдрал, бүх алдаа, оноогоо нэг бүрчлэн дүгнэн шинжилж удаан хугацаагаар эргэцүүлэн бодсоны эцэст хэлсэн түүний хамгийн алдартай, бас хамгийн үнэ цэнтэй үг юм. Асуудлыг гаднаас биш, харин өөрийнхөө дотроос илрүүлэн шийдвэрлэх замаар өндөр амжилтанд хүрсэн олон хүний зам мөр энэ үг хичнээн үнэн болохыг баталдаг. Хуучин тогтолцооны үед үүнийг арай өөрчлөн "өөрийгөө шүүцгээе" уриан дор бүх нийтийн ариун үйл хэрэг болгох том аян зохиохдоо энэ гайхамшигт үгийн утга, учрыг бүрэн гажуудуулсан гашуун түүх бий. Харамсалтай нь түүх дахин давтагдсаар байна.

Үр тарианы үйлдвэрлэл бол ганц хүний хийх ажил биш төрөл бүрийн мэргэжлийн олон хүний хийх ажил гэдэг нь ойлгомжтой. Энэ үйлдвэрлэлийг хөл дээр нь босгохын тулд дор хаяж гурваас таван жилийн уйгагүй хөдөлмөр зарцуулна, үүний тулд хүмүүсийн сахилга бат, хариуцлагыг дээшлүүлэх хэрэгтэй гэж хүн бүхэн ярьдаг. Жишээ нь компани харж хандах эзэнгүй боллоо, хэн нэгэн мөнгөтэй хүн компанийг эзэмшилдээ оруулаад хатуу гараар захирвал ажил сайжирна гэж нэг хэсэг давхиад хад мөргөсөн. Ингэснээр асуудал шийдэгдэх биш харин ч улам дордох тал нь илүү давамгайлсан. Яагаад? Учир нь хариуцлагын тухай ярьснаас болоод тэр. Үнэндээ компанийн удирдагчаасаа авахуулаад цэргээ хүртэл хэн ч хариуцлага үүрэхийг хүсдэггүй. Бүгд л асуудлыг өөрөөсөө аль болох холхон түлхэхийг чармайх нь хүний төрөлх араншин.

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

Энд нэг зүйлийг анзаарч болно. Хариуцлага бол нийтийн жишиг даган амаа хамхих гэрээ хэлэлцээр, гэрээгээ зөрчвөл торгууль хүлээх шийтгэлийн тогтолцоо мөн гэсэн дүр зураг тодрон гарна. Энд ямар асуудал байна? Хариуцлага бол эзэнгүй зүйл биш. Хэрвээ бүх хүн нэг загвар, нэг жишгээр явбал хариуцлага маань ямар ч эзэнгүй, хий хоосон зүйл болж хувирна. Нэг жишээ авъя. Хүнсний дэлгүүрт ороход хоорондоо төстэй хоёр өөр бараа /жишээ нь өндөг/ байна. Нэг нь үнэтэй, нөгөө нь хямд. Худалдан авагчийг хямд, эсвэл үнэтэй бараа сонгохыг хэн ч албадахгүй. Ямар ч компани бараагаа хурдан зарахын тулд, эрсдлээ бууруулахын тулд зардлаа хямдруулан үнээ буулгахыг хичээн зүтгэдгийг бид мэднэ. Тэгэхлээр хэн нэгэн хүн жишээ нь хямд өндөг худалдан авснаар хоолны хордлогод өртөн амь насаа ч алдаж болно, харин үнэтэй өндөг худалдан авсан хүний хувьд ноцтой асуудал үүсэх магадлал маш бага. Өөрөөр хэлбэл хариуцлага бол мөнгө. Энэ бол бодит зардал. Энэ бол тодорхой бодлого. Ийм хариуцлага нь эзэнгүй хариуцлагаас огт өөр.

Хариуцлагын асуудлыг дэлгэрүүлэн авч үзэхдээ дахиад л газар тариалангийнхаа үйлдвэрлэл дээр тогтож яръя. Тариа тарина гэдэг нь үр булахын нэр биш гэж хэлсний нэгэн адил үр булна гэдэг нь зүгээр л трактор хөлөглөн араасаа үрслэгч чирж давхихын нэр биш. Трактор талбайд гарахын өмнө агрономч хүн үрслэгчийн тохиргоо хийж өгнө. Мөрийн зай, үрслэгч хошууны гүн, өргөн гэх мэт. Энэ нь талбай бүхэнд өөр өөр. Гэтэл тодорхой нэг талбай гэдэг нь өөрөө бас нэгэн жигд биш. Туршлагатай тракторчин бол талбайгаа мэдэрч хурдлах газраа хурдалж, удаашрах газраа удааширч, зогсох газраа зогсож ажиллана. Шаардлагатай бол үрслэгчийн тохиргоогоо явцын дунд өөрөө өөрчлөн тохируулж чаддаг. Хэрвээ ингэж чадахгүй бол хожим маш ноцтой асуудлууд үүсэх магадлал ихсэнэ. Тухайлбал талбай цоохортож болно. Өөрөөр хэлбэл, зарим газраа тарианы болц нь түргэсч, зарим газраа оройтно. Хэрвээ оройтож байгаа хэсгээ болц гүйцэхийг нь хүлээнэ гэвэл түрүүлж болсон хэсэг нь унах ч магадлал бий. Эсвэл хэтэрхий хатснаас болж хадгалалт, хамгаалалт даахгүй болно. Хэрэв түүхий тариагаа болсон тариатай хамт хураана гэвэл комбайны хэвийн ажиллагаанд хортойгоор нөлөөлж болсон тариагаа ч зүгээр хурааж чадахгүй тариагаа няцлах, бяцлах гэхчилэн хорогдол их гарна. Дараа нь шигшиж цэвэрлэхэд ч бас хүндрэл учирна. Атга түүхий тарианаас болж хэдэн тонн ч үр тариа хаягдах, машин техник гэмтэн улмаар хураалтын ажил хэдэн цаг, хэдэн өдрөөр ч сунжирч болно. Энэ бол маш өндөр эрсдэл.

Тэгэхлээр яг нэг цагт, нэг талбайд, нэг тохиргоогоор, нэг тракторчны тарьсан тариа хожим эрс, тэс өөр үр дүн үзүүлж болно гэсэн үг. Үүнээс болоод тариа тарьснаас хураах хүртэл явагдах завсрын технологи ажиллагаанд зардлын нэмэлт ачаалал бас өгнө. Тиймээс тариалалтанд маш хянуур хандах хэрэгтэй. Гэтэл амьдрал дээр ингэж чаддаггүй. Яагаад? Үүнд олон шалтгаан бий. Нэг түгээмэл алдаа нь хэдийчинээ их талбайд тарина, төдийчинээ ашигтай гэсэн хуучин тогтолцооны сэтэхүй байна. Өнөөдөр хэнийг ч заавал их талбайд тарь гэж төлөвлөгөө, нормоор шахаж дарамтлаагүй. Гэтэл албатай юм шиг заавал их талбайд тарих гэж бүгд чармайдаг. Ингэснээр эрсдэл буурна гэж боддог. Нэг хэсэг нь шатлаа гэхэд нөгөө хэсэг нь аварна гэсэн бодолтой. Гэтэл юунаас болоод яагаад шатаад байна гэдгээ харахыг ч хүсдэггүй. Тухайлбал хэр хэмжээнээсээ хэтэрсэн талбайд тариалалт явуулахын тулд хэдэн тракторчдаа өдөр, шөнөгүй, цаг наргүй талбайд зүтгүүлдэг. Ийм нөхцөлд талбайгаа мэдэрч ажиллахын тухай бодохын ч хэрэггүй. Жаахан л удах аваас цалингаараа торгуулах юмуу бүр ажлаасаа хөөгдөж ч болно. Тракторчид ажилдаа ядарлаа гэсэн гомдол гарвал тэр даруй хоёр юмуу гурван ээлжээр ажиллуулна. Гэтэл хүн бүх өөр, трактор бүхэн ондоо. Зангийг нь мэдэхгүй морь унасан хүн, морь хоёр хоёулаа зовохын адил тракторчин, трактор хоёр хоёулаа зовлонд унана. Нэг тракторчин нь сэлбэг хэрэгслэлдээ гамтай ханддаг байхад нөгөө нь шатахуун тос, сэлбэг хэрэгслэлийг хормын төдийд залгиж орхино. Хичнээн сайн металл байсан ч буруу харьцвал хормын төдий нимгэн цаас болон хувирна. Үүнээс болоод дахиад л олон асуудал үүснэ. Товчоор хэлэхэд, удирдлагын буруу шийдлээс үүдэлтэй чанаргүй ажлын хариуцлагыг гүйцэтгэх ажилтнууд үүрэх сонирхолгүй байдаг. Тэр тусмаа хамжлагат ёсыг халсан өнөө цагт ажилтнууд ажлаа орхин дүрвэх нь ойлгомжтой. Гэтэл тэдгээр хүмүүсийг орлох ажилтан олно гэдэг нь дэлгүүр дотроос бараа сонгон худалдан авахтай адил амар зүйл огт биш. Ийм хүмүүсийг бий болгохын тулд хэдэн арван жил шаардагдана.

Нөхцөл байдал урвуугаар эргэхийг мэдэрсэн удирдлага хариуцлагаас мултрах шинэ арга хайж олсон нь түрээсийн гэрээ байдаг. Энэ нь олон талаараа дэлгүүрийн лангуу түрээслэхтэй адил. Өөрөөр хэлбэл тав, арван жилээ байг гэхэд ядаж хоёр, гурван жилээр тооцож гэрээгээ байгуулдаггүй, зөвхөн өнөөдрийн ашгаа урьтал болгодог. Энэ нь эхэндээ үр дүн өгдөг. Гэхдээ асуудал бий. Гэрээнд хариуцлагын тухай асуудлыг хатуу тусгадаг боловч хэрэгжүүлэх тал дээр цоорхой үүсдэг. Тухайлбал тариа муу ургавал гэрээ шиг хэрэгтэй зүйл байхгүй болдог бөгөөд бүх хохирлыг түрээслэгчид үүрэх аюул нүүрлэдэг. Гэтэл тариа сайн ургавал гэрээ шиг хэрэггүй зүйл алга болж тариаланчдаа мартах явдал гардаг. Тариаланчид хөрөнгө оруулагчдыг татахын тулд хамгийн таатай нөхцөл, давуу эрхийг олгодог. Хэрэв хамтарч ажиллабал амжилтанд хүрч болно гэсэн итгэл төрүүлэхийн тулд. Гэтэл үүнийг хөрөнгө оруулагчид мөнхийн давуу эрх гэж ойлгодог. Үүнийг ойлгохгүй бол зөрчил үүсэх нь зайлшгүй. Нэгэнт энэ ажилд хариуцлагатай ажилласан бол дараа, дараагийн ажилд бас ингэж хариуцлагатай ажиллана гэж хүлээх хэрэггүй. Хариуцлага бол хүнд өгдөг амлалт биш, энэ бол мөнгө. Хөрөнгө оруулагчдын нүдэнд тариаланчдын үүрч буй хариуцлага, өөрсдийгөө золиосолж буй зардал нь ямагт хий, хоосон зүйл болж харагддаг. Тариаланчид бол мөнгөгүй хоосон гуйлгачид, мөнгө өгвөл сэхнэ, өгөхгүй бол мөхнө. Хариуцлага бол хүний сэтгэл учраас тариаланчдыг сайн уярааж сэтгэлээр нь тоглобол хожил ирнэ гэж сэтгэдэг. Удалгүй үйлдвэрлэл бол чихэрт хууртдаг хүүхэд биш, олон технологи дамжлагатай, өндөр өртөгтэй бизнес гэдгийг мэдмэгц хамаг мөнгөө аваад хурдан зугтахыг боддог. Энд ямар асуудал байна? Тариаланчдад хамгийн их хохиролтой. Харилцагч тал гэнэт зангаа хувирган дангаар гэрээ цуцалснаар үе, шаттай явагдах ёстой байсан ажил зогсож зарцуулсан бүх хичээл, зүтгэл талаар өнгөрнө. Урьж, залж авч ирсэн хөрөнгө оруулагчаа шүүхэд дуудах нүүргүй, эсвэл хөрөнгө оруулагчдаа давуу эрхээр хамаг баялгаа зүгээр өгөх бас нэг хэцүү. Хөрөнгө оруулагчийн хувьд богино хугацааны өндөр ашиг хэрэгтэй юу, удаан хугацааны тогтвортой ашиг хэрэгтэй юу гэсэн сонголт хийх шаардлага гарна. Хүмүүс эхний хувилбарыг сонгох нь элбэг байдаг.

Программын систем бүтээх нь үр тарианы үйлдвэрлэл эрхлэхтэй бас л адилхан. Ялангуяа веб систем хийхэд төрөл бүрийн олон оролцогчийг тооцох хэрэгтэй болдог. Юуны өмнө бүх тоглогчдын тоглоомын дүрэм буюу гэрээг тодорхойлох хэрэг гарна. Гэрээг тодорхойлохдоо явцын дунд тоглоомын дүрэмд өөрчлөлт орж болзошгүйг харгалзан аль болох уян хатан, гэхдээ тогтвортой, алсыг харсан байдлаар хандана. Анхнаасаа гэрээгээ дутуу дулимаг хийснээс явцын дунд өөрчлөлт орвол систем бүхэлдээ ч нурж болох эрсдэл бий. Гэрээг хэрэгжүүлэх явцад хариуцлага дагалдана. Тухайн гэрээнд хариуцлагын хэд хэдэн хувилбар харгалзаж болно. Хариуцлага нь хувирамтгай боловч аль болох гэрээндээ өөрчлөлт оруулахааргүй байх хэрэгтэй. Мэргэжлийн нэр томъёогоор, гэрээг интерфэйс буюу үүд гэнэ, харин хариуцлагыг method буюу арга гэж нэрлэнэ. Эдгээр нь хий хоосон зүйл биш, маш бодитой, бас тун хэцүү зүйл гэдгийг программ зохиогчид бүгд мэднэ.

Системийн инженер гэж хэн бэ?

"Eat that frog" Brian Tracy

"Гашуун ч гэсэн эм"

эхний хэсэг

Хоёрдугаар хэсэг

Өдгөө бид шинжлэх ухаан техник, тэр дундаа мэдээллийн технологийн үсрэнгүй хөгжлийн эрин үед амьдарч байна. Таван жилийн өмнө гар утас ямар байсан, компьютер ямар байгаад одоо ямар болов гэдэг асуултанд хэн ч түвэггүй хариулж чадна. Компьютерын хүчин чадал эрс дээшилж, үнэ ханш нь огцом уруудан гарын доорхи хэрэглээний программууд маань ажиллахад илүү эвтэйхэн, нөхөрсөг, таатай болсон гэдэгтэй хэн ч маргахгүй. Үүний дотор интернет бидний амьдрал руу улам гүнзгий, идэвхтэй хүч түрэн орж ирж байгааг дурдахгүй орхиж үл болно. Товчхондоо бүх зүйл хэвийн, амар сайхандаа жаргаж байна. Гэвч энд нэг асуудал бий. Олон хүмүүс ойлгохдоо хэдэн жилийн өмнөхтэй харьцуулахад өнөө цагт программ бичих нь илүү амар, илүү хялбар, илүү хурдан, зовлон бэрхшээл багатай болсон гэж боддог. Харин бодит байдал бол үүний яг эсрэгээрээ.

Хүмүүсийн дунд нэн хурдацтай түгэн дэлгэрч буй блог системийг жишээ болгон авч үзье. Энгийн нүдээр харахад иймэрхүү систем бол маш энгийн, авсаархан эд. Тэмдэглэл оруулах нэг маягт, санал сэтгэгдэл оруулах нэг маягт гээд үндсэндээ хоёрхон цахим маягтаас бүрдэнэ. Маш амархан. Магадгүй үүн дээр хэрэглэгч бүртгэх ганц хоёр маягт нэмэгдлээ гээд ч нэг их сүйдтэй хүндрэл бэрхшээл гарахгүй. Хэрвээ интернет ухвал иймэрхүү систем яаж бүтээх тухай хичээл хэдэн арваараа олдоно. Программын код нь гэхэд тав, арван хуудас, магадгүй хорь, гучин хуудас л болно. Иймэрхүү кодыг хуулбарлан аваад блог систем бүтээлээ гэхэд нэг их айхтар цаг зав, хүч хөдөлмөр орохгүй. Гэвч бодит амьдрал дээр ийм кодыг хэн ч хэзээ ч ашиглахгүй. Дэлхий дахинд өргөн тархсан үнэгүй блог хөдөлгүүрүүд /blog engine/ болон тэдний хэмжээг дор харуулав:

php хэлээр бүтээгдсэн блог хөдөлгүүрүүд:

WordPress - 3Mb
b2evolution - 9Mb
drupal - 2Mb

java хэлээр бүтээгдсэн блог хөдөлгүүрүүд:

pebble - 10Mb
roller - 22 Mb

Хамгийн цомхон хөдөлгүүр гэхэд л 2-3 Мб хэмжээтэй байна. Энэ бол хэдэн арван мянган мөр код гэсэн үг. Амьдрал дээр блог систем бүтээхдээ иймэрхүү л хөдөлгүүр авч ашигладаг.

Бид ердөө л хоёрхон маягтын тухай ярьж байгаа гэдгийг дахин сануулъя. Мэдээж хэрэг, долоо хоног, эсвэл сарын дотор иймэрхүү систем цоо шинээр босгоход болохгүй гэх газаргүй. Гэхдээ чанарын хувьд яагаад ч эдгээр блог хөдөлгүүрүүдийн түвшинд хүрч чадахгүй. Өөрөөр хэлбэл долоо, арав хоног, магадгүй сарын настай гэсэн үг. Бүр тодруулбал ийм системийг тэжээн тэтгэж ажиллууллах нь асар өндөр өртөг зардалтай, эдийн засгийн хувьд маш их хохиролтой үрэлгэн систем болж хувирна.

Өөр нэг жишээ авъя. Хүн бүхэн өдөр тутмын амьдралдаа мөнгө олж, бас үрж байдаг учраас орлого, зарлага, үлдэгдэл болон үүнтэй холбоотой санхүүгийн тэнцэл, балансын талаар зохих мэдлэгтэй байдаг. Банкны гүйлгээ гэхэд л хэн нэгний дансны үлдэгдлээс тодорхой мөнгө хасагдахад өөр нэг хүний дансны үлдэгдэл дээр мөн тэр хэмжээний мөнгө нэмэгдэх үйл ажиллагаа байдаг. Жишээ нь та гудамжнаас 100 төгрөгний үнэтэй нэг ширхэг сонин худалдан авлаа гэхэд худалдан борлуулагчийн сонины тоо нэгээр буурч мөнгө нь 100 төгрөгөөр өснө. Үүнтэй зэрэгцээд таны мөнгө 100 төгрөгөөр хорогдож харин таны худалдан авсан сонины тоо нэгээр нэмэгдэнэ. Энэ үйл явцыг тоо бүртгэлд тэмдэглэн хөтлөхийг давхар бичилт хэмээн нэрлэдэг. Хэрвээ та интернет ухвал нягтлан бодох бүртгэл юмуу банкны систем хэрхэн ажиллахыг харуулсан жишээ программуудыг хэдэн арав, бүр мянгаар нь түвэггүй олж болно. Нэг данснаас тоо нэмэх, бас тоо хасах үйлдэл бол айхтар нарийн тооцоо, шинжлэх ухаан шаардаад байх хэцүү үйлдэл биш. Гэсэн хэдий ч амьдрал дээр банкны систем юмуу нягтлан бодох бүртгэлийн систем нь хэн нэгний төсөөлдөг шиг амар хялбар систем байдаггүй, харин ч эсрэгээрээ хэдэн зуун мянга, сая долларын үнэ өртөг бүхий нүсэр хүнд түвэгтэй систем байдаг. Яагаад?

Асуудлыг арай өөр өнцгөөс харъя. Хүн бүр цахилгаан гүйдэл, цахилгаан цэнэгийн талаар мэднэ. Бас цахилгаан станц юмуу цахилгаан үүсгүүр гэж юу болох талаар анхны мэдэгдэхүүнтэй байдаг. Нэмэх, хасах туйлтай хоёр соронзонгийн дотор жишээ нь зэс утсаар ороосон ороомог хийгээд эргүүлэхэд дотор нь хувьсах цахилгаан гүйдэл үүсдэг тухай дунд сургуулийн физикийн хичээлийг зарим хүмүүс санаж байгаа. Уг зарчим нь давхар бичилтийн систем гэдэгтэй адил маш энгийн. Хадаас ч юмуу ямар нэгэн төмөр гол аваад түүнийгээ зэс утсаар ороон ороомог бэлдээд дараа нь хос хоёр соронзон дотор түүнийгээ эргүүлэн цахилгаан гүйдэл гаргах нь бараг л хэн дуртай хүний хийж чадах хялбар ажил. (хялбархан цахилгаан хөдөлгүүрийн жишээ) Харин амьдрал дээр бол цахилгаан үүсгүүр бүтээх нь хэн дуртай хүний хийгээд байх ажил биш. Наад зах нь ороомгийн эргэлтийн хурдыг яаж тогтмол түвшинд барих вэ гэдэг асуудал үүснэ. Учир нь бүх цахилгаан хэрэгслэлүүд 50 герц юмуу 60 герц гэх мэт тодорхой давтамж буюу эргэлтийн хурд дээр ажиллахаар бүтээгдсэн байдаг. Үүний дээр цахилгаан гүйдлийн хүч /ампер/, даралт /вольт/, чадал /ватт/ гэх мэт үзүүлэлтүүд нэмэгдэнэ. Хэрэв цахилгаан үүсгүүрийн эргэлтийн хурд нь тогтвортой бус савалгаатай байх аваас түүгээр тэжээгдэх цахилгаан хэрэгслэлүүд хэвийн ажиллаж чадахгүй эвдэрч хэмхэрнэ. Жишээ нь таныг тааваараа тайван алхаж явтал араас чинь ямар нэг зүйл гэнэт хүчтэй түлхвэл та тэр даруйдаа тэнцвэрээ олж чадахгүй газар унах юмуу эсвэл ямар нэгэн юм мөргөж магадгүй та хүнд бэртэж болно. Эсвэл таныг хурдтай гүйж явтал араас чинь гэнэт чангаан зогсоох гэвэл та тэр даруйдаа зогсож чадахгүй бас л тэнцвэр алдан газар шургаж унах юмуу юм мөргөн бэртэж болно. Цахилгаан хөдөлгүүрийн эргэлтийн хурд савлана гэдэг нь үүнтэй л агаар нэг үзэгдэл. Ийм таагүй үзэгдлээс сэргийлэхийн тулд үндсэн системдээ ноцтой гэмтэл учруулахгүйгээр өөрөө эвдрэх чадвартай гал хамгаалагч гээч зүйлийг цахилгаан хэрэгслэл дотор өргөн ашигладаг. Цахилгаан хэрэгслэлийн гэмтэл нь зөвхөн өөрөө өөртөө гай тариад зогсохгүй бусдыг, тэр дундаа цахилгаан үүсгүүрийг ч эвдэлж хэмхлэх аюултай. Товчоор хэлэхэд цахилгаан хөдөлгүүрийн эд ангиудын 10 - 20 хувь нь л цахилгаан үүсгэх үндсэн ажлаа гүйцэтгэх үүрэгтэй байдаг бол үлдэх 80 - 90 хувь нь элдэв төрлийн осол, гэмтлээс хамгаалах, боломжтой бол өөрийгөө анагаах, тэнцвэржүүлэх, тогтворжуулах зэрэг туслах үүрэг гүйцэтгэнэ. Мэдээж хэрэг, тухайн үүсгүүр нь нэг хэрэглэгчийнх уу, мянган хэрэглэгчийнх үү, эсвэл сая хэрэглэгчийнх үү гэдгээс хамааран цахилгаан хөдөлгүүрийн дотоод бүтэц зохион байгуулалт, ажиллах горим, туслах үйлдлүүдийн тоо хэмжээ зэрэг нь харилцан адилгүй өөр, өөр байна. Хэдийгээр туслах үйлдлүүд нь цахилгаан гүйдэл үүсгэхэд шууд хамаатай бус боловч чухамдаа ийм үйлдлүүд л цахилгаан үүсгүүрийг жинхэнэ цахилгаан үүсгүүр болгон хувиргахад нөлөөлдөг гол амин сүнс, зүрх судас нь байдаг. Тэдгээрийг хийж бүтээх нь нэг, хоёр хүний нэг, хоёр сарын ажил гэхээсээ илүү хэдэн арав, зуун хүнийн ажил, бүхэл бүтэн судалгааны хүрээлэнгийн хэдэн арван жилийн нөр их ажил байсан, байсаар ч байгаа, байх ч болно. Үнэн чанартаа, программын систем бүтээнэ гэдэг нь үүнээс зарчмын хувьд нэг их ялгаа байхгүй.

Өнөөгийн хөтөлбөрлөгчид буюу программ зохиогчид нь нэг талдаа маш азтай, нөгөө талдаа маш азгүй хүмүүс. Тухайлбал арван жилийн өмнө хүмүүс код бичихдээ функц, ажилбар /procedure/ гэх мэт атга код өргөн ашигладаг байсан. Ширхэг тоосгоор байшин барина, өөрөөр хэлбэл өрлөг хийх хугацаа маш урт гэсэн үг. Гэхдээ нэг функц юмуу ажилбар дотроос алдаа хайж илрүүлэх нь атга өвсөн дотроос зүү хайхтай адил харьцангуй хялбар ажил байлаа. Мэдээж бүх системээс алдаа илрүүлэх нь хэцүү, гэсэн ч завсар өөрчлөлт хийх нь арай хялбар байв. Нэгэнт ширхэг, ширхэгээр тоосго өрж барилга барьж байсан тул барилгын хэлбэр, дүрсийг яаж л бол яаж өөрчлөх боломж нээлттэй байлаа. Харин өнөөгийн хөтөлбөрлөгчид "барилга барихдаа", ширхэг, ширхэг тоосго өрөх замаар бус харин бүхэл бүтэн өрөө, давхар, давхраар нь бэлэн бэлдцүүд ашиглан маш хурдан босгодог болсон. Зарим хүн 100, 200, 300 хувиар өндөр бүтээмжтэй ажилладаг тухай домог байдаг. Үүнийг шууд худлаа хэмээн үгүйсгэхэд хэцүү. Гэхдээ хүрзээр шороо ухах, эксаватороор шороо ухах хоёр нь бүтээмжийн хувьд хоёр өөр ойлголт. Тэгэхлээр, бэлдэц /component/ бол экскаватор гэсэн үг. Экскаваторыг дурын хүн ажиллуулж чадахгүй, тодорхой хугацаанд хүнийг бэлдэж сургах шаардлагатай. Бас техникийн үйлчилгээ, арчилгаа, маллагаа гэж нэг том ажил бий. Харин хүрзээр дурын хүн газар ухаж болно. Нэг их сургалт, арчилгаа, маллагаа шаардагдахгүй. Ингэж үзвэл, орчин үеийн хөтөлбөрлөгч хүн арван жилийн өмнөх хөтөлбөрлөгчөөс харьцангуй өндөр мэдлэгтэй байх шаардлагатай. Өөр нэг асуудал бол алдаа илрүүлэх, засах ажил байна. Өнөөгийн нэг бэлдэц гэдэг нь арван жилийн өмнөх дундаж системээс ч нүсэр том эд. Эндээс алдаа илрүүлж, засах нь атга өвс дотроос алдаа илрүүлж засахтай адил амар, хялбар ажил яавч биш. Энэ бол ихээхэн цаг хугацаа, хүч хөдөлмөр шаардсан хүнд, бэрх ажил. Энэ үүднээсээ өнөөгийн хөтөлбөрлөгчид бол маш азгүй хүмүүс. Зүйрлэбэл, машин бүтээхийн тулд дугуйгаа, бүхээгээ, хурдны хайрцгаа, хөдөлгүүрээ хөтөлбөрлөгчид өөрсдөө бүтээдэг байсан бол өдгөө бэлэн дугуй, бэлэн хөдөлгүүр, бэлэн бүхээг, бэлэн тэвш ашигладаг болон өөрчлөгдсөн. Код бичихээсээ илүү эвлүүлэх, угсрах ажил түлхүү хийнэ гэсэн үг. Төрөл бүрийн дугуй, төрөл бүрийн хөдөлгүүр дотроос сонголт хийх өргөн боломжтой. Яг л машины нэг сэлбэгийг өөр нэг сэлбэгээр орлуулан сольж болдогтой адилаар нэг бэлдэцийг нөгөөгөөр орлуулан хэрэглэж болно. Харамсалтай нь хэн нэгний бичсэн бэлдэц хэрхэн, яаж ажилладаг нь төдий л тодорхой бус, хэрэв гэдэс дотрыг нь ухаж үзнэ гэвэл маш их хугацаа ордог. Заримдаа ямар нэгэн бэлдэцийн гэмтлийг илрүүлэн засах гэж оролдохоос өөр төстэй бэлдэц хайн олж ашиглах нь илүү хурдан байх тохиолдлууд олон бий.

Ер нь өнөөгийн хөтөлбөрлөгчид маш тодорхой бус орчинд ажиллаж байгаа гэдгийг зориуд цохон тэмдэглэх нь зүйтэй. Аль нэгэн бэлдэц дотор гэмтэл, согог гарлаа гэхэд шалтгаан нь юу вэ гэдгийг шууд таамаглан хэлэхэд нэн бэрх. Ямар нэгэн эрхтэн, эд анги гэмтэж бэртэнэ гэдэг нь тухайн эд зүйл гэмтжээ хэмээн шулуухан дүгнэх үндэс болохгүй. Өөр нэг жишээ авъя. Амьсгал давхцах, толгой эргэх, чих шуугих, дотор муухайрах гэх мэт өвчин эмгэгийг үүсгэгч нян нь элэг, зүрх, ходоод, уушиг, булчирхай гээд хүний биеийн аль ч хэсэгт үүрлэсэн байж болзошгүй. Хэрэв өсгөдөг дуран авайгаар хүний бие махбодь, эд эрхтнүүдийг нэгбүрчлэн нэгжиж шалгана гэвэл хэдэн мянган төрлийн нянтай тулж харьцах хэрэгтэй болно. Учир нь ямар ч эрүүл саруул хүний бие махбодь дотор ухаан санаанд багтамгүй олон төрлийн нян, өт хорхойнууд язганан амьдарч байдаг. Хэрэв өнөөгийн программын системийн ямар нэгэн бэлдэц, эд ангийг өсгөдөг дуран авайгаар томруулж харвал яг л үүнтэй төстэй дүр зураг харагдах болно.

Windows, linux, Solaris, MacOs гэх мэт үйлдлийн системүүдийг нуур, цөөрөм хэмээн сэтгэвэл Word, Excel, Photoshop гэх мэт хэрэглэгдэхүүнүүд нь тэдгээр нуур, цөөрөмд амьдрах олон янзын загас, жараахайнууд болон харагдана. Цэнгэг болон шорвог ус, эсвэл тогтмол болон урсгал усны найрлага, шинж чанар харилцан адилгүй, тиймээс загас, жараахай нь ч ялгаагүй дотоод бүтцээрээ өөр өөр байдаг. Хэрэв цэнгэг нуурын загасыг шорвог нуурын усанд, эсвэл шорвог нуурын загасыг цэнгэг нуурын усанд тавьбал тэр даруйдаа амьсгал нь боогдож үхнэ. Учир нь нэг нь гадагшаа, нөгөө нь дотогшоо амьсгалах бүтэц, зохион байгуулалттай байдаг. Усны найрлагаас хамааран даралт өөрчлөгдмөгц биеийн дотоод даралт, гадаад даралтын тодорхой зөрүүгээр ажиллахаар бүтээгдсэн эд эрхтэн, булчин шөрмөсүүд нь ажиллагаагүй болж үхнэ. Гэхдээ ямар ч усанд дасан зохицох чадвартай, тэр ч бүү хэл хуурай газар хол зайд мөлхөн явах чадвартай загас, жараахай байдгийг дашрамд дурдахад илүүдэхгүй.

Жава бол олон нутагтан систем, нэг ёсондоо шилэн хүлэмж маягийн бичил орчин юм. Бүр тодруулбал, Жава хэлээр бичигдсэн программууд нь Windows, Linux, MacOs гэх мэтчилэн төрөл бүрийн орчин дотор урьдчилан суурилуулж бэлдсэн бичил орчинд ажиллах чадвартай байдаг. Нэг зүйлийг сануулахад аливаа орчин өөрийн гэсэн сул ба давуу талууд, бас өөрийн мөн чанараас урган гарсан элдэв төрлийн өвчин эмгэг, архаг хуучтай байдаг. Ялангуяа суурь эмгэгүүдийг нь илааршуулан анагаахад маш урт удаан хугацаа шаардагддаг. Жишээ нь Windows үйлдлийн систем гэхэд л сар тутам, өдөр тутам хэдэн арав, хэдэн зуун өт хорхой, нян, бөөс, хуурсыг олж илрүүлэн устгаж цэвэрлэж байдаг. Эцсийн дүндээ бөөс, хуурстай зогсоо зайгүй тэмцэх нь эдийн засгийн хувьд алдагдалтай, үрэлгэн дайн болох нь тодорхой болмогц системээ үндсээр нь өөрчилж шинэчилдэг. Ингэснээр олон архаг өвчнөөсөө салах үүд хаалга нээгдэх боловч урьд өмнө огт тааралдаж байгаагүй цоо шинэ асуудлууд, цоо шинэ өвчнөөр залгуулан өвчилдөг. Үйлдлийн системийн нэг хувилбараас дараагийн шинэ хувилбар гарах хүртэл ядаж гурван жил, хэвийн ажиллагаатай болох хүртлээ ойролцоогоор таван жил зарцуулагддаг. Windows, Linux, MacOS, Solaris гээд бүхий л үйлдлийн систем ийм замаар урагш хөгждөг. Гэхдээ Linux эсвэл Solaris систем нь Windows систем шиг гүн гүнзгий өөрчлөлтөнд өртөх нь харьцангуй бага, илүү тогтвортой, илүү төлөвшсөн систем байдаг. Тэгэхлээр Жава хэлээр бичсэн программыг Linux юмуу Solaris орчинд ажиллуулах боломжтой байна гэдэг нь найдвартай, тогтвортой гэдэг утгаараа маш том давуу тал юм. Нэгэнт Жава хэлээр бүтээгдсэн программ нь үйлдлийн системээс бүрэн тусгаарлагдан хамгаалагдсан тусгай бичил орчин дотор ажилладаг тул төрөл бүрийн гадаад орчны өвөрмөц онцлог, онцгой шинж чанар хийгээд өвчин эмгэгийг нь судлах, тэдгээртэй тэмцэх шаардлага харьцангуй бага гарна. Гэхдээ энэ нь Жава систем бол бүрэн найдвартай, ямар ч өвчин зовлонгүй, төгс төгөлдөр орчин гэсэн үг бас биш.

Жава систем нь маш олон үе, давхрагуудаас бүрддэг онцлогтой. Энэ нь олон давуу талтай. Жишээ нь аль нэг үе давхрагын эд эрхтнийг ижил төстэй эд эрхтнээр орлуулан солилоо гэхэд бусад үе давхрагууддаа нөлөөлөхгүй байх боломжтой. Өөрөөр хэлбэл маш уян хатан, нэмэлт өөрчлөлт оруулахад илүү хялбар, хурдан, шуурхай гэсэн үг. Мөн үе давхрага бүрд гал хамгаалагч маягийн хамгаалах хэрэгслэлүүд, мөн ажиглалт, хяналтын хэрэгслэлүүд суурилуулах боломжтой. Аль нэг давхрагын эд эрхтэн дотор гэмтэл, осол гарлаа гэхэд үндсэн чухал эрхтэн рүү цааш тархан халдварлаж ноцтой аюул үүсгэхээс нь өмнө гал хамгаалагч шатаж аюулыг зайлуулах боломж нэмэгдэнэ. Хэдий чинээ олон хамгаалагч байна, төдийчинээ өндөр найдвартай. Санаанд бууж буй хамгийн наад захын давуу талууд гэхэд ийм байна. Гэхдээ энэ бүхэн бол ердөө л боломжууд, түүнээс бус яг ийм байдаг гэсэн санаа биш. Ямар ч байсан ерөнхий хандлага, ирээдүйн зүг чиг ийм байна. Гэтэл жишээ нь хүмүүсийн дунд өргөн тархсан php системийн хувьд ингэж хэлэхэд хэцүү. Тэнд хаана хөл, толгой нь байрлаж байна, хаана элэг зүрх нь ажиллаж байна гэдгийг ялгаж салгаж хэлэхэд тун түвэгтэй. Ийм системийн өвчин эмгэгийг оношлох, эмчилгээ, сувилгаа хийх нь тийм ч амар ажил биш. Ердөө ханиад тусах төдий л зүрх нь зогсох юмуу уушиг нь устаж ухаан алдан унах магадлал хангалттай өндөр. Нэг өдөр цовоо сэргэлэн, эрч хүчтэй ажиллаж байснаа маргааш өглөө нь гэхэд л хэвтэрт ороод босч чадахгүй элгээрээ газар мөлхөж байхад гайхах зүйлгүй. Тэгэхлээр Жава систем бол илүү нарийн, илүү найдвартай систем, тиймээс ийм системийг ойлгож эзэмшихэд илүү хүнд. Энэ бол Жавагийн нэг сул тал. Зүйрлэбэл, машины хөдөлгүүрийг дугуйтай нь шууд холбохгүй, дунд нь хурдны хайрцаг, хүч дамжуулагч, дифферинциал хийгээд тэдгээрийг өөр хооронд нь холбох элдэв холбоос, холхивч, жийрэг гээд олон эд анги, сэлбэг хэрэгслэлүүдийг ашиглана гэсэн үг. Мэдээж хэрэг, түрдэг тэрэгнээс өөр тэрэг үзэж хараагүй хүний хувьд энэ бүхэн ямар учиртай, яагаад хэрэг болдог талаар ухаж ойлгох нь дэндүү хэцүү гэдэг нь ойлгомжтой. Түрдэг тэргэнд ямар нэгэн гэмтэл гарлаа гэхэд түүнийг илрүүлж засах нь хэцүү биш. Харин машины эд анги гэмтэж бэртвэл түүнийг оношлон эмчлэх нь тийм ч хялбар ажил биш. Гэхдээ оношлогоо, эмчилгээний автомат багаж төхөөрөмж байвал асуудлыг шийдэхэд илүү хялбар, найдвартай. Жава бол автоматоор оношлогдох, эмчлэгдэх өргөн боломжтой систем юм. PHP хэлээр вэб программ бичих нь Жава хэлээр бичихээс илүү хялбар гэж үздэг хүмүүс бий. Нэг талдаа үнэн. Нөгөө талаасаа энэ бол худлаа. Жава хэлээр PHP шиг код бичиж болох уу гэвэл болно. Харин ч илүү хурдан, илүү хялбарханаар бичиж болно. Ингэснээр Жава хэлний бүх давуу талууд үгүй болж арчилгаа, маллагаа хийхэд тун түвэгтэй хүнд систем бий болоход хүргэнэ. Чухам үүнд л хамаг учир оршино.

Компьютерын систем бий болсноор бидний ажлыг 100 хувь хөнгөвчилдөг нь үнэн боловч бидний ажлыг 300 хувиар хүндрүүлдэг гэсэн нэг үг байдаг. Энэ бол маш бодууштай санаа. Өдөрт хэдэн арав, бүр хэдэн зуун мянган хүмүүст хүрч үйлчилдэг аварга том мэдээллийн системүүд хэдэн зуугаараа интернет дээр ямар ч гэмтэл, согог гаргахгүй ажиллаж чадаж байна. Цөөн хэрэглэгчтэй жижиг систем бүтээхэд ямар асуудал байна гэсэн асуулт тавигддаг. Яг үнэндээ тухайн систем том байна уу, жижиг байна уу гэдгээс үл хамааран бүх системд тэгш үйлчилдэг нийтлэг өвчин, эмгэг гэж бий. Үүнийг хэн ч тойрч гарч чадахгүй. Том системүүд яагаад найдвартай ажиллаж чаддаг вэ гэвэл үүний цаана техникийн үйлчилгээ хариуцсан нүсэр том алба, үйлчилгээний олон байгууллагууд тэдгээр системийг цаг ямагт нүд цавчилгүй манаж байдагт гол нууц нь оршино. Ийм байгууллагууд нь тодорхой хуваарийн дагуу өдөр тутам, долоо хоног тутам, сар тутам, улирал тутам төрөл бүрийн нарийн мэргэжлийн үзлэг, оношлогоо байнга хийж аливаа асуудал гарахаас урьдчилан сэргийлж байдаг. Өчүүхэн төдий сэжигтэй зүйл илэрмэгц даруй хариу арга хэмжээг яаралтай авч чаддаг. Гэмтэл, согогууд нь дотроо маш олон янз. Хортой, хоргүй, хүнд, хөнгөн, халдартай, халдваргүй гэх мэт. Зарим ноцтой хүнд гэмтлээс урьдчилан сэргийлэхийн тулд тусгай эм тарилга, вакцин хийх хүртэл онцгой арга хэмжээ бас авна. Тэгэхлээр компьютерын системийн арчилгаа, маллагаа гэдэг бол маш өндөр өртөгтэй нарийн үйл ажиллагаа гэсэн үг.

Урьд цагт компьютерын программ бичихэд нийт зардлын 80 хувь нь код бичихэд, үлдэх 20 хувь нь арчилгаа, тордолгоо хийхэд зарцуулагддаг байсан, харин одоо нийтийн зардлын 20 хувь нь код бичихэд, харин үлдэх 80 хувь нь арчилгаа, маллагаа хийхэд зарцуулагддаг болсон гэсэн тооцоо гаргасан байдаг. Энэ юу гэсэн үг вэ? Арван жилийн тэртээ бодлого бодох жор буюу алгоритм бол программын амин сүнс гэж үздэг байсан, тиймдээ ч алгоритм судлах, эзэмших нь ямар ч хөтөлбөрлөгчийн эн тэргүүний зорилт байсан. Харин өнөө цагт алгоритм хэмээх ойлголт хуучран үеээ өнгөрөөсөн бөгөөд энэ нь хоёрдугаар, гуравдугаар, эсвэл дөрөвдүгээр, магадгүй бүр тавдугаар зэргийн ач холбогдолтой асуудал болон хувирсан. Үндсэндээ ямар бодлогыг ямар жороор шийдэх нь илүү ойлгомжтой тодорхой болж цааш нь ухаж судлах шаардлага бараг байхгүй болсон гэхэд хилсдэхгүй. Өнөөдрийн гол асуудал нь уян хатан, найдвартай, чанартай бүтэц, зохион байгуулалт, уялдаа холбоо, стандарт гэх мэт асуудлууд болсон. Энд алгоритм гэхээсээ илүү нийтлэг хэв маяг, хээ хуар /pattern/ гэдэг ойлголт хүчтэй яригддаг.

Хоорондоо огтхон ч холбоо хамааралгүй мэт олон төрлийн алгоритмууд нэг хэв маягаар илэрхийлэгдэх боломжтой байдаг. Үүний нэг тод томруун жишээ бол үйлдлийн систем. Хамгийн энгийнээр хэлэхэд, үйлдлийн систем бол төрөл бүрийн төхөөрөмжүүдийг удирдах зориулалттай хөтлөгч /driver/ программуудын нэгдэл юм. Нэг хөтлөгч нь нэг л төхөөрөмж удирдах бөгөөд унших, бичих гэсэн хоёр үйлдлээс бүрдэнэ. Мэдээж хэрэг, гар, хулгана, камер, санах ой, хатуу диск, флеш диск гээд бүх төхөөрөмжүүд өөр хоорондоо ялгаатай, гэхдээ мэдээлэл унших, бичих чадвараараа төстэй. Бүр тодруулбал, алгоритмын түвшинд унших, бичих аргууд нь өөр өөр, харин хэв маягийн түвшинд унших, бичих чадвараараа ижил. Ямар нэгэн шинэ төхөөрөмж, жишээ нь шинэ загварын дэлгэц, эсвэл шинэ загварын хатуу диск зохион бүтээгдлээ гэхэд хөтлөгч программыг нь зохиож бичээд үйлдлийн системдээ холбон бүртгүүлэхэд л хангалттай. Бидний өдөр тутмын ажилдаа хэрэглэдэг Word, Excel гэх мэт программ дотор юуг ч өөрчлөх шаардлага гарахгүй. Энэ бол үйлдлийн системийн ид шид, бүр тодруулбал хэв маягийн гайхамшиг. Яг энэ үүднээсээ, үйлдлийн систем зохион бүтээнэ гэдэг тийм ч хэцүү ажил биш. Үндсэн араг ясаа босгоод хөтлөгч программууд бичих ажлыг тоног төхөөрөмж үйлдвэрлэгч пүүсүүдэд хариуцуулчихна. Олон программ зэрэг ажиллуулах асуудал бий. Үүнийг ч бас тоноглолын түвшинд шийдэн тухайлбал процессор үйлдвэрлэгч пүүсүүдэд даатган хариуцуулах боломжтой. Ингэж үзвэл хүмүүсийн хүнд хэцүү гэж бодоод байдаг үйлдлийн системийг хүмүүсийн маш амархан гэж бодоод байдаг вэб программ бичихээс ч хурдан, хялбархнаар босгож болно. Харамсалтай нь амьдрал дээр ийм байж чаддаггүй, учир нь асуудлын гол нь алгоритм юмуу код бичихдээ биш харин огт өөр зүйлд оршдог.

Аливаа ажлыг хийхэд тогтсон жишиг, стандарт арга, техник гэж нэг юм заавал байдаг. Тиймээс стандарт техник ашиглан программыг богино хугацаанд чанартай бүтээж болно гэж үздэг. Уг нь бол зөв санаа. Гэхдээ юуг стандарт гэж тооцох вэ гэдэг дээр асуудал бий. Нэг систем хийгээд тодорхой туршлага хуримтлууллаа, дараагийн системийг илүү хурдан чанартай хийнэ гэж ярьдаг. Боддог л бодол. Гэвч амьдрал дээр асуудал илүү түвэгтэй. Жишээ нь ямар нэгэн шинэ барилга, эсвэл машины шинэ загвар бүтээх асуудлыг авч үзье. Уул нь нэг загвараас өөр нэг шинэ загвар руу шилжилт хийхэд нэг их сүртэй өөрчлөлт гардаггүй. Хялбарчлаад бодоход суурь загвар дээрээ бага зэрэг засвар оруулаад л шинэ загвар босгоод ирнэ. Их л бага хугацаа зарцуулмаар. Гэвч амьдрал дээр шинэ загвар гаргах хугацаа нь хуучин загвар бүтээсэн хугацаанаас нэг их богино байж чаддаггүй. Энд дахиад л чанарын асуудал, найдвартай, баталгаатай байх асуудал хөндөгдөнө. Зарим хүн өмнөх туршлага дээрээ тулгуурлан жилийн ажлыг хагас жилд багтаан хийлээ гэх юмуу гурван сар бичих программыг нэг сарт амжууллаа хэмээн сайрхах маягтай ярьдаг. Энэ бол маш харьцангуй ойлголт. Ерөөс гурван сар бичих программыг нэг сарын дотор бичнэ гэдэг нь өөрөө маш том асуудал. Энд ямар нэгэн зүйл худлаа байна гэсэн үг. Ямар нэгэн ажлыг хийхэд зайлшгүй зарцуулах хугацаа, зайлшгүй хийх ёстой ажлууд гэж байдаг. Үнэхээр бүх ажлаа бүрэн гүйцэд хийсэн үү гэдэг тун эргэлзээтэй. Тухайн ажлыг найдвартай, баталгаатай хийж дуусгахад хүрэлцэхүйц хугацааг төслийн суурь хугацаа болгон авдаг. Ихэнхи тохиолдолд энэ хугацаа сунжирдаг. Гэтэл энэ хугацаанаас хамаагүй богино хугацаанд ажил дуусна гэдэг нь цаанаа маш том асуудал, том ангал үүсгэнэ. Жишээ нь олон хүмүүсийн хүслэн болсон Windows Vista үйлдлийн системийг аваад үзье. Үүнийг эхлээд 2005 онд багтааж дуусгана гэж төлөвлөсөн, дараа нь 2006 онд багтаан дуусгах тухай ярьж байна, гэтэл зарим хүмүүс 2007 оны долоо, найман сард дуусгах нь зохистой хэмээн үзэж байна (үз: www.joeuser.com/index.asp?AID=125779). Өөр нэг жишээ. Олон хүн MySQL гэж юу байдгийг мэднэ. Энэ бол өгөгдлийн сан байгуулах зориулалт бүхий систем. Хэдийгээр энэ систем үнэгүй систем мөн боловч үйлчилгээ нь төлбөртэй. Бусад бүх системийн адил, энэ системд өөрийн гэсэн сул талууд, өвчин эмгэгүүд бий. Мэдээж хэрэг ямар асуудал гарахад хэрхэн яаж шийдэх талаар үнэгүй гарын авлага, сурах бичиг интернетээр дүүрэн байгаа. Гэвч яг бодит амьдрал дээр үүсэх асуудлыг юунаас болов, хэрхэн яаж эмчлэх талаар хэн ч хэлж чадахгүй. Хэрэв төлбөртэй үйлчилгээ авахаар гэрээ байгуулсан бол нарийн мэргэжлийн "эмч" нартай хамтран үүссэн асуудлыг хурдан шийдэх боломж бий (үз: www.mysql.com/consulting/). Товчоор хэлэхэд код бичих, дараа нь бичсэн кодоо арчлан хамгаалах хоёр бол хоёр өөр асуудал.

Магадгүй, энэ дэлхий дээр хамгийн хурдан өөрчлөгдөж, хамгийн эрчимтэй хөгжиж байгаа салбар бол мэдээллийн технологи. Энэ үүднээсээ нэг үүссэн асуудал дараа дахин тохиолдоно гэж бараг байдаггүй. Бид цаг ямагт цоо шинэ асуудлуудтай тулгарч байдаг. Цаг хугацаа давчуу байна, шинэ хүмүүс туршлага багатай байна гэсэн яриа олонтаа гардаг. Тиймээ энэ бол үнэн гэж шууд хэлэхэд хэцүү. Арван ажлыг хагас дутуу мэддэг байснаас нэг ажлыг сайн хийдэг байсан нь хавьгүй дээр гэж нэг үг бий. Багаар ажиллана гэдэг нь хэн ч юу ч хийж болно гэхээсээ илүү хүн аль нэг салбараар дагнаад хөдөлмөрөөрөө хоршин ажиллахын нэр юм. Чухамдаа хөдөлмөрийн хуваарь ингэж нарийсан төрөлжсөний үрээр орчин үеийн программын бэлэн бэлдцүүд, эд ангиуд бий болсон түүхтэй. Өнөөдөр хүмүүс код бичнэ гэхээсээ илүү код эвлүүлэх, угсрах ажил түлхүү хийдэг болсон нь яах аргагүй технологийн том дэвшил. Наад зах нь код үйлдвэрлэнэ гэдэг утгаараа дэлхийн хамгийн гарамгай программ зохиогч, сургууль төгсч буй шинэхэн оюутан хоёрын хоорондох хөдөлмөрийн бүтээмжийн ялгаа бараг арилсан. Үүссэн асуудлыг шинэхэн оюутан илүү хурдан илрүүлж, илүү хурдан засаж залруулж болохгүй гэх газаргүй. Хамгийн гол нь аль нэг чиглэлийг тууштай барьж дагнах хэрэгтэй. Зөвхөн энэ нөхцөлд хүний хөгжлийн тухай асуудлыг бодитойгоор ярьж болно. Зүйрлэбэл, чихний эмч хүн чихний эмгэг, түүнийг хэрхэн эмчлэх тухай бусдаас илүү ихийг мэдэх бол зүрхний эмч хүн зүрхний асуудлыг чихний эмчээс хамаагүй сайн мэднэ. Чихний эмчийг зүрхний эмчтэй харьцуулаад энэ нь илүү, тэр нь дутуу гэж үнэлэх хэцүү. Тэгэхлээр ямар нэгэн системийг ганцаараа, эсвэл хоёр, гурван хүн нийлээд хийлээ гэвэл энэ нь бахархал гэхээсээ илүү түгшүүр, болгоомжлолыг төрүүлнэ. Учир нь юм бүхнийг мэддэг хүн гэж байхгүй, байх ч боломжгүй.

Программын арчилгаа, маллагааны асуудал яагаад ийм чухлаар тавигдах эн тэргүүний асуудал болов? Юуны өмнө арчилгаа хийхэд маш өндөр зардал гарна. Захиалагч тал ихэвчлэн хугацааг, ялангуяа богино хугацааг чухалчлан үздэг. Ингэснээр зардал хэмнэнэ гэж ойлгодог. Энд наад зах нь хоёр асуудал үүснэ. Кодыг богино хугацаанд бичиж болно. Ийм нөхцөлд бүтээгдэхүүний чанарын баталгаа өгөх ямар ч боломжгүй болно. Код бичих зардлын 80 хувь нь чанартай холбоотойгоор, ихэвчлэн анхны хувилбар гарснаас хойш эцсийн хувилбар гарах хооронд гарна гэдгийг дахин сануулъя. Богино хугацаанд бичсэн код алдаа мадаг ихтэй байх нь мэдээж. Бичсэн кодыг шууд хараад илрүүлэх боломжгүй, зөвхөн ашиглалтын явцад уйгагүй хөөцөлдөж байж илрүүлэх тийм алдаа олон бий. Ийм алдааг засаж залруулахыг захиалагч тал гүйцэтгэгч талаас нэхэж шаардах нь зүйн хэрэг. Гүйцэтгэгч тал ч үүнийг хийх нь дамжиггүй. Гүйцэтгэгч талын хийх ажлыг гүйцэд хийлгүйгээр хугацаанаас нь өмнө ажлаа хүлээн аваад дараа нь алдаа засуулах нэрээр үлдсэн ажлыг нь үнэгүй хийлгэхийг хүсдэг захиалагчид олон байдаг. Хэрэв ийм маягаар ажил цааш үргэлжлэн, зардлын 80 хувиа гүйцэтгэгч тал өөрөө хариуцна гэвэл энэ нь гүйцэтгэгч талыг дампууралд хүргэх хангалттай үндэслэл болно. Хоёрдахь асуудал. Ажлыг үнэхээр яаралтай шахуу дуусгах шаардлага захиалагч талд гарч болно. Ийм нөхцөлд ажлын чанараа бууруулахгүйгээр богино хугацаанд чанартай бүтээгдэхүүн гаргахын тулд Extreme Programming /буюу Pair Programming/ гэдэг техник хэрэглэдэг. Өөрөөр хэлбэл нэг компьютер дээр хоёр хүн зэрэг ажилладаг. Нэг нь код бичихэд нөгөө нь хянаж, дараа нь хоёр хүн байраа солих маягаар цааш үргэлжлүүлэн ээлжлэн ажиллана. Ийм маягаар ажиллабал наад зах нь хоёр дахин олон хүн ажиллах хэрэгтэй болж цалин хөлсний зардал хоёр дахин өснө. Хэрэв захиалагч тал зардлын өсөлтийг хариуцахаас татгалзвал гүйцэтгэгч тал бас л томоохон алдагдал хүлээх таагүй нөхцөл байдал үүснэ.

Захиалагч тал захиалсан бүтээгдэхүүнээ хүлээн авахдаа юм бүхнийг мэдэх албагүй юу? Албагүй. Жишээ нь ямар, ямар технологи хэрхэн яаж ашиглав гэдгийг заавал мэдэх хэрэггүй. Гэхдээ шаардлагатай бол үүнийг нууцлах хэрэггүй. Харин зайлшгүй мэдэх ёстой юм гэж бас бий. Тухайлбал богино хугацаанд хийсэн бүтээгдэхүүн чанарын шаардлага хангахдаа муу, арчилгаа маллагаа хийхэд код бичихээс хавьгүй өндөр зардал гарна гэдгийг анхнаасаа ойлгосон, мэддэг байх ёстой. Зүйрлэбэл техникийн үзлэг, үйлчилгээ хийгээгүй, хэзээ эвдэрч хэмхрэх нь тодорхойгүй онгоцонд захиалагч түншээ суулган бүх юм хэвийн тайван зорчиж болно гэж итгүүлэх хэрэггүй. Та маш эрсдэлтэй онгоцонд сууж байгаа, асуудал үүсвэл та өөрөө хариуцна гэдэг ам өчгийг нь авч байж хөөргөх хэрэгтэй гэсэн үг. Ингэсэн нөхцөлд хожим хэрүүл, уруул дэгдэн шүүх цагдаагаар зарга хөөцөлдөн асар их хохирол гарахаас сэргийлнэ. Ямарваа тохиролцоо, түүнээс үүдэн гарах сайн, муу аливаа үр дагавруудыг талууд анхнаасаа харилцан ойлголцсон нөхцөлд л цаашдын ажил урагштай явагдана. Тухайлбал баталгаагүй кодыг шууд ашиглалтанд оруулахаас гүйцэтгэгч тал эрс татгалздаг байх ёстой. Зарим хүмүүс үүнийг баахан цаг идэж кодоо сайжруулж засаж янзлана гэдэг нэрийн дор кодоо үнэ хүргэж зарах гэж байна хэмээн хардах тал ажиглагддаг. Эсвэл ажлаа хийж чадахгүй байна гэх юмуу цааш хамтран ажиллахаас татгалзаж байна хэмээн үзэх ч тохиолдол бас бий. Үнэн хэрэгтээ, энэ бол асар их үргүй зардал гарах ёроолгүй гүн ангалд унахаас захиалагч түншээ хамгаалж буй сайн санааны хориг арга хэмжээ болой.

Код бичсэний дараа тухайн кодоо арчлан хамгаалах гэж том даваа бий, энэ нь маш өндөр зардалтай /цаг хугацаа урсан өнгөрөх тусам, цагийн зүүний хором тутам зардал улам эрчимтэй өснө/, үүнийг бууруулахын тулд код бичих хугацааг сунгах, код бичих зардлыг өсгөх /ядаж зардлаа хугацаанаас хамааралгүй болгон хязгаарлах/ хэрэгтэй гэдгийг бас дахин сануулъя. Энэхүү амьдралын гашуун үнэнийг талууд хэрхэн хүлээн зөвшөөрч үйл ажиллагаа, хамтын ажиллагаандаа бодитойгоор тусгана, үүнээс цаашдын бүх хувь тавилан хамаарна. Том, бага, дунд зэргийн систем гэлтгүйгээр кодын арчилгаа, маллагаа, чанарын асуудлыг орхигдуулснаар юуны өмнө ашиглалтын зардал эрс өснө. Тодорхой хугацааны дараа ашиглалтын зардлын хэмжээ зохистой хил хязгаараас давмагц цаашид ийм системийг үргэлжүүлэн ашиглах ямар ч боломжгүй болдог. Ихэнхи тохиолдолд захиалагч тал нь гүйцэтгэгч талтай гэрээгээ цуцлан гаднын компаниудад хандаж системээ шинэчлүүлэхийг хүсдэг. Ийм жишээ хангалттай олон бий. Энд нэг асуудал бий. Улс орон бүрийн сүлжээний хурд, хүчин чадал, компьютерийн системийн техникийн үзүүлэлт гэх мэтчилэн мэдээллийн дэд бүтцийн хөгжлийн түвшин харилцан адилгүй байдаг. Тоноглолын хөгжил нь программынхаа хөгжлөөс түрүүлж явдаг өндөр хөгжилтэй орны компаниудын хувьд нэг далайлтаар харьцангуй хүчтэй программын систем бүтээгээд түүнийгээ олон удаа ашиглах боломж бий. Харин тоноглолын хөгжил нь программын технологийн хөгжлөөс хоцорч явдаг хөгжлөөр сул орны хувьд техникийн үзүүлэлтэндээ баригдаж сулхан систем бүтээдэг, тэр нь урт насгүй байдаг. Нэг систем нь шулуун, дардан замаар давхидаг байхад нөгөө нь бартаат замаар давхидаг гэсэн үг. Хэрэв шулуун замаар явах зориулалттай машиныг бартаат замаар давхиулбал юу болох вэ гэдэг нь хэнд ч ойлгомжтой. Эсвэл дэд бүтэц харьцангуй сайн хөгжсөн нийслэл хотод үйлдвэр байгуулах, дэд бүтэц сул хөгжсөн алс бөглүү газар яг тийм үйлдвэр байгуулах хоёр ямар ялгаатай вэ гэдгийг өөрөөсөө асуугаад үз. Магадгүй шаардлагатай дэд бүтцийг бүрдүүлэх нь үйлдвэр байгуулахаасаа илүү их зардал шаардана. Товчхондоо, гаднаас авсан системийг өөрийн орчинд нийцүүлэн зохицуулахын тулд илүү их хугацаа, илүү их зардал зарцуулна. Магадгүй, хэвийн хэмжээний зардал хоёр, гурав дахин, түүнээс ч олон дахин өсөх магадлал бий. Эндээс хэн ч хожихгүй. Эцсийн эцэст, цаг хугацааг хэн ч мөнгөөр худалдан авч чадахгүй. Тиймээс хожим илүү түвэгтэй асуудал үүсэхээс сэргийлэхийн тулд захиалагч тал, гүйцэтгэгч тал хоёулаа анхнаасаа цаг хугацаа, зардал мөнгөө хангалттай тооцож төлөвлөх зайлшгүй шаардлага гарна. Ямар ч ажлыг энгийн, хялбар хэмээн дутуу үнэлж болохгүй. Энэ нь эргээд маш том асуудал үүсгэнэ.

Бидний амьдарч буй орчин бүхэлдээ цахилгаан, соронзон талбайгаар нэвт хучигдсан байдгийг зарим хүмүүс мэднэ. Нар, сар, од гаригийн хөдөлгөөнөөс хамааран энэхүү цахилгаан, соронзон талбай мөнхийн хэлбэлзэл дунд оршино. Компьютерийн систем бол цахилгаан систем гэдгийг бүгд мэднэ. Өөрөөр хэлбэл, компьютерийн систем, үүний дотор программын систем нь байгаль, цаг уурын шууд нөлөөлөл дор ажилладаг, тиймээс систем хэвийн ажиллахад саад учруулах хангалттай олон үл үзэгдэх, үл таагдах, үл баригдах дайснууд бий гэсэн үг. Чухам ийм учраас өнөө цагт алгоритмыг чухал хүчин зүйл гэж үздэггүй. Учир нь алгоритм бол ямар ч өө сэвгүй, ямар ч алдаагүй, амьдралаас тасархай хийсвэр орчинд зориулагдсан эд. Нэг ёсондоо шилэн хүлэмж дотор амьдардаг хэврэг амьтан. Ийм амьтныг хором тутам зангаа хувирган салхи, шуурга, цас мөсөөр тасралтгүй бөмбөгдөх эрс тэс уур амьсгалтай орчинд оруулбал магадгүй нэг удаагийн хамрын ханиадаар л амьсгал хураана. Математикийн салбарт өндөр амжилт гаргасан оюутнууд программын салбарт амжилт гаргаж чаддаггүйгээ гайхдгийн учир шалтгаан нь ердөө л энэ. Хийсвэр орчин, бодит амьдрал хоёр бол хоёр өөр зүйл.

Бодит амьдрал бол хэнд ч таагдашгүй нууцлагдмал орчин, бүх эрсдлийг тооцож код бичнэ гэвэл хэзээ ч дуусахгүй ажил болно гэсэн яриа бий. Нэг талаас үнэн, нөгөө талаас худлаа. Чухамдаа яг ийм тодорхойгүй асуудлыг шийдэхийн тулд, хязгааргүй шийдлийг хязгаарлагдмал шийд болгон хувиргахын тулд шинжлэх ухаан оршин тогтнодог. Жишээ нь магадлалын онолыг аваад үзье. Энэ онолоор, байгалийн ямар ч үзэгдэл тодорхой цөөн тооны тархалтын хуулинд захирагдана гэж үздэг. Тухайлбал код бичихэд зарцуулах хугацаа, гарах алдааны тоо, хэмжээ, алдаа засахад зарцуулах хугацаа гэх мэт зүйлсийг тархалтын хууль ашиглан урьдчилан тооцож болдог. Тэр ч байтугай, тухайн тохиолдолд ямар төгсгөлд хүрэх нь ашигтай вэ гэдгээ тооцон гарааны хэд хэдэн хувилбараас сонголт хийх боломж бий. Заримдаа явцын дунд нэг хувилбараас нөгөө рүү шилжиж болно. Энэ нь олон талаараа шатар, эсвэл даам тоглохтой төстэй. Чухамдаа эндээс математик, түүн дээр суурилсан эдийн засаг, төслийн удирдлага, санхүүжилт гээд олон асуудал урган гарч ирнэ.

Дашрамд хэлэхэд, зарим хүний богино хугацаанд бичсэн код ямар ч алдаа мадаггүй ажилладаг. Энэ бол баярлаж, бахархах зүйл огт биш. Харин ч эсрэгээрээ, программ алдаагүй ажиллана гэдэг нь өөрөө гаж үзэгдэл. Ийм кодыг маш муу код болжээ гэж үнэлэхээс өөр арга байхгүй. Энд ямар нэгэн зүйлийг орхигдуулсан юмуу дутуу орхигдуулсан байх магадлал маш өндөр. Хожим энэ нь юунд ч хүргэж мэднэ. Тухайн үед зөв ажиллана гэдэг нь үргэлж зөв ажиллана гэсэн ямар ч баталгаа болохгүй. Программын бүтээгдэхүүнд ихэвчлэн гурван сараас нэг жилийн баталгаа өгдөг. Үүний тулд дор хаяж зургаан сараас хоёр, гурван жил код бичих шаардлага гарна. Харин нэг, хоёр сар юмуу гурван сарын хугацаанд хийсэн программд баталгаат хугацаа өгөхийг зориглох компани олдохгүй болов уу. Гэхдээ энэ бүхнийг хүн-сартай холбон ярьж байна, мэдээж олон хүн хамтарч ажиллаад богино хугацаанд чанартай код бичиж бас болно. Хамгийн гол нь код бичихэд зарцуулах нэгж зардал бүхэн арчилгааны зардлыг магадгүй арван нэгжээр бууруулна гэдгийг ойлгох хэрэгтэй. Эцэст нь хэлэхэд кодын 80 хувийг бичихэд нийт хугацааны 20 хувь зарцуулагддаг, үлдсэн 20 хувийг бичихэд нийт хугацааны 80 хувь зарцуулагддаг гэдэг тооцоо бол зүгээр нэг хий хоосон үг биш. Программын эхний хувилбар гарсны дараа урт удаан хугацаа шаардсан жинхэнэ ажил өрнөнө гэдгийг бас дахин сануулж байна.

үргэлжлэл

Системийн инженер гэж хэн бэ?

"Good judgement is the result of experience...
Experience is the result of bad judgement."
Fred Brooks

"Хашир хүн гэж хаширсан хүнийг хэлнэ."
Фред Бруукс

Нэгдүгээр хэсэг

Компюьтерын системийн үндсэн зориулалт бол мэдээлэл боловсруулах, хадгалах, дамжуулах явдал гэдэг нь хэнд ч ойлгомжтой. Харин хичнээн хэмжээний мэдээллийг ямар хугацаанд ямархуу өртөг зардлаар хэрхэн, яаж боловсруулах, хадгалах, дамжуулах тухай асуудлыг хүмүүс тэр бүр анзаарахгүй орхигдуулах тал түгээмэл ажиглагддаг. Мэдээлэл хэмээх ухагдахуун нь маш ерөнхий хийсвэр зүйл. Харин ямар мэдээлэл гэж яривал асуудал илүү тодорхой, ойлгомжтой болно. Үүний дээр тоо хэмжээ, чанарын тухай асуудал хөндөгдвөл компьютерын системийн тухай яриа бүр ойлгомжтой болно.

Жишээлбэл байшин гэж юу болохыг бүгд мэднэ. Харин тухайлбал байшин барих тухай асуудал гарвал ямар байшин барих тухай яриа заавал өрнөнө. Учир нь байшин бүхэн адилгүй. Яг адилхан зураг төслөөр баригдах байшин байсан ч төслийн удирдлага, зохион байгуулалт, өртөг зардал өөр өөр байж болно. Тухайн барилгын байршлаас хамааран наад зах нь тээвэрлэлтийн өртөг зардал өөрчлөгдөнө. Бас ажлыг хийж гүйцэтгэх хугацаанд ч өөрчлөлт гарч болно. Банкны зээлийн хүү нь нийт зээлийн мөнгөн дүнгээс гадна зээлийн хугацаанаас хамааран хувьсан өөрчлөгдөнө. Энэ нь бас л барилгын өртөг зардал, удирдлага, зохион байгуулалтанд нөлөөлнө. Тухайн байшин эрчим хүчний шугам, цэвэр болон бохирын төвлөрсөн хоолойноос хэр хол, ойр байрлаж байна гэдэг нь барилгын өртөгт дахиад л нөлөөлнө.

Өнөө үед барилгын олон ажлыг хөнгөвчлөх, хурдасгах олон янзын багаж, хэрэгслэлүүдийг ашигладаг. Ийм багажуудыг ажиллуулах цахилгааны эх үүсвэрийг яаж шийдэх вэ? Мэдээж дизель юмуу бензинээр ажилладаг цахилгаан үүсгүүр ашиглавал төвийн шугамаас эрчим хүч татан хэрэглэхээс үнэтэй тусна. Цахилгаан үүсгүүрүүд нь хүчин чадлаасаа хамааран нэг цагт хичнээн литр шатахуун зарцуулах нь харилцан адилгүй. Хэрэв цахилгаанаар ажилладаг багажуудыг аль болох нэгэн зэрэг ажиллуулахаар ажлаа зохицуулж чадвал өндөр чадлын цахилгаан үүсгүүр ашиглах нь зардал хэмнэх боломж олгоно. Мэдээж өндөр чадлын цахилгаан үүсгүүр ажиллуулаад түүгээрээ цөөн хэдэн /бага чадлын/ багаж ажилуулбал өртөг зардал огцом өсөх нь ойлгомжтой. 40 тоннын даацтай "Белаз" юмуу 10 тоннын даацтай "Камаз" машин дээр 100кг жинтэй 2 шуудай мод ачаад 100 км газар тээвэрлэхгүйтай л адил. Тэгвэл маш их зардал гарна.

Барилгын нэг шугам зураг өгөөд яг ийм зургаар ийм байшинг төдий хугацаанд ийм зардалд багтаан босго гэсэн захиалга өгөхөд дундаж өртөг баримталж болох тал бий. Гэхдээ хэрэв чанарын тухай асуудал яригдвал асуудал шал өөрөөр эргэнэ. Чанар гэдэг ухагдахуунд баталгаат хугацаа гэсэн ойлголт заавал яригдана. Бид чанарын тухай асуудлыг ярихын тулд тухайн байшин барих газрын бүтцийн тухай асуудлыг зайлшгүй ярина. Газрын бүтэц, үе давхрага нь ерөнхий ойлголт болохоос бус яг тухайн газар бүртээ харилцан адилгүй шинж чанартай. Жилийн дөрвөн улирлаа дагаад газрын гүнд ямагт хөдөлгөөн, урсгал явагдаж байдаг. Энэ урсгалын хурд, шинж чанар, хөдөлгөөний чиглэл, хүч гэх мэт үзүүлэлтүүд нь хөрсөнийхөө бүтэц, эргэн тойрны байгалийн тогтоц /уул, ус, мод/ зэргээс хамаарна. Бид ийм үзүүлэлтийг сайтар мэдэж байж, зөв тооцож байж барилгынхаа суурийг таарч тохирох материалаар нь зөв тавина. Үүний дээр тухайн орчныхоо салхины чиглэл, агаарын урсгал, чийгшэл, дулааны хэм, гэрлийн тусгал гэх мэтчилэн бусад олон хүчин зүйлсийг харгалзан үзэж байж барилгын ханаа ямар материалаар барихав, барилгын зуурмаг, цемент нь ямар найрлагатай байх юм, цахилгааны утас нь ямар утас байхав, цахилгаан болон соронзон орны нөлөөлөл, аянгын хамгаалалт, газардуулга гэх мэтчилэн бусад бүх тооцоог нарийвчлан үйлдэж хийнэ. Зөвхөн ийм нөхцөлд л бид чанарын тухай асуудлыг бодитойгоор ярьж болно. Энд барилгын дундаж өртгийн тухай ярих бараг боломжгүй болно. Учир нь энд өчүүхэн жижиг мэт санагдах аливаа ялгаа, өөрчлөлт нь чанарын шаардлагад маш хүчтэй нөлөөлж өртөг зардал, гүйцэтгэлийн хугацаанд дорвитой гүнзгий нөлөө үзүүлнэ. Жижиг барилга дээр ялгаа нь анзаарагдахгүй байж болно, харин томоохон барилгын хувьд өчүүхэн төдий өөрчлөлт нь зарчмын асуудал болон хувирна. Тэгэхлээр барилгын шугам зураг зурна гэдэг нь нэг асуудал, харин түүний дагуу барилга барьж босгоно гэдэг нь тусдаа бас нэг шал өөр асуудал. Тэр байшинг энэ зургаар ийм хугацаанд ийм зардлаар босгосон, тиймээс энэ байшинг бараг адилхан барих ёстой гэж үзэх нь амьдрал дээр бараг боломжгүй зүйл. Харин жижиг хороолол, хотхон босгоход дундаж өртгийн зарчим, дундаж хугацааны зарчим баримтлахад болохгүй гэх газаргүй.

Зарим хүмүүс чанарын тухай ойлголтыг мөнгөтэй шууд холбож үздэг. Тухайлбал, үнэтэй, чанартай материалыг мөнгөөр зодож аваад хаана ч, юу хүссэнээ барьж босгож болно гэж зүтгэдэг. Энэ бол дэндүү хялбарчилсан гэнэн мөрөөдөл. Чанар гэдэг нь эцсийн дүндээ орчноо хэр таньж мэдэв, материалаа хэр оновчтой зөв сонгож чадав гэсэн ганцхан асуудал байдаг. Хэрэв орчноо зөв таньж тохирох материалаа оновчтой сонгож чадаагүй бол хичнээн үнэтэй, хичнээн чанартай материал хэрэглээд ч амжилт олохгүй. Магадгүй, бүр эсрэг үр дүн үзүүлж болно. Аливаа төслийн амин сүнс нь төслийг хийж гүйцэтгэхэд зарцуулах хугацаа байдаг. Хэрэв хугацаа хэтэрвэл алдагдал хүлээнэ. Энэ бол бизнесийн хууль. Төслийн хугацааг богиносгох сонгодог арга нь аль болох олон ажлыг нэгэн зэрэг хийж гүйцэтгэх явдал байдаг. Энэ нь бөөний худалдаа эрхлэх, эсвэл бөөнөөр үйлдвэрлэхтэй агаар нэг ойлголт. Тухайлбал үйлдвэрлэлийн зардал тооцоход тогтмол зардал, хувьсах зардал гэсэн 2 ялгаатай ойлголт байдаг. Тогтмол зардлын тоо хэмжээ, мөнгөн дүн нь үйлдвэрлэж буй бүтээгдэхүүний тоо хэмжээнээс үл хамаарна. Жишээ нь байрны түрээсийн үнэ нь гол төлөв тогтмол хэмжигдэхүүн байдаг. Хичнээн их эсвэл хичнээн бага бараа үйлдвэрлэхээс үл хамааран түрээсийн үнэ хувирахгүй. Бүтээмж хэдийчинээ өндөр байна, нэгж хугацаанд хичнээн их ажил хийнэ, нэгж бараанд ноогдох тогтмол зардлын хэмжээ төдийчинээ бууна. Хувьсах зардлын хувьд бол ойлгомжтой. Хэдийчинээ их тоосго үйлдвэрлэнэ төдийчинээ их элс хайрга, шавар, шохой, тээвэрлэлт шаардагдана. Үүнийг хүн бүхэн мэднэ. Харин хүмүүсийн анзаардаггүй орхидог нэг чухал сэдэв бий. Энэ бол чанартай холбоотой асуудал. Ажлаа хурдан дуусгана гэдэг нь ямар нэгэн ажлыг дутуу дулимаг хийх, эсвэл алгасан харайхын нэр биш. Тухайлбал байшингийн суурь цутгах, баганууд босгох, хана өрөх, дээвэр тавих гэх мэт ажлууд тодорхой дарааллаар, тодорхой хугацаагаар үргэлжлэн хийгдэнэ. Сууриа цутгаад хатаж бэхжиж гүйцээгүй байхад нь баганын ажил юмуу ханын ажлаа хийгээд эхэлбэл тухайн үедээ юм мэдэгдэхгүй байж болох боловч хожим маш ноцтой үр дагаварт хүргэж мэднэ. Ажлын хатуу дараалал баримтлана гэдэг нь зарим ажлыг зэрэг хийж болохгүй гэсэн үг биш. Суурийн ажлаа хийж байхтай зэрэгцүүлээд ханаа үйлдвэрлэх, тээвэрлэх, эсвэл дээврийн эд ангиудыг угсрахад бэлтгэх гэх мэтчилэн ажлыг зэрэг хийж байж болно. Хэрэв барилгын талбайд зай хомс байвал овор ихтэй хана, туурга гэх мэт бэлдэц, хийцүүдийг барилгын ажилд хүлээлгэ, дараалал үүсгэхгүйгээр, тасралтгүй урсдаг байхаар тээвэрлэлтийг зохион байгуулж болно. Мэдээж, энэ нөхцөлд ажлын тасралтгүй, найдвартай ажиллагааг хангахын тулд удирдлага, зохион байгуулалтын зардал өснө.

Онолын хувьд олон ажлыг зэрэг хийж гүйцэтгэх нь зөвхөн хугацаа хэмнээд зогсохгүй өртөг, зардлыг бууруулна. Гэвч амьдрал дээр ийм боломж маш хомс. Энд дахиад л чанарын шаардлага босч ирнэ. Орчин үед бараа, бүтээгдэхүүний үйлдвэрлэлийн хэмжээ, чанарыг дээшлүүлэхийн тулд автомат шугам, үйлдвэрийг өргөн хэрэглэх практик бий. Гэхдээ энд нэг асуудал бий. Учир нь өнөөгийн ямар ч автомат шугам зуун хувийн чанарын баталгаатай бараа үйлдвэрлэж чаддаггүй. Гологдол заавал гарна. Энэ бол хууль. Хэдийчинээ өндөр бүтээмжтэй ажиллана, төдийчинээгээр гологдол олж илрүүлэх нь улам түвэгтэй болно. Энд зуу, мянга, эсвэл арван мянган бараанд ноогдох дундаж гологдол гэсэн ойлголт хэрэглэдэг. Үйлдвэрлэлээс гарч буй бараан дотроос дундаж хэмжээний гологдол олж илрүүлэх ёстой, үлдсэн бараа нь чанартай бараа гэсэн тохиролцоо байдаг. Харин дундаж хэмжээг бодож гаргах олон статистик аргачлал бий. Ихэвчлэн асар олон бараан дотроос тодорхой тооцоогоор хэсэг барааг түүвэрлэн аваад хэмжилт хийнэ. Миний энд хэлэх гэсэн гол санаа бол тухайн ажлыг машинаар хийх үү, эсвэл хүнээр хийлгэх үү гэдгээс үл хамааран хэдийчнээ олон ажлыг нэгэн зэрэг хийж гүйцэтгэнэ, хэдийчинээ өндөр бүтээмжтэй хурдан ажиллана, ажлын алдаа, дутагдал, доголдол гарах магадлал төдийчинээ өснө, гологдол, дутагдлыг олж илрүүлэх засаж залруулах нь төдийчинээ нарийн түвэгтэй болно. Магадгүй ямар нэгэн гологдлыг хугацаа алдаж илрүүлээд, үүнээс болж хожим маш ноцтой асуудал үүсэхийг үгүйсгэхгүй. Тэгэхлээр чанар, хугацаа хоёрын хооронд шууд эерэг хамаарлаас гадна урвуу сөрөг хамаарал бас бий. Хоёр ижил цэнэгийг ойртуулбал түлхэлцэж, холдуулбал таталцдагтай л адил төстэй гэсэн үг. Өөрөөр хэлбэл, ямар нэгэн төслийг хэрэгжүүлэхэд сонголтын хязгааргүй эрх чөлөө гэж байхгүй, харин эсрэгээрээ алтан дундаж буюу зохистой ганц цэгийг олох явдал байдаг. Үүнийг оновчлолын бодлого гэж нэрлэдэг. Ийм бодлого гол төлөв нэг шийдтэй, цөөн тохиолдолд хоёр шийдтэй байж болно, эсвэл ямар ч шийдгүй, өөрөөр хэлбэл биелэх боломжгүй байж бас болно.

Оновчлолын бодлого бол инженерийн урлагын амин сүнс юм. Гар хуруугаа ашиглана уу, савх, сампин, тооны машин, компьютер, ер юу ашиглахаас үл хамааран хоёр дээр хоёрыг нэмэхэд хариу нь ямагт дөрөв гарна. Бүр тодруулбал тухайн инженер ямар ч арга хэрэглэсэн бай, тухайн тооцооны шийд нэг л гарна. Хэрэв уг инженер тооцоон дээрээ алдаа гаргаагүй л бол бусад хүмүүс шийд нь зөв байна уу, буруу байна уу гэдгийг давхар тооцон шалгаж болдог. Энэ үүднээсээ, тухайн инженерийн үгийг тэр хүний, эсвэл энэ хүний хувийн үзэл бодол гэж үзэхээсээ илүүтэйгээр тухайн системийн онцлог гэж ойлговол илүүтэй зохино. Өөр хэн ч байсан тэгэж л хэлнэ, тэгэж л дүгнэнэ. Тэгэхлээр системийн инженер гэдэг хүн бол нэг ёсондоо дээд тэнгэрийг газар дэлхийтэй холбон өгч буй гүүр, хэлмэрч гэж ойлгож болно. Хэрэв тооцоо зөв бол амьдрал дээр гарах үр дүн нь урьдчилан бодож тооцсон тооцоотойгоо яг мөргөнө. Үүнийг л шинжлэх ухаан гэж нэрлэдэг.

Шинжлэх ухааны дүгнэлтийг жишээ нь зам барих төсөл дээр тоймлон авч үзье. Онолын хувьд ямар ч орчин, ямар ч цаг уур, ямар ч газар таарах замын материал гэж байхгүй. Энэ нь оновчлолын бодлогын нэг ёсны мөрдөлгөө юм. Ямар ч өвчнийг анагаах цорын ганц эм гэж байдаггүйтэй л адилхан. Тухайн хүний нас, хүйс, өвчний онцлог, улирлын шинж байдлаас хамааруулан цөөн тооны суурь хэдэн эмийг /үүнийг эмийн хөл юмуу тан гэх мэтчилэн нэрлэдэг/ тодорхой харьцаагаар, тодорхой тунгаар хольж найруулаад маш олон төрлийн өвчнийг анагааж болно. Яг л хөгжмийн долоон эгшгээр олон янзын хөг, аялгуу, дуу хуур үүсгэхтэй адил. Зам барихад зарчим нь яг адилхан. Тухайн газар орны онцлог, өндөр, нам, налуу, хөрсний хатуу, зөөлөн, газрын гүний хөдөлгөөний шинжүүд гээд олон үзүүлэлтээс хамааруулан хучилтын зузаан, замын олон үе давхрагуудын хэм хэмжээ, материалын хольц, найрлага тун гээд олон зүйлийг зам барихаасаа өмнө урьдчилан тооцож бодно. Ийм тооцооны шийд нь хэн яаж тооцон бодохоос үл хамааран нэг л байна. Мэдээж олон хувилбартай тооцоо хийж болно, гэхдээ тухайн хувилбар бүрийн хувьд шийд нь ганц л байна. Аль ч хувилбарыг сонголоо гэсэн чанарын шаардлага өөрчлөгдөхгүй. Тухайн сонгосон хувилбар шаардлага хангаж буй эсэхийг хэмжилт, туршилт хийх замаар тогтоож болно. Үүний тулд тавьсан замаа эхнээс нь дуустал нэг бүрчлэн шалгах шаардлагагүй. Түүвэр судалгааны арга хэрэглэн тодорхой цэг, зурвас газрыг шалгалтанд хамруулж болно. Ингэхдээ магадлалын онолоор /нэг ёсондоо шоо хаяна/ дээж болох цэгүүдийг сонгон авах боловч ийм сонголтын шийдийг ч бас хоёрдмол утгагүйгээр тооцон гаргах боломж онолын хувьд бас бий. Эцсийн дүндээ ажлын үр дүн, чанар гэдэг зүйл маань хүний хүчин зүйл гэхээсээ илүүтэйгээр инженерийн тооцоо хэр үнэн зөв хийхээс ихээхэн хамаарна.

Одоо чадлын тооцооны талаар бяцхан яриа өрнүүлье. Жишээ нь бид байшин барихын тулд эхлээд орон сууцны барилга уу, үйлдвэрлэл, үйлчилгээний зориулалттай барилга уу, хэдэн айлын сууц юм, хэдэн давхар байх юм гэдгээ тодорхойлно. Эндээс бүх тооцоо эхэлнэ. Ямар материалаар, хичнээн хүн сарын ажил хийж хэр их зардал гарах вэ гэх мэт. Энэ бол ойлгомжтой. Арай өөр түвэгтэй жишээ татъя. Жишээ нь нисэх төхөөрөмж бүтээх тухай асуудал гарчээ гэж бодъё. Мэдээж хэрэг, хамгийн түрүүнд даацын тухай асуудал яригдана. Нэг хүний суудалтай юмуу хоёр хүний суудалтай юмуу, эсвэл хорин хүн юмуу тавин хүний суудалтай байх уу? Нэг хүний суудалтай бол бүхээгтэй байх уу бүхээггүй байх уу? Ямар өртөгтэй байх юм? Хөдөлгүүр нь ямар багтаамжтай байх юм, шатахууны нэг цэнэглэлтээр хир хол зай туулах юм? Агаарын давхрага бүр хоорондоо ялгаатай, тэгвэл ямар өндөрт хөөрөх юм гэх мэт асуултууд бас гарна. Агаарын урсгал дотор өдөр тутам байнга тохиолдох үзэгдлүүдээс гадна үе үе тохиолдох ховор үзэгдлүүд гэж бас байна. Нэгэнт л бид цаг уурын үзэгдлийг өндөр нарийвчлалаар урьдчилан харж чадахгүй тул иймэрхүү гэнэтийн үзэгдлийг даван туулдаг байхаар тооцоо хийх ёстой. Үнэн чанартаа нэг биш, харин хэд хэдэн нисэх төхөөрөмжийг нэгэн зэрэг зохион бүтээнэ гэсэн үг. Харин бусад хүмүүст энэ нь нэг л төхөөрөмж болж харагдана. Мэдээж хэрэг, 500 зорчигчтой онгоцны хөдөлгүүрийг 1 хүний суудалтай нисэх төхөөрөмжид суурилуулахгүй. Компьютерын систем бүтээх зарчим үүнтэй яг ижилхэн. Харамсалтай нь хүмүүс үүнийг тэр бүр ойлгодоггүй, программ л бол программ, хоорондоо бүгд адилхан гэж боддог. Тийм зүйл огт байхгүй.

Шатар, даам, эсвэл хөзөр гэж ямархуу тоглоом байдгийг бүгд мэднэ. Жишээ нь шатрын хөлөг, хүү, морь, тэрэг гээд шатрын боднууд бол шатар гэдэг тоглоом өөрөө биш, харин энэ тоглоомыг тоглоход хэрэглэгддэг эд материал төдий зүйл. Программ, бүр тодруулбал программыг бүрдүүлэгч кодууд бол компьютерын системийг бүтээхэд хэрэглэгдэж буй нэг л төрлийн шатрын бод маягийн зүйл. Гэтэл олон хүмүүс программын кодыг программ гэж ташаа ойлгодог. Үнэн хэрэгтээ, программ зохионо гэдэг нь тоо бодохын нэр. Барилга барих, онгоц, машин, гар утас үйлдвэрлэхэд бас адилхан тоо бодно. Нэг хүний суудалтай онгоц, эсвэл зуун хүний суудалтай онгоцны ялгааг хэн ч хараад мэднэ. Эсвэл автобусны зогсоол дээр байгаа ТҮЦ, их дэлгүүрийн өндөр барилга хоёр бол хоёулаа адилхан байшин мөн боловч нэг нь үнэтэй, нөгөө нь хямдхан, нэг нь ганц хоёр хүний багтаамжтай, нөгөө нь хэдэн зуу, мянган хүний багтаамжтай гэдэг ялгааг ямар ч хүн хараад шууд хэлнэ. Үүний тулд ямар нэгэн тоо бодох ч хэрэггүй, бараг мэдээжийн ойлгомжтой зүйл. Үүний нэгэн адил компьютерийн системийн хүчин чадлын үзүүлэлт нь системийн инженерийн хувьд ердийн л ойлгомжтой зүйл. Жолооч хүн жолооны А, B, C, D ангиллын үнэмлэх гэж юу вэ гэдгийг мэддэгтэй л бараг ижил. Харин мэргэжлийн бус хүмүүсийн хувьд энэ бол маш учир битүүлэг, огт ойлгомжгүй зүйл болох нь тодорхой.

Хүмүүсийн огт мэдэхгүй, ойлгохгүй зүйлээр яаж тэдэнтэй харьцаж ажлын гэрээ, хэлцэл хийх вэ гэсэн асуулт урган гарна. Үүний хариулт нь макет буюу үлгэр хийх явдал. Жишээ нь барих барилгынхаа загварыг цаасаар ч юмуу картон эсвэл фанер гэх мэт хямд төсөр материалаар хэмжээг нь хэд дахин багасган хийгээд үүн дээрээ захиалагч, гүйцэтгэгч хоёр харилцан ярилцаж эцсийн хувилбараа тохиролцон шийдэж болно. Эндээс барилгын өртөг зардал, хугацаа гээд маш олон зүйлийг хөөн олж болно. Мэдээж, ийм үлгэр дотор хүн амьдрахгүй гэдэг нь ойлгомжтой. Компьютерын систем бүтээхэд хэрэглэгддэг үлгэр ч бас ялгаагүй. Ийм үлгэрийг бүтээхэд айхтар их хугацаа, өртөг зардал гарахгүй. Энэ бол нэг базахад л нурж унах, ямар ч насгүй, хэврэг систем. Гэтэл захиалагч нар ийм системийг хармагцаа бодлоо өөрчлөх, хүслээ тулгах хандлага элбэг тохиолддог. Тэдний хувьд үлгэр (prototype), амьд систем хоёр огт ялгаагүй адилхан зүйл болж харагддаг. Тухайлбал, хамгийн хурдан, хамгийн хөнгөн, хамгийн олон үйлдэлтэй, хамгийн өндөр хүчин чадалтай, хамгийн уян хатан, хамгийн хямд гэх мэтчилэн зөвхөн мөрөөдөж болох бүх хүслийг нэг дор шаардах тохиолдол бий. Үлгэрлэвээс, өднөөс хөнгөн хэрнээ агуу хүч чадалтай, асар холыг туулах чадвартай мөртлөө ямар ч шатахуун хэрэглэдэггүй онгоц бүтээх, гэхдээ үүнийг ахар богино хугацаанд туйлын хямд зардлаар босгох хүсэлтийг тавьдаг. Богино хугацаанд бүтээсэн системийн үлгэр нь ийм шаардлага тавьж болох мэт хуурамч сэтгэгдэл төрүүлдэг. Гэтэл тухайн үлгэрт тусгагдсан системийг жинхэнэ амьд систем болгон хувиргахын тулд хичнээн их хүч, хөдөлмөр, цаг хугацаа зарцуулагддаг болохыг захиалагчид огтхон ч төсөөлдөггүй. Долоо хоногийн дотор үлгэрийг нь босгосон бол сарын дотор гэхэд системийг бүрэн ашиглалтанд оруулна гэж тэд төсөөлдөг. Зүйрлэбэл, хорин давхар барилгын макетыг /цаасаар ч юмуу картоноор хийсэн/ долоо хоногийн дотор босгосон юм чинь сарын дотор хорин давхар байшинг босгож болно гэж сэтгэхтэй агаар нэг.

Чанар гэдэг ухагдахууныг тодорхой систем, тодорхой шийдэл дээр л бодитойгоор ярьж болно. Харин чанартай бүтээгдэхүүний төлөө, чанартай техникийн төлөө гэх мэт ерөнхий үгс бол ердөө уриа дуудлага, лоозон маягийн л зүйл. Техникийн зүйлчлэл /ямар?/, шаардлага тодорхой болсны дараа, харилцан зөвшилцөж тохиролцсоны дараа сая чанарын асуудал босч ирнэ. Бүх зүйлээ тохиролцсоны дараа тухайн системийг бүтээн босгох хамгийн оновчтой шийдлийг бодож гаргана. Энэ нь хатуу биеийн хүндийн төвийг олохтой бараг адил. Хүндийн төв дээрээ тухайн хатуу биет хамгийн тогтвортой удаан хугацаагаар оршин байж чадна. Хэрэв хүндийн төв өөрчлөгдвөл /ямар нэгэн гаднын нөлөөгөөр/ нурж унах аюул нүүрлэнэ. Үүнийг зүүний үзүүр дээр тэнцвэрийн цэгээ олон тогтож буй өндөгтэй адилтган зүйрлэж бас болно. Системийн үлгэр гаргахад оновчлолын бодлого бодох, хүндийн төвийг олох гэх мэт асуудал гардаггүй. Энэ бол ердөө л санал солилцох үзүүлэн маягийн эд. Ийм үлгэр дээр юм нэмэж, хасаж, өөрчилж болно. Тэглээ гээд ямар ч аюул учрахгүй. Харин тооцоо нь бодогдоод ажил нь нэгэнт эхэлчихсэн систем дээр өөрчлөлт оруулах нь араасаа маш өндөр эрсдэл дагуулна. Хүндийн төв ялимгүй хазайхад л бүх систем нуран унана. Зарим тохиолдолд нэг ёсондоо уран нугаралтын гайхамшгийг үзүүлэн системд өөрчлөлт оруулан хүндийн төвийн шинэ цэг рүү шилжилт хийж болох тал бий. Гэхдээ үүнд бас л их хугацаа орно.

Эхлээд нэг систем гаргаад явцын дунд юм нэмэж, хасаад тодорхой хугацааны дараа хүлээлгэн өгөх тухай яриа элбэг тааралддаг. Магадгүй зарим нэгэн ганц хэрэглэгчийн систем бүтээхэд иймэрхүү хандлага хэрэглэж болох юм. Системийн үлгэр гаргахад ч ийм арга ашиглаж бас болно. Харин олон хэрэглэгчийн систем бол огт өөр асуудал. Энд тэнцвэрийн цэгийн асуудал маш хурцаар тавигддаг. Арай өөр, ойролцоо жишээ авъя. Танд хэн нэгэн хүн эхлээд амбаар барих захиалга өгчээ гэж бодъё. Та амбаараа бариад дуусах дөхөж байтал гэнэт ерөөсөө амбаараа болиод шилэн ТҮЦ баръя гэсэн хүсэлт тавьжээ. Мэдээж та жаахан уурлаж байгаад амбаараа нураагаад шилэн ТҮЦ болгон өөрчилнө. Гэтэл шилэн ТҮЦ-ээ дуусахын даваан дээр захиалга дахин өөрчлөгдөж шилэн ТҮЦ биш, харин хоёр давхар барилга барих төлөвлөгөө болон өөрчлөгдөнө. Та дахиад л шилэн ТҮЦ-ээ нураан дэлгүүрээ дахин шинээр барьж эхлэнэ. Дараа нь хоёр давхар барилга нь хорин давхар барилга болон өөрчлөгдөнө. Дахиад л өмнөх барьснаа нураагаад суурь, багануудаа цутгахаас эхлээд бүх ажлаа шинээр хийнэ. Системийг явц дунд нь хөгжүүлнэ гэдэг ийм утгатай. Хэрвээ барьсан, буулгасан бүх ажлын зардлыг захиалагч тал хариуцвал асуудал алга. Харин амьдрал дээр захиалагч тал зөвхөн эцсийн хүлээн авсан бараа, бүтээгдэхүүн дээрээ төлбөр төлнө, бусад зардал бидэнд огт хамаагүй гэж зүтгэдэг. Үүний дээр, бид анхны тохиролцсон ТҮЦ-ний үнээр хорин давхар барилгаа хүлээн авна, харин ч ажлаа их удаан гүйцэтгэсэн тул дээр нь нэмэж алданги тооцно гэх мэтээр асуудалд ханддаг. Тэдний хувьд амбаар босгох, хорин давхар байшин босгох хоёр яг адилхан мэт сэтгэгдэнэ. Ингэж үзэх үндэслэл бий. Гэхдээ амьдрал дээр ийм зүйл байх ямар ч боломжгүй.

Программын системийн анхны хувилбар гаргахад нийт кодын 90 хувь нь бэлэн болдог, харин үлдсэн 10 хувийг гаргахад нийт зардлын 90 хувь зарцуулагддаг гэсэн алтан дүрэм байдаг. Үүнийг шатрын гарааны онолтой адилтган үзэж болно. Тухайлбал өрсөлдөгч талууд ямар гараа харилцан сонгосноос хамааран шатрын гарааны эхний 10 - 20 нүүдэл нь стандарт нүүдлүүд байдаг учраас нэг их хүч, хөдөлмөр шаарддаггүй. Харин тоглолтын дунд үеэс жинхэнэ сунжирсан урт тоглолт эхэлдэг. Магадгүй цөөхөн нүүдэл хийж болно. Гэхдээ үүнд маш урт хугацаа зарцуулна. Үүний нэгэн адил, программын анхны хувилбараас эцсийн хувилбар хүртэл харьцангуй цөөхөн мөр /10 хувь гэж ярьдаг/ код бичнэ. Харин үүнд маш урт хугацаа зарцуулагдана. Энэ нь гол төлөв программын чанарыг дээшлүүлэхтэй холбоотой ажлууд байна. Ажлын хэмжээ нь программынхаа хүчин чадалтай шууд хамааралтай байдаг. Тухайлбал жижиг программаас /амбаар гэж бодьё/ алдаа илрүүлж засах нь том программаас /20 давхар байшин гэж тооцъё/ алдаа илрүүлж засахаас хэд дахин хурдан, хямд, хялбар байна. Зүйрлэбэл, хоёр хүний суудалтай онгоц хийх зардлаар хорин хүний ч юмуу хоёр зуун хүний суудалтай онгоц хийж чадахгүй гэдэгтэй л адил. Эсвэл нэг амбаарны үнээр хоёр давхар байшин босгож үл чадна гэдэгтэй агаар нэг. Хэрэв энэхүү гарцаагүй үнэнийг ойлгож, ойлгуулж чадвал захиалагч тал программын анхны хувилбарыг хараад, эсвэл программын явцыг хараад санаандаа орсон үйлдэл бүрийг захиалсан бүтээгдэхүүндээ багтаан оруулахыг чармайхаа болих болно. Дахин хэлье. Гарааны цэг дээр шинээр нэмэх, эсвэл өөрчлөлт оруулахыг хүссэн хүсэлт бүхэн зардлыг тухайн үйлдэлтэйгээ харьцангуйгаар 90 хувийн нэмэлт зардал авч ирнэ. Энэ бол амьдралаар шалгагдаж нотлогдсон үнэн. Үнэхээр зайлшгүй нэмэх шаардлагатай, зардлыг нь захиалагч тал хариуцна гэж хүлээн зөвшөөрсөн нөхцөлд л программд нэмэлт өөрчлөлт оруулах хэрэгтэй. Эс тэгвэл гүйцэтгэгч тал ажлаа хугацаанд нь амжуулж чадахгүй алдагдалд орно. Ялангуяа олон хэрэглэгчийн систем хийж буй нөхцөлд гүйцэтгэгч тал дампуурах магадлал маш өндөр. Нэг хэрэглэгч, арван хэрэглэгч, зуун хэрэглэгч, эсвэл мянган хэрэглэгчийн систем нь гаднаасаа харахад үйлдлүүд нь адилхан мэт санагдаж болох боловч хийх арга, технологи нь хоорондоо тэнгэр, газар мэт эрс тэс ялгаатай. Олон хүмүүс үүнийг ойлгодоггүй. Нэг хэрэглэгчийн систем бүтээснийгээ тэр даруйд нь арав юмуу зуун хэрэглэгчийн систем болгон хялбархан хувиргадаг гэж ойлгодог. Энэ бол боломжгүй. Майхан босгоход, эсвэл амбаар барихад төмөр бетон суурь юмуу багана цутгах шаардлага гарахгүй. Харин өндөр барилга барихад газар шорооны маш их ажил хийх хэрэг гарна. 1 - 2 тоннын даацтай бага оврын ачааны машины дугуй, эсвэл хөдөлгүүрийг 5 тоннын даацтай машин бүтээхэд хэрэглэж болохгүй. Үүний нэгэн адил нэг хэрэглэгчийн систем бүтээхэд хэрэглэгдэх кодыг /машины дугуй, хөдөлгүүр, хурдны хайрцаг гэдэгтэй адил программын бэлэн эд ангиуд, сэлбэг хэрэгслэлүүд гэж бий/ олон хэрэглэгчийн систем бүтээхэд хэрэглэж болохгүй. Тиймээс хийх ажлаа захиалагч, гүйцэтгэгч тал анхнаасаа сайтар тохиролцон үнэ өртөгөө шийдэх ёстой. Эцэст нь санаагаа товчлоод хэлэхэд программын үлгэр /prototype/, анхны хувилбар болон эцсийн хувилбар гэдэг ойлголтууд тус тусдаа өөр өөр ертөнцүүд. Эдгээрийг хооронд хольж хутгавал /жишээ нь анхны хувилбарыг хорь хоногийн дотор гаргалаа, тэгэхээр эцсийн хувилбар долоо хоногийн дараа л бэлэн болно гэх мэт/ хожим маш ноцтой асуудал үүснэ. Мэдээж хэрэг анхны хувилбар гарснаас хойш долоо хоног байтугай нэг хоногийн дараа ч эцсийн хувилбарыг гаргаж болно. Гэхдээ энд тэндээ эрэг шураг нь суларсан, хаа сайгүй шүүрэн шанага мэт онгорхой цоорхойгоор дүүрэн онгоцыг тэнгэрт хөөргөвөл юу болох вэ? Өнөөдөр тэнгэрт амжилттай хөөрөв гээд хүлээлгээд өгөхөд л маргааш, эсвэл нөгөөдөр нь агаарт салж унаад онгоц ч үгүй, нисгэгч ч үгүй, зорчигч ч үгүй, мөнгө ч үгүй, нэр хүнд ч үгүй, бүх зүйл дуусна. Программын системийн зарчим үүнтэй яг адилхан. Тиймээс асуудалд маш бодитой, үнэн зөв хандах хэрэгтэй. Үнэтэй системийг хямд зардлаар үйлдэж бөөн мөнгө хэмнэнэ гэж санахын ч хэрэггүй. Зардал хэмнэхийг хичээх нь зардал хэтрүүлэхээс хавьгүй их хортой үр дагавар авч ирнэ гэдгийг хэн бүхэн санаж явахад илүүдэхгүй.