บทเรียนนี้อธิบายแนวคิดของ Unified Process (UP) อย่างละเอียด ตั้งแต่ความหมายของกระบวนการพัฒนาซอฟต์แวร์ ลักษณะสำคัญของ UP การพัฒนาแบบวนรอบเพิ่มพูนผล การขับเคลื่อนด้วย Use Case สถาปัตยกรรมเป็นศูนย์กลาง รวมถึง 4 เฟสสำคัญ คือ Inception, Elaboration, Construction และ Transition
บทที่ 3 ของรายวิชา OOAD เน้นเรื่อง Unified Process (UP) ซึ่งเป็นแนวทางการพัฒนาซอฟต์แวร์เชิงวัตถุที่ได้รับความนิยมอย่างมาก เพราะช่วยให้การพัฒนาระบบเป็นระบบมากขึ้น มีการแบ่งงานชัดเจน และควบคุมความเสี่ยงของโครงการได้ดี แทนที่จะพัฒนาแบบทำทีเดียวทั้งระบบแล้วค่อยตรวจสอบในตอนท้าย UP เสนอให้พัฒนาระบบ เป็นรอบ ๆ (Iterations) โดยแต่ละรอบจะสร้างผลลัพธ์ที่ใช้งานหรือทดสอบได้จริง
จากสไลด์ ผู้สอนชี้ให้เห็นว่า UP ไม่ได้เป็นเพียงขั้นตอนเขียนโปรแกรมเท่านั้น แต่ครอบคลุมตั้งแต่ การกำหนดโครงการ การวิเคราะห์ความต้องการ การออกแบบสถาปัตยกรรม การพัฒนาและทดสอบระบบ ไปจนถึงการติดตั้ง ถ่ายทอด และอบรมผู้ใช้ ดังนั้นผู้เรียนจึงต้องเข้าใจภาพรวมทั้ง วงจรชีวิตของโครงการ และ กิจกรรมทางเทคนิค ภายในแต่ละระยะ
บทนี้ยังสำคัญมากต่อการทำโครงงานรายวิชา เพราะเป็นกรอบที่สามารถนำไปใช้วางแผนจริงได้ เช่น การเขียนข้อเสนอโครงการ (Proposal), การจัดทำ Requirement, การออกแบบ Use Case และ UML, การเขียนโปรแกรม การทดสอบ และการจัดทำเอกสารส่งมอบระบบ
ก่อนเข้าใจ UP เราต้องเข้าใจก่อนว่า “กระบวนการพัฒนาซอฟต์แวร์” คืออะไร และทำไมจึงจำเป็น
คือแนวทางหรือกรรมวิธีที่ใช้กำหนดว่า ทีมพัฒนาซอฟต์แวร์จะทำงานอย่างไร ตั้งแต่วางแผน ออกแบบ พัฒนา ทดสอบ ติดตั้ง และบำรุงรักษาระบบ กระบวนการที่ดีช่วยให้ทีมรู้ว่า ใครทำอะไร เมื่อไร และทำอย่างไร ลดความสับสน ลดต้นทุนความผิดพลาด และช่วยให้ส่งมอบซอฟต์แวร์ที่มีคุณภาพมากขึ้น
ในสไลด์ยังเชื่อมโยงให้เห็นการเปลี่ยนผ่านจากแนวทางพัฒนาระบบแบบดั้งเดิม เช่น SDLC, DFD, ERD, NF ไปสู่แนวทางเชิงวัตถุ ที่ใช้ OO, UP และ UML เป็นแกนหลัก
| แนวทางดั้งเดิม | แนวทางเชิงวัตถุ |
|---|---|
| SDLC 7 ขั้นตอน | UP 4 Phase |
| วิเคราะห์ด้วย DFD / ERD | วิเคราะห์ด้วย Use Case / UML |
| เน้นกระบวนการเชิงโครงสร้าง | เน้น Object, Interaction, Architecture |
| มักพัฒนาตามลำดับมากกว่า | พัฒนาแบบวนรอบ เพิ่มพูนผล และยืดหยุ่นกว่า |
Unified Process (UP) คือกระบวนการพัฒนาซอฟต์แวร์ที่ให้คำแนะนำตั้งแต่การวางแผน การออกแบบ การพัฒนา การทดสอบ การติดตั้ง ไปจนถึงการบำรุงรักษา โดยมีเป้าหมายสำคัญคือทำให้ทีมพัฒนาทำงานร่วมกันได้อย่างมีประสิทธิภาพ และสร้างระบบที่มีคุณภาพ ตรงตามความต้องการของผู้ใช้ และอยู่ภายใต้งบประมาณที่ควบคุมได้
สไลด์อธิบายว่า UP เป็นแนวคิดในสายของวิศวกรรมซอฟต์แวร์ (Software Engineering Process) ที่ได้รับอิทธิพลจาก Rational Unified Process (RUP) ซึ่งเป็นแนวทางที่เป็นที่รู้จักมาก่อน โดย UP ปรับให้เหมาะสมและยืดหยุ่นกับโครงการได้ตั้งแต่ขนาดเล็กจนถึงขนาดใหญ่
จุดเด่นของ UP คือไม่ได้มองงานพัฒนาแบบเส้นตรงเพียงครั้งเดียว แต่แบ่งการทำงานออกเป็นเฟสและรอบงาน ทำให้สามารถควบคุมคุณภาพ ตรวจสอบความเสี่ยง และปรับเปลี่ยนตามสถานการณ์จริงของโครงการได้อย่างต่อเนื่อง
จากสไลด์ บทนี้เน้น 3 แนวคิดหลักของ UP ได้แก่ Use Case Driven, Iterative & Incremental และ Architecture-Centric
UP ขับเคลื่อนด้วย Use Case ซึ่งหมายถึงฟังก์ชันการทำงานที่ให้คุณค่าแก่ผู้ใช้ ผู้ใช้คาดหวังอะไรจากระบบ สิ่งนั้นควรถูกระบุเป็น Use Case แล้วนำไปใช้เป็นฐานในการวิเคราะห์ ออกแบบ เขียนโปรแกรม และทดสอบ
กล่าวอีกแบบคือ Requirement → Use Case → Analysis → Design → Implement & Test
โครงการถูกแบ่งออกเป็นหลาย Iterations หรือรอบงานย่อย แต่ละรอบมีการวิเคราะห์ ออกแบบ สร้าง และทดสอบของตนเอง เมื่อจบรอบจะได้ระบบย่อยหรือระบบที่สมบูรณ์ขึ้นกว่ารอบก่อน เป็นการ “เพิ่มพูนผล” ทีละขั้น
แนวคิดนี้ช่วยให้รับมือกับความเสี่ยงและการเปลี่ยนแปลงได้ดีกว่าการทำงานแบบทีเดียวจบ
UP ให้ความสำคัญกับ สถาปัตยกรรมของระบบ เป็นศูนย์กลาง เพราะระบบที่ดีต้องมองได้หลายมุม เช่น Logical View, Development View, Process View, Deployment View และ Use Case View
การมีสถาปัตยกรรมที่ชัดเจนช่วยให้ทีมพัฒนา โปรแกรมเมอร์ ผู้ทดสอบ และวิศวกรระบบสื่อสารกันได้ดีขึ้น
Unified Process แบ่งการพัฒนาออกเป็น 4 เฟสหลัก โดยแต่ละเฟสมีวัตถุประสงค์ กิจกรรม และผลลัพธ์ของตนเอง
ระยะเตรียมงาน เป็นช่วงกำหนดแนวทางของโครงการ วิเคราะห์ความเป็นไปได้ และระบุขอบเขตของระบบที่จะพัฒนา
ระยะจัดทำรายละเอียด เป็นช่วงทำ Requirement ให้ชัดเจน สร้าง Business Model/Rule และออกแบบสถาปัตยกรรมของระบบ
ระยะจัดสร้าง เป็นช่วงลงมือพัฒนาระบบจริง ทั้งซอฟต์แวร์ ฮาร์ดแวร์ เครือข่าย และอุปกรณ์ต่อพ่วงที่เกี่ยวข้อง
ระยะถ่ายโอน เป็นช่วงนำระบบไปติดตั้งใช้งานจริง จัดอบรมผู้ใช้ และตรวจสอบความเข้ากันได้ของข้อมูลเดิมและใหม่
UP จัดโครงสร้างงานออกเป็น 2 มิติ คือ มิติด้านเวลา (Phase) และมิติกระแสงาน (Workflow)
Iteration คือรอบงานย่อยภายในแต่ละเฟส ในหนึ่งรอบงาน ทีมพัฒนาจะทำกิจกรรมหลักหลายอย่างร่วมกัน เช่น เก็บความต้องการ วิเคราะห์ ออกแบบ เขียนโปรแกรม และทดสอบ แล้วได้ผลลัพธ์บางส่วนของระบบออกมา
จุดสำคัญคือ “จบแต่ละรอบต้องมีผลลัพธ์ที่นำไปใช้งานหรือประเมินได้” ไม่ใช่เพียงเอกสารอย่างเดียว ดังนั้นระบบจะค่อย ๆ เติบโตจาก Project 1.1 → Project 1.2 → Project 1.3 ไปเรื่อย ๆ จนสมบูรณ์
ในแต่ละ Iteration ทีมงานไม่ได้ทำกิจกรรมเพียงอย่างเดียว แต่ประกอบด้วยหลายกระแสงานที่ดำเนินควบคู่กัน
สไลด์อธิบายว่าโครงสร้างของ UP แบ่งเป็น 2 มิติสำคัญ คือ มิติด้านเวลา (Time / Phase) และ มิติกระแสงาน (Workflow) โดยในแต่ละเฟสจะมีหลายรอบงาน และในแต่ละรอบงานจะประกอบด้วยกิจกรรมทั้งกระแสงานหลักและกระแสงานสนับสนุน
กระแสงานหลักมักเน้นงานเชิงเทคนิค เช่น Requirement, Analysis, Design, Implement และ Test ส่วนกระแสงานสนับสนุนจะช่วยให้โครงการเดินหน้าได้อย่างมั่นคง เช่น Deployment, Project Management และ Configuration Management
สไลด์ระบุว่าการพัฒนาระบบภายใต้ UP ต้องกำหนดบทบาทและความรับผิดชอบของทีมให้ชัดเจน
Project Manager ดูแลภาพรวมโครงการ วางแผน ควบคุมเวลา งบประมาณ ความเสี่ยง และประสานงานทุกฝ่าย
System Analyst วิเคราะห์ระบบ เก็บ Requirement เขียน Use Case และเชื่อมโยงความต้องการสู่การออกแบบ
นักพัฒนาโปรแกรม เช่น Front-End, Back-End หรือ Full Stack รับผิดชอบการสร้างระบบจริงตามแบบออกแบบ
นักออกแบบ UX/UI, Mockup, Wireframe หรือวิศวกรผู้ออกแบบประสบการณ์และภาพรวมอินเทอร์เฟซ
นักทดสอบระบบรับผิดชอบสร้าง Test Case ทำ Unit Test, Integration Test และช่วยตรวจสอบคุณภาพก่อนส่งมอบ
สไลด์ยกตัวอย่างว่าโครงการอาจเกิดภายในองค์กรเอง (In-house) หรือรับจ้างจากหน่วยงานภายนอก (Outsource) ซึ่งมีผลต่อการบริหารทีม เวลา และรูปแบบการส่งมอบ
ใน UP แต่ละเฟสไม่ได้จบเพียงกิจกรรม แต่ต้องมีผลลัพธ์หรือ Deliverables ที่ชัดเจน
ช่วยกำหนดงาน บทบาท และความรับผิดชอบของทีมให้ชัดเจน
Use Case Driven, Iterative & Incremental และ Architecture-Centric
Inception → Elaboration → Construction → Transition
แต่ละรอบสร้างผลลัพธ์ที่ทดสอบหรือใช้งานได้จริง
ทั้ง Requirements, Analysis, Design, Implement, Test และ Supporting Workflow
บทถัดไปจะต่อยอดไปสู่รายละเอียดของ UML, Requirement และการใช้แบบจำลองเพื่อสื่อสารและออกแบบระบบเชิงวัตถุอย่างเป็นรูปธรรมมากขึ้น