-- WisitWongwilai - 18 Apr 2008

วิธีการประเมินโครงการโดยใช้ Use Case (The Project Estimate)

ในการประเมินโครงการเพื่อที่จะนำไปวางแผนงานในการพัฒนาโปรแกรมนั้นเป็นสิ่งที่ไม่ใช้เรื่องง่ายสำหรับ Project manager ที่จะสามารถประเมินระยะเวลาในการพัฒนาของโปรแกรมเมอร์ (Person-hours) และการกำหนดเวลาที่โครงการเสร็จและสามารถส่งมอบให้ลูกค้าได้ถูกต้องหรือใกล้เคียง *ซึ่งโดยส่วนใหญ่ก็ต้องเป็นผู้มีประสบการณ์และคุ้นเคยกับการพัฒนามาเป็นผู้ประเมินและวางแผนงานในการพัฒนาระบบนั้น ซึ่งอาจจะมีความไม่แน่นอนได้เนื่องการบุคคลแต่ละท่านมีความชำนาญไม่เท่ากันหรืออาจจะมีอคติ ทั้งทางดี หรือไม่ดีก็ได้เกิดขึ้น จะเห็นได้ว่าในการวางแผนงานนั้นปัจจัยส่วนใหญ่ขึ้นอยู่กับบุคคลมากเกินไป ดังนั้นนักคิดทั้งหลายก็มีความพยายามสร้างกฎเกณฑ์ วิธีคิด ต่างๆ *เพื่อที่จะนำมาประยุคใช้เพื่อที่จะให้ผลของการประเมินโครงการนั้นออกมาให้ใกล้เคียงกับความเป็นจริงมากที่สุด

ในปี ค.ศ. 1995 บริษัท Rational Software ได้ซื้องานวิจัยที่มีคุณค่าของ Gustav Karner และได้มีการปรับปรุงและเพิ่มทฤฎีบางส่วนโดย Ivar Jacobson และได้ตั้งชื่อว่า Objectory AB ขึ้นซึ่งในส่วนหนึ่งของ Objectory AB นั้นได้กล่าวถึงวิธีการประเมินเวลาการทำงานของบุคคลากร (Person-hours) ในโครงการโดยใช้พื้นฐานของ Use Case ถึงแม้ว่าการประเมินที่ใช้พื้นฐาน Use Case จะมีการถูกนำมาใช้ก่อนหน้า โดยวิธีการที่เรียกว่าการวิเคราะห์แบบ Function point ก็ตามแต่ Objectory ก็มีความแตกต่างจาก Function point ที่ Objectory จะใช้ข้อมูลต่างๆ (Artifacts) ที่ได้มาจาก Use Case โดยตรง

สิ่งที่ใช้ในการคำนวณเพื่อประเมินโครงการ

กระบวนการของ Objectory นั้นจะมี Input อยู่ 4 อย่างด้วยกันดังนี้

1. น้ำหนักของ Actors
2. น้ำหนักของ Use-Case
3. น้ำหนักของ ปัจจัยทางด้านเทคนิค (Technical factors)
4. น้ำหนักของ ผู้มีส่วนร่วมของโครงการ (Project participants)

การคิดน้ำหนักของ Actors (Weighting Actors)

ในการให้น้ำหนักของ Actors นั้นจะจัดประเภทของ Actors ออกเป็น 3 ประเภทด้วยกันคือ

• ง่าย (Simple)
• ปานกลาง (Average) และ
• มีความยับซ้อน (Complex)

Simple Actors: actors ที่ถูกจัดอยู่ในประเภท Simple Actors นั้นคือ actor ที่เป็น “ระบบภายนอก” (External System) actors ประเภทนี้จะสามารถหาได้ไม่ยากนั้นและมักถูกกำหนดประเภทได้ถูกต้อง ซึ่ง Actors ประเภทนี้จะเป็นผู้ร้องขอ Output ของระบบ หรือเป็นแหล่ง Input ให้กับ Interface ของระบบ หรือทั้งสองอย่าง

Average Actors: actors ที่ถูกจัดอยู่ประเภท Average Actors นั้นคือ actor ที่เป็น “Hardware device” หรือ “Timer” actors ประเภทนี้ก็เป็น actors ที่สามารถหาได้ไม่ยาก ในการวิเคราะห์ แต่ actors ประเภทนี้จะต้องมีการควบคุม (Control) และตรวจสอบข้อผิดพลาด (error) มากกว่า Simple Actors

Complex actors: actors ที่ถูกจัดอยู่ประเภท Complex actors นั้นคือ actor ที่เป็น “บุคคล” เนื่องจาก actors ที่เป็นบุคคล ควบคุมได้ยากและไม่สามารถคาดหมายได้ ถึงแม้ว่าเราจะสามารถควบคุมผู้ใช้งานได้ผ่านทาง User Interface แต่ก็เป็นไปได้ยากที่จะทราบว่าผู้ใช้งานจะทำงานระบบแบบใด (“บุคคล” มีความสามารถเลือกที่จะทำอะไรได้ตามใจชอบ โดยที่ผู้พัฒนาโปรแกรมไม่สามารถคาดเดาได้)

Factors น้ำหนักของ Actors

ประเภทของ Actor	คำอธิบาย	น้ำหนัก
แบบง่าย (Simple)	ระบบภายนอก	1
แบบปานกลาง (Average)	อุปกรณ์ Hardware หรือ Timer	2
แบบซับซ้อน (Complex)	บุคคล	3

จากตารางเราสามารถนำ Factors มาคำนวณหาเพื่อประมาณงาน โดยจากตัวอย่างของ เราจะคำนวณได้ดังนี้

ตัวอย่าง เ่ช่นถ้าในโครงการเรานักจำนวน Actor ที่เป็นแบบง่ายได้ 1 actor แบบปานกลางได้ 1 actor และมีแบบซับซ้อน 4 actors

จำนวน actor x น้ำหนัก	ผลที่ได้
1 x 1	1
1 x 2	2
4 x 3	12
น้ำหนักของ Actors	15

การคิดน้ำหนักของ Use Cases (Weighting Use Cases)

ในการคิดหาน้ำหนักของ Use Cases นั้นเราจะคำนึงถึงว่า Use Case นั้นมีเส้นทางการทำงานเป็นอย่างไร (Pathways: ตัวอย่างของ Use Case Pathway ดูได้จากหัวข้อการเขียน Use Case) เราจะใช้จำนวนของเส้นทางการทำงานของ Use Case ทั้งที่เป็น เส้นทางปกติ (Happy Path or Common Path) และเส้นทางที่เป็นทางเลือก (Alternate pathways) เพื่อใช้ในการประเมิน รวมทั้งที่เป็นเส้นทางที่เมื่อมีข้อผิดพลาดด้วย (Exception Path) โปรดอย่างลืมว่าในบางครั้งโปรมแกรมบางโปรแกรมก็ให้ความสำคัญกับ ข้อผิดพลาด มากกว่า เส้นทางที่ทำงานปกติ ก็มีได้ด้วยเหมือนกัน ดังนั้นเราจะสรุปง่ายๆ ว่าเราจะทำเอาทุกๆ เส้นทางการทำงานของ Use Cases มาพิจารณาหาน้ำหนักให้กับ Uses Case

และอีกส่วนหนึ่งที่จะพิจารณาคือชนิดของ Use Case ที่เราจะนำมาหาน้ำหนักนั้นเราจะนำ Use Cases ทั้งหมดมาพิจารณา ถึงแม้ว่า Karner จะกำหนดให้ Use Case ที่เป็นแบบ includes , extends , และ generalize เป็นส่วนที่ถูกเพิ่มเข้ามาและไม่ได้ถูกคำนึงถึงในการหาน้ำหนัก แต่ในทางปฏิบัติแล้ว Use Case ดังกล่าวจะต้องถูกนำไปพัฒนาและเป็นส่วนที่นักพัฒนาจะต้องลงแรงไป

ในโปรแกรมที่มีความซับซ้อนเราอาจจะเขียน Use Case ที่เป็น extends เพื่อบอกถึง เส้นทางที่เป็นทางเลือก (Alternate pathway) เพื่อให้ง่ายต่อการวิเคราะห์ และ Use Cases ที่เป็น include จะเป็น Use Case ที่ถูกซ้อนการทำงานเอาไว้ใน Use-Case อื่น และเราต้องการแสดงการทำงานนั้นออกมาให้ชัดแจน (โดยส่วนใหญ่จะเขียน include Use Cases ที่มีการซ้อนอยู่ของการทำงาน ของหลากๆ Use Case: Repeated) ถึงอย่างไรก็ตามในการพิจารณาในการให้น้ำหนักของแต่ Use Case ก็อาจจะได้ใช้ประสบการณ์เข้าไปในการพิจารณาด้วยเหมือนกัน เนื่องจากในบางครั้งนักวิเคราะห์อาจจะเขียน Use Case ออกมาในลักษณะที่หยาบ หรือละเอียดไม่เท่ากัน ทั้งจำนวนของ Use Case และ Pathways ซึ่งอาจจะทำให้การประมาณเกิดความคาดเคลื่อนไม่เท่ากัน**

** โดยปกติถ้านักวิเคราะห์เขียน Use-Cases จำนวนน้อย และส่งผลให้จำนวน Pathway มีมาก (Complex) และในทางกับกันถ้ามีการเขียน Use Case มากจำนวน Pathway ควรจะมีไม่มากนัก (Average หรือ Simple) แต่ถ้าหากในการหาน้ำหนักของ Use Cases พบว่ามี จำนวน Pathway ไม่สมเหตุสมผลกับ Use Case อาจจะต้องมีการทบทวนการวิเคราะห์ Use Cases อีกครั้ง

Factors น้ำหนักของ Use Cases

ประเภทของ Use Case	คำอธิบาย	น้ำหนัก
แบบง่าย (Simple)	3 เส้นทาง หรือ น้อยกว่า	5
แบบปานกลาง (Average)	4 ถึง 7 เส้นทาง	10
แบบซับซ้อน (Complex)	มากกว่า 7 เส้นทาง	15

ตัวอย่าง เ่ช่นถ้าในโครงการเรานักจำนวน Use Case ที่เป็นแบบง่ายได้ 1 use case แบบปานกลางได้ 1 use case และมีแบบซับซ้อน 4 use cases

จำนวน usecases x น้ำหนัก	ผลที่ได้
1 x 5	5
1 x 10	10
4 x 15	60
น้ำหนักของ Use Case	75

Unadjusted Use-Case Point (UUCP)

ถึงตอนนี้เราจะนำค่าน้ำหนักจาก Actors และน้ำหนักจาก Use Case มารวมกัน ซึ่งเราจะเรียกค่านี้ว่า Unadjusted Use Case Point (UUCP) ซึ่งค่านี้จะถูกน้ำไปให้ค่าใหม่โดยใช้วิธีการทางเทคนิค และการประเมินของผู้มีส่วนเกี่ยวข้องของโครงการอีกครั้ง

UUCP ของโครงการจะมีค่าเท่ากับ

น้ำหนักของ Actors + น้ำหนักของ Use-Case
15 + 75 = 90 UUCP

การคิดน้ำหนักทางปัจจัยด้านเทคนิค (Technical Factors)

ในขั้นตอนนี่เราจะมาคิดน้ำหนังในอันดับที่ 3 คือน้ำหนังทางปัจจัยทางด้านเทคนิคของโครงการ โดยเรากรอกข้อมูลใน ตารางการคิด Techinical Factors โดยเราจะกำหนดช่วงในการให้คะแนนตั้งแต่ 0 (ไม่ตรงกับหัวข้อที่กำหนดไว้) ถึง 5 (มีความสำคัญตรงกับหัวข้อ)** เมื่อเราให้คะแนนทางเทคนิคในโครงการ แล้วให้นำไปคุณกับค่าน้ำหนักของแต่ละหัวข้อ (Weight) ซึ่งผลลัพธ์ที่ได้เราจะเรียนว่าค่า Extended Weight (EW = Weight X Rate) ค่ารวมทั้งหมดของ Extended Weight ของปัจจัยด้านเทคนิคเราเรียกค่านี้ว่า T Factor หรือ “ค่าปัจจัยทางด้านเทคนิค” ** ในการให้คะแนนของแต่ละปัจจัยทางเทคนิคควรจะปิดซ่องของค่าน้ำหนักเสียก่อน เพื่อจะทำให้การให้คะแนนมีอคติน้อยที่สุด

ตัวอย่าง ตารางค่าปัจจัยทางน้ำหนักสำหรับการคำนวณปัจจัยทางเทคนิค (T Factor)

ปัจจัยทางเทคนิค (Technical Factor)	น้ำหนัก (Weight)	คะแนน (Rating)	Extended Weight (W x R)	เหตุผล
1. เป็นระบบแบบกระจาย	2	5	10	...
2. จุดประสงค์ของระบบคำนึงถึง ประสิทธิภาพใน การตอบสนอง หรือ การประมวลผล	1	4	4	...
3 ระบบสามารถตอบสนองกับผู้ใช้งานได้ดี	1	2	2	...
4 มีขบวนการที่ซับซ้อนภายในระบบ	1	4	4	...
5 ความสามารถในการนำ Codeไปใช้ได้อีกในโครงการอื่น	1	2	2	...
6 ง่ายต่อการติดตั้ง	0.5	5	2.5	...
7 ง่ายต่อการใช้งาน	0.5	4	2	...
8 Portability	2	3	6	...
9 ง่ายต่อการเปลี่ยนแปลง เพิ่มเติม	1	5	5	...
10 ความสามารถในการทำงานพร้อมๆ กัน (Concurrency)	1	4	4	...
11 มีระบบความปลอดภัยพิเศษ	1	3	3	...
12 Third parties สามารถติดต่อกับระบบได้	1	5	5	...
13 มีการอบรมพิเศษให้ผู้ใช้งาน	1	3	3	...
T Factor			52.5	...

เมื่อเราได้ค่า T Factor แล้วจะนำมาคำนวณลงไปในสูตรและเรียกค่านี้ที่คำนวณได้ว่าเป็น “ค่าปัจจัยความซับซ้อนทางด้านเทคนิค” (Technical Complexity Factor: TCF)

TCF = 0.6 + (0.01 x T Factor)

ดังนั้นโครงการตัวอย่างเมื่อเราคำนวณจะได้ค่า TCF ดังนี้

TCF = 0.6 + (0.01 x 52.5) = 1.125

การคิดน้ำหนักของผู้มีส่วนร่วมของโครงการ (Project participants)

ค่าปัจจัยสุดท้ายที่จะใช้ในการประเมินโครงการ เราจะคำนึงถึงระดับความสามารถและประสบการณ์ของทีมงาน ซึ่งค่าที่จะได้จากการคำนวณนี้เราจะเรียกว่า “ค่าปัจจัยความซับซ้อนทางสภาวะแวดล้อม” (Environmental Complexity Factor: ECF) ในการคำนวณค่า ECF นั้นเราจะให้คะแนนลงในตาราง ก-4 ตั้งแต่ 0 ถึง 5 ในแต่ละหัวข้อโดยมีข้อพิจารณาในการให้คะแนนดังนี้

ในหัวข้อที่ 1 ถึง 4	0 หมายถึงไม่มีความชำนาญในหัวข้อนั้น
	3 หมายถึง มีความชำนาญปานกลาง
	5 หมายถึง มีความชำนาญในหัวข้อนั้นมาก
ในหัวข้อที่ 5	0 หมายถึง ไม่มีความกระตือรือร้นในงาน
	3 หมายถึง ปกติ
	4 หมายถึง มีความกระตือรือร้นมาก
ในหัวข้อที่ 6	0 หมายถึง ความต้องการไม่ชัดแจนหรือสามารถเปลี่ยนแปลงได้ง่าย
	3 หมายถึง ปกติทั่วไป
	5 หมายถึง ไม่สามารถเปลี่ยนแปลงได้
ในหัวข้อที่ 7	0 หมายถึง ไม่มีผู้ร่วมงานทางเทคนิคที่เป็น Part-time
	3 หมายถึง ปกติทั่วไป
	5 หมายถึง ทีมทางด้านเทคนิคเป็น Part-time ทั้งหมด
ในหัวข้อที่ 8	0 หมายถึง ภาษาง่ายต่อการพัฒนา
	3 หมายถึง ปานกลาง
	5 หมายถึง ภาษายากต่อการพัฒนา

ตัวอย่าง ตารางค่าปัจจัยทางน้ำหนัก สำหรับผู้มีส่วนร่วมโครงการ

ค่าปัจจัยความซับซ้อนทางสภาวะแวดล้อม (Environmental Complexity Factor)	*น้ำหนัก (Weight)	คะแนน (Rating)	Extended Weight (W x R)	เหตุผล
1. ใช้วิธี ขบวนการในการพัฒนาแบบปกติ	1.5	4	6	...
2. มีความเข้าใจในการทำงานของระบบ	0.5	3	1.5	...
3. มีความเข้าใจทางด้าน Object-Oriented	1	4	4	...
4. มีความสามารถในการวิเคราะห์ระบบ	0.5	4	2	...
5. มีความกระตือรือร้นในการทำงาน	1	3	3	...
6. มีความเสถียรภาพของความต้องการ	2	4	8	...
7. จำนวนพนักงาน Part-time	-1	0	0	...
8. ภาษาที่ใช้มีความยากในการพัฒนา	-1	3	-3	...
E Factor			21.5	...

ค่าของ EW ของสภาวะแวดล้อมทั้งหมดนำมารวมกันเราจะเรียกค่านี้ว่า E Factor หรือ “ค่าปัจจัยทางด้านสภาวะแวดล้อม” จะถูกนำมาใส่สูตรหาค่า ECF ดังนี้

ECF = 1.4 + (-0.03 x E Factor)

ดังนั้นในโครงการตัวอย่างเราจะคำนวณค่า ECF ได้ดังนี้

ECF = 1.4 + (-0.03 x 21.5) = 0.755

การคำนวณ Use Case Points

ในตอนนี้เราจะมีค่า 3 ค่า คือ

1. UUCP : Unadjusted Use Case Point
2. TCF : Technical Complexity Factor
3. ECF : Environmental Complexity Factor

เราจะนำค่าทั้งสามมาหาค่า Use Case Points (UCP) โดยใช้สูตรดังนี้

UCP = UUCP x TCF x ECF

ดังนั้นโครงการตัวอย่างเราจะคำนวณค่า UCP ได้ดังนี้

UCP = 90 x 1.125 x 0.755 = 76.44

การประเมินโครงการ (The Project Estimate)

ในการวิจัยของ Karner จะให้ค่า 20 person-hours ต่อ 1 UCP ดังนั้นในโครงการตัวอย่างนี้เราจะได้ 1529 person-hours (20 x 76.44) ถ้าทางบริษัทให้เวลาในการทำงานของพนักงาน 1 สัปดาห์เท่ากับ 32 ชั่วโมง (32-hour-per-week) เราจะประมาณจำนวนสัปดาห์ที่จะต้องให้กับโครงการนี้ทั้งหมดเท่ากับ 47.78 สัปดาห์ ถ้าในโครงการนี้เรามีทีมงานทั้งหมด 5 คน ดังนั้นการประมาณเวลาที่คาดว่าจะเสร็จจะเป็น 9.55 สัปดาห์ แต่อย่างไรก็ดีเราจะต้องคำนึงถึงเวลาที่จะต้องใช้ไปกับขบวนการที่ไม่ใช้เวลาในการพัฒนาระบบด้วยเช่นกัน เช่น เวลาในการติดต่อสื่อสาร การประชุม และอื่นๆ (ซึ่งในความเป็นจริงเราจะสังเกตได้ว่าในวันหนึ่งๆ เราทำอะไรมากมายที่ไม่ได้อยู่ในกำหนดการ หรือถูกวางแผนไว้) ดังนั้นเราจะเพิ่มเวลาไปอีก 4 สัปดาห์เข้าไปในแผนงานการทำงาน (Margin**) ** ในการกำหนด Margin จะขึ้นอยู่กับการประมาณของแต่ละองค์กร ซึ่งในครั้งแรกเราจะกำหนดไว้ประมาณ 4 สัปดาห์ และจะมีการปรับเปลี่ยนค่านี้ต่อไปในโครงการหน้าจนได้ค่าที่ใกล้เคียงกับความเป็นจริงมากที่สุด

เวลาในที่ประเมินได้ประมาณ 13.55 สัปดาห์ ~ 14 สัปดาห์ ( 3 เดือน 2 สัปดาห์ )

ถึงแม้ว่าวิธีการประมาณค่างานของโครงการของ Karner จะไม่ได้เป็นค่าที่ถูกต้องร้อยเปอร์เซ็นต์ แต่เราจะได้ค่าในการประมาณที่ดีในระดับหนึ่งในการว่างแผนในการพัฒนาโปรแกรม มีข้อแนะนำเพื่อเติมในการคำนวณหาระยะเวลาในหนังสือ Applying Use Case: A Practical Guide ของ Geri Schneider และ Jason Winter ได้แนะนำให้เราเพิ่มความสนใจใน “ค่าปัจจัยทางสภาวะแวดล้อม” (ECF) โดยให้เรานับจำนวนคะแนน (Rating) ที่ให้ในแต่ละหัวข้อดังนี้

• นับจำนวนคะแนนในหัวข้อที่ 1 – 6 ว่าที่มีคะแนนต่ำกว่า 3 จำนวนกี่ข้อ
• นับจำนวนคะแนนในหัวข้อที่ 7 – 8 ว่าที่มีคะแนนมากกว่า 3 จำนวนกี่ข้อ
• นำจำนวนที่นับได้มารวมกัน

จำนวนที่นับได้ 0 – 2 : ให้ใช้ค่า 20 person-hours ต่อ 1 UCP
จำนวนที่นับได้ 3 – 4 : ให้ใช้ค่า 28 person-hours ต่อ 1 UCP
จำนวนที่นับได้เท่ากับ 5 หรือมากกว่า :แสดงว่าในโครงการนี้จำเป็นต้องเพิ่มอะไรบ้างอย่างเข้าไป เพราะมีความเสี่ยงอย่างมากที่จะไม่ประสบความสำเร็จ

เช่น ถ้าเรานับได้ 3 แปลว่าโครงการนี้มีความเสีียงสูงอาจจะต้องให้เวลามากกว่าปกติดังนั้นจะคำนวณเวลาในการพัฒนาระบบใหม่ได้ดังนี้

28 x 76.44 = 2140.32 person-hours ~ 4 เดือน 1 สัปดาห์

สรุปการประเมินโครงการด้วย Use Case Point

การประเมินโครงการก่อนการที่จะดำเนินการเป็นวิธีที่จะทำให้เราทราบสถานะของเรา และสามารถวางแผนป้องกันความเสียหายก่อนที่จะเกิดขึ้น
และการประเมินโดยใช้ Use Case Point ก็เป็นวิธีหนึ่งที่สามารถนำไปใช้ได้ในขณะที่ยังไม่มีความชัดเจนของโครงการมากนักเพราะเนื่องจาก
มีการใช้ Use Case Diagram เป็นเอกสารหลักในการประเมินเพียงอย่างเดียว อย่างไรก็ตามวิธีการประเมินแบบ Use Case Point อาจมีความเบี่ยงแบนได้จากประสบการณ์ของผู้ประเมิน
และปัญจัยอื่นๆ ที่เข้ามาเกี่ยวข้องกับโครงการด้วย

การประิเมินโครงการด้วยวิธีอื่นเช่น Function Point เป็นอีกทางเลือกหนึ่งที่ได้รับความนิยม ซึ่งมีการประเมินโครงการจากปัจจัยต่างๆ มากกว่า Use Case Point และมีวิธีการ
Feedback เพื่อให้การประเมินในครั้งต่อๆ ไปมีความเม้นยำมากขึ้น แต่อย่างไรก็ตามผู้ประเมินโครงการจำเป็นต้องทราบรายละเอียดของโครงการที่จะพัฒนาจนถึงการออกแบบโปรแกรมในเบื้องต้นแล้ว
ซึ่งในทางปฏิบัติจะทำได้ยากมากในกรณีที่มีเวลาจำกัด