Программ хангамжийн төслүүдийн амжилттай болох хувь бусад төрлийн төслүүдтэй харьцуулбал харьцангуй бага байдаг. Нийт төслүүдийн 30 орчим хувь нь амжилттай болж, 50 орчим хувь нь ямар нэгэн шинэ асуудлуудтай тулгарч, 20 орчим хувь нь амжилтгүй болдог гэсэн судалгаа байдаг.
Программ хангамжийн төслүүдийн амжилтгүй болох нэг шалтгаан бол төслийн цар хүрээг буруу тооцоолсон, тодорхойлсон байдал юм.
- Яагаад төслийг хэмжих шаардлагатай вэ?
Программ хангамжийн төслүүд нь өөрийн болон бусдын хэрэгцээ, шаардлагад зориулж бүтээгддэг. Хөгжүүлэлтийг эхлүүлэхээс өмнө кейсүүдийг судалж, тодорхойлж, уг кейсүүдээс бүтээгдэх боломжтой шийдлүүдийг ангилж, нэгтгэж үр дүнд хүрэх нь хамгаас чухал. Бидний амьдарч буй орчин, нийгэм, бизнес өдрөөс өдөрт өөрчлөгдөж, хувьсаж байдаг тул бид бизнесийн хэрэгцээг хангахуйц “Амьд систем” хөгжүүлэх нэн шаардлагатай тулгардаг.
“Мэдээлэл-Технологийг дэмжих агентлаг, Японы программ хангамжийн инженерийн төв” -н гаргасан судалгаагаар нийт программ хангамжийн төслийн 31.1% нь амжилттай болдог. Энэ үзүүлэлт дээр илүү нарийн шинжилгээ хийж үзвэл ямар нэгэн тоон хяналтын арга ашиглаж удирдсан төслүүдийн 45.6%, ашиглаагүй төслүүдийн 24.3% нь амжилттай болсон байна.
Прогамм хангамжийн төслийг амжилттай эсэхийг
- “Cost буюу Зардал”
- “Deadline буюу Хугацаа”
- “Quality буюу Чанар”
- “Scope буюу Хамрах хүрээ” зэргээр хэмждэг.
Эдгээрээс зардал болон хугацааг тоон арга ашиглаж удирдах боломжтой ба ингэснээр төслийг амжилттай болгох магадлалыг 2 дахин ихэсдэг. Тэгвэл зардал болон хугацааг удирдахын тулд төслийн цар хүрээг хэмжих зайлшгүй шаардлагатай тулгарна. Төслийн цар хүрээг хэмжиж чадахгүй бол үүнийг удирдах ямар ч боломжгүй юм.
Төслийн цар хүрээг хэмжих хамгийн үр дүнтэй арга бол “AGILE” аргачлалын “Function Point” юм.
Өнөөдрийг хүртэл “AGILE” -р ажиллаж буй тохиолдолд төслийг хэмжих хамгийн үр дүнтэй арга нь “Function Point”, зардал болон хугацааг тооцох үед туршлага болон өгөгдөл дээр үндэслэсэн тоон арга нь “CoBRA”, зөвхөн өмнө байгаа өгөгдөл дээр тулгуурласан арга нь “COCOMOII” гэж үзэж байна.
- Төслийг хэмжих нь. (Function Point)
Аливаа AGILE төслийг эхний гаргасан “User Story” дээр үндэслэн хэмжих нь цор ганц арга юм. Учир нь user story нь хамгийн анхны болхи хэмжилт хийх боломжтой түлхүүр үгнүүдийг агуулдагт оршино. Уг түлхүүр үгнүүдийг жагсаалтыг Хүснэгт 1.1 -д дурдав.
Хүснэгт 1.1. Түлхүүр үг (user story) болон түүнд харгалзах хэмжээ
| Keyword | Function Point | Keyword | Function point |
| Access | 20 fps | Master | 15 fps |
| Activity | 20 fps | Message | 10 fps |
| Add | 4 fps | Modify | 6 fps |
| Address | 15 fps | Name | 4 fps |
| Adjust | 5 fps | New | 25 fps |
| Assign | 15 fps | Number | 10 fps |
| Audit | 7 fps | Payment | 25 fps |
| Browse | 4 fps | Pricing | 40 fps |
| Change | 6 fps | Query | 4 fps |
| Charges | 10 fps | Rate | 15 fps |
| Code | 10 fps | Record | 6 fps |
| Contact | 15 fps | Recurring | 15 fps |
| Contract | 25 fps | Remove | 3 fps |
| Create | 6 fps | Report | 5 fps |
| Delete | 4 fps | Request | 6 fps |
| Detail | 7 fps | Response | 6 fps |
| Discount | 35 fps | Revenue | 7 fps |
| Display | 6 fps | Search | 6 fps |
| Edit | 15 fps | Send | 6 fps |
| Error | 10 fps | State | 10 fps |
| Event | 5 fps | Status | 5 fps |
| Feature | 25 fps | Strategy | 10 fps |
| File | 7 fps | Sub | 25 fps |
| Get | 5 fps | Sum | 5 fps |
| Group | 15 fps | Summary | 7 fps |
| History | 5 fps | Tax | 20 fps |
| Information | 15 fps | Transfer | 4 fps |
| Inventory | 20 fps | Type | 15 fps |
| Level | 25 fps | Update | 6 fps |
| Link | 6 fps | Usage | 20 fps |
| Map | 65 fps | View | 4 fps |
Ямар нэгэн “User Story” -д Хүснэгт 1.1 дэх түлхүүр үгнүүдээс нэг ширхэг олдвол “Function point” -н утга нь, нэгээс олон олдвол хамгийн их утга нь уг “User Story” -н хэмжээ болдог. Хэрвээ таны user story олдоогүй тохиолдолд уг “User Story” -г олон жижиг хэсэгт задлах шаардлагатай болно.
Түлхүүр үгэн дээр тулгуурлаж төслийг хэмжих нь хурдан бөгөөд амархан ч, тэдгээр дээр анализ хийхгүй хэмжвэл буруу тооцоо гарах магадлалтай. Энэхүү аргачлалын тусламжтайгаар төслийн цар хүрээ, анхны таамаглалууд болон буруу ойлголтуудыг тодорхой болгох боломжтой. Гэсэн хэдий ч энэ арга нь хэмжилт хийх боломжгүй нөхцөл байдалд орсноор ажиллахгүй тохиолдлуудтай тулгарна. Ийм үед тухайн “user story” дээр хэмжилт хийхийн тулд шинжилгээ хийх шаардлагатай болдог. Мөн нэг “user story” нь өөртөө олон түлхүүр үг агуулагдаж байгаа үед буруу тооцоолол хийгдэнэ. Иймд “User Story” -г задрахгүй болтол нь задлах нь заримдаа хамгийн зөв арга хэмээгддэг.
User story-г түлхүүр үгнүүдээр хэмжихээс гадна түүний функциональ үйлдлийг тооцон хэмжих хэрэгтэй байдаг. Энэ нь түүний чадамж, үйлдэл болон хэр төвөгтэй процесс болохыг тодорхойлох явдал юм.
Function Point аргачлалд user story-г:
- Typical Process буюу энгийн процесс
- General Process буюу ерөнхий процесс
- Macro Process буюу Макро процесс гэсэн бизнесийн процессуудын төрлүүдэд ангилж авч үздэг.
Ихэнх тохиолдолд user story-г “Typical Process” ба “General Process” -д задлах нь хамгийн тохиромжтой байдаг ба илүү дэлгэрэнгүй мэдээлэл шаардлагатай тохиолдолд “Elementary Process” -д оруулан задалдаг.
- “Typical Process”
Энэ процесс нь хэд хэдэн “Elementary Process” -уудын бүлэг нийлбэр гэж хэлж болно. (жишээ процессыг Хүснэгт 2.1 -д дурдав)
Жишээлбэл “Үйлчилгээний ажилтан нь хэрэглэгчийн хувийн мэдээллийг удирдах боломжтой байна” гэдэг анхны “User Story” байна гэж үзвэл уг тохиолдолд үйлчилгээний ажилтан нь хэрэглэгчийн хувийн мэдээллийг устгах боломжтой эсэх, ямар нэгэн тайлан гаргах боломжтой эсэх нь тодорхойгүй байгаа ба энэ тодорхойгүй байдал нь гүйцэтгэлийн үйл явцад тодорхой болдог. Иймд Хүснэгт 2.1 -д дурдсан дунд хэмжээний “Typical Process” гэж урьдчилсан байдлаар тодорхойлж “21.1 function point” гэж тооцоолох нь тохиромжтой.
Хүснэгт 2.1. Typical Process дах хэмжээ
| Хэмжээ | Тайлбар | Function Points |
| Жижиг | CRUD | 16.5 |
| Дунд | CRUD + Жагсаалт (EQ) | 21.1 |
| Том | CRUD + Жагсаалт + Тайлан (EO) | 26.3 |
- “General and Macro Process”
“General Process” нь ихэвчлэн “Epic Story” -той нийцдэг бөгөөд хэд хэдэн төрлийн оролт гаралтын процессын нийлэмж гэж үзэж болно. Мэдээж цар хүрээний хувьд “Typical process”-с илүү өргөн. “General Process” -г хэрхэн тооцохыг Хүснэгт 2.2 -д үзүүлэв.
Харин “Macro Process”-н хувьд нэлээдгүй том цар хүрээтэй, тойм байдлаар ерөнхийд нь тооцоолдог тул тухайн байгууллага өөрийн өмнөх үеийн туршлага дээр үндэслэн тооцдог. Жишээлбэл тухайн байгууллага нь өмнө нь санхүүгийн холбогдолтой, түүний ойлголтуудыг тодорхойлсон хэд хэдэн систем хөгжүүлж байсан гэж үзвэл дараа дараагийн энэ чиглэлийн нэмэлт чадамжууд, ижил төстэй төслүүдийг хэрэгжүүлэхдээ өмнөх туршлага дээр үндэслэн цар хүрээг тооцоолох боломжтой. “Macro Process” -н тооцоог Хүснэгт 2.3 -д дурдав. Үүнийг ашиглахдаа болгоомжтой байх хэрэгтэй, учир нь хоёр “Macro Process” нь ижил төстэй юм шиг боловч дотроо процессын хувьд маш ялгаатай байх тохиолдол байдаг.
Хүснэгт 2.2. General Process дах хэмжээ
| Хэмжээ | Тайлбар | Function Points |
| Жижиг | 6~10 тодорхойгүй “Elementary Process” | 35.2 |
| Дунд | 11~15 тодорхойгүй “Elementary Process” | 57.2 |
| Том | 16~20 тодорхойгүй “Elementary Process” | 79.2 |
Хүснэгт 2.3. Macro Process дах хэмжээ
| Хэмжээ | Тайлбар | Function Points |
| Жижиг | 2~4 тодорхойгүй “General Process” | 171.5 |
| Дунд | 5~7 тодорхойгүй “General Process” | 285.9 |
| Том | 8~10 тодорхойгүй “General Process” | 457.4 |
- “Elementary Process”
Заримдаа “User Story” -г “Elementary Process” -үүдэд задлах нь хамгийн зөв шийдэл байдаг тухай өмнө нь дурдсан. Хэд хэдэн “Elementary Process”-уудыг агуулах “User Story” -ны хувьд дараах алхмын дагуу тооцоолж хэмжих боломжтой:
- Эхлээд процессыг оролт эсвэл гаралт гэдгийг ялгах хэрэгтэй. Хэрэв оролт байвал “External Input (EI)” гэж үзэн “4.2 function points” -р хэмжинэ. Харин оролт, гаралт эсэх нь мэдэгдэхгүй тохиолдолд “4.4 function point” гэж үздэг.
- Хэрэв процесс нь гаралт байвал “External output (EO)” эсвэл “External Query (EQ)” эсэхийг тодорхойлно. “EO” нь 5.2, “EQ” нь 3.9 “function points” гэж үзнэ. Гаралтын процесс нь ямар нэгэн тооцоолол эсвэл логик үйлдэлтэй байдаг тул анхны “User Story” түвшинд хэмжих боломжгүй тохиолдол гарч ирж болдог гэдгийг санах хэрэгтэй. Энэ тохиолдолд туршлагатай ажилтны(expert) тусламжтай анхны таамаг гаргаж болох ба таамаглах боломжгүй тохиолдолд “4.6 function points” гэж үзэх нь тохиромжтой.
- Төслийн COST тооцоолох “Тоон арга”
Бид төслийн цар хүрээг тодорхойлж сурлаа. Одоо төслийн зардлыг тооцох асуудалд шилжиж байна. Төслийн зардал тооцоолох тоон арга-д суурилсан CoBRA болон COCOMO-II аргачлалуудыг товчхон авч үзье.
- “CoBRA”
Уг аргыг ашиглах үед туршлага ихтэй мэргэжилтэн шаардлагатай болно. Сонгогдсон мэргэжилтнүүдийн гаргаж ирсэн “CO Cost Overhead” гэх зардал ихэсгэх магадлалтай хүчин зүйлүүд дээр үндэслэдэг арга. Энэ алхмыг тодорхойлж дараах тэгшитгэлд орлуулснаар хүн-цаг тооцоолж, уг утга дээр үндэслэн зардал болон цаг хугацааг тодорхойлдог.
Effort=a × Size× 1+ COi
Тэгшитгэлийн Effort нь хүн-цаг, a нь коэффицент, Size нь ажлын цар хүрээ, COi нь зардлын параметрүүд юм.
“CO” -г албан газар өөрийн хэмжээнд тодорхойлдог. Жишээлбэл, “оролцогч талуудын хамтын ажиллагааны зэрэг” -г “CO” гэж тодорхойлбол, 4 шатлалд ангилж төслүүдийн хувьд тодорхойлж уг аргыг хэрэгжүүлдэг.
- “COCOMOII”
Уг арга нь дараах үндсэн тэгшитгэлийн дагуу ажиллана.
PM=A × SizeEEMi
E=B+0.01 ×SFi
Тайлбар:
PM = хүн-цаг
Size = ажлын цар хүрээ
EM = “Effort Multiplier” буюу хүн-цагт нэмэгдүүлэх боломжтой параметр
SF = “Scale Factor” буюу цар хүрээний параметр
A, B = коэффицент
A болон В коэффицентийн хувьд олон төслүүдийн дунджаас үндэслэж A = 2.94, B = 0.91 гэж тодорхойлсон байдаг ба тухайн байгууллага өөрийн төслүүдийн өгөгдөл дээр үндэслэн өөрсдөө тодорхойлон ашиглах боломжтой.
“Effort Multiplier”, “Scale Factor”-н утгуудыг төсөлтэй холбоотой шоблоом бөглөн тодорхойлж гаргаж авдаг. Жишээ болгон “TEAM Cohesion” буюу багийн нийлэмжтэй байдлыг илэрхийлдэг “Scale Factor” -н шоблоомыг дараах хүснэгтэд үзүүлэв.
Хүснэгт 3.1. TEAM -н үнэлгээний бүрэлдэхүүн хэсгүүд
| Very Low | Low | Nominal | High | Very High | Extra High | |
| Оролцогч талуудын зорилго ба соёлын нийцтэй байдал | ・ | ・ | ・ | ・ | ・ | ・ |
| Бусад stakeholders зорилгод нийцүүлэх stakeholder-н чадвар, хүсэл эрмэлзэл | ・ | ・ | ・ | ・ | ・ | ・ |
| Багаар ажиллах stakeholders-н туршлага | ・ | ・ | ・ | ・ | ・ | ・ |
| Алсын хараа, амлалтанд хүрэх team-building | ・ | ・ | ・ | ・ | ・ | ・ |
- Дүгнэлт
Эцэст нь дурдахад аливаа мэдээллийн технологийн төслүүдийн амжилттай болсон % тийм ч хангалттай бус. Дэлхий нийтээрээ төслүүдийг амжилттай байлгахын тулд төслийн цар хүрээг тодорхой болгох ажилбар дээр бүгд анхаарч байна. Төслийн цар хүрээг хэр хэмжээнд тодорхой болгох тусам төслийг удирдах бүрэн боломж бүрдэнэ. Төслийн цар хүрээг тодорхойлох гэдгийг бид юу юу хийгдэх гэдгээр ойлгодог нь дутуу дулимаг ойлголт юм. Төслийн цар хүрээг тодорхойлох гэдэг нь хэр хэмжээний жин дарсан ажилбарууд хийгдэхийг тодорхойлох явдал гэдгийг санах нь зүйтэй.
Орчин цагт бүх мэдээллийн технологийн төслүүд AGILE-р явагддаг болоод удаж байна. Тиймээс та бүхэндээ AGILE төслүүдийн цар хүрээг хэрхэн тодорхойлж түүнийгээ хэрхэн жинлэж, өртөг зардлыг хэрхэн тооцоолж гаргах талаар хэсэгхэн мэдлэг олгохыг зорив.
- Ашигласан үгнүүдийн тайлбар
Хүснэгт 3.1. TEAM -н үнэлгээний бүрэлдэхүүн хэсгүүд
| Ашиглагдсан үг | Тайлбар |
| Agile | Төслийн удирдлага, програм хангамж боловсруулахад чиглэсэн арга |
| User Story | Agile -н хүрээн дэх ажлын хамгийн жижиг нэгж |
| Function Point | Програм хангамжийн хөгжүүлэлтийн процессын эхэн үед зардлыг ойролцоогоор тооцоолоход тусалдаг арга |
| Elementary Process | Хэрэглэгчийн сонирхож болох хамгийн жижиг бизнес процесс |
| Typical Process | Тодорхойлсон хамгийн жижиг бизнес процессуудын нэгдэл |
| General Process | Тодорхой болоогүй хамгийн жижиг бизнес процессуудын нэгдэл |
| Macro Process | Төслийн ерөнхий процесс |
| External input (EI) | Програм хангамж руу оролт хийх процесс |
| External Output (EO)External Query (EQ) | Програм хангамжаас гаралт хийх процесс |
| CoBRA | Мэргэжилтний тодорхойлсон туршлага болон өгөгдөл дээр үндэслэн төслийг хэмжих тоон арга |
| COCOMOII | Өгөгдөл дээр үндэслэн төслийг хэмжих тоон арга |
| Cost Overhead | Зардлыг ихэсгэх боломжтой хүчин зүйлүүд |
| Effort Multiplier | Хүн-цагийг ихэсгэх боломжтой хүчин зүйлүүд |
| Scale Factor | Төслийн цар хүрээг ихэсгэх боломжтой хүчин зүйлүүд |
