วิชา 4122309 วิศวกรรมซอฟต์แวร์ (Software Engineering)

1. วิชา 4122309วิศวกรรมซอฟต์แวร์ (Software Engineering) วิศวกรรมระบบ (System Engineering) การบริหารโครงการผลิตซอฟต์แวร์ การประมาณการซอฟต์แวร์ (Software Estimation)

2. วิศวกรรมระบบ (System Engineering) • วิศวกรรมระบบ ไม่ได้มุ่งเน้นในเรื่องของซอฟต์แวร์อย่างเดียว แต่ให้ความสำคัญกับส่วนประกอบอื่นๆ ด้วย • วิศวกรรมระบบ หมายถึง กระบวนการศึกษาและวิเคราะห์ของระบบที่มีความสลับซับซ้อน เพื่อสนับสนุนการทำงานในส่วนของวิศวกรรมซอฟต์แวร์ กิจกรรมของวิศวกรรมระบบ จะถูกดำเนินการไปพร้อมๆ กับกิจกรรมของวิศวกรรมซอฟต์แวร์

3. วิศวกรรมระบบ (System Engineering) กิจกรรมของวิศวกรรมระบบ มีดังนี้ • กำหนดวัตถุประสงค์ของระบบ • กำหดนขอบเขตของระบบ • แบ่งระบบออกเป็นส่วนๆ ตามฟังก์ชันงานหรือคุณสมบัติระบบ • พิจารณาความสัมพันธ์ของส่วนประกอบต่างๆ ที่เกี่ยวข้องทั้งหมด • กำหนดความสัมพันธ์ของปัจจัยนำเข้า ประมวลผล และผลลัพธ์

4. วิศวกรรมระบบ (System Engineering) • พิจารณาปัจจัยที่มีส่วนเกี่ยวข้องในระบบ • กำหนดความต้องการในส่วนของการดำเนินการและฟังก์ชันงานทั้งระบบ • สร้างแบบจำลอง เพื่อใช้วิเคราะห์และพัฒนาให้สอดคล้องกับแบบจำลองซอฟต์แวร์ที่สร้างขึ้น • นำเสนอและแลกเปลี่ยนข้อคิดเห็นกับผู้ใช้ระบบ

5. วิศวกรรมระบบ (System Engineering) กระบวนการวิศวกรรระบบ ประกอบไปด้วยขั้นตอน 7 เฟส ดังนี้ • การกำหนดความต้องการ (Requirement Definition) • การออกแบบระบบ (System Design) • การพัฒนาระบบย่อย (Sub-system Development) • การผนวกรวมระบบ (System Integration) • การติดตั้งระบบ (System Installation) • การเปลี่ยนแปลงระบบ (System Evolution) • การปลดระวางระบบ (System Decommission)

6. วิศวกรรมระบบ (System Engineering)

7. วิศวกรรมระบบ (System Engineering) • การกำหนดความต้องการ (Requirement Definition) • เพื่อกำหนดนิยามความต้องการของระบบให้ชัดเจน กำหนดหน้าที่ว่าระบบควรจะทำอะไรได้บ้าง เป็นเพียงข้อกำหนดเบื้องต้น • การออกแบบระบบ (System Design) • เป็นการกำหนดรายละเอียดของฟังก์ชันในแต่ละส่วนประกอบของระบบ มีดังนี้ • แบ่งส่วนความต้องการ • กำหนดระบบย่อย • กำหนดความต้องการในแต่ละระบบย่อย • กำหนดฟังก์ชันของแต่ละระบบย่อย • กำหนดส่วนประสานของระบบย่อย

8. วิศวกรรมระบบ (System Engineering) • การออกแบบระบบ (System Design)

9. วิศวกรรมระบบ (System Engineering) • การพัฒนาระบบย่อย (Sub-system Development) • เป็นการนำเอาระบบย่อยที่ถูกกำหนดรายละเอียดไว้ในระยะออกแบบ มาสร้างด้วยกระบวนการที่เหมาะสม • การผนวกรวมระบบ (System Integration) • ระบบย่อยที่พัฒนาเสร็จแล้ว จะนำมาผนวกรวมเข้าด้วยกันจนเป็นระบบที่สมบูรณ์ หลังจากรวมระบบแล้ว ทีมงานต้องทำการทดสอบการทำงานของระบบอีกครั้ง

10. วิศวกรรมระบบ (System Engineering) • การติดตั้งระบบ (System Installation) • นำระบบที่พัฒนาเรียบร้อยแล้วมาติดตั้ง เพื่อใช้งาน • การเปลี่ยนแปลงระบบ (System Evolution) • ในช่วงการใช้งานระบบ อาจเกิดการเปลี่ยนแปลงต่างๆ อาจต้องการการแก้ไขข้อผิดพลาดต่างๆ • การปลดระวางระบบ (System Decommission) • หมายถึง การเลิกใช้งานหลังจากพบว่าระบบไม่สามารถใช้ประโยชน์ได้อีกต่อไป

11. การสร้างแบบจำลองระบบด้วย UML • UML มีแผนภาพ (Diagram) หลายๆ แบบให้เลือกใช้เพื่อการวิเคราะห์และการออกแบบในระดับระบบ และระดับซอฟต์แวร์ • UML คือ โมเดลมาตรฐานที่ใช้หลักการออกแบบ OOP(Object oriented programming)

12. การสร้างแบบจำลองระบบด้วย UML • Class Diagram • Object Diagram • Component Diagram • Deployment Diagram • Use Case Diagram • Sequence Diagram • Collaboration Diagram • StateTransition Diagram • Activity Diagram Structural Diagrams Behavioral Diagrams

13. State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams Class Diagrams Object Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Sequence Diagrams Use Case Diagrams Collaboration Diagrams Statechart Diagrams Models Activity Diagrams

14. การสร้างแบบจำลองระบบด้วย UML • 5 มุมมองหลักของ UML • Use-case view : หน้าที่การทำงานของระบบซอฟต์แวร์ โดยพิจารณาจากมุมมองของผู้ใช้ภายนอก หรือ ระบบภายนอก • use-case diagram • Logical view : หน้าที่การทำงานของระบบมีโครงสร้างอย่างไร มองในรูปของ static structure และ dynamic behavior • class diagram, object diagram, state, sequence, collaboration, activity diagrams

15. การสร้างแบบจำลองระบบด้วย UML • Component view : องค์ประกอบย่อยในการ implement ที่ประกอบเป็นระบบ และ dependency ระหว่างองค์ประกอบเหล่านั้น • component diagram • Concurrency view: การแบ่งแยก process และ processors โดยพิจารณาทั้ง communication และ synchronization • dynamic diagrams (state, sequence, collaboration activity) • implementation diagrams(component และ deployment) • Deployment view : โครงสร้างทางกายภาพเกี่ยวกับ การติดตั้ง และใช้งานระบบ • deployment diagram

16. การสร้างแบบจำลองระบบด้วย UML • Use case Diagram ในการพัฒนาระบบงานใดๆ นั้น การเก็บรวบรวมความต้องการของผู้ใช้มีความสำคัญมาก และจะทำในระยะแรกๆ ของการพัฒนาระบบงานเสมอ Use case diagram เป็น Diagram ที่ทำหน้าที่ Capture requirement • เป็นเทคนิคในการสร้างแบบจำลองเพื่อใช้อธิบายหน้าที่ของระบบใหม่ หรือระบบปัจจุบัน • กระบวนการสร้าง Use case เป็นแบบ Iteration • ความต้องการของระบบจะได้จาก ลูกค้า/ผู้ใช้ + ผู้พัฒนาระบบ • องค์ประกอบจะมี Use case, Actor, Use case Relation และ System

17. deposit withdraw transfer customer statement teller add interest Use Case Diagram

18. Class Diagram • Class Diagram ประกอยด้วย Class และความสัมพันธ์ระหว่าง Class เช่น Dependency, Generalization, Association เป็นต้น Class Diagram สามารถแสดงรายละเอียดว่ามี Method และ Attribute อย่างไร

19. Class Diagram

20. Object Diagram • Object Diagram ประกอบด้วย Object และ Relation ระหว่าง Object โดยแต่ละ Object จะแสดง Instance ของแต่ละ class ที่มีในระบบ และความสัมพันธ์ระหว่าง Class เช่น Dependency, Generalization หรือ Association ซึ่งมีลักษณะเช่นเดียวกับ Class Diagram

21. Object Diagram

22. Sequence Diagram • Sequence Diagram จะแสดงลำดับการทำงานของระบบ โดยมี Object และ เวลาเป็นตัวกำหนดลำดับของงาน และเน้นไปที่ instant ของ Oject • Sequence Diagram เป็น Diagram ซึ่งแสดงปฏิสัมพันธ์(Interaction) ระหว่าง Object ตามลำดับของเหตุการณ์ที่เกิดขึ้น ณ เวลาที่กำหนด message ที่เกิดขึ้นระหว่าง class จะสามารถนำไปสู่การสร้าง method ใน class ที่เกี่ยวข้องได้

23. Sequence Diagram

24. Collaboration Diagram • Collaboration Diagram แสดงลำดับการทำงานของ วัตถุ ผู้เกี่ยวข้อง และกิจกรรม โดยลำดับการทำงานไม่ขึ้นกับเวลา เพราะการแสดงความสัมพันธ์ของ Object กับเวลาเป็นหน้าที่ของ Sequence Diagram

25. Collaboration Diagram

26. State Diagram • State Diagram ประกอบด้วย State ต่างๆ ของ Object และเหตุการณ์ต่างๆ ที่ทำให้สถานะของ Object เปลี่ยนและการกระทำที่เกิดขึ้นเมื่อสถานะของระบบเปลี่ยนไป สามารถบอกสถานะของ Object ได้ โดยจะให้ความสนใจว่า ณ เวลาใดๆ Object นั้นมี status เป็นแบบใด

27. State Diagram

28. Activity Diagram • Activities Diagram แสดงลำดับ กิจกรรมของการทำงาน(Work Flow) สามารถแสดงทางเลือกที่เกิดขึ้นได้ Activity Diagram จะแสดงขั้นตอนการทำงานในการปฏิบัติการ โดยประกอบไปด้วยสถานะต่างๆ ที่เกิดขึ้นระหว่างการทำงาน และผลจากการทำงานในขั้นตอนต่าง ๆ

29. Activity Diagram

30. Component diagram • Component Diagram เป็น Diagram ซึ่งแสดงโครงสร้างทางกายภาพของ Software โดยจะประกอบด้วยองค์ประกอบซึ่งอยู่ในรูปต่างๆ เช่น Binary, text และ executeable ภายใน Component Diagram ก็จะมีความสัมพันธ์แสดงอยู่เช่นเดียวกับ Class Diagram, Object Diagram

31. Component diagram

32. Deployment diagram • Deployment Diagram เป็นสิ่งที่สามารถทำการแสดงระบบสถาปัตยกรรมของ Hardware/Software ตลอดจนความสัมพันธ์ระหว่าง hardware/software

33. Deployment diagram

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

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

36. Gantt Chart

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

38. PERT/CPM • เวลาที่เร็วที่สุดของแต่ละกิจกรรม (Time Earliest : TE) • คำนวณจากซ้ายมาขวา คือ บวกค่าเพิ่มจาด้านซ้ายมาด้านขวา • เวลาที่ช้าที่สุดของแต่ละกิจกรรม (Time Latest : TL) • เวลาที่ช้าที่สุดที่งานนั้นยังสามารถทำเสร็จได้โดยไม่กระทบแผนงาน นั้นคือ ลดค่าที่เกี่ยวข้องจากด้านขวามาซ้าย โดยพิจารณาจากงานสุดท้ายก่อน

39. PERT/CPM

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

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

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

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

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

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

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

47. Function Point (FP)

48. Function Point (FP) • แต่ละฟังก์ชันพอยต์นั้น มีองค์ประกอบต่างๆ ในฟังก์ชันแต่ละประเภทซึ่งจะแตกต่างกันได้ เช่น • การเกี่ยวข้องกับองค์ประกอบข้อมูล (Data Element : DET) • เป็นข้อมูล เปรียบเสมือนฟิลด์ข้อมูลที่สนใจในแต่ละฟิลด์ • เรคคอร์คข้อมูล (Record Element : RET) • กลุ่มของข้อมูล หรือกลุ่มย่อยของ DET หรือการนับประเภทของเรคคอร์ดข้อมูลที่เกี่ยวข้องสัมพันธ์กับฟังก์ชันที่สนใจ • ประเภทไฟล์ (File Type of Record : FTR)

49. คำนวณ Function Point (FP) จำนวนของฟังก์ชัน หาได้จาก FP ที่ยังไม่ได้ถูกปรับแต่ง (Unadjusted Function Point : UFP) คูณกับค่าปัจจัยคุณลักษณะของระบบ (Value Adjustment Factor : VAF) FP = UFP x VAF VAF = 0.65 + [0.01 x Total DI] DI : Degree of Influence

50. UAF • จะเห็นว่าการกำหนดฟังก์ชันโดยแยกออกเป็น 5 ประเภทหลัก ตามลักษณะของการทำงานนั้น จะช่วยทำให้การประเมินลักษณะความต้องการของซอฟต์แวร์ การพิจารณาองค์ประกอบที่เกี่ยวข้องกับประเภทของแต่ละฟังก์ชันพอยต์นั้น จะทำให้สามารถพิจารณาความซับซ้อนของฟังก์ชันพอยต์ได้อย่างเป็นรูปธรรมมากขึ้น โดยพิจารณาจากตาราง