Технологи ба стартап экосистемийн мэдээ мэдээллийг танд хүргэнэ.

Технологийн төслийн цар хүрээ, үр дүнг ЯАЖ хэмжих вэ?

itproject

Программ хангамжийн төслүүдийн амжилттай болох хувь бусад төрлийн төслүүдтэй харьцуулбал харьцангуй бага байдаг. Нийт төслүүдийн 30 орчим хувь нь амжилттай болж, 50 орчим хувь нь ямар нэгэн шинэ асуудлуудтай тулгарч, 20 орчим хувь нь амжилтгүй болдог гэсэн судалгаа байдаг. 

Программ хангамжийн төслүүдийн амжилтгүй болох нэг шалтгаан бол төслийн цар хүрээг буруу тооцоолсон, тодорхойлсон байдал юм. 

  1. Яагаад төслийг хэмжих шаардлагатай вэ?

Программ хангамжийн төслүүд нь өөрийн болон бусдын хэрэгцээ, шаардлагад зориулж бүтээгддэг. Хөгжүүлэлтийг эхлүүлэхээс өмнө кейсүүдийг судалж, тодорхойлж, уг кейсүүдээс бүтээгдэх боломжтой шийдлүүдийг ангилж, нэгтгэж үр дүнд хүрэх нь хамгаас чухал. Бидний амьдарч буй орчин, нийгэм, бизнес өдрөөс өдөрт өөрчлөгдөж, хувьсаж байдаг тул бид бизнесийн хэрэгцээг хангахуйц “Амьд систем” хөгжүүлэх нэн шаардлагатай тулгардаг.

“Мэдээлэл-Технологийг дэмжих агентлаг, Японы программ хангамжийн инженерийн төв” -н гаргасан судалгаагаар нийт программ хангамжийн төслийн 31.1% нь амжилттай болдог. Энэ үзүүлэлт дээр илүү нарийн шинжилгээ хийж үзвэл ямар нэгэн тоон хяналтын арга ашиглаж удирдсан төслүүдийн 45.6%, ашиглаагүй төслүүдийн 24.3% нь амжилттай болсон байна. 

Прогамм хангамжийн төслийг амжилттай эсэхийг 

  • “Cost буюу Зардал”
  • “Deadline буюу Хугацаа”
  • “Quality буюу Чанар”
  • “Scope буюу Хамрах хүрээ” зэргээр хэмждэг. 

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

Төслийн цар хүрээг хэмжих хамгийн үр дүнтэй арга бол “AGILE” аргачлалын “Function Point” юм. 

Өнөөдрийг хүртэл “AGILE” -р ажиллаж буй тохиолдолд төслийг хэмжих хамгийн үр дүнтэй арга нь “Function Point”, зардал болон хугацааг тооцох үед туршлага болон өгөгдөл дээр үндэслэсэн тоон арга нь “CoBRA”, зөвхөн өмнө байгаа өгөгдөл дээр тулгуурласан арга нь “COCOMOII” гэж үзэж байна.

  1. Төслийг хэмжих нь. (Function Point)

Аливаа AGILE төслийг эхний гаргасан “User Story” дээр үндэслэн хэмжих нь цор ганц арга юм. Учир нь user story нь хамгийн анхны болхи хэмжилт хийх боломжтой түлхүүр үгнүүдийг агуулдагт оршино. Уг түлхүүр үгнүүдийг жагсаалтыг Хүснэгт 1.1 -д дурдав.

Хүснэгт 1.1. Түлхүүр үг (user story) болон түүнд харгалзах хэмжээ

KeywordFunction PointKeywordFunction point
Access20 fpsMaster15 fps
Activity20 fpsMessage10 fps
Add4 fpsModify6 fps
Address15 fpsName4 fps
Adjust5 fpsNew25 fps
Assign15 fpsNumber10 fps
Audit7 fpsPayment25 fps
Browse4 fpsPricing40 fps
Change6 fpsQuery4 fps
Charges10 fpsRate15 fps
Code10 fpsRecord6 fps
Contact15 fpsRecurring15 fps
Contract25 fpsRemove3 fps
Create6 fpsReport5 fps
Delete4 fpsRequest6 fps
Detail7 fpsResponse6 fps
Discount35 fpsRevenue7 fps
Display6 fpsSearch6 fps
Edit15 fpsSend6 fps
Error10 fpsState10 fps
Event5 fpsStatus5 fps
Feature25 fpsStrategy10 fps
File7 fpsSub25 fps
Get5 fpsSum5 fps
Group15 fpsSummary7 fps
History5 fpsTax 20 fps
Information15 fpsTransfer4 fps
Inventory20 fpsType15 fps
Level25 fpsUpdate6 fps
Link6 fpsUsage20 fps
Map65 fpsView4 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” -д оруулан задалдаг. 

  1. “Typical Process”

Энэ процесс нь хэд хэдэн “Elementary Process” -уудын бүлэг нийлбэр гэж хэлж болно. (жишээ процессыг Хүснэгт 2.1 -д дурдав) 

Жишээлбэл “Үйлчилгээний ажилтан нь хэрэглэгчийн хувийн мэдээллийг удирдах боломжтой байна” гэдэг анхны “User Story” байна гэж үзвэл уг тохиолдолд үйлчилгээний ажилтан нь хэрэглэгчийн хувийн мэдээллийг устгах боломжтой эсэх, ямар нэгэн тайлан гаргах боломжтой эсэх нь тодорхойгүй байгаа ба энэ тодорхойгүй байдал нь гүйцэтгэлийн үйл явцад тодорхой болдог. Иймд Хүснэгт 2.1 -д дурдсан дунд хэмжээний “Typical Process” гэж урьдчилсан байдлаар тодорхойлж “21.1 function point” гэж тооцоолох нь тохиромжтой.


Хүснэгт 2.1. Typical Process дах хэмжээ

ХэмжээТайлбарFunction Points
ЖижигCRUD16.5
ДундCRUD + Жагсаалт (EQ)21.1
ТомCRUD + Жагсаалт + Тайлан (EO)26.3
  1. “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
  1. “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” гэж үзэх нь тохиромжтой.
  1. Төслийн 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 LowLowNominalHighVery HighExtra High
Оролцогч талуудын зорилго ба соёлын нийцтэй байдал
Бусад stakeholders зорилгод нийцүүлэх stakeholder-н чадвар, хүсэл эрмэлзэл
Багаар ажиллах stakeholders-н туршлага
Алсын хараа, амлалтанд хүрэх team-building
  1. Дүгнэлт 

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

Орчин цагт бүх мэдээллийн технологийн төслүүд AGILE-р явагддаг болоод удаж байна. Тиймээс та бүхэндээ AGILE төслүүдийн цар хүрээг хэрхэн тодорхойлж түүнийгээ хэрхэн жинлэж, өртөг зардлыг хэрхэн тооцоолж гаргах талаар хэсэгхэн мэдлэг олгохыг зорив.

  1. Ашигласан үгнүүдийн тайлбар

Хүснэгт 3.1. TEAM -н үнэлгээний бүрэлдэхүүн хэсгүүд

Ашиглагдсан үгТайлбар
AgileТөслийн удирдлага, програм хангамж боловсруулахад чиглэсэн арга
User StoryAgile -н хүрээн дэх ажлын хамгийн жижиг нэгж
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Төслийн цар хүрээг ихэсгэх боломжтой хүчин зүйлүүд
Total
6
Shares

Leave a Reply

Related Posts
Total
6
Share