290342 Software Development Process

1. 290342 Software Development Process บทที่ 3การบริหารจัดการโครงการผลิตซอฟต์แวร์ อ.ธารารัตน์ พวงสุวรรณ คณะวิทยาศาสตร์และศิลปศาสตร์ มหาวิทยาลัยบูรพา วิทยาเขตสารสนเทศจันทบุรี

3. Project Life Cycle ประกอบไปด้วย 5 เฟส SDLC 3 2 4 1 5

4. Systems Development Life Cycle (SDLC) เวลาเราจะพัฒนาระบบ (โปรแกรม) อะไรสักอย่างหนึ่ง จะประกอบไปด้วย 5 เฟส เช่นกัน

5. The Relationship Between the PLC & SDLC

6. Software Project • ในโครงการผลิตซอฟต์แวร์ หรืองานด้านวิศวกรรมซอฟต์แวร์ สิ่งที่ต้องคำนึงถึง คือ • งบประมาณที่ใช้ในการบริหารจัดการโครงการ • บุคลากรที่เกี่ยวข้อง • ระยะเวลา • เครื่องมืออุปกรณ์ • ค่าใช้จ่ายอื่น ๆ

7. การบริหารโครงการผลิตซอฟต์แวร์การบริหารโครงการผลิตซอฟต์แวร์ • การบริหารโครงการ (Project management) • การประยุกต์ใช้องค์ความรู้ ทักษะ เครื่องมือ และเทคนิค เพื่อดำเนินกิจกรรมตามความต้องการของโครงการให้บรรลุวัตถุประสงค์ที่กำหนดไว้

8. Software Project Management • จะเริ่มต้นจากการวางแผนโครงการ (Project Planning) • Project Planning จะเกี่ยวข้องกับการประมาณการ (Estimation) • Resources • Cost • Schedule • Project Planning จะเริ่มจากการกำหนด Software scope • Estimation of resources, cost and schedule required experience, access to good historical information and the courage to commit to quantitative predictions. • Estimation carries inherent risk

9. Project Resources • Human Resources • Reusable Software Resources • Environmental Resources

10. Human Resources • กำหนดหน้าที่ความรับผิดชอบตามความชำนาญเช่น • Manager • Senior Software Engineer • ถ้าเป็นโครงการขนาดเล็ก คนเดียวอาจทำหลาย ๆ งานและมีผู้เชี่ยวชาญในการให้คำปรึกษา • จำนวนคนที่ต้องใช้จะถูกกำหนดหลังจากการประมาณ Effort(person-months)

11. Reusable Software Resources • Component-based software engineering จะเน้นการนำ component กลับมาใช้ใหม่ (Reusability) • Off-the-shelf components • Full-experience components • Partial-experience components • New components

12. Environmental Resources • The environment that support the software project • called Software engineering environment (SEE) • ประกอบด้วย Hardware and software tools

13. การบริหารโครงการผลิตซอฟต์แวร์การบริหารโครงการผลิตซอฟต์แวร์ • การจัดตารางงานโครงการ • Gantt Chart • PERT/CPM

14. GanttChart • GanttChart ผังแสดงกำหนดระยะเวลาของกิจกรรมต่างๆ • แสดงในรูปของแท่งกราฟ • แนวนอนแสดงระยะเวลา • แนวตั้ง แสดงชนิดของกิจกรรม

15. หลักในการเขียน GANTT’s CHART • กำหนดงานและกิจกรรม • กำหนดระยะเวลาการทำงานให้แล้วเสร็จ • พิจารณาว่างานใดควรทำก่อน หรือ หลัง

16. Gantt Chart

17. Gantt Chart

18. PERT/CPM • เป็นเทคนิคที่ใช้ในการวางแผนและควบคุมโครงการ • มีลักษณะเป็นข่ายงาน (Network) ที่แสดงความสัมพันธ์ของกิจกรรมต่าง ๆ ของโครงการ • เทคนิคทั้งสองถูกพัฒนาจาก Bar Chart และ Gantt Chart โดยมีหลักในการสร้างข่ายงานแบบเดียวกัน • ผู้ริเริ่มคือ Henry Gantt

19. การวิเคราะห์ข่ายงาน PERT/CPM การวิเคราะห์ข่ายงาน PERT/CPM มีวัตถุประสงค์เพื่อหาวิถีวิกฤตของโครงการ ขั้นตอนการวิเคราะห์ข่ายงานประกอบด้วย • การแยกแยะงาน (job breakdown)เป็นขั้นตอนการแจกแจงของกิจกรรมต่างๆ ที่จำเป็นต้องทำในโครงการทั้งหมดว่า มีกิจกรรมอะไรบ้างที่ต้องทำ กิจกรรมต่างๆ มีความสัมพันธ์กันอย่างไร กิจกรรมใดต้องทำก่อน กิจกรรมใดต้องทำหลัง • การประมาณการเวลาของกิจกรรม (activity time estimation)เป็นการประมาณการเวลาที่ต้องใช้ทำแต่ละกิจกรรมโดยอาศัยผู้ชำนาญงานในแต่ละกิจกรรม

20. การวิเคราะห์ข่ายงาน PERT/CPM • สำหรับข่ายงาน CPM การประมาณการจะทำโดยประมาณการเพียงค่าเดียว โดยถือว่าค่านี้มีความเป็นไปได้มากที่สุด มีโอกาสน้อยมากที่จะเกิดความคลาดเคลื่อนซึ่งเป็นแบบ Deterministic • ถ้าข้อมูลเวลาการทำงานของแต่ละงานไม่ค่อยแน่นอน โดยที่เราสามารถกำหนดหาความน่าจะเป็นของเวลาเหล่านั้น เรียกว่า PERT ซึ่งเป็นแบบ Probabilistic

21. PERT/CPM • มีการแสดงงานในลักษณะของ Node และความเกี่ยวเนื่อง (Dependency) ของงานแต่ละอันที่เกิดขึ้นอย่างชัดเจน • จุดเด่นของ PERT/CRM คือ การคำนวณหาเส้นทางวิกฤติในการดำเนินกิจกรรม ทำให้ผู้บริหารโครงการคำนวณหาเวลาได้หลายลักษณะ เช่น เวลาที่เร็วที่สุดของแต่ละกิจกรรม (Time Earliest : TE) เวลาที่ช้าที่สุดของแต่ละกิจกรรม (Time Latest : TL) เป็นต้น

22. ความแตกต่างและความเหมือนกันของ PERT กับ CPM • หลักการคล้ายกัน แต่ PERT เวลาที่ใช้ในการทำกิจกรรมจะเป็นเวลาโดยประมาณ • PERT ส่วนใหญ่ใช้กับโครงการที่ไม่เคยทำมาก่อน ซึ่งยังมีความไม่แน่นอนในด้านระยะเวลาการดำเนินการ • สำหรับ CPM เวลาที่ใช้ในการทำกิจกรรมจะเป็นการประมาณเวลาที่แล้วเสร็จของแต่ละกิจกรรมเพียงค่าเดียว • CPM ใช้กับโครงการที่เคยทำมาก่อนหรือโครงการที่มีการใช้เทคโนโลยีเก่า

23. องค์ประกอบของ PERT/CPM 1. สัญลักษณ์ที่ใช้ในการเขียนข่ายงาน แทนกิจกรรม คืองานที่ต้องทำในโครงการ ต้องมีเวลาในการทำให้เสร็จ แทนเหตุการณ์ แสดงจุดเริ่มและจุดสิ้นสุดของกิจกรรม แทนกิจกรรมจำลอง ช่วยในการลำดับขั้นตอน

24. องค์ประกอบของ PERT/CPM 2. การสร้างข่ายงาน เป็นการอธิบายกิจกรรมและเหตุการณ์ต่าง ๆ • มีวิธีการสร้างได้ 2 วิธี • กิจกรรมบนเส้น (Activity on arc) • กิจกรรมบนโหนดเหตุการณ์ (Activity on node)

25. ขั้นตอนการวิเคราะห์ข่ายงานด้วย PERT/CPM • เขียนข่ายงาน (Draw Network) • วิเคราะห์หาวิถีวิกฤต (Critical path analysis) • ES (Earliest start) • EF (Earliest finish) • LS (Latest start) • LF (Latest finish) • FF (Free float) • TF (Total float) กิจกรรมใดที่มีค่า TF เป็น 0 ก็คือ กิจกรรมวิกฤติ • t (Time) เวลาที่ใช้ทำกิจกรรม

26. ขั้นตอนการวิเคราะห์ข่ายงานด้วย PERT/CPM • สูตรคำนวณ • EF = ES + t • ES = max{EF ของกิจกรรมที่ทำก่อนหน้า} • LS = LF – t • LF = min{LS ของกิจกรรมที่ตามมา} • TF = LS – ES หรือ TF = LF - EF • FF = ES ของงานที่ตามมา - EF

27. การประมาณการซอฟต์แวร์ (Software Estimation) การประมาณการซอฟต์แวร์ถือว่าเป็นส่วนสำคัญในการวางแผน โดยในการพัฒนาซอฟต์แวร์นั้นมีมุมมองในการประมาณการ 4 ส่วน • ขนาด (Size) • ค่าใช้จ่าย (Cost) • บุคลากรที่ใช้พัฒนา (Effort) หน่วยที่นิยมมากที่สุดคือ Man-Month • ระยะเวลา(Schedule)

28. การวัดซอฟต์แวร์ (Measurement) • สิ่งแรกที่จะต้องทำก่อนการเริ่มต้นการประมาณการ คือ การวัด แยกลักษณะการวัดออกเป็น 2 เชิง คือ การวัดในเชิงปริมาณ (Software Quantitative) และการวัดเชิงคุณภาพ (Software Qualitative)

29. ขั้นตอนในการประมาณการขั้นตอนในการประมาณการ • ประกอบด้วย 7 ขั้นตอนดังนี้ • การเลือกกรรมวิธีการวัดลักษณะของซอฟต์แวร์(Measurement Method) • เลือกวิธีที่ใช้ในการประมาณการ (Estimation Techniques) • ทำการประมาณการในส่วนของ ขนาด ค่าใช้จ่าย บุคลากร ระยะเวลา และทรัพยากรที่จำเป็น (Product Estimation) • ทำการวิเคราะห์ความเสี่ยง หรือ ผลกระทบจากปัจจัยต่างๆ (Risk Assessment /Impact Analysis) • ทำการตรวจทาน ตรวจสอบ และ ปรับแก้ให้เหมาะสม (Review/Revise/Refine/Document) • ทำการติดตามและวัดผลผลิตภัณฑ์หรือซอฟต์แวร์ที่ได้ทำการพัฒนาจริง(Tracking/Product Measurement) • ทำการปรับปรุงแก้ไขกระบวนการ(Process Improvement)

30. การประมาณการต้นทุนของซอฟต์แวร์(Software Cost Estimation) • แนวทางในการประมาณการต้นทุนซอฟต์แวร์ จะมุ่งเน้นถึงการประมาณขนาดของซอฟต์แวร์ (Size) การประมาณความพยายามที่ต้องใช้ (Effort) การประมาณระยะเวลาของการพัฒนาซอฟต์แวร์ (Time) และการประมาณค่าใช้จ่ายอื่นในการพัฒนา (Investment)

31. การประมาณการซอฟต์แวร์การประมาณการซอฟต์แวร์ • การวัดขนาดของซอฟต์แวร์ด้วยวิธีการ • Lines of codes (LOC) • Function Point (FP) • การใช้ Model ในการประเมินราคาซอฟต์แวร์

32. การวัดขนาดซอฟต์แวร์ • การวัดขนาดของซอฟต์แวร์มีวัตถุประสงค์เพื่อ • ชี้ให้เห็นถึงคุณภาพของผลิตภัณฑ์ • เพื่อประเมินผลที่เกิดจากบุคลากรผู้ทำการผลิต • เพื่อคาดคะเนผลกำไร • เพื่อจัดเตรียมแนวทางในการประเมิน • เพื่อจัดสรรเครื่องมือและอุปกรณ์ต่างๆในการพัฒนา

33. Size Estimation • กรรมวิธีที่ใช้ในการวัดขนาดของซอฟต์แวร์ มี 2 ลักษณะ คือ • Line of Code (LOC) Count • Function Point (FP)

34. Line of Code (LOC) Count • นับเฉพาะบรรทัดที่มีการจัดส่งเป็น Source Code ไม่นับรวมส่วนของการทดสอบ (Test Driver) หรือส่วนงานที่รองรับการทำงานอื่นๆ • นับเฉพาะบรรทัดที่พัฒนาโดยบุคลากร ไม่นับรวมสิ่งที่ระบบงานสามารถ Generate ได้อัตโนมัติ • ถือว่าหนึ่งคำสั่ง คือ หนึ่ง Line of Code <LOC> • นับส่วนของการประกาศค่า (Declaration) เป็นส่วนของ Instruction • ไม่นับส่วนของการขยายความ หรือ Comment • ข้อเสีย คือ ไม่สามารถนำมาใช้วัดประสิทธิผลการผลิตซอฟต์แวร์ของโปรแกรมเมอร์ที่ใช้ภาษาโปรแกรมมิ่งที่แตกต่างกันได้

35. Function Point (FP) • ปัจจุบันการนับขนาดของโปรแกรมด้วยการนับบรรทัดนั้น ไม่สามารถให้ผลการวัดในเชิงผลสัมฤทธิ์ของโปรแกรมได้อย่างชัดเจน การนำวิธีการนับด้วยฟังก์ชั่นพอยต์เข้ามาใช้นั้น จึงได้รับความสนใจ • การวัดด้วยฟังก์ชันพอยต์ จะมุ่งเน้นที่การวัดด้วยฟังก์ชัน หรือการวัดโดยผ่านมุมมองความต้องการของซอฟต์แวร์ • Allan Albrecht [1] John Gaffney, Jr [2] ได้ออกแบบ FPs ที่ใช้วัดฟังก์ชั่นพอยต์ FPs เป็นผลรวมของขนาด ข้อมูลเข้า, ข้อมูลออก, ข้อมูลความต้องการ, แฟ้มข้อมูล และส่วนของโปรแกรมที่ใช้ในการติดต่อกับลูกค้า

36. Function Point (FP) • กระบวนการนับฟังก์ชันพอยต์ มีลักษณะดังนี้ ขั้นที่ 1 นำ Requirement ที่เก็บรวบรวมไว้มาทำการแบ่งฟังก์ชันพอยต์ ขั้นที่ 2 ประเมินความซับซ้อนของฟังก์ชัน ขั้นที่ 3 เปรียบเทียบความซับซ้อน เพื่อให้ได้ระดับความซับซ้อน เพื่อคำนวณฟังก์ชันพอยต์ที่ยังไม่ได้ปรับค่า (Unadjusted Function Point : UFP) ขั้นที่ 4 คำนวณค่าตัวแปรปรับค่า (Value Adjustment Factor) ตามลักษณะของโครงการ ขั้นที่ 5 คำนวณจำนวนฟังก์ชันพอยต์ที่ผ่านการปรับค่า (Adjusted Function Point : AFP) ขั้นที่ 6 ฟังก์ชันพอยต์ที่ผ่านการปรับค่า สามารถนำไปคำนวณเป็น LOC ได้

37. สูตรคำนวณ Function Point : FP FP = UFP * VAF FP คือ ขนาดของซอฟต์แวร์ UFP (Unadjusted Function Point) ค่า FP ที่ยังไม่ได้ถูกปรับแต่ง VAF (Value Adjustment Factor) ค่าปัจจัยคุณลักษณะของระบบคือค่าของตัวแปรปรับค่าตามลักษณะโครงการ

38. การคำนวณหา FP ที่ยังไม่ได้ปรับแต่ง (UFP) • ประเภทของฟังก์ชันพอยต์ สามารถแบ่งได้ 5 ลักษณะหลัก คือ • External Input (EI) • External Output (EO) • External Inquiry (EQ) • Internal Logical Files (ILF) • External Interface Files (EIF)

39. การคำนวณหา FP ที่ยังไม่ได้ปรับแต่ง (UFP)

40. การคำนวณหา FP ที่ยังไม่ได้ปรับแต่ง (UFP) • ฟังก์ชันแต่ละประเภทเกิดจากการทำรายการข้อมูล (Transaction) ของผู้ใช้ จึงมีความซับซ้อนแตกต่างกันขึ้นอยู่กับสิ่งต่อไปนี้ • จำนวนของข้อมูล ฟิลด์ข้อมูล (Data Element Type : DET) • จำนวนเรคคอร์ด ( Record Element Type: RET ) • ไฟล์ที่เกี่ยวข้อง (File Type Reference:FTR)

41. UFP • ดังนั้นการนับฟังก์ชันแต่ละประเภท จึงต้องนับที่จำนวนของ DET , RET และ FTR ที่เกี่ยวข้องกับฟังก์ชันแต่ละประเภท แล้วนำมาเทียบกับตารางเกณฑ์ระดับความซับซ้อนของฟังก์ชัน • เกณฑ์ความซับซ้อนแบ่งเป็น • ระดับต่ำ (Low) • ระดับปานกลาง (Average) • ระดับสูง (High)

42. ตารางเกณฑ์ระดับความซับซ้อนของฟังก์ชันตารางเกณฑ์ระดับความซับซ้อนของฟังก์ชัน

43. UFP จากตารางข้างบน จะได้ระดับความซับซ้อนของการทำงาน จากนั้นนำค่าความซับซ้อนที่เป็นค่าเฉลี่ยมาทำการคำนวณค่า Complexity weight ตามตารางถ่วงน้ำหนักดังนี้

44. ตัวอย่างการหาค่า UFP • ถ้าข้อมูลสินค้าที่จะนำเข้าสู่ระบบ (EI) เกี่ยวข้องกับไฟล์ 2 ชนิด (FTR) และข้อมูลสินค้านี้ประกอบด้วยฟิลด์ข้อมูลไม่เกิน 15 ฟิลด์(DET) • เมื่อเทียบกับตารางเกณฑ์ระดับความซับซ้อนของฟังก์ชัน พบว่า EI มีระดับความซับซ้อนอยู่ที่ Average • เมื่อดูจากตารางถ่วงน้ำหนักแล้ว EI ที่มีค่าความซับซ้อนอยู่ที่ Average จะมีตัวคูณถ่วงน้ำหนักอยู่ที่ 4 • จะได้ UFP = 2 * 4 = 8

45. การคำนวณค่าปัจจัยคุณลักษณะของระบบ VAF การประเมิน VAF นั้นจะประเมินค่าของ 14 ปัจจัย ดังนี้ การติดต่อสื่อสารข้อมูล (Data Communication) การประมวลผลข้อมูลแบบกระจาย (Distributed Data Processing) ประสิทธิภาพของระบบ (Performance) การแก้ไขค่าของระบบ (Configuration) ปริมาณรายการข้อมูล (Transaction) การป้อนข้อมูลเข้าสู่ระบบแบบออนไลน์ (Online Data Entry)

46. VAF ประสิทธิภาพการใช้งานของผู้ใช้ (End user Efficiency) การปรับปรุงข้อมูลแบบออนไลน์ (Online Update) ความซับซ้อนของการประมวลผล (Complex Processing) การนำไปใช้ซ้ำได้ (Reusability) ความง่ายในการติดตั้ง (Installation Ease) ความง่ายในการดำเนินงาน (Operational Ease) การใช้งานได้หลายไซต์ (Multiple Sites) รองรับการเปลี่ยนแปลงความต้องการของผู้ใช้ (Change Requirement)

47. VAF การประเมินนั้น แบ่งออกเป็น 6 ระดับ (0-5) ตาม Degree of Influence (DI)

48. สูตรการคำนวณ VAF VAF = 0.65 + [ 0.01 x Total DI ] DI : Degree of Influence

49. ตารางเปรียบเทียบค่า FP เพื่อแปลงไปเป็น LOC

50. ตัวอย่างการคำนวณค่าฟังก์ชันพอยต์ตัวอย่างการคำนวณค่าฟังก์ชันพอยต์ จาก Use case Diagram ดังรูป จะทำการแยกประเภทของ use case ตามฟังก์ชันพอยต์