เกี่ยวกับ Rational Unified Process

posted on 13 Aug 2008 17:18 by wonam in softdev

ช่วงนี้ลองอ่าน Rational Unified Process (RUP)  เจอเรื่องน่าสนใจหลายอย่าง เอามาเขียนต่อ ๆ กันเลยแล้วกันครับ

เรื่องแรกเกี่ยวกับการแบ่งกลุ่ม

ปกติเวลาเวลาแบ่งระเบียบวิธีในการพัฒนาซอฟต์แวร์เรามักแบ่งเป็นสองกลุ่ม คือกลุ่มเน้นการวางแผน (plan-based) ที่น่าจะนับรวมพวก CMMI และ RUP ไว้ด้วยกัน กับกลุ่มพริ้ว (agile) 

อย่างไรก็ตามถ้าดูตามที่พวก RUP แบ่ง หรือในเอกสาร EssUP ของ Jacobson เองจะแบ่งเป็นสามกลุ่ม คือ กลุ่มประกันคุณภาพกระบวนการ (CMMI), กลุ่มพริ้ว (agile), แล้วก็ RUP เองซึ่ง Jacobson เรียกว่าเป็นกลุ่มที่มาจากสายวิศวกรรมซอฟต์แวร์

ทีนี้อ่าน ๆ ดูก็จะเห็นว่า RUP เองก็ระบุว่าระเบียบวิธีของเขาเนี่ยะ ปรับเปลี่ยนได้ตามสะดวก จะให้เอกสารเยอะหรือจะให้พริ้วก็ได้

อ่านไปเจอแนวคิดหลักของ RUP ว่าจะลองอ่านดูว่ามันเน้นต่างจากกลุ่ม Agile อย่างไรบ้าง เพราะว่าอ่านเผิน ๆ ก็ไม่ต่างกันเท่าไหร่ แต่วันนี้ดันไปเจอเรื่องน่าสนใจที่สองก่อน

เรื่องที่สองเกี่ยวกับบทวิจารณ์ RUP เอง

ผมกดไปกดมากดไปเจอรายงานฉบับนี้ ของ Wolfgang Hesse (ลิงก์จากวิกิพีเดีย) ที่เขียนวิจารณ์ RUP ไว้ว่าโบราณไป

เวลาเราเห็นที่ไหนอธิบาย RUP เราก็จะเห็นแผนภาพรูปด้านล่างนี่

 

 

(รูปจากวิกิพีเดีย)

RUP มองกระบวนการในการพัฒนาซอฟต์แวร์ว่าพัฒนาเป็นรอบ ๆ (iteration) แต่ละรอบก็จะประกอบไปด้วยระยะ (phase) ต่าง ๆ สี่ระยะ (ดูรูปด้านบน แกนนอนคือเวลา) คือ inception, elaboration, construction, transition  แต่ละระยะก็จะมีหน้าที่และเป้าหมายแตกต่างกัน (ดูได้จากวิกิพีเดีย)

แนวคิดอีกอันคือเรื่องของ workflow คือลำดับของกิจกรรมที่ทำต่อเนื่องกันไป  ถ้าเราดูกิจกรรมที่ทำในแต่ละระยะ จะเห็นว่านี่เป็นพัฒนาการมาจากโมเดลน้ำตก (ที่มี analysis, design, code, test) นั่นเอง  

Hesse วิจารณ์โครงสร้างของกระบวนการของ RUP  โดยแบ่งเป็น 7 ข้อ   ผมขอสรุปเอาย่อ ๆ แค่ 3 ข้อที่พอสรุปได้นะครับ

  •  การแบ่งเป็นระยะนั้นไม่เหมาะ  เขากล่าวว่าระยะนั้นเห็นแนวคิดที่เหมาะกับซอฟต์แวร์ที่เป็นก้อนเดี่ยว ๆ ไม่ใช้เป็นระบบที่ประกอบด้วยส่วนย่อย ๆ มากมาย ที่สามารถพัฒนาและจัดการแยกจากกันได้
  • แม้ว่า RUP จะกล่าวว่าเป็นกระบวนวิธีที่มีสถาปัตยกรรมเป็นศูนย์กลาง แต่จริง ๆ แล้ว Hesse มองว่าไม่ได้เป็นเช่นนั้น  เขากล่าวว่ากระบวนวิธีที่เน้นสถาปัตยกรรมเป็นศูนย์กลางจะต้องผูกกิจกรรม รอบการทำงาน และอื่น ๆ เข้ากับหน่วยย่อยเชิงสถาปัตยของซอฟต์แวร์  เช่นโมดูลหรือส่วนย่อย  อย่างไรก็ตาม RUP กลับผูกของต่าง ๆ เข้ากับโมเดล (ที่เป็นสิ่งที่ทำให้ RUP ระบุว่าเป็นกระบวนวิธีแบบเน้นสถาปัตยกรรมเป็นศูนย์กลาง)
  • การแยกระยะ ออกจาก workflow ไม่ได้ให้อะไรใหม่  เขาสังเกตว่ากิจกรรมใน workflow ก็จะมีช่วงเน้นอยู่ตามแต่ละระยะ แล้วก็แทบจะจับคู่กับระยะได้ทั้งหมดอยู่แล้ว  การเพิ่มแนวคิดใหม่เข้ามายิ่งจะทำให้กระบวนวิธีซับซ้อนขึ้น
ส่วนอีก 4 ข้อที่เหลือ ผมอ่านแล้วไม่ค่อยเข้าใจหรือเห็นด้วยอย่างชัดแจ้งเท่าใด ก็มีดังนี้ครับ
  • Hesse กล่าวว่าการแบ่งการพัฒนาเป็นรอบ ๆ ก็ดี แต่ว่าเขาสงสัยว่าทำไมแต่ละรอบจะต้องเริ่มกระบวนการแบบน้ำตก (ไล่ตามระยะ) ซ้ำแบบเดิมอีก
  • RUP ไม่ได้มีกระบวนการรองรับการจัดโครงสร้างซอฟต์แวร์และกระบวนการที่ซับซ้อน
  • การดำเนินการตาม RUP ไม่โปรงใสพอสำหรับฝ่ายบริหาร แล้วก็แนวคิดเกี่ยวกับหลักไมล์ก็ไม่มีรายละเอียดมากพอ (เขายกตัวอย่างว่า เวลาระบุว่าทำ usecase ไปได้ 80% หมายความว่าอย่างไร?)
  • RUP ไม่ได้จัดการเกี่ยวกับการประสานงานระหว่างบทบาทต่าง ๆ  และนอกจากนี้ยังไม่ค่อยสนใจผู้ใช้และ feedback จากผู้ใช้

หลังจากคุณ Hesse วิจารณ์ RUP เสร็จ ก็ได้เสนอแนวคิดของการโมเดลกระบวนการอีกแบบ ที่พยายามแก้ข้อเสียที่เขากล่าวมาข้างต้นของ RUP (นั่นคือ, เวลาอ่านวิจารณ์ของ Hesse อาจจะต้องอ่านตาไว้ตาเหมือนกัน)

เรื่องสุดท้ายเกี่ยวกับ OpenUP

ระหว่างที่อ่าน ๆ เกี่ยวกับ RUP อยู่ก็เจอ OpenUP ซึ่งเป็นอีกกระบวนวิธีหนึ่งที่พัฒนาต่อมาจาก RUP โดยรวมอยู่ใน Eclipse Process Framework เลย  (แต่ก็ไม่รู้ว่ารวมอยู่แล้วจะใช้ได้แบบไหนกันแน่)   ในเว็บยังกล่าวว่าในรุ่นที่พริ้วสุดของ OpenUP ที่เรียกว่า OpenUP/Basic ก็เป็น agile เหมือนกัน

ท่านใดมีประสบการณ์เกี่ยวกับ RUP และลูกหลาน รบกวนช่วยฝากไว้ที่ comment นะครับ

Comment

Comment:

Tweet

Thanks for the article. I read the above post.

#8 By Chicgraphic on 2012-03-30 22:41

Your online business is going worse? You tried to increase your sales but nothing changed? Probably, you din't utilize the article submission company! Experts can help you getting better.

#7 By YorkMarquita33 (31.184.236.16) on 2011-12-24 07:09

ขยันจังเลย อยากขยันอย่างมะนาวมั่งจัง big smile

#6 By rainam on 2008-08-16 10:51

คุณ Kan: ขอบคุณมากครับที่แวะมาบอกเล่าประสบการณ์ครับ ;)

#5 By wonam on 2008-08-14 17:51

แล้วก็อีกอย่างครับ

ผมคิดว่า RUP เนี่ย แค่เหมาะสำหรับงานบางประเภทเท่านั้นเอง แล้วผมก็เห็นด้วยกับข้ออื่นๆ ที่ อ. สรุปมาครับ double wink

#4 By Kan (58.137.117.114) on 2008-08-14 13:21

ตามที่ประสบการณ์ผมเคยลองๆ มานะครับ จริงๆ ก็ไม่ค่อยรู้ถึงแก่นแท้ของมันเท่าไหร่นัก แหะๆ cry

ที่บอกว่ากระบวนการแบบน้ำตก จริงๆ ผมก็ว่าจริงส่วนหนึ่งครับ ทำงานซ้ำกันก็จริง วนลูปกลับขึ้นไปใหม่ แต่ก็ไม่ได้ทำซ้ำๆ กันทุกอย่าง ระดับการทำซ้ำจะมากน้อยแตกต่างกันออกไป ขึ้นกับว่าเราอยู่ใน Phase ไหน เช่น Inception จะเน้นพวก Requirement ส่วน Elaboration จะเน้นพวก Design แต่ทั้ง 2 Phase นี้ก็ยังคงทำส่วนที่คาบเกี่ยวกัน ซึ่งยังต้องทำอยู่ ตามรูปจากวิกิพีเดีย

แล้วก็ เหมือนกับว่า RUP นั้นต้องการที่จะลดความเสี่ยงของโปรเจค จึงทำให้เกิดการทำซ้ำกันในแต่ละ iteration

ส่วนความโปร่งใสหรือไม่ ผมเห็นว่าค่อนข้างที่จะโปร่งใสในระดับหนึ่ง เนื่องจากว่าในแต่ละ iteration ที่ทำ จะมีการส่งมอบงาน เช่น รายงานต่างๆ (use case, class diagram, seq diagram) ออกมาให้กับ user/client ได้เข้าใจตามไปกับเราได้ เหตุผลก็ เพื่อลดความเสี่ยงอีกนั่นแหละ

ไม่ค่อยสนใจผู้ใช้ อันนี้ก็ไม่ค่อยเห็นด้วยอ่าครับ จากรูป ก็จะเห็นได้ว่า ทุก Phase นั้น ยังคงต้องไปเกี่ยวข้องกับ Requirement อยู่เลย

#3 By Kan (58.137.117.114) on 2008-08-14 13:18

plug.in ฮ่าฮ่า รู้ได้ไง

#2 By wonam on 2008-08-14 08:31

อัพเดตรายวันจริงๆนะจาน กลัวเรตติ้งตกหรือเปล่า

#1 By CyberAlchemist on 2008-08-14 04:53