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

BlackcatKaizer

  • Administrator
  • Hero Member
  • *****
  • Posts: 3,661
  • Karma: +1/-0
  • =- -=
    • MSN Messenger - blackcatkaizer@hotmail.com
    • View Profile
    • BoardDev
    • Email
ในการประเมินโครงการเพื่อที่จะนำไปวางแผนงานในการพัฒนาโปรแกรมนั้นเป็นสิ่งที่ไม่ใช้เรื่องง่ายสำหรับ 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

ถ้าในโครงการเรานับจำนวน 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 นั้นมีเส้นทางการทำงานเป็นอย่างไร  เราจะใช้จำนวนของเส้นทางการทำงานของ Use Case ทั้งที่เป็น เส้นทางปกติ (Happy Path or Common Path) และเส้นทางที่เป็นทางเลือก (Alternate pathways) เพื่อใช้ในการประเมิน รวมทั้งที่เป็นเส้นทางที่เมื่อมีข้อผิดพลาดด้วย (Exception Path) โปรดอย่างลืมว่าในบางครั้งโปรแกรมบางโปรแกรมก็ให้ความสำคัญกับ ข้อผิดพลาด มากกว่า เส้นทางที่ทำงานปกติ ก็มีได้ด้วยเหมือนกัน ดังนั้นเราจะสรุปง่ายๆ ว่าเราจะทำเอาทุกๆ เส้นทางการทำงานของ Use Cases มาพิจารณาหาน้ำหนักให้กับ Use 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 หรือ “ค่าปัจจัยทางด้านเทคนิค” ในการให้คะแนนของแต่ละปัจจัยทางเทคนิคควรจะปิดซ่องของค่าน้ำหนักเสียก่อน เพื่อจะทำให้การให้คะแนนมีอคติน้อยที่สุด




ข้อมูลอื่นๆ
Coming soon



ข้อมูลจาก: Xpdian, The Code Project
« Last Edit: February 09, 2010, 05:54:25 PM by BlackcatKaizer »
-------------งานเข้า--------------