Програм хангамжийн инженерчлэл

UML-ийн хичээл

2011-01-03T18:26:00.007+08:00

Жич: Үргэлжлэлийг доорх DVD хичээлээс авч үзээрэй.

Объект хандлагат програмчлалын хэлүүд - DVD сурах бичиг 2010.11.08-с худалдаанд гарлаа

2010-10-21T20:23:00.010+08:00

Ном, бичиг хэргийн томоохон дэлгүүрүүдээр худалдаалагдаж байгаа.
Лавлах утас 99016978.

Жич:
ЖАВА хэлний жишээ програм: 114 файл
С++ хэлний жишээ програм: 67 файл

Татаж авах:
Жава програмчлалын хөтөлбөр
C++ програмчлалын хөтөлбөр
DVD хичээлийн demo хувилбар

ҮНЭ: 15 000 төгрөг.

Холбогдох хаяг:
Утас: 99016978
И-Мейл: delger@stars.edu.mn

2010 оны 09.27-10.06 хооронд СУРГАЛТ болно

2010-03-03T20:25:00.021+08:00

“Програм хангамжийн төсөл (PMBOK), системийг хөгжүүлэх арга зүй(UML) ба өгөгдлийн сангийн зохион байгуулалт хийх аргачилал (Data WareHouse)” сэдэвт сургалтанд урьж байна.

Хаана: Мэдээллийн технологийн СТАРС дээд сургууль
БЗД, 2-р хороо, Капитал НИММ Аудит ХХК-ын байр 5-р давхар
/Сансарын тунелын урд талд, 33-р сургуулийн баруун талд/ Утас: 463159

Хэзээ: 2010.09.27 – 2010.10.06 өдрүүд , 17.00 – 20.00 цагуудад, нийт 40 цаг

Хэн заах: Старс сургуулийн захирал, Старсофт ХХК-г үүсгэн байгуулагч
Компьютерийн ухааны докторант Д.Дэлгэрсайхан
/99016978, delger@stars.edu.mn, www.ddelgersaikhan.blogspot.com, Танилцуулга /

Сургалтын онцлог, зорилго:
Бодит системийг жишээ болгож дадлага хийх, маш тодорхой аргачилал заах. Системийн шинжээч, төслийн менежер, өгөгдлийн сангийн администратор болох хүмүүст зориулагдана. /Хэрэглэх материалуудаар хангана/

Хэн хамрагдах:
Мэдээллийн технологийн чиглэлээр ажиллаж байгаа мэргэжилтнүүд, багш нар болон програм хангамжийн инженерчлэлээр дээд түвшинд суралцах хүсэлтэй хүмүүс. /Хүний тоо хязгаартай – дээд тал нь 20/

Төлбөр: 110 000 ₮

Бүртгэл: delger@stars.edu.mn хаягаар эсвэл холбогдох утасуудаар хүсэлт гаргана уу.
/Суралцагчдын тоог урьдчилан мэдэх шаардлага байгаа тул/
Мөн Старс дээд сургууль, сургалтын алба /2010.09.20 – 2010.09.27 хооронд/
бүтгүүлж болно.

Дэлгэрэнгүй

Хэсэгчилсэн тест /Uint test/

2009-10-15T08:29:00.004+08:00

Зарим тохиолдолд програм хангамжийг хөгжүүлэх процессын үед хэсэгчилсэн тест ба програмын кодчилолыг хамт хийх тохиолдол байдаг.
Програм хангамжийн хэсэгчилсэн болон өгөгдлийн сангийн тест, өгөгдөл бэлдэх
• Програм хангамжийн тест бэлдэх, өгөгдлийн сан үүсгэх
• Хэсэгчилсэн тест болон өгөгдлийн сангийн тестийг явуулахын тулд дэс дарааллыг бэлдэх. Програм зохиох явцаас програм зохиож дуусах хүртэл хэсэгчилсэн тестийг ямар хэлбэрээр явуулах вэ гэдгийг боловсруулна. Жиш нь: Салбаруудын удирдагч болон ажилтнуудын мэдээллийг бэлдэх гэх мэт.
Хэсэгчилсэн болон өгөгдлийн сангийн тестийг явуулах.
• Хэсэгчилсэн тест болон өгөгдлийн сангийн тестийг хийж эндээс шаардлага хангаж байгаа эсэхийг шалгах. Тестийн үр дүнг бичгээр баталгаажуулан үйлдэнэ. Мөн URD, SRS, HLD, LLD-ийн шаардлагуудыг хангаж байгааг шалгана.

Хэрэглэгчийн гарын авлага түүнтэй холбоотой бичиг баримт хийх. /Ажиллах, засвар үйлчилгээний гэх мэт бичиг баримт/
Програм хангамжийн нэгдсэн тестийн төлөвлөгөөг шинэчлэн гаргаж өөрчлөлт хийх, ө.х нэгдсэн тестнд тавигдах шаардлагыг өөрчлөж шинэчлэнэ.
Хэсэгчилсэн тестийг програм зохиогчид өөрсдөө хийдэг.
Хэсэгчилсэн тестийн үр дүнг дүгнэх. Үүнд:
• Програм хангамжийн бүтээгдэхүүнд тавигдах шаардлага болон зохиожийн эргэн шалгах бололцоог олгох
• Програм хангамжийн бүтээгдэхүүнд тавигдах шаардлага болон гадаад орчинтой зохицох
• Тухайн хэсгийн тавигдах шаардлагын дотоод зохицох байдал
• Хэсэгчилсэн тест түүний хэлхээ холбоо. /Хамгийн их ачаалал, тэмдэгт тоо шалгах гэх мэт/
• Хэрэглэж байгаа кодын арга /алгоритм/ болон стандартын зохицол. /Хялбар шийдэл/
• Програм хангамжийн нэтгэлийн тестийг хэрэгжүүлэх боломж. /Сонгогдсон арга хэрэгсэлээ ашигласан байгаа эсэх гэх мэт/
• Ажиллуулах болон цаашид хэвийн үйл ажиллагаа явуулах боломж

Нэгдсэн тест /Integration test/

2009-09-18T18:28:00.004+08:00

Програм хангамжийн нэгдсэн тестийн төлөвлөгөөг зохиох
• Програм хангамжийн нэгж хэсгүүдийг нэгтгэж /тухайн програм хангамжийн бүтээгдэхүүний хувьд нэгтгэх/ тетсийн нэгдсэн төлөвлөгөөг боловсруулах
• Төлөвлөгөөнд тестнд шаардлагатай үзүүлэлтүүд, тавигдах шаардлагууд, дэс дараа, өгөгдлүүд, хариуцлага болон төлөвлөгөө багтана. Ажлын хувиарлалт, мөн баг бүрдүүлэх хариуцлага их чухалд тооцогдоно. Gantt гэх мэт диаграмаар төлөвлөгөөг гаргах хэрэгтэй.
• Нэгдсэн тестийн төлөвлөгөө үр дүнг бичгээр үйлдэж байх хэрэгтэй.

Нэгдсэн тестийг явуулах
• Програм хангамж хийгдэж дуусаад хэсэгчилсэн тест (Unit test) хийгдэж дууссаны дараа хийгдэнэ. Ө.х програм хангамжийн бүрэлдэхүүн хэсгүүдийг нэгтгээд нэгдсэн төлөвлөгөө хийгдсэн бол уг тестийг явуулна.
• Нэгтгэж байгаа хэсэг тус бүр нь програм хангамжийн бүтээгдэхүүний шаардлагыг хангаад нэгтгэсний дараа буюу програм хангамжийн бүтээгдэхүүн нь бүтнээрээ дууссан байх шаардлагатай. Нэгдсэн тест хийгдэж дууссаны дараа систем бий болдог.
• Програм хангамжийн бүтээгдэхүүний хэрэглэгчийн болон системийн гарын авлагыг шинэчлэн өөрчлөнө.

Програм хангамжийн чанар буюу зохицолдолгоог шалгах тест
• Гол нь нэгдсэн тест явуулахын тулд холбогдох тестийн болон бусад дэс дарааллыг хийх ёстой.
• Програм нь програм хангамжийн бүтээгдэхүүнд тавигдах шаардлага тус бүрээр нь (шаардлагыг хангаж байгаа эсэхээр) холбогдох тестийн оролт ба гаралт, үндсэн стандартыг бий болгон бичиг баримтыг бичгээр үйлдэнэ.
• Хэсэгчилсэн тест нь нэг бүрчилэн хийгдсэн эсэхийг мөн шалгах.
Нэгдсэн тестийн үнэлгээ
• Системийг шаардлагыг хангах, URD, SRS гэх мэт үе шатуудыг эргэн “замаар нь” шалгах боломжийг олгоно.
• Гадна хэсгийг зохицолгоо, харилцан хамаарал. /Харагдах байдал таарч байгаа эсэх/
• Дотоод зохицолгоо, харилцан үйлдэл.
• Програм хангамжийн бүтээгдэхүүний үзүүлэлтийн тестийн зохицолгоо
• Бүрэн бүтэн байдал буюу /функцийн бүтэц/ аргументийн түвшний стандарт зохицолгоо.
• Гарах ёстой үр дүнтэйгээ таарч байгаа эсэх.
• Програм хангамжийн шалгуур таарч байгааг шалгаж тестийг явуулах боломж.
• Ажиллуулах болон түүний цаашид хэвийн ажиллах боломж. /Ямар ч тохиолдолд цааш явуулах, ажиллуулах боломжтой байх ёстой/
Нэгдсэн тестийн хамтарсан эргэн дүгнэлт хийх
• Хэрэглэгч, системийн шинжилгээ хийсэн хүн (HLD, SRS,URD)-тэй хамтран эргэн дүгнэлт хийх.

Нэгдсэн тест (Integration Test)-ийн төлөвлөгөө
1. Танилцуулга
1.1 Шалгаж танилцсан бичлэгүүд. Тестийн бичиг баримттай танилцсан протокол.
1.2 Хэрэгцээ шаардлага ба хүрээ хязгаар. Тестийн шаардлага ба хүрээ хязгаар тодорхойлсон бичиг баримт.
1.3 Лавлах бичиг баримтын жагсаалт
Лавлах бичиг баримтуудын жагсаалтанд:
* Програм хангамжийн бүтээгдэхүүний архитектурын бичиг баримт /SRS/
* Програм хангамжийн шинжилгээний бичиг баримт /High Level Software Design/
* Техник хангамжийн шинжилгээний бичиг баримт /High Level Hardware Design/
* Боломж, “аюул”-ын шинжилгээ

2. Нэгдсэн тестийн стратеги
2.1 Шалгуур оруулах.
Тестийн шалгууруудыг нэгдсэн байдлаар хийхийн өмнө элементүүдийн түвшинд тус тусд нь тодорхойлох (жиш нь хэсэгчилсэн тестний функцууд байгаа эсэх гэх мэт).
2.2 Элементүүдийг нэгтгэх.
Бүх элэментүүдийг нэгтгэх буюу дэд системүүдийг нэгтгэн нэгтгэл үүсгэж шалгах.
2.3 Нэгдсэн стратеги.
Нэгдсэн хандлага чиглэлийг ба холбоо хамаарлыг үндэслэн сонголт хийх. (дээрээс доош, доороос дээш, функционал бүлэглэх гэх мэт)
2.4 Онцгой чухал/Функцийн дараалал ба ТХ/ПХ нэгтгэл
ТАЙЛБАР: Энэ хэсэгт нэг чиг хандлагыг санал болгоно. Байгууллага 2.2-т заасны дагуу элементүүдийг нэгтгэх үед тодорхой чиг хандлагыг сонгох шаардлагатай болдог.
2.4.1 Програм хангамжийн нэгтгэлийн дараалал. Зарим дэд систем:
Програм хангамжийн код функцууд ба модулиуд тодорхой дараалалтайгаар нэгтгэгддэг. Ямар нэгэн програм хангамжийн бүтээгдэхүүний онцгой байдал/функцуудыг байгуулахад энэ дараалал хамаатай байдаг. Зарим үед ямар нэгэн техник хангамжийн хамааралтай байдлыг тодорхойлохоос өмнө програм хангамжийн үйл ажиллагаануудын нэгтгэл яригддаг.
2.4.2 Техник хангамжийн нэгтгэлийн дараалал. Зарим дэд систем:
Техник хангамжийн элементүүдийн нэгтгэлийг тус тусд нь хийдэг. Зарим үед ямар нэгэн програм хангамжийн хамааралтай байдлыг тодорхойлохоос өмнө техник хангамжийн үйл ажиллагаануудын нэгтгэл яригддаг.
2.4.3 ТХ/ПХ-уудын нийтэд нь нэгтгэх дараалал. Зарим дэд систем:
Програм хангамжийн байгуулалт нь техник хангамжийн модультай хамт нэгтгэгдэх түүний дарааллыг тодорхойлох.
2.4.4 Дэд системийн нэгтгэлийн дараалал. Дэд системүүдийг нэгтгэх дарааллыг тодорхойлох.

3. Тестийн алхмууд ба тестийн тодорхойлолт
3.1 Програм хангамжийн нэгтгэлийн тестийн тодорхойлолт
3.2 Техник хангамжийн нэгтгэлийн тестийн тодорхойлолт
3.3 ТХ /Програм хангамжийн нэгтгэлийн тестийн тодорхойлолт
3.4 Дэд системийн нэгтгэлийн тестийн тодорхойлолт
3.5 Эцсийн функционал тест.
Эцсийн функционал тест нь эцсийн байдлаар нэгтгэх үед систем хэрхэн ажиллахыг тодорхойлдог. Мөн систем тестийн төлөвлөгөөг гаргах үндэс болно.

4. Хэрэгсэлүүд ба тест хийх тоног төхөөрөмжийн шаардлага
Тестнд хэрэглэх хэрэгтэй бүх хэрэгсэлүүдийг нэгтгэлд зориулан бүтээж бий болгох. Жишээ нь компьютерууд, үйлдлийн систем гэх мэт.

5. Програмын хэсгүүд ба тестийн өгөгдлийн шаардлага
Тестийн стратеги ба тестийн зохиомжинд үндэслэн програмын хэсгүүд ба тестийн өгөгдлүүдийг бэлдэнэ.

6. Хариуцлага ба хуваарь
Хувийн ур чадвар болон чанар, зохилцолгоонд үндэслэн хариуцлага хуваарийг гаргах.
6.1 Үүрэг /дүрүүд/ ба хариуцлагууд
6.2 Хамаарал
6.3 Эрсдэл ба таамаглал
6. Хуваарь

7. Асуудал ба шийдвэр, тогтоол
Асуудлыг тодорхойлох ба түүний дагуу гаргах шийдвэр, тогтоолын механизм бий болгох.

8. Эргэн дүгнэх, ярилцах, дахин шалгах үйлдлүүд
Тестийн үйлдлүүдийн эргэн дүгнэх, дахин шалгах болон ямар нэгэн элементүүдийн өөрчлөлт сайжруулалтыг тодорхойлох.

9. Түр зогсоох, эргэн ачаалах ба шалгуураас гарах
a) Дуусахаас өмнө тестийг түр зогсоох(том асуудал гарах)
b) Шалгууруудаар дахин тестлэх

Системийн тест /ST – System Test/

2009-08-22T21:52:00.006+08:00

СИСТЕМ ТЕСТ

A.Систем тестийг явуулах урьдач нөхцөл
1) Бүх модулийн нэгдсэн тест заавал хийсэн байх
2) Ажиллуулах гарын авлага /manual/, аргачилал хийгдсэн байх. Хэрэглэгч энэ системийг ашиглах арга, түүнтэй холбоотой бичиг баримт гарсан байх.
3) Систем тестийн төлөвлөгөө, систем тестийн үзүүлэлтүүд, нэвтрүүлэх төлөвлөгөө. Хүлээн авах үеийн тестийн төлөвлөгөө.
4) Систем тестийн хэрэглэгч тал болон түүнийг хийж байгаа талын хоорондын уялдаа , бүтэц бүрэлдэхүүн, тодорхой тогтолцоо бий болсон байх. /бэлтгэсэн байх/
5) Тухайн системийн орчин бий болсон байх. /Компьютер, сүлжээ гэх мэт/

B. Систем тестийн төлөвлөгөө гаргах
1) Систем тестийн хуваарь гаргах
2) Систем тестийн орчинг тодорхойлох
• Техник хангамжийн бүтэц
• Програм хангамжийн бүтэц
3) Тестийн агуулгыг тодорхойлох
• Функцийн тест
• Өгөгдлийн хэмжээний тест
• Ачааллын буюу стресс тест
• Хэрэв ямар нэгэн алдаа гарвал буцаж сэргээх тест
4) Тестийн өгөгдөл бэлдэх
• Өгөгдлийн сангийн эхний сууриллуулалт
• Мастер буюу лавлах өгөгдлийг бүртгэх
• Ажил, үйл ажиллагааны өгөгдлийг оруулах /шилжүүлэх/
• Өгөгдлүүдийн бэлтгэл
5) Систем тестийн дэс дараалал
• Үйл ажиллагааны зөв дэс дарааллын тест
• Тест явуулах үйл ажиллагааны дэс дараалал
• Өдөр тутмын, сар тутмын боловсруулалтын дэс дараа
6) Тестийн бүтэц, тест явуулах тогтолцоо
• Хэрэглэгчийн ажил үүргийн болон удирдлагын тогтолцоо
• Хөгжүүлэгцийн ажил үүргийн болон удирдлагын тогтолцоо

C. Систем тестийн үзүүлэлтүүд, шаардлагууд
1) Ямар хувилбараар тест хийх
2) Тестийн үзүүлэлтийг тогтоох
3) Тестийн өгөгдлийг тодорхойлох
4) Тест хийх дэс дараа
5) Тест явуулах таамаглал
6) Тест явуулсан үр дүн
• Тест явуулсан хүн, огноо, тестийн үр дүн
• Тест явуулахад учир дутагдалтай байгаа түвшин болон шалтгааныг тодорхойлох

D. Тест явуулах

E. Тестийн үр дүнг эргэх дүгнэх

{ТӨСЛИЙН НЭР – Дэд төсөл}
СИСТЕМ ТЕСТИЙН ТӨЛӨВЛӨГӨӨ

ТАНИЛЦУУЛГА
Бэлтгэсэн:
Тестийн бичиг баримтыг боловсруулж бэлтгэсэн хүмүүсийн нэр, албан тушаал, и-мейл хаяг ба бусад мэдээлэл.

Дэмжигчид:
Бичиг баримт бүрдүүлэхэд дэмжсэн, туслалцаа үзүүлсэн хүмүүсийн мэдээлэл.

ШАЛГАЖ ТАНИЛЦСАН

СИСТЕМ ТЕСТИЙН ТӨЛӨВЛӨГӨӨ
Тестийн орчин
Энэ нь зүй зохиостой ба хэрэгтэй хэсэг юм. Юу хийхийг таамаглах.
Техник ба програм хангамжууд тодорхойлох

СИСТЕМИЙН ОРЧИН
СИСТЕМИЙН БАТАЛГААНЫ ТЕСТ
Системийн баталгааг тестлэх нь системийн бүх функционал шаардлагуудыг баараггүй болгож шалгах явдал юм.

ӨГӨГДЛИЙН ШААРДЛАГА
Тодорхой тестийн өгөгдлийг хэрхэн үүсгэх, энэхүү тестийн өгөгдөл нь өмнөх бичиг баримтын системийн шаардлагуудад хүрэлцэх эсэхийг тодорхойлох.

ТЕСТЛЭГЧ БА ТЕСТЭНД ХЭРЭГТЭЙ БАГЦАА ЦАГ
Уг тестнд хэрэгтэй өгөгдлийн шаардлагуудыг биелүүлэх буюу гүйцэтгэхэд мөн тестийн нөхцөлүүдийг тодорхойлоход хэрэглэх барагцаалсан X цагийг тодорхойлох. Мөн Y тестлэгчийн хийх үйлдлийн Z цагийг тооцоолох.

ОНЦГОЙ ХЯНАЛТУУД
Процесс буюу үйлдлийн дараа ямар нэг онцгой байдал агуулж байгаа эсэхийг тодорхойлох.

ЭРГЭН АЖИЛЛАХ СТРАТЕГИ
Тестийн үед тохиолдсон “зөв” асуудлуудын процедуруудыг тодорхойлох.
o Шүүмжлэлтэй дефект - системийн осолтой, аюултай алдааны учир шалтгаан (түгжигдэх буюу цоожлогдох, хэвийн бус төгсгөл гэх мэт)
o Чухал дефект – систем дэх түлхүүр гол функцуудын зохисгүй үйлдэлийг бодож тооцоолох, харин энэ үед тестийн үйл ажиллагааг саатуулахгүй байх.
o Жижиг декект - Програмын зүс царай болон шууд шүүмжлэлгүй хэсэг.

ТЕСТ СКРИПТ

Ачааллын буюу стресс тест
Системийн ачаалал буюу стресс нь системийн шаардлагад хэр нийцэж байгааг тодорхойлох тест.

ӨГӨГДЛИЙН ШААРДЛАГА
Тодорхой тестийн өгөгдлийг хэрхэн үүсгэх, энэхүү тестийн өгөгдөл нь өмнөх бичиг баримтын системийн шаардлагуудад хүрэлцэх эсэхийг тодорхойлох.

ТЕСТЛЭГЧ БА ТЕСТЭНД ХЭРЭГТЭЙ БАГЦАА ЦАГ
Уг тестнд хэрэгтэй өгөгдлийн шаардлагуудыг биелүүлэх буюу гүйцэтгэхэд мөн тестийн нөхцөлүүдийг тодорхойлоход хэрэглэх барагцаалсан X цагийг тодорхойлох. Мөн Y тестлэгчийн хийх үйлдлийн Z цагийг тооцоолох.

ОНЦГОЙ ХЯНАЛТУУД
Процесс буюу үйлдлийн дараа ямар нэг онцгой байдал агуулж байгаа эсэхийг тодорхойлох

ТЕСТ СКРИПТ

Системийн зохиомж /LLD – Low Level Design/

2009-06-28T19:44:00.004+08:00

Програм хангамжийн бүтээгдэхүүний нарийвчилсан тайлбар

• Эхлээд бүрэлдэхүүн хэсэг тус бүр дээр нарийвчилсан зохиомжийг гаргана.
• Програм хангамжинд тавигдах шаардлага, програм хангамжийн бүрэлдэхүүн хэсгүүдээс нэгж хэсгүүдэд харгалзуулан хувааж өгөх хэрэгтэй. Системийн шинжилгээ /HLD/-тэй адил хуваасан зохиомжийг бүгдийг бичгийн хэлбэрээр тодорхойлж баримтжуулах хэрэгтэй.
Програм хангажийн интерфейсийн нарийвчилсан зохиомж
• Хэрэглэгчийн интерфейсээс модуль хоорондын интерфейсыг явуулах хэрэгтэй. Програм хангамжийн бүтээгдэхүүн ба түүний орчин тойрон, програм хангамжийг бүрдүүлсэн элементүүдийн хоорондох болон нэгжүүд хоорондох интерфейсын нарийвчилсан зохиомж гарган бичгээр бичиг баримт үйлдэх.
• Интерфейсын нарийвчилсан зохиомжийг гаргах тохиолдолд түүнээс илүү ямарч мэдээлэл хэрэггүйгээр програмчлал явуулах бололцоотой байдлаар кодын болон бусад зохиомжийг гаргадаг. Ө.х нарийвчилсан зохиомжийн бичиг баримтыг өөр ямар нэгэн аман тайлбар авахгүйгээр програмчилж болох л шаардлага тавигддаг. Програмчлалын үе шат болон нарийвчилсан зохиомжийн үе шат хамтдаа хийгдэх тохиолдол их байна. Жишээ нь 70% програм бичээд эргэн зохиомжийг гаргаад үлдэх 30% програмыг бичих гэх мэт.
• Ялангуяа өгөгдлийн сангийн зохион байгуулалт бүхий системийн хувьд энэ үе шатанд өгөгдлийн сангийн нарийвчилсан загварыг гаргадаг.
Програм хангамжийн хэсэгчилсэн тестнд тавигдах шаардлагын тодорхойлолт
• Програм хангамжийн хэсэгчилсэн тестийг явуулахын тулд тестнд тавигдах шаардлага болон хуваарийг гаргана. Гол нь ямар хэсгийн тестийг ямар хугацаанд хийх вэ гэдгийг гаргана.
• Тестнд тавигдах шаардлагын гол нь програм хангамжийн нэгж хэсгийн хувьд шаардлагын хүрээнд хамгийн их ачааллаар ажиллуулах явдал байдаг.
• Програм хангамжийг нэгтгэхийн тулд явуулах тестнд тавигдах шаардлагыг шинэчлэн өөрчлөх буюу нэгтгэлийн тест /integration test/-нд тавигдах шаардлага, агуулга, хуваарийг шинэчлэнэ.
• Дээрх бичиг баримтыг бичгээр үйлдэж баримтжуулж байх хэрэгтэй.

Програм хангамжийн нарийвчилсан зохиомжийн болон түүнтэй холбоотой тестнд тавигдах шаардлагын үнэлгээ
1. Програм хангамжийн бүтээгдэхүүнд тавигдах шаардлага, шаардлагад эргэн шинжилгээ хийх /эргэн дүгнэх/ бололцоотой байх.
2. Сонгон авсан аргачилалын зохиомж нь системийн шинжилгээтэй хэр зохицох, авцалдаатай байх чадвар. Жиш нь: Ямар нэг функцийн хувьд тухайн SRS, HLD дээр хамаатай байгаа эсэх гэх мэт
3. Програм хангамжийн бүрэлдэхүүн хэсгүүд болон програм хангамжийн нэгж хэсгүүдийн хоорондын дотоод уялдаа холбоо, зохицолдолгоот чанар. Өөр програм хангамжтай холбогдох чадвар. /Гол нь хөгжүүлэлтийн стандарт баримталж програм бичих хэрэгтэй/
4. Ашиглагдаж байгаа зохиомжийн аргачилал болон стандартын тохиромжтой байдал. Тэрхүү хөгжүүлэх стандарт зөв сонголт болсон эсэхийг шалгах.
5. Ашиглалт болон нэвтрүүлэлт, сууриллуулалтыг хэрэгжүүлэх бололцоо.
Програм хангамжийн нарийвчилсан зохиомж гаргасны дараа хамтарсан эргэн дүгнэлт хийнэ.

Програм хангамжийн зохиомжийн загвар бичиг баримт
• Гарчиг
• Танилцуулга
• Системийн тойм дүгнэлт
• Зохиомжийн бодлого, ач холбогдолууд
o Таамаглалууд ба харилцан хамааралууд
o Ерөнхий бодлого
o Дүрэм ба зааварчилгаа
o Хөгжүүлэх аргууд
• Архитектурын стратеги
o стратеги-1 нэр буюу тайлбар
o стратеги-2 нэр буюу тайлбар
o ...
• Системийн архитектур
o бүрэлдэхүүн хэсэг-1 нэр буюу тайлбар
o бүрэлдэхүүн хэсэг-2 нэр буюу тайлбар
o ...
• Бодлого ба тактик Policies and Tactics
o бодлого/тактик-1 нэр буюу тайлбар
o бодлого/тактик-2 нэр буюу тайлбар
o ...
• Нарийвчилсан системийн зохиомж
o модуль-1 нэр буюу тайлбар
o модуль-2 нэр буюу тайлбар
o ...
• Лавлах материалууд ба хэрэглэсэн үгийн тайлбар

Бичиг баримтын тайлбар
Энэхүү бичиг баримт нь програм хангамжийн зохиомжийн нарийвчилсан загварыг гаргах, түүнийг бичгээр үйлдэх зориулалттай юм.
________________________________________
Танилцуулга
Бичиг баримт нь дараах зүйлсээр хангагдсан байх ёстой. Үүнд:
• Бичиг баримтанд хамаарагдах зорилго, үр дүнг тодорхойлох
• Бичиг баримтанд хамаарагдах хүрээ хязгаарыг тодорхойлох
• Систем/бүтээгдэхүүнд хэрэглэх ямар нэгэн хэрэглэж болмоор нэр ба хувилбарын дугаарыг тодорхойлох.
• Ямар нэгэн бусад тохирох бичиг баримтуудын лавлахуудаар хангах:
o Дагалдах бичих баримтуудтай холбох
o Хэрэгцээтэй, шаардлагатай байх бичиг баримтууд
o Бичиг баримт дахь агуулга болон цаад орчны мэдээллээр хангах
o Энэхүү бичиг баримтын үр дүнгийн бичиг баримт гаргах (тестийн төлөвлгөө, хөгжүүлэх төлөвлөгөө гэх мэт)
• Чухал нэр томъёо болон хураангуй үгнүүдийг тодорхойлох
• Бичиг баримтын дүгнэлт
________________________________________

Системийн тойм дүгнэлт
Нийт системийн болон зохиомжийн програм хангамжийн систем дэх агуулж үйл ажиллагаа ба асуудал, шалтгааны хамааралыг тодорхойлох (Магадгүй үүнд үндсэн зохиомжийн хандлага буюу байгууллага түүний бүтцийн хэлэлцүүлэг байж болно).
________________________________________
Зохиомжийн бодлого, ач холбогдолууд
Энэ хэсэгт зохиомжийн бүрэн шийдлийн олон үр дүнг гаргах шийдэмгий оролдлого, бодлогуудыг тодорхойлдог.
________________________________________
Таамаглалууд ба харилцан хамаарал
Програм хангамжийн таамаглалууд ба харилцан хамаарлын талаар энд тодорхойлдог:
• Техник хангамж ба програм хангамжийн хамаатай байдал
• Үйлдлийн систем
• Эцсийн хэрэглэгчийн шинж чанар, онцлог
• Боломжтой ба болзошгүй функционал өөрчлөлтууд
________________________________________
Ерөнхий бодлого
• Програм хангамж ба техник хангамжийн орчин
• Эцсийн хэрэглэгчийн орчин
• Нөөцийн ашиглалт буюу хувиралт
• Стандартууд
• Интерфейсийн шаардлагууд
• Өгөгдлийн хадгалалт ба хувиарлалтын шаардлага
• Нууцлалт хамгаалалтын шаардлага
• Санах ой ба бусад хүчин чадлын хязгаарлалт
• Гүйцэтгэл, биелүүлэлтийн шаардлагууд
• Сүлжээний харилцаа, холбоо
• Шалгалт биелэлт ба хүчин төгөлдөр байх шаардлагууд (тестчилэл)
• Чанарын шаардлагын дундаж хэмжээ
• Бусад хэрэгцээ, шаардлагуудыг тодорхойлох
________________________________________
Дүрмүүд ба зааварчилгаа
Дүрмүүд, зааварчилгаа болон хууль зарчмыг тодорхойлох.
Хөгжүүлэлтийн аргууд
Хөгжүүлэлтийн аргуудыг тооцох.
________________________________________
Архитектурын стратеги
• Бүтээгдэхүүний төрлийн сонголт, хэрэглээ (програмчлалын хэл, өгөгдлийн сан, сангууд ... гэх мэт)
• Програмын бүрэлдэхүүн хэсгүүдийн буюу системийн олон талын өөр ялгаатай хэсгүүдийн хөгжүүлэлт
• Програм хангамжийн нэмэгдэл буюу өргөтгөлийн төлөвлөгөө гаргах
• Хэрэглэгчийн интерфейсын загвар, жишээ (системийн оролт ба гаралтын модулиуд)
• Техник хангамж болон програм хангамжийн интерфейсын жишээ загвар
• Алдаа болон эргэн сэргээлт
• Санах ойн удирдлагын бодлого
• Гадаад өгөгдлийн сан ба өгөгдөл хадгалалтын удидлага ба тогтвортой хадгалалт
• Хувиарлагдсан өгөгдөл буюу сүлжээний хяналт, хамгаалалт
• Хяналтын хандлагууд
• Хамтын болон зэрэгцээ ажиллагаа
• Харилцаа холбооны механизм
• Бусад нөөцүүдийн удирдлага
________________________________________
Системийн архитектур
<Нийт системийн архтектурыг /бүтэц/ гаргах>
Дэд системийн архитектур
<Дэд системийн архитектурыг /бүтэц/ гаргах>
________________________________________
Бодлого ба тактик
• Бүтээгдэхүүнийг хэрэглэх сонголт (компилятор, өгөгдлийн сан, сангууд ... гэх мэт)
• Инженерчлэл
• Кодын зааварчилгаа
• Системийн үйл ажиллагааны нэгж хэсгийн хөгжүүлэлтийн тодорхой алгоритмын сонголт
• Шаардлагуудад баталгаа өгөх, төлөвлөх
• Програм хангамжийн тестийн төлөвлөгөө
• Програм хангамжийн нэвтрүүлэлтийн төлөвлөгөө
• Эцсийн хэрэглэгч, харилцаа холбоо, програм хангамж, техник хангамжийн интерфейс
• Физик бүрэлдэхүүн хэсэг ба иерархи бүтэц
• Системийг хэрхэн байгуулах (компиляци хэрхэн хийх гэх мэт)

Системийн нарийвчилсан зохиомж
Ангилагдсан
Бүрэлдэхүүн хэсгүүд, дэд систем, модуль, класс, багц, функц, файл .... гэх мэт
Тодорхойлсон
Бүрэлдэхүүн хэсэг дэх агуулга, ач холбогдлыг тодорхойлох. Энэ нь шаардлага, үзүүлэлтүүдийг илүү түвшинд тодорхойлох зорилготой.
Хариуцлага, үүрэг амлалт
Бүрэлдэхүүн хэсгүүдийн үүрэг хариуцлага ба ажиллах хариуцлага. Бүрэлдэхүүн хэсэг юу хийх вэ? Энэ “тоглолтонд” ямар “дүрээр” оролцох вэ? Харилцагч ямар төрлийн үйлчилгээ үзүүлэх вэ?
Шаардлага хязгаарлалт
Бүрэлдэхүүн хэсгийн шаардлага, хязгаарлалт, хамаатай холбоотой байдал.
Хэрэглэгчид/Харилцан үйлчлэл
Бусад бүрэлдэхүүн хэсгүүдийн хамтын ажиллагааг тодорхойлох. Бусад бүрэлдэхүүн хэсгүүд нь ямар объектыг хэрэглэх?
Нөөцүүд
Тухайн хэсэгт бүх нөөцүүд нь удирдагдах, нөлөөлөл буюу хэрэглэгдэхийг тодорхойлох.
Дэд системийн нарийвчилсан зохиомж
<Дэд системийн нарийвчилсан зохиомж гаргах>

Системийн шинжилгээний бичиг баримтын загвар /HLD template/

2009-06-04T22:04:00.002+08:00

1 Бичиг баримтын танилцуулга
Системийн шинжилгээний бичиг баримтын зорилго, агуулга, шаардлагатай мэдээллүүд.

2 Бичиг баримтын болон санал болгож буй бодлогын даалгаврыг шийдвэрлэх асуудал
Энэ хэсэгт ямар бодлогын даалгавар тавигдаад байгаа, түүнийг хэрхэн шийдэхээр
төлөвлөж буй талаар бичнэ. Мөн шаардлагатай мэдээллүүд /цуглуулсан мэдээллүүд/-ийн
талаар бичнэ.

3 Системийн тодорхойлолт буюу диаграмууд
Системийн шинжилгээний үр дүнд бий болох диаграмуудыг дүрслэх, зурах болон
системийн үндсэн загвар ба үндсэн интерфейсыг дүрслэнэ.

4 Системийн шаардлагууд
4.1 Ерөнхий систем:
Ерөнхий буюу нийт системийн шаардлагуудыг нарийвчлан тодорхойлох. /Ө.х бодлогын даалгаврын нарийвчлан тодорхойлно, гэхдээ энэ бодлогын даалгавраар систем юу хийхийг гол нь тодорхойлно. Мөн нийт системийн хийх ажлууд, үйлдлүүдийн нарийвчилсан төлөвлөгөөг гаргана. Нийт үйл ажиллагаануудыг гаргана. Эдгээр задаргаа нь дэд системүүдийн тодорхойлолт гарах үндэс болно.

4.2 Дэд системийн шаардлага:
Дэд систем тус бүрийн үндсэн интерфейсүүдийг зурж тодорхойлох. Нийт системийн шаардлагуудыг илүү нарийвчилсан буюу доод түвшинд тодорхойлох. Програм хангамж болон техник хангамж бүхий дэд системүүд нь олон дэд хэсэг болж задрах ч гол нь програм хангамжийн шаардлага тодорхойлж байгаагаа мартаж болохгүй.

4.3 Системийг цаашид сайжруулах шаардлагууд
Боловсруулж буй системийг цаашид хэрхэн хөгжүүлэх, түүний шаардлагууд ямар байхыг тодорхойлох.

5. Системийн шинжилгээний шийдвэрүүд
Системийн хөгжүүлэлтэнд шаардлагатай дэд систем буюу интерфейсүүдийн дээд түвшний шинжилгээний дүрслэл мөн хөгжүүлэх гэж буй системд шаардлагагүй, хэрэггүй дэд систем, интерфейсүүдийг ялгаж гаргах.
Дэд систем буюу үндсэн интерфейс тус бүрийн үйл ажиллагаанууд буюу түүнд хэрэглэх зохистой технологиудыг тодорхойлох. Шийдвэрийн түвшин нь системийн онцгой, тусгай хэсгийн бус нийт системд ашиглагдах сайн технологийн сонголт байх юм.

6. Үндсэн бүрэлдэхүүн хэсгүүд ба зардлууд
Системийн үндсэн бүрэлдэхүүн хэсгүүдын зардлууд, үнэ ашгийн шинжилгээ хийх.

7. Төгсгөл /дүгнэлт/
Дүгнэлт
Лавлах материалууд
Цуглуулсан материалуудын жагсаалт /хавсаргана/

PMBOK - Төслийн менежментийн мэдлэгийн цогц

2009-05-19T20:38:00.003+08:00

Төсөл гэж юу вэ?
• Эхлэх дуусах хугацаа нь тов тодорхой, бие даасан үр дүн гаргах үйл ажиллагаа
• Аливаа төсөл урьд өмнө агуулагдаж байгаагүй онцлог чанартай. (Ялангуяа IT-ийн төслүүд)
• Байнгийн тасралтгүй явагдах үйл ажиллагаа төсөл биш. Бэлэн програм хангамж зарах бол төсөл биш.

Төслийн менежмент
Төслийн гол гүйцэтгэлийг болон бусад Stack Holder-уудаас тухайн төсөлд тавих шаардлага, тэдний хүсэн хүлээж байгаа зүйлийг хангах, мөн түүнээс илүү үр дүнг бий болгохын төлөөх хамгийн оновчтой арга техник, мэдлэг, технологи, хэрэгсэлүүдийг авч хэрэглэх явдал юм.
Тайлбар: Stack Holder нь хэрэглэгч, гадны байгууллага ...

PMBOK-ийн тухай

Project Management Body of Knowledge
• PMI – Project Management Institute (1996, USA, Philadelphia, Pennsylvania)
1996 оны 3-р сард PMBOK стандартыг гаргасан
• PMI нь PM-ийн үндэс суурийг тодорхой болгож, төслийн төлөвлөгөө гүйцэтгэлийн хяналтыг амжилтанд хүргэхийн төлөөх мэдлэгийн цогцыг бий болгосон
• PMBOK бол дээрх эрхэм зорилгыг бодит зүйл болгосон үр дүн юм

PMBOK-ийн зорилго
- Төслийн менежментийг ашиглах хүрээ хязгаараас хамааран гарсан стандарт мэдлэгийн цогцыг бий болгох, нийтлэг нэр томъёог шийдэж олны хүртээл болгох
- Төслийн менежментээр ажилладаг хүмүүсийн мэдлэгийн төвшинг шалгах шалгуурыг тэдэнд зааж өгөх.
- Төслийн менежментээр лавлах материалын стандарт бий болгох
- Их дээд сургуулиуд дахь төслийн менежментийн хэмжих хэмжүүр болох

PMBOK-ийн мэдлэгийн цогц

PMBOK-ийн мэдлэгийн цогц ба төслийн процесс

Өгөгдлийн урсгалын диаграм

2009-05-12T20:55:00.005+08:00

ªãºãäëèéí Óðñãàëûí Дèàãðàì - ӨУД (Data Flow Diagram)
Áîäèò ñèñòåìèéã ìýäýýëëèéí ñèñòåìèéí çàãâàð áîëãîí ä¿ðñëýõ õýðýãñýë þì. Үр дүн нь: Тухайн системийн нийт үйл ажиллагааны загварыг гаргах буюу бодит систем ЮУ хийхийг тодорхойлж, бүрэлдэхүүн хэсгүүдийг задалж мэдээллийн систем болгох улмаар логик загвар дүрслэх.

ªÓÄ-ûí á¿ðýëäýõ¿¿í õýñã¿¿ä:
1. Гадаад объект /тэгш өнцөгт хэлбэртэй дүрслэгдэнэ/
2. Ïðîöåññ /дугуй хэлбэртэй дүрслэгдэнэ/
3. ªãºãäëèéí óðñãàë /сумаар дүрслэгдэнэ/
4. ªãºãäëèéí ôàéë /дугаар бүхий тэгш өнцөгт/

1. Гадаад объект
Гадаад объект нь мэдээллийн эх үүсвэр эсвэл мэдээллийн гадаад хүлээн авагч юм. Ерөнхий Диаграм(ЕД)-д системийн оролт, гаралт(үр дүн) байдлаар дүрсэлдэг.
Гадаад объекттой холбогдуулж гарч болзошгүй алдаанууд:
- Гадаад объект хооронд өгөгдөлийн урсгал дүрсэлсэн ???
(Шалтгаан: Системд хэрэглэгдэхгүй өгөгдөлийн урсгал дүрсэлсэн)
- Файлаас гадаад объект, гадаад объектоос файл руу өгөгдөлийн урсгал дүрсэлсэн ???
(Шалтгаан: Хооронд байх процессыг орхигдуулсан)
- Гадаад объектыг хүний нэрээр нэрлэсэн ???
(Шалтгаан: Логик бус физик загвар дүрсэлсэн)

2. Процесс
Процесс нь оролтыг гаралтанд хувиргах системийн хэсэг юм.
Процесстой холбогдуулж гарч болзошгүй алдаанууд:
- Процесс руу орсон эсвэл гарсан урсгал байхгүй ???
(Шалтгаан: Урсгалыг орхигдуулсан)
- Процессыг нэр үгээр нэрлэсэн ???
(Шалтгаан: Физик загварыг логик загварт хувиргаагүй)
- Тодорхойгүй нэр тэмдэглэгээгээр нэрлэсэн ???
(Шалтгаан: Процессыг муу тодорхойлсон)

3. Өгөгдлийн урсгал
Өгөдөлийн урсгал нь сумныхаа чиглэлд өгөгдөлийг зөөгч юм.
Өгөгдлийн урсгалтай холбогдуулж гарч болзошгүй алдаанууд:
- Нэрлэгдээгүй өгөгдөлийн урсгал дүрсэлсэн ???
(Шалтгаан: Шинжилгээ дутуу хийсэн. Гэхдээ файл руу орсон эсвэл гарсан урсалыг нэрлэхгүй байж болдог. Орж буй урсгал нь өөрчлөх,бичих харин гарч буй урсгал нь унших үйлдлийг агуулдаг)
- Өгөгдөлийн урсгал өгөгдөл зөөх хэрэгсэл болсон ???
(Шалтгаан: Физик шаардлагыг бүрэн хасаагүй)
- Урсгал нь гадаад объектоос файл руу, гадаад объектоос гадаад объект руу, файлаас гадаад объект руу, файлаас файл руу чиглэсэн байж болохгүй ???
Үйлдлийн үр дүн дүрслэгдээгүй ???
(Шалтгаан: Орхигдуулсан) гэх мэт алдаануудаас болгоомжил.

4. Өгөгдлийн файл
Өгөгдөлийн файл нь ОХД дээрх нэг объект гэж ойлгож болно.
Өгөгдөлийн файл нь өгөгдөлийг хадгалах учир юуг өгөгдөлийн файл болгож авах вэ гэдгийг бодох хэрэгтэй

ªãºãäëèéí Óðñãàëûí Дèàãðàì хэрхэн дүрслэх вэ?
ӨУД-ыг дүрслэхдээ эхлээд ЕД-ыг /CAD/ дүрслэх хэрэгтэй ба энэ нь системийн хүрээ хаагуур хязгаарлагдах, гадаад орчинтой хэрхэн харилцан үйлчлэлцэхийг харуулдаг. ЕД-д гадаад объектууд болон нийт системийг төлөөлж чадахуйц нэг системийг дүрсэлдэг.
Дараах алхамаар ӨУД-ыг дүрсэлж болно.
1. Нийт оролтын өгөгдөлийн урсгалуудыг тэдгээрийн эх үүсвэр гадаад объектын хамт дүрсэлнэ.
2. Нийт гаралтын өгөгдөлийн урсгалуудыг тэдгээрийн хүлээн авагч гадаад объектуудын хамт дүрсэлнэ.
3. Оролтыг гаралтанд хувиргаж буй үйлдлийг заах процессуудыг тодорхойлж дүрсэлнэ.
4. Процессыг нэг энгийн функц гүйцэтгэх төвшинд хүртэл цааш процессуудад задална.
5. Дараагийн төвшинд өгөгдөлийн урсгал болон файлыг мөн дүрсэлж өмнөх төвшинтэй баланс барьж байгаа эсэхийг шалгана. Энэ нь дараагийн төвшинд процесс руу орсон эсвэл процессоос гарсан өгөгдөлийн урсгалын тоо баланс барих буюу ижил байх ёстой гэсэн үг юм. Ингэснээр төвшин хоорондын холбоог харуулах төдийгүй нийт системийн бүрэн байх нөхцөлийг хангадаг.

Анхаарах зүйлс
• ЕД-ийн дараагийн диаграмыг ӨУД 0, Төвшин 1 гэх ба ямар процессыг задалж байна түүний дугаараар ӨУД-ыг дугаарладаг. Жишээ нь: 1.2 гэсэн дугаартай процесс байвал үүнийг задлавал ӨУД 1.2 болох ба төвшин 3 болох нь ойлгомжтой. Харин 1.2 гэсэн дугаартай процесс дүрслэгдсэн төвшин нь 2-р төвшин байна.
• Процесс бүрийг дугаарлах хэрэгтэй.
• Ер нь нэг төвшинд олон процесс дүрслэн нийлмэл диаграммд хүргэхгүйн тулд 7-оос илүү процесс дүрслэхээс зайлсхийх хэрэгтэй.
• Нэг төвшинд ямар процессуудыг дүрслэх вэ? гэдэг асуудал их чухал юм. Үүнээс үндэслэн процессуудыг дараалалын дагуу дүрслэх гэсэн асуудал гарч ирж байгаа юм.
• Системийнхээ хэрэгцээ шаардлагыг зөв, бүрэн тодорхойлсон, тодорхой мэдээлэл цуглуулсаны үндсэн дээр ӨУД-ыг дүрсэлдэг.
• ӨУД-ын тусламжтайгаар системийн нийт үйл ажиллагаа, түүний логик загвар гарсан байх ёстой.
• Хүүрнэн тоочсон байдлаар системийг тодорхойлох нь ямагт тодорхой биш байдаг учраас ӨУД гэсэн хэрэгсэл ашиглаж байгаа гэдгийг сана. Мөн системийн талаархи ойлголт бүрхэг, түүнийг бүрэн ойлгохын тулд энэхүү загварыг ашиглаж байгаа юм.
• Хуучин системийн загварыг шаардлагатай үед хэрэглэж болох ба заавал хэрэглэх зүйл биш юм.
• Хэрэв боломжтой бол шууд шинэ системийн загварыг гаргах хэрэгтэй юм.
• Системд гарч болох өөрчлөлтөөс аль болох зайлсхийсэн, ө.х ситем ХЭРХЭН хийгдэхийг бус ЮУ хийх ёстойг үзүүлнэ. Энэ нь бүх физик шаардлагуудыг хассан идеал загвар бий болгоно гэсэн үг юм. Ингэж технологи, хүмүүс, өгөгдөл дамжуулалт, механик үйл ажиллагааг хассанаар систем хэрхэн ажиллаж байгааг бус харин ЮУ хийж байгааг дүрсэлсэн логик загвар гарч байгаа юм.
• Дээрхтэй холбогдуулж загварт өгөгдөл хадгалах болон зөөх физик процесс, процессийг гүйцэтгэн эрхлэх хүн машин, өгөгдөл хадгалах хэрэгсэл дүрслэгдэхгүй учраас ӨУД маань шинэ болон бодит системийн алиных нь ч бүрэн төгс илэрхийлэл болж чадахгүй юм.
• Үйлдлийн дараалалын логик чухал бөгөөд зарим процесс өмнөх процессын үр дүнд гарах өгөгдөлийг ашиглах бол зарим нь харилцан үл хамааран зэрэгцэн хийгдэж болно.
• Гадаад объектыг мэдээлэлийн эх үүсвэр эсвэл мэдээллийн гадаад хүлээн авагч гэдэг ойлголтоор авч үзнэ. Ингэснээр Ерөнхий Диаграм (ЕД)-д системийн оролт, гаралт (үр дүн) маш тодорхой харагдаж байх юм шүү.

Класс диаграм

2009-04-28T19:00:00.008+08:00

Класс ба объект диаграм
Класс диаграмын зорилго нь шинэ системд хэрэгтэй обьектуудыг тодорхойлох явдал юм. Класс диаграмд обьектын шинж чанар, төлөв байдлууд нь бүрэн тодорхойлогдсон байх ёстой. Ерөнхийдөө энгийн түвшний диаграм нь системийн бүх классууд тэдгээрийн хоорондын уялдаа холбоог харуулахад ашиглагдана. Уламжлалт системийг хөгжүүлэх арга зүйд өгөгдлийн сангийн загвар гаргахад хэрэглэгддэг ERD(Entity Relationship Diagram) буюу Объектын холбоосын диаграмтай ижил дүрслэгддэг.
Класс диаграм нь доорх зүйлсийг харуулна :
*Обьект хандлагат шинжилгээ ба зохиомжийн процессийн үед гарах зарим ялгаатай дүрслэлүүд
*Үйл ажиллагааны ерөнхий ойлголтуудыг тодорхойлох болон асуудлуудын талаар шинжлэх ашигтай хэрэгсэл юм.
*Асуудлуудад оршиж буй “төрлүүд”-ийг шалгах арга
*Мэдээллийг баримтаар нотлох арга юм.
Обьектын диаграм нь обьектуудын хоорондын бүтцийн зохион байгуулалтыг тодорхойлоход туслана.
Класс диаграм нь системийн статик бүтцийг дүрсэлдэг. Классууд болон тэдгээрийн хоорондын холбооноос бүрдэнэ.
-Нэр (классын нэр)
-Шинж чанар –5 элемэнтээр дүрслэгдэнэ: хандах хандалт, нэр, олон тоо, өгөгдлийн төрөл ба анхдагч утга.
-Үйлдэл буюу функцүүдын хэсэг – 4 элементээр дүрслэгдэнэ: хандах хандалт, нэр, параметрүүдийн жагсаалт (параметрийн нэр : төрөл) ба буцаах утгыг тодорхойлно. Нэр нь ерөнхий байна. Хэрэв буцаах утгыг тодорхойлоогүй бол буцаах утга нь (void) байна. Хийсвэр функцийн нэр нь ташуу бичигдэнэ.

Класс диаграмд хэрэглэх холбоос ба тэмдгэлгээ

Төрөлт холбоосын хувилбарууд

Обьектын диаграм
Обьектын диаграм нь системийн статик бүтцийг дүрслэн харуулдаг. Обьектын диаграм нь үйл ажиллагааны бодит орчинд байх тодорхой обьектуудыг дүрслэхэд ашиглагдах график дүрслэл юм. Обьектын диаграм нь обьектууд болон тэдгээрийн хоорондын холбоосыг харуулна. Класс диаграмыг илүү ойлгомжтой /жишээн дээр/ тайлбарладаг.

Обьектууд болон классуудыг тодорхойлохдоо шинжилгээний шатанд системд шаардагдах обьектууд болон классуудын жагсаалтыг тодорхойлох шаардлагатай болдог.Энэ нь үйл ажиллагааны мэдээллүүдээр тодорхойлогдоно.Үйл ажиллагааны мэдээллүүдээс нэр үгээс обьект болон классуудыг гаргаж авах буюу өгүүлбэр зүйн анализ хийдэг.

Програм хангамжийн шаардлага тодорхойлох

2009-04-16T22:30:00.002+08:00

1. Ерөнхий зүйл

1.1 Програм хангамжийн шаардлага тодорхойлох бичиг баримтын зорилго
<Програм хангамжийн шаардлага тодорхойлох энэхүү бичиг баримтын зорилго нь хөгжүүлэх гэж буй системийн програм хангамжийн урьдач нөхцөлүүд, гарч болох эрсдэл, нийтлэг үзүүлэлтүүд, архитектурын сонголт, гадаад орчинтой холбогдох интерфейсын үзүүлэлт, системийн чадвар, функцийн шаардлагын үзүүлэлтүүд зэргийг тодорхойлоход оршино.>

2. Нийтлэг үзүүлэлтүүд

2.1 Урьдач нөхцөл, гарч болох эрсдэл
<Шинээр боловсруулах системийг нэвтрүүлэхэд үед гарч болох эрсдлийн талаар буюу ерөөсөө эрсдэлд тавигдах шаардлага, тохирч чадаагүй байгаа, авч хэлэлцэгдээгүй зүйлүүд энд яригдах юм. Жиш нь: Системийг нэвтрүүлсний дараа хэрэглэгчид цааш өөрсдөө системийг хариуцаж бусад байгууллагуудад нэвтрүүлэх ажлыг гүйцэтгэх эсэх гэх мэт.>

2.2 Архитектурын сонголт
a. Програм хангамжийн талаар
Жиш нь:
Өгөгдлийн сан удирдах системийн талаар: <>
Үйлдлийн системийн талаар: <>
Програмчлах хэлбэр, технологийн талаар: <>
b. Техник хангамж, техник тоног төхөөрөмжийн талаар
Жиш нь:
Өгөгдөлийн сангийн сервер
/Dual Xeon 3.0GHz Processor (1M Cache, 800MHz FSB)
2GB 266 DDR RAM with ECC
8 X 250GB 7200RPM w/8MB Cache Hot-swappable Hard Drives
Dual 10/100/1000 Gigabit Ethernet
Single SCSI 160 LVD Connector
PCI-X bus ( 1 GHz )
Redundant, Hot-Swap Cooling Fan Modules
Redundant, Hot-Swap Power Supplies
19" Rack Mountable
Dual Power Supply, 550W
1.44MB FDD
52x CD-ROM/
<Хавсралтаар одоогийн ашиглаж байгаа техник, тоног төхөөрөмж, сүлжээ нь уг
системийг хийж гүйцэтгэхэд хангалттай байгаа талаар оруулж өгдөг.>

2.3 Системийн чадвар
<Уг системийг хийж гүйцэтгэхэд хэрэглэгчийн шаардлага болон хийж гүйцэтгэх функцуудыг судалсанаар хамгийн шинэ, боломжит технологиор, уян хатан чанарын өндөр түвшинд гүйцэтгэх боломжтой талаар бичнэ.>

3. Функцийн шаардлагын үзүүлэлтүүд

3.1 Програм хангамжийн объектууд, класс диаграм зэргийг хавсралтаар үзүүлнэ. Энд зурагдах диаграмууд нь эхний түвшний диаграмууд зурагдана гэдгийг санах хэрэгтэй.

Unified Modeling Language (UML)

2009-04-13T13:34:00.008+08:00

Нэгдсэн загварчилгааны хэл - Unified Modeling Language (UML)

Нэгдсэн загварчилгааны хэл буюу Unified Modeling Language(UML) нь програм хангамжийн системүүдийг загварчилах тодруулбал програм хангамжийн системийн бүрдэл хэсгүүдийг дүрслэх, тодорхойлох, байгуулах болон бичиг баримт үүсгэхэд зориулагдсан график хэл юм.
Уг хэлийг 1990-ээд оны эхээр обьект хандлагат загварчилгааны ертөнцөд томоохон тэргүүлэгчид болох Grady Booch, James Rumbaugh болон Ivars Jacobson нар зохиожээ.Тэдгээрийн зорилго нь тухайн үеийн 3 чухал загварчилгааны хэлүүдийг нэгтгэх зорилготой байв. Эдгээр нь Booch–ийн загвар, Обьект загварчилгааны техник (OMT) болон обьект хандлагат програм хангамжийн инженерчлэл (Object Oriented Software Engineering(OOSE)) гэсэн загварчилгааны хэлүүд юм. UML нь Обьект менежмент групын (OMG) стандарт хэл болсон бөгөөд 1.3 хувилбар нь 1999 онд зохиогдсон ба энэ нь 2.0 хувилбарын эхлэл болох зориулалттай байв. UML нь системийн шинжээч болон програм хангамжийн архитекторын сонгосон сонголтуудыг бичиг баримт рүү хөрвүүлэхэд өргөн ашиглагдана.
Програмын шаардлагыг обьект хандлагат загварчиллаар тодорхойлохын тулд тусдаа боловч хоорондоо холбоотой , обьект хандлагат 5 диаграмыг үндэс болгон ашиглана. Ихэнх тохиолдолд, системийн шинжээч нь бизнесийн хэрэгцээ шаардлагын талаарх бүрэн тодорхойлолт авахын тулд үндсэн 5 диаграмыг ашигладаг. Гэсэн хэдий ч, зарим тохиолдолд шаардлагыг хангалттай тодорхойлохын тулд 3 эсвэл 4 диаграм нь л ашиглагдах тохиолдол бас байдаг. Эдгээр 5 диаграм нь: 1-рт класс диаграм, 2-рт use case диаграм, 3-рт хамтын ажиллагааны диаграм (collaboration), 4-рт дэс дарааллын диаграм (sequence), 5-рт төлөв байдлын диаграм (statechart) зэрэг болно. /Үндсэн 5 диаграмын талаар тус бүрд нь болон тодорхой жишээнүүдийг энэ блогтоо цаашид дүрслэн үзүүлнэ/
Класс диаграмын зорилго нь шинэ системд хэрэгтэй обьектуудыг тодорхойлох явдал юм. Класс диаграмд обьектын шинж чанар, төлөв байдлууд нь бүгд тодорхойлогдсон байх ёстой. Ерөнхийдөө энгийн түвшний диаграм нь системийн бүх классууд тэдгээрийн хоорондын уялдаа холбоог харуулахад ашиглагдана.
Use case диаграмын зорилго нь систем яаж ашиглагдах вэ гэдгийг тодорхойлох зорилготой.
Хамтын ажиллагааны диаграм (collaboration)нь ямар обьект өгөгдсөн функцтэй ажиллах вэ гэдгийг тодорхойлно. Энгийн хамтын ажиллагааны диаграм нь функцийг гүйцэтгэхийн тулд обьектууд тэдгээрийн харилцан хамаарал, тэдгээрийн хооронд дамжигдаж буй мэдээллүүдийг дүрслэнэ.
Дэс дарааллын диаграм нь хамтын ажиллагааны диаграм дээр дүрслэгдэх мэдээллүүдийн өөр нэг дүрслэл юм. Гэхдээ бага зэрэг ялгаатай дүрслэгдэнэ. Обьектуудын хамтын ажиллагааг харуулахаасаа илүүтэйгээр тэдгээрийн хооронд дамжигдах мессежүүдийн дарааллыг чухалчилж харуулна. Дараалал нь дээрээс доош чиглэлд зурагдана. Дэс дарааллын диаграм болон хамтын ажиллагааны диаграм нь нийлээд харилцан ажиллагааны(interaction) диаграмыг бүрдүүлнэ.
Төлөв байдлын диаграм нь обьект бүрийн хувь дахь төлөв байдлуудыг дүрслэнэ. Класс бүрд нь төлвийн диаграм зурагдана.
Обьект хандлагат шаардлага = Класс диаграм + Use case диаграм + харилцан ажиллагааны диаграм (дэс дарааллын болон хамтын ажиллагааны) + төлөв байдлын диаграм
Шинжилгээний үе шатанд асуудлын үйл ажиллагааны талаарх ойлголтуудыг ойлгоход туслах класс диаграмыг үүсгэдэг. Эдгээр диаграмууд нь програм хангамжийн нэвтрүүлэлтийн нарийвчилсан хэсгүүдийг харуулдаггүй. Байгуулалтын үе шатанд ижил класс диаграмыг ашиглаж нэмэлт хэсгүүдийг харуулж болно. Нэмэлт хэсгүүд нь нэвтрүүлэлтийн талын хүндрэлүүдийн ондоо дүрслэлийг харуулна. Энэ шатанд дүрслэгдэх класс диаграмыг хэтийн төлвийн тодорхойлолтын үүсэх класс диаграм гэж нэрлэнэ. Энэ хэтийн төлвийн дүрслэл нь классын програмын дүрслэлийг дүрслэн харуулах ба шийдийг хэрэгжүүлэх хангалттай нарийвчилсан хэсгүүдээс тогтоно. UML нь процессийг тодорхойлдоггүй гэдгийг санах хэрэгтэй. UML –ийг зөвхөн маш ойлгомжтой тодорхойлогдсон обьект хандлагат шинжилгээ ба зохиомжийн процессд л ашиглана. Ихэнх тохиолдолд, обьект хандлагат шинжилгээ ба зохиомжийн процесс нь програм байдаг.

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

Хэрэглэгчийн дүрслэл
Хэрэглэгчийн дүрслэл нь системийн хэрэглэгч нарын хэтийн төлөв, хэрэгцээ шаардлагуудаас системийг дүрслэн харуулна. Use case диаграм нь системийн гадаад орчинтой харьцах харьцааг гол нь дүрсэлдэг. Диаграм нь “хэрэглэгч” буюу “actor” гаднаас орж ирэх функц, процедурууд буюу “use case” болон тэдгээрийн холбоосноос тогтоно. Системд хэрэгтэй мэдээллийн эх үүсвэр болон түгээгч хэлбэрээр хэрэглэгчдийг ойлгох хэрэгтэй юм.

Бүтцийн дүрслэл
Бүтцийн дүрслэл нь системийн статик талуудыг дүрслэн харуулдаг. Класс диаграм нь системийн статик бүтэц зохион байгуулалтыг дүрслэнэ. Диаграм нь классууд болон тэдгээрийн хоорондын холбоосноос бүрдэнэ. Обьект диаграм нь хугацааны онцгой тохиолдлууд дахь системийн статик бүтэц зохион байгуулалтыг дүрслэнэ. Уг диаграм нь обьектууд болон тэдгээрийн хоорондын холбоосноос бүрдэнэ.

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

Гүйцэтгэлийн дүрслэл
Гүйцэтгэлийн дүрслэл нь системийн биелэлтийн бүтцийн болон тохиолдлын хэсгүүдийг дүрслэнэ. Бүрдэл хэсгийн диаграм нь програм хангамжийг нэвтрүүлэх бүрдэл хэсгүүдийн дагуух хэрэгцээ ба зохион байгуулалт, бүтэц тогтолцоог дүрслэнэ.

Хүрээлэн буй орчины дүрслэл
Системийн биелэлтийн физик орон зайг дүрслэнэ. Холбоо хамаарлын диаграм нь нөөц элементүүдийн сүлжээ болон физик элемент бүр дэх програм хангамжийн бүрдэл хэсгүүдийн хэлбэр дүрсүүдийг дүрслэн харуулдаг.

UML диаграмын төрлүүд
Загварыг UML-ийн 9 үндсэн диаграм, багц бичиглэл, UML тайлбарууд болон UML-ийн өргөжүүлсэн механизмуудыг ашиглан үүсгэнэ. Диаграмуудыг хоёр хэсэг болгон авч үздэг:
* Статик загвар – статик загвар нь загварчилж буй системийн үндсэн бүтцийг дүрслэн харуулдаг.
* Динамик загвар – системийн төлөв байдлуудыг онцолж харуулдаг.

Статик загвар
Системийн статик хэсгүүдийг үүсгэх ба дүрслэн харуулна. Системийн үндсэн, суурь хэсгүүдийг тусгаж өгдөг. Асуудлуудын үндсэн чухал дүрс, загваруудыг үүсгэдэг. Статик загвар нь UML-ийн дараах диаграмуудыг агуулна:

* Use case диаграм
* Класс (class) диаграм
* Обьект (object) диаграм
* Бүрдэл хэсгүүдийн (component) диаграм
* Холбоо хамаарлын (deployment) диаграм

1.Use case диаграм доорх зүйлст хэрэгтэй. Үүнд:
* Системийн шаардлагуудын үндсэн шинжүүдийг тодорхойлох
* Эдгээр шаардлагуудыг хэн ашиглахыг тодорхойлох
2. Класс диаграм нь хамгийн өргөн ашиглагддаг диаграм юм. Диаграм нь доорх зүйлсийг харуулна. Үүнд:
* Обьект хандлагат шинжилгээ ба зохиомжийн процессийн үед гарах зарим ялгаатай дүрслэлүүд
* Үйл ажиллагааны ерөнхий ойлголтуудыг тодорхойлох болон асуудлуудын талаар шинжлэх ашигтай хэрэгсэл юм.
* Асуудлуудад оршиж буй “төрлүүд”-ийг шалгах арга
* Сүүлд нэвтрүүлэх мэдээллийг баримтаар нотлох арга юм.
3. Обьектын диаграм нь обьектуудын хоорондын бүтцийн зохион байгуулалтыг тодорхойлоход туслана.
4. Бүрдэл хэсгүүдийн диаграм нь програм хангамжийг байрлуулахад туслана
5. Идэвхижүүлэлтийн диаграм нь техник хангамжийн бүрдэл хэсгүүдийг тодорхойлно.

Динамик загвар
Динамик загвар нь системийн төлөв байдлуудыг харуулна. Дараах диаграмуудыг агуулна:
* Дэс дарааллын (Sequence) диаграм
* Хамтын ажиллагааны (Collaboration) диаграм
* Төлөв байдлын (State chart) диаграм
* Үйл ажиллагааны (Activity) диаграм

Дэс дараалал болон хамтын ажиллагааны диаграмууд нь харилцан ажиллагааг ялгаатай хоёр төрлөөр дүрслэнэ.

1. Дэс дарааллын диаграм нь онцгой шинжүүд болон шаардлагуудад зориулсан мэдээнүүдийн дэс дарааллыг харуулна.
2. Хамтын ажиллагааны диаграм нь обьектуудын хоорондын мэдээнүүд болон обьектуудын хоорондын бүтцийг харуулна.
3. Нөхцөл байдлын диаграм нь тухайн нэг обьектийн төлөв байдлыг шалгана.
4. Үйл ажиллагааны диаграм нь хэсэг бүлэг обьектуудын төлөв байдлыг шалгана. Үйл ажиллагаан болон нөхцөл байдлын диаграмууд нь хоёулаа дан шинжүүд болон шаардлагуудын төлөв байдлыг шалгана.

Хүлээн авах үеийн тест

2009-04-03T17:19:00.003+08:00

Хүлээн авах үеийн тест - Acceptance test

Хүлээн авах үеийн тест гэж юу вэ?
- Програм хангажийн системийн хамгийн сүүлийн шатанд хийгдэх тест.
- Ихэвчлэн програм хангамжийг хэрэглэх эцсийн хэрэглэгчтэй хамтран хийдэг.
- Энэ төрлийн тестийн гол нь хэрэглэгчийн эхний тавьж байсан шаардлагатай уялдуулан хэрэглэгч хэрэглэх үеийн нөхцөл дээр үндэслэн шалгалт хийдэг онцлогтой.
- Энэ тест нь нэг талаас програм хангамжийн системийн “bug” илрүүлэх, нөгөө талаас хэрэглэгчтэй ойлголцох явдал юм.

Хүлээн авах үеийн тестчилэл – Бэлтгэл:
Хүлээн авах үеийн тестийн хийхээс өмнө прогорам хангамж бүрэн хийгдсэн байх ёстой. Мөн хэсэгчилсэн, нэгдсэн, системийн тестүүд хийгдсэн, бичиг баримтуудыг бүрдүүлсэн байна.

Хүлээн авах үеийн тестчилэл – Хэрхэн хийх вэ?
Хүлээн авах үеийн тестийг ихэвчлэн “хар хайрцаг бодлого”-р хийдэг.
Дараах алхмуудаар гүйцэтгэнэ:
1) Хүлээн авах үеийн тестийн төлөвлөгөө
2) Загвараа гаргах
3) Тестийн оролцогчдыг тодорхойлох
4) Гүйцэтгэх
5) Алдаа дутагдалыг баримтжуулах
6) Шийдвэр гаргалт /алдаа “bug”-г хэрхэх талаарх/
7) Дуусгах

Хүлээн авах үеийн тестийн стандарт
1. Төрөл
Хүлээн авах үеийн тестийг хийхдээ дараах 3-н төрлийн тестийг авч үзнэ. Үүнд:
Шинэ системийн тест: Програм хангамжийн системийг бүхэлд нь авч үзэх.
Regression тест: Нийт систем нь аливаа өөрчлөлтөд оршин тогтнож чадаж байгааг шалгах.
Хязгаарлагдсан тест: Нийт систем нь аливаа онцгой нэг өөрчлөлтөд оршин тогтнож чадаж байгааг шалгах.

1.1 Шинэ системийн тест
Зорилго:
Ситсемийн оролцогчидтой хийх уулзалтаар бүх тестчилэлийн объектуудыг тус тусд тодорхойлох, баталгаажуулах.
Шинэ програм хангамжийн системийн хэрэгцээ, шаардлагыг баталгаажуулах.
Хэзээ төлөвлөж эхлэх вэ: Хүлээн авах үеийн тестийн төлөвлөгөөг програм хангамжийг хөгжүүлэх процессийн эхэнд хийдэг.
Дараах материалуудыг хэрэглэнэ. Үүнд:
* Хэрэглэгчийн болон програм хангамжийн шаардлага тодорхойлох бичиг баримт
* Програм хангамжийн зохиомжийн тайлбар бичиг баримт
* Төслийн бичиг баримт
* Техникийн бичиг баримт
* Тусламжийн /help/ бичиг баримт
* Хэрэглэгчийн сургалтын материал
* Хэрэглэгчийн гарын авлага
* Програм хангамжийн явцын өөрчлөлтын хүсэлтүүд
* Тест хийх, тестийн төлөвлөгөөний гэрээ, дүрэм журам
* Тестийн үр дүнгийн гэрээ, дүрэм журам
* Өөр програм хангамжийн системд хийж байсан хүлээн авах үеийн тестийн материал /өмнөх ижил төрлийн ажлын туршлага/

1.2 Regression тест
Зорилго:
"Бүхэл бүтэн, цэвэр, төгс төгөлдөр" систем дээр ажиллах баталгааг гаргах.
Програм хангамжийн систем нь өөртөө цаашид өөрчлөгдөхөөр функц агуулаагүйг баталгаажуулах. /өөрчлөлтийг тооцсон байх/
Шинэ хөгжүүлэлтэнд /кодчилол/ бүх шаардлагууд тохирохыг баталгаажуулах.
Хэзээ төлөвлөж эхлэх вэ: Хүлээн авах үеийн тестийн төлөвлөгөөг програм хангамжийг хөгжүүлэх процессийн эхэнд хийдэг.
Дараах материалуудыг хэрэглэнэ. Үүнд:
* Хэрэглэгчийн болон програм хангамжийн шаардлага тодорхойлох бичиг баримт
* Програм хангамжийн зохиомжийн тайлбар бичиг баримт
* Төслийн бичиг баримт
* Техникийн бичиг баримт
* Тусламжийн /help/ бичиг баримт
* Хэрэглэгчийн сургалтын материал
* Хэрэглэгчийн гарын авлага
* Програм хангамжийн явцын өөрчлөлтын хүсэлтүүд
* Тест хийх, тестийн төлөвлөгөөний гэрээ, дүрэм журам
* Тестийн үр дүнгийн гэрээ, дүрэм журам
* Өөр програм хангамжийн системд хийж байсан хүлээн авах үеийн тестийн материал /өмнөх ижил төрлийн ажлын туршлага/

1.3 Хязгаарлагдмал тестчилэл
Энэ тестчилэл нь дотроо ялгаатай төрлүүдтэй ба нийт системийн хаана, ямар нөхцөлд шаардлага тодорхойлж чадахгүй байгааг шалгадаг.

Хүлээн авах үеийн тестийн төлөвлөгөө
Тест хийх үүрэг, хариуцлага
i. Хүлээн авах үеийн тестийн хэрэглэгч, харилцагчдийн үүрэг хариуцлагуудийг бэлдэх, гүйцэтгэх үүргүүдийг тодорхойлох.
Тестийн аргачилал, хандлага
i. тестчилэлийг ямар төрлүүдээр гүйцэтгэх (ө.х. гадны хүчний нөлөөллийн тестчилэл, хугацааны тестчилэл, даган мөрдөх, санал нийлэх тестчилэл, бүтээмж, чадварын тестчилэл).
ii. тестчилэлийг ямар түвшинд гүйцэтгэх (ө.х. системийн түвшин, бүрэлдэхүүн хэсгүүдийн түвшин, тодорхой хэсгийн нэгдсэн түвшин).
iii. тестийн ямар аргууд, хэрэгсэлүүд ба үйлдлүүдийг хэрэглэх.
iv. тестийн өгөгдлийн эх бэлтгэх.

Тестийн хуваарь
i. тестүүдийн эхлэх ба дуусах хугацаануудыг тодорхойлох.
Алдаа дутагдалыг тайлагнал ба өгөгдлүүдийн “бичлэг хийх”
i. Ямар үйл ажиллaгаанд алдаа байгааг тайлагнах / тайлбарлах лавлагаа гаргах/.
ii. Тестийн үр дүн болгон дээр “бичлэг хийх”.

Шаардлагатай нөөцүүд
i. Техник хангамж (тоног төхөөрөмжүүд).
ii. Програм хангамж (үйлдлийн систем, компилятор, тестийн хэрэгсэлүүд).
iii. Бичиг баримт (тестчилэлийн бичиг баримт, хэрэглэгчийн шаардлага тодорхойлох гэх мэт бичиг баримтууд).
iv. Хүмүүс (ажилтан албан хаагчид, хэрэглэгч, харилцагчид).
v. Тестийн өгөгдөлүүд
vi. Бусад ...

Тестийн орчин
i. Тестийн орчныг бүдүүвчлэн зурах
Тестийг эхлүүлэх
i.. техник хангамжийг бэлдэх.
ii. програм хангамжийг бэлдэх

Тестийн оролт
i. Тестийн оролтууд
Тестийн үйл ажиллагаа
i. Тестийн алхамуудыг нарийвчлан гаргах.

Татаж авах:
Хүлээн авах үеийн тестийн загвар

Хэрэглэгчийн шаардлага тодорхойлох бичиг баримтын загвар

2009-03-28T18:31:00.002+08:00

ХЭРЭГЛЭГЧИЙН ШААРДЛАГА ТОДОРХОЙЛОХ БИЧИГ БАРИМТЫН ЗАГВАР
/URD – User Requirement Definition Template/

1. Ерөнхий зүйл
1.1 Хэрэглэгчийн шаардлага тодорхойлох бичиг баримтын зорилго
Хэрэглэгчийн шаардлага тодорхойлох энэхүү бичиг баримтын зорилго нь системийн ерөнхий ойлголт, хэрэглэгчийн талаарх мэдээлэл түүний онцлог, системийг хүлээн авах үеийн стандарт, шинэ системийн онцлог, системийн хамрах хүрээ болон хэрэглэгчийн шаардлагыг тодорхойлох явдал юм.
Програм хангамжийн үндэслэл
<Програм хангамжийг боловсруулах болсон шалтгаанд хариу өгөх байдлаар бичих буюу хуучин системийн дутагдалтай талыг нээн илрүүлж бичнэ>
Өнөөгийн нөхцөлд
<Системийн өнөөгийн байдлыг бичнэ>
Ач холбогдол
<Энэхүү симстемийг боловсруулсны ач холбогдол>
1.2 Хэрэглэгчийн талаарх мэдээлэл
Байгууллагын дэлгэрэнгүй танилцуулга, байгууллагын иерархи бүтэц
1.3 Системийн хамрах хүрээ
<Системийн хамрах хүрээг дэд системүүд, байгууллагууд, салбарууд, хэрэглэгчдийн тоо зэргээр гаргана>
1.4 Хэрэглэсэн нэр томъёоны тодорхойлолт
<Лавлах материалын жагсаалт, нэр томъёоны тайлбарууд>

2. Хэрэглэгчийн шаардлага
2.1 Системийн тухай ерөнхий ойлголт
<Одоо хэрэглэгчдэж байгаа системийн талаар дэлгэрэнгүй тайлбар бичнэ.>
2.2 Хэрэглэгчийн онцлог
<Хэрэглэгч системийг хүлээн авах үед ямар байх, хэрэглэгч системийг ашиглахад бэлэн байдал, хэрэглэж байгаа програм хангамж, техник хангамжийн шаардлага үзүүлэлтүүд, боловсруулах гэж буй системийг хэрэглэх хэрэглэгчдийн ажлын байрны тодорхойлолт зэргийг бичнэ.>
2.3 Хүлээн авах үеийн ерөнхий стандарт шаардлага
<Хэрэглэгч системийг хүлээн авах үед ямар шаардлага тавигдах буюу хүлээн авах үеийн тест /acceptance test/ хийх хэв маяг, төлөвлөгөөтэй холбоотойгоор бичнэ>

3. Шаардлагын үзүүлэлтүүд
3.1 Хэрэглэгчийн үйл ажиллагааны шаардлага (Функционал шаардлага)
<Хэрэглэгч юу хүсэж байгааг нэг талаас хэрэгцээ, нөгөө талаас шаардлагатай холбон бичнэ>
3.2 Чанарын шаардлага
<Боловсруулах системийн чанар ямар байх, ямар стандарт хэрэглэх талаар бичнэ>
3.3 Системийн ашиглалтын талаар
<Хэрэглэгч хуучин болон шинэ системийг хэрхэн хэрэглэж байгаа, хэрхэн хэрэглэх талаар бичнэ>

Тайлбар: Жишээ болгон хэдэн жилийн өмнө хийж байсан БСШУЯ-ны удирдлагын мэдээллийн систем боловсруулах үеийн бичиг баримтыг орууллаа.

Хэрэглэгчийн шаардлага тодорхойлох

2009-03-28T18:30:00.003+08:00

Төслийн үйл ажиллагаа

2009-03-28T18:29:00.003+08:00

V загвар

2009-03-24T15:58:00.008+08:00

Системийн хөгжүүлэлтийн түүх
* 80-д он Waterfall /хүрхрээ/ хэлбэрийн хөгжүүлэлт
Өнөөдөр ч хэрэглэгдэж, гол үндэс суурь болж байгаа арга юм.Хэрэгцээ шаардлага– шинжилгээ-зохиомж- кодчилол-тестчилэл-нэвтрүүлэлт гэсэн дарааллыг баримтлах арга.Үндсэн философи нь "Хүрхрээ эргэж урсдаггүй". Үе шатын хэрэгжүүлэлт бүрт урвуу холбоо буюу эргэх холбоо гаргахгүйд гол анхаарлаа хандуулах хэрэгтэй. Эхний үе шат маш сайн, алдаагүй хийгдсэн тохиолдолд сайн хөгжүүлэлтийн арга байж чаддаг. Дээрх ойлголтын эсрэг хэлбэр буюу дээд үе шат муу хийгдэхэд дараагийн үе шатууд муу хийгдэх болно.
* 90-д он Spiral хэлбэрийн хөгжүүлэлт
Prototype хэлбэрийн хөгжүүлэлт. Програмын хамгийн гол цөм хэсгийг туршилтын журмаар бүтээж түүний ажлууд гарах үр дүнгээр дүгнэлт хийх арга юм. Хөгжүүлж буй хүн нь чадварлаг байхыг шаардана. Гол үзэл санаа нь: "Бид багадаа цасан өвгөн хийж тоглохдоо, эхлээд гарын алганд багтах хэмжээний цас бөөрөнхийлж /үндсэн хэсэг нь болгож/, дараа нь цасан дээр өнхөрүүлсээр байгаад том болгодог байсан. Энэ тоглоомтой утга нэг юм." Гол нь хөгжүүлэх гэж буй системийн үндсэн суурь хэсгийг буюу гол цөмийг олох нь, тэр хэсгийг л "тордох" замаар хөгжүүлэлт хийдэг.
* 2000-д он Жижиг хэсгүүдэд хувааж хөгжүүлэх арга
Жижиг хэсгүүдэд хувааж, хуваасан хэсгүүдэд үе шат бүрийг хэрэгжүүлэх. Богино хугацаанд гарч ирсэн үр дүнд шинжилгээ хийж дараагийн үе шатанд орно. Хэсэг бүрийг нэгтгэх асуудал их чухал байдаг. Жижиглэн хуваалтын хэсгүүдийг биеэ даасан,бусад хэсгээс аль болох бага хамааралтай, харин их харилцаатай байхаар тооцох хэрэгтэй.

V загвар

V загвар нь хүрхрээ загварын нэгэн хувилбар юм. /Энэ загвар их сайн загвар юм шүү/ Бодлогын даалгавар гаргах болон шинжилгээ, зохиомжийн үе шатуудыг хийх явцдаа тестийн бичиг баримтын төлөвлөгөөг хамт боловсруулдаг нь нэвтрүүлэлт, сууриллуулалтын үед сайн систем хэрэглэгчдэд очдог юм. Хэрэглэгч хүлээн зөвшөөрч байвал тухайн програмчлагдсан системийг сайн систем болжээ гэж үзэж болдог. V загвар нь тестийн үе шатанд эхнээс нь ихээхэн ач холбогдол өгч үе шатуудын боловсруулалтын хийдэг гол онцлогтой юм.
URD – User requirement definition. Õýðýãëýã÷èéí øààðäëàãà òîäîðõîéëîõ. Хэрэглэгчтэй хамтдаа системийн хамрах хүрээ, шаардлага тодорхойлох буюу хэрэглэгч чухам юу хүсэж байгааг хэрэглэгчийн үгээр гаргах бичиг баримт юм.
SRS – Software Requirement Specification. Ïðîãðàìûí øààðäëàãà òîäîðõîéëîõ. Хэрэглэгчтэй болон мэргэжилтнүүдтэй хамтдаа шаардлага тодорхойлох. Хэрэглэгч “ямар хэлбэрээр” хэргэлмээр байгааг програм хангамжийн техникийн даалгавар болгон илэрхийлнэ.
HLD – High Level Design. Ñèñòåìèéí øèíæèëãýý. Îðøèí áàéãàà ñèñòåìèéã çàäëàí, á¿ðýëäýõ¿¿í õýñã¿¿ä ñèñòåìèéí á¿òöèéã òîäîðõîéëîí àñóóäëûã øèéäâýðëýõ øèíý îíîâ÷òîé ñèñòåì áàéãóóëàõ òºëºâëºãºº ãàðãàõ ¿éë àæèëëàãàà þì.
LLD – Low Level Design. Ñèñòåìèéí çîõèîìæ. Сèñòåìèéн шинжилгээний бичиг баримтанд тулгуурлан системийн физик загвар гаргах.
UT– Unit test. Нýãæèéí òåñò
IT – Integration test. Íýãäñýí òåñò
ST– System test. Ñèñòåìèéí òåñò
AT – Acceptance test. Õ¿ëýýí àâàõ ¿åèéí òåñò
/Бүх үе шатын тухай болон тухайн үе шатын template-г дараа дараагийн хэсгүүдэд бичих болно./

Димломын ажил

2009-03-19T16:34:00.007+08:00

Энэ блогт өөрийн болон оюутнуудын хийж байгаа, хийсэн дипломын ажлуудыг тавьж байхаар боллоо. Эхлээд бүр 1999 онд буюу 10 жилийн өмнө миний хийж байсан магистрын дипломын ажлыг хэсгээс тавилаа. Энэ ажил нь "Системүүдийн шинжилгээ хийх арга зүйн харьцуулсан судалгаа" нэртэй. Ажлын зорилго нь системийн шинжилгээний Уламжлалт, Объект хандлагат арга зүйг харьцуулан судлан өөрийн гэсэн нэгэн арга зүй гаргах зорилготой. Одоо эргээд харахад харин хэрэгтэй, хэрэгтэй өгүүлбэрүүд бас байна шүү.
Доорх файл яг өөрийн хийсэн хэсгийг /тухайн үед онолын хэсэг гээд л их юм бичдэг байсан даа/ оруулсан байгаа.

Татаж авах:
Дипломын ажил - 1999 он, "Системүүдийн шинжилгээний арга зүйн харьцуулсан судалгаа"

Системийн шинжилгээ

2009-03-19T16:18:00.006+08:00

Системийн шинжилгээний эхлэлийг 1890 он буюу Фредрик Тейлорын /Frederick Winslow Taylor 1856 – 1915/ зарчимтай холбон үздэг. Энэ зарчимын хандлага нь хүн хүчийг үр ашигтай зарцуулахад чиглэгдсэн байна. Гэхдээ Тейлоризмд дутагдалтай талууд байсан ба хүний зөвхөн физилогийн чадавхийг чухалд үзэж, ажлын сахилга батыг орхигдуулсан, ямар нэг удирдлагын шийдвэр хэрхэн гаргахыг авч үзээгүй юм. 1940 оны үед Тейлорын онол Маслов, Грегор, Ликерт, Шейны онолоор өөрчлөгдсөн. Тэд сэтгэл зүйн хэрэгцээнд тулгуурлан хүмүүсийг зохион байгуулалтын иерархи төвшинөөр дүрсэлсэн. Дэлхийн I дайны нөлөөгөөр хөдөлмөр хөнгөвчлөх, автоматжуулалт гэсэн ойлголт бий болжээ. Үүний үр дүнд барааг түргэн, хямд өртөгтэйгээр үйлдвэрлэх болсон байна. Энэ байдал 1950-иад он хүртэл үргэлжлээд 1960 оноос системийн шинжилгээ хийх эрин үе эхэлсэн гэж үздэг. Системийн шинжээч энэ үед зэр зэвсэгийн системд үнэ ашгийн шинжилгээ хийж бараа материал, хөрөнгө хянах техникийг ашиглан зэр зэвсэгийг хаана хичнээн хэмжээгээр хадгалсаныг тогтоодог байсан байна. Харин компьютер бий болсоноор компьютерийн тусламжтайгаар асуудлын шийдэх арга замыг хайх болжээ. Ингэж системийн шинжээчдийн ажлын хандлагад шинэ өөрчлөлт бий болсон юм. Компьютерийн ухааны салбар харьцангуй залуу салбар боловч асар хурдацтай хөгжиж байгаатай холбогдуулж өнөөгийн түвшинд системийг хөгжүүлэх нэлээд хэдэн аргачилалууд бий болсон байгаа ба зарим аргачилууд нь хэд хэдэн шат дамжсан нэлээд боловсронгуй гэгдэх аргачилалууд байгаа юм. Өнөөдөр манайд стандарт болж тогтсон арга хэрэгсэл байхгүй байгаа ба сонгодог төслийн загварыг ихээхэн хэрэглэж байна.
Систем гэдэг нь нэг талаас байгууллагын болон түүний асуудлуудыг шийдвэрлэх арга зам, хэрэглэгдэх техникийн олонлог, нөгөө талаас тодорхой нэгж хэсгүүдийн хооронд бий болсон харилцаа холбоо юм. Мөн системийн оршин байх үндэс нь систем нь нэг буюу түүнээс дээш зорилгод хүрэхээр загварчилагдсан байдагт оршино.

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

Объект хандлагат болон уламжлалт арга зүйн боломжууд.
Шинжилгээ Зохиомж Кодчилол Боломж
1.Уламжлалт-Уламжлалт-Уламжлалт-Их
2.Уламжлалт-Уламжлалт-Объект хандлагат-Бага
3.Уламжлалт-Объект хандлагат-Объект хандлагат-Дунд
4.Объект хандлагат-Объект хандлагат-Объект хандлагат-Их
5.Объект хандлагат-Объект хандлагат-Уламжлалт-Муугүй
6.Объект хандлагат-Уламжлалт-Уламжлалт-Дунд
Боломж гэдэг нь сайн систем гарах боломж нь юм.

Жич: Дээр зурагт үзүүлсэн ОРОЛТ-БОЛОВСРУУЛАЛТ-ГАРАЛТ гэсэн загвар нь үнэхээр гайхамшигтай загвар юм. Би өөрийн заадаг бүх хичээлийн эхэнд, дунд, төгсгөлд ерөөсөө энэ загварыг бүх боломжит хувилбарыг их яридаг. Жишээ нь програм бичиж сурч байгаа оюутнуудад Оролт-Гаралт эсвэл Гаралт – Оролт гэдэг загвараар дадлага хийлгэх, хичээл заах нь тохиромжтой байдаг. Ө.х бүх оролтын өгөгдөл хэрхэн бэлдэх /хувьсагч зарлах, яагаад зарлаж байгаа, яагаад төрөл гэдэг ойлголт байдаг гэх мэт/ дараа нь ямар нэгэн боловсруулалтгүйгээр зөвхөн үр дүнг ойлгуулах. Энэ нь гаралтын файл эсвэл гаралтын үр дүнгийн төсөөлөл бий болгох аргачилал юм уу даа. Дараа нь өөр нэг бодлогын даалгаврын хувьд эхлээд гаралтыг бэлдээд оролт нь ямар байх талаар төсөөлөл бий болгох гэх мэт. Ерөнхий боловсролоос сурагчдад мэдлэгийг олгох гол суурь нь x,y-н аль нэг нь мэдэгдэж байхад нөгөөгийн утгыг олох бодлогын даалгавар байдаг биз дээ. Тэгвэл энэ л жижиг /том шүү/ дүрмийг дээрх загварт ашиглан төрөл бүрийн хувилбараар хэрэглэх нь их зүгээр санагддаг юм. Энэ талаар буюу “Програмчлалын хэл заах нь бас сурах нь” гэдэг сэдвээр би энэхүү блогтоо дараа нь маш тодорхой бичих болно.

Товчлол:
1. Системийн шинжилгээ бол компьютерийн ухаан гарч ирэхээс бүр өмнө бий болсон. Тийм ч учраас системийн шинжээч хүнд олон төрлийн ур чадвар шаардагддаг. Харин компьютер, мэдээллийн технологитой холбоотойгоор системд шинжилгээ хийх хэв маяг өөрчлөгдөж, үр дүн маш гайхамшигтай болсон.
2. Өөрийн мэддэг, илүү ашиглаж чадах кодчилох хэрэгсэлээс ихээхэн хамаарч шинжилгээ зохиомж хийх сонголтыг хийх хэрэгтэй юм.
3. Аливаа системд шинжилгээ хийж сурахад
- Системийн үндсэн тодорхойлолтыг эхлээд “цээжил”, дараа нь үг бүрийг нь
бясалгаж бодох хэрэгтэй. Ө.х системийг аль хэсгийг дэд систем, аль хэсгийг бүрэлдэхүүн хэсэг, аль хэсгийг элемент гэх вэ гэдэгт тодорхойлолт өгөх хэрэгтэй.
- Энгийн загваруудыг эхлээд маш сайн хэрэглэж сур. (О-Б-Г)
- Янз бүрийн хэрэгсэл програмуудын аль нэгийг төгс эзэмш.
4. Системийн шинжилгээ гэдэг нь мэдээлэл цуглуулах, задлах, нэгтгэн дүгнэх гэсэн ойлголт юм.

Түүх

2009-03-19T16:10:00.009+08:00

Би 1997 оны өвөл КТМС-ыг төгсөөд багш болоход “Системийн шинжилгээ ба зохиомж”-той холбоотой дипломын ажил хийсэн юм. Энэ ажил нь тухайн үед нэлээд шинэлэг тэр болгон оюутнууд хийгээд байдаггүй ажил байсан санагдана. /Харамсалтай нь энэ дипломын ажлаа хайгаад олсонгүй, гэхдээ магистрт үргэлжлүүлэн хийсэн ажлаа Дипломын ажил буландаа тавих болноо/ Д.Ариунбат багш маань намайг бүр 3-р курсэд байхад энэ чиглэл рүү хөтлөн оруулж энэ чиглэлээр багш болохыг ч “тулгаж” билээ. Сайн багшийн шавь байсандаа одоо хүртэл их баярлаж явдаг шүү. Тухайн үед зөвхөн програм хангамж бичих гэдэг боловсруулалтын үе шатыг л чадан ядан суралцаж байсан болохоор програм хангамжийг хөгжүүлэх процесс, системийн хөгжүүлэлт, цаашилбал төслийн менежмент гэж том хүрээгээр сэтгэдэггүй байсан, энэ төрлийн хичээл ч бага ордог байсан юм. Өөрөөр хэлбэл жижиглэн хувааж /top to down/ нэгтгэн дүгнэх /down to top/ бус өөр хоорондоо уялдаагүй жижиг хэсгийг боловсруулахад ихээхэн анхаарал хандуулдаг байж. Гэхдээ Д.Өлзий-Орших, Д.Соёл-Эрдэнэ, Т.Мөнхбаяр гээд бид нар бүр багаасаа төрөл бүрийн програм хийж борлуулдаг байсан нь туршлага суухад их нөлөө болсон юм. Лав л Мөнхөө бид хоёр диплом, курсын ажил их хийдэг байж билээ. :)
Би КТМС-д Ууганчулуун багшийн хичээлийг цааш үргэлжлүүлэн заасан. Системийн шинжилгээ ба зохиомж хичээлийг заахад, сурахад ер нь програм хангамжтай холбоотой мэргэжил эзэмшихэд их нягт нямбай байхыг шаарддаг. Ууганчулуун багш маань их нямбай бас яг тэгж нямбай бэлдсэн лекц надад үлдээсэн нь их хэрэг болсоон. Харин хэдэн сарын л өмнө дөө интернэт үзэж байтал зарим нэг сайт дээр миний тухайн үеийн лекц, материалууд тэр чигээрээ байна лээ. Тэр үеийн лекц, материалууд харин Ууганчулуун багшийн үеийн “угшилтай” лекц, материал юм шүү.
Нэг удаа Д.Ариунбат багш “Замын гэрлэн дохио та хоёр юугаараа адил вэ” гэдэг асуултыг асууж билээ. Нэлээн сүүлд харин хариултыг нь олсоон. Замын гэрлэн дохио бид хоёрын адил зүйл нь хоёулаа нэртэй, хоёулаа хэмжээтэй, хоёулаа хэлбэртэй гэх мэт шинж чанар адил юм байна гэж. Харин ялгаа нь шинж чанартаа харгалзах утга нь юм. Энэ асуулт болон энэ төрлийн асуултыг би оюутнуудаасаа байнга асуудаг. Ер нь бодоод байхад бодит амьдралын жинхэнэ сайн зарчмууд, дүрмүүдыг объект хандлагат технологи, системийн шинжилгээний сайн аргачилалд хэрэглэсэн байдаг учраас их сайхан сэтгэлтэй, зарчимч хүн сайн програм зохиогч, системийн шинжээч болох байхаа. :)
Энэ блогтоо би өмнө хийж байсан болон одоо зааж байгаа хичээлүүдийн бүх л материалыг, бас өөрийн бодлоо бичих болно. Гэхдээ их л цэгцтэй, сургалтын хэлбэртэйгээр бичих санаатай байгаа тул энэ тэндээс нь бичихгүй ээ. Яг л эхнээс нь дараалалтай бичнэ.

Хүмүүс 4-н бүлэгт хуваагдана.
1 Юм мэддэг(1),Мэддэгийгээ мэддэг(1)-Мэргэн хүн(1) /Түүнийг дагагтун/
2 Юм мэддэг(1),Мэддэгийгээ мэддэггүй(0)-Унтаа хүн(1)/Түүнийг сэрээгтүн/
3 Юм мэддэггүй(0),Мэддэггүйгээ мэддэг(1)-Ном сурах хүн(1)/Түүнд ном заагтун/
4 Юм мэддэггүй(0),Мэддэггүйгээ мэддэггүй(0)-Тэнэг хүн(0)/Түүнийг хөөхтүн/
Дорно дахины сургааль

Товчлол:
- Хүн биеийг олж төрөхийн учир нэг нэгэндээ туслах. /Багш ба сурагч./
Багшийг хүндэл, тэгж гэмээнэ мэдлэг авна.
- Сайн програм хангамжийн бүтээгдэхүүн гаргах, бий болох системийг тодорхойлох,
системийн шинжилгээ хийхийн гол нь нэгж хэсэг болтол нь задалж чадах, эргээд
нэгтгэн дүгнэх л юм шүү.
- Нягт нямбай байх, харьцуулан ойлго, дүгнэлт хий, боломж л гарвал програм бич
/туршилтын ч байж болно/, туршлага суу