เราสามารถนำ TRIZ มาใช้กับงานพัฒนาซอฟต์แวร์บนอินเทอร์เน็ตได้อย่างไร

TheInk
ติดตาม ผู้ติดตาม 
ติดต่อ
หากเรามองเพียงผิวเผิน TRIZ อาจจะไม่สามารถประยุกต์ใช้กับการแก้ปัญาซอฟต์แวร์ได้เพราะ ซอฟต์แวร์ไม่มี atom, ไม่มี molecule, ไม่มี layer ที่สัมผัสได้

Theory of Inventive Problem Solving (TRIZ) คือ ขบวนการหาคำตอบด้วยการใช้หลักตรรกศาสตร์และข้อมูล โดยไม่อาศัยสัญชาตญาณส่วนบุคคล จึงเป็นขบวนการที่มีโครงสร้างและวิธีการที่แน่นอน สามารถทำซ้ำ และคาดเดาผลลัพธ์ได้ แต่หลักการนี้ส่วนใหญ่จะถูกนำมาใช้กับงานด้านกลศาสตร์และการประดิษฐ์คิดค้นสิ่งของที่จับต้องได้ ผมจึงเกิดความสงสัยว่า เราสามารถนำ TRIZ มาใช้กับงานพัฒนาซอฟต์แวร์บนอินเทอร์เน็ตได้หรือไม่ และจากการค้นหาข้อมูลในเว็บไซต์ triz-journal.com ก็ได้พบบทความ "Application of TRIZ in Software Development" ซึ่งแต่งโดย Herman Hartmann, Ad Vermeulen และ Martine van Beers ที่ได้ค้นคว้าและแนวทางโดยสำหรับซอฟต์แวร์โดยรวมไว้

บทความได้สรุปไว้ว่า แม้หลักการการแก้ปัญหาเชิงประดิษฐ์คิดค้น(Inventive Principles) ของ TRIZ จะสามารถนำมาประยุกต์ใช้กับปัญหาทางซอฟต์แวร์ได้ แต่มันเป็นแค่เพียงทำให้ชุดคำสั่ง (Algorithm) ทำงานได้เร็วขึ้น ซึ่งก็ไม่ได้เพิ่มมูลค่าใดๆ ให้กับซอฟต์แวร์เพราะข้อจำกัดเหล่านั้นจะถูกแก้ปัญหาอย่างอัตโนมัติโดยการพัฒนาของฮาร์ดแวร์ตามกฏ Moore's law อย่างไรก็ตามหลักการการแก้ปัญหาเชิงประดิษฐ์คิดค้นจะเป็นประโยชน์มากในการแก้ปัญหาความขัดแย้ง (contradiction) ในการสร้างสถาปัตยกรรมซอฟต์แวร์ และ TRIZ Trends of Technical Evolution อาจจะมีประโยชน์สำหรับการระบุผลิตภัณฑ์ในอนาคตแต่ก็ยังไม่มีใครศึกษาค้นคว้าทางด้านนี้มาก่อน

ถ้าหากเรามองเพียงผิวเผิน TRIZ อาจจะไม่สามารถประยุกต์ใช้กับการแก้ปัญาซอฟต์แวร์ได้เพราะ ซอฟต์แวร์ไม่มี atom, ไม่มี molecule, ไม่มี layer ที่สัมผัสได้ แต่ผู้เขียนกล่าวไว้ในบทความว่าปัญหาด้านซอฟต์แวร์ได้เคยถูกแก้ไขได้สำเร็จโดยใช้หลักการการแก้ปัญหาเชิงประดิษฐ์คิดค้น และตารางแมทริกซ์ความขัดแย้ง (Contradiction Matrix) อย่างงานของ Kevin Rea ได้ทำเกี่ยวกับเรื่อง Concurrent Programming เขาได้แก้ปัญหาชุดคำสั่ง โดยการระบุสถานะความเป็นอุดมคติ (Ideal situation) ซึ่งก็คือสถานะที่ไม่มีปัจจัยลบใดๆ ทำให้สามารถสร้างฟังก์ชันที่ก่อให้เกิดประโยชน์ได้ตามต้องการ แล้ววิเคราะห์ความขัดแย้งและใช้หลักการนี้เพื่อพัฒนาชุดคำสั่งที่ดีขึ้น คล้ายกับ Smart construction ในวิศวกรรมเครื่องกล แต่อย่างไรก็ตามการแปลหลักการ TRIZ มาใช้กับซอฟต์แวร์เป็นเรื่องที่ยุ่งยากและจำกัดขอบเขตเฉพาะสาขาใดสาขาหนึ่งเท่านั้น ดังนั้นผู้เขียนจึงแนะนำว่าทางที่ดีคือการนำวิธีการของ Genrich Altshuller มาวิเคราะห์สิทธิบัตรด้านวิศวกรรมซอฟต์แวร์และมาพัฒนาหลักการใหม่ที่เหมือนกับหลักการการแก้ปัญหาเชิงประดิษฐ์คิดค้น และตารางแมทริกซ์ความขัดแย้งที่ใช้กันอยู่ในปัจจุบันจะดีกว่า

อีกสิ่งหนึ่งที่ถูกบรรยายใน TRIZ คือการพัฒนาชุดคำสั่งที่เร็วและไว้ใจได้ด้วยทรัพยากรที่มีอยู่จำกัด ก็เหมือนกับขนาดของหน่วยความจำและความเร็วของหน่วยประมวลผล แต่ด้วย Moore's law ที่กล่าวถึงการพัฒนาความสามารถของฮาร์ดแวร์ไว้ว่า "จำนวนทรานซิสเตอร์ต่อตารางนิ้วบนแผงวงจรจะเพิ่มขึ้นเท่าตัวทุกๆ 18 เดือน" ทำให้ปัญหาการพัฒนาซอฟต์แวร์เบาบางลงเนื่องจากเมื่อใดที่ซอฟต์แวร์ทำงานช้าลงและต้องการหน่วยความจำมากขึ้น เมื่อนั้นเราก็จะมีฮาร์ดแวร์ใหม่ๆ มาคอยแก้ปัญหาเหล่านี้ได้ ดังนั้นการสร้างชุดคำสั่งที่รวดเร็วจึงไม่จำเป็นเท่ากับการจัดการความซับซ้อนเนื่องมาจากขนาดของซอฟต์แวร์และทีมงานผู้พัฒนาซอฟต์แวร์เอง

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

เมื่อกล่าวถึงซอฟต์แวร์ ขนาดหรือจำนวนบรรทัดของมันก็เพิ่มขึ้นเช่นเดียวกับการเพิ่มขึ้น 2 เท่าทุก 18 เดือนของหน่วยความจำ ดังนั้นผลิตภัณฑ์ซอฟต์แวร์จึงใหญ่ขึ้นเรื่อยๆ ทุกปี และต้องการคนมากขึ้นให้การพัฒนา จึงเป็นแนวโน้มที่มาของ การทำระบบเปิด, การทำสัญญารับช่วง, การใช้ซ้ำ ซึ่งทั้งหมดนี้ทำให้งานซอฟต์แวร์ซับซ้อนขึ้น และก็เป็นที่มาของการส่งงานเลยเวลา ซอฟต์แวร์ทำงานไม่ได้ดั้งใจและความไม่พอใจของลูกค้า ดังนั้นตั้งแต่ช่วงต้น 1990 องค์กรส่วนมากจึงหันมาใช้ Capability Maturity Model (CMM) หรือเฟรมเวิร์คอื่นๆ เพื่อปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ให้ดีขึ้น

นอกจากนี้การจัดการกับความซับซ้อนที่ทวีคูณขึ้นคือการสร้างสถาปัตยกรรมซอฟต์แวร์ใหม่ โดยจัดเตรียมโครงสร้างทางเทคนิคสำหรับโปรเจคไว้ สถาปัตกรรมที่ดีจะทำให้เราทำงานได้ง่ายขึ้น และในการสร้างสถาปัตยกรรมนี้ก็เหมือนกับการจัดการความต้องการที่ขัดแย้งกัน (Conflicting demand) สถาปัตยกรรมนี้ต้องตอบสนองความต้องการแบบ fulfill funcional และ non-functional ตัวอย่างของ non-functional ก็อย่างเช่น ความสามารถในการเคลื่อนย้าย, การบำรุงรักษา, ความยึดหยุ่น, การขยาย, และการใช้ซ้ำ ซึ่งทั้งหมดอาจจะเรียกอีกอย่างว่า Soft Intents ในด้านการประยุกต์ Softgoal interdependency graph ได้ถูกใช้เพื่อทำให้ความขัดแย้งเห็นภาพได้ชัดเจนขึ้น ดังนั้นการนำ TRIZ มาใช้สามารถที่จะช่วยแก้ปัญหาความต้องการที่ขัดแย้งได้ดี และถ้าสถาปัตยกรรมนั้นๆ ใช้ความรู้อื่นๆ ของวิศวกรรมเครื่องกล เราสามารถเรียนรู้วิธีการประยุกต์ TRIZ ให้เหมาะสมกับงานนั้นๆ อีกด้วย

สำหรับผมการพัฒนาซอฟต์แวร์บนอินเทอร์เน็ตก็ใช้หลักการเดี๋ยวกันกับการพัฒนาซอฟต์แวร์ จะแตกต่างกันก็ตรงที่ซอฟต์แวร์บนอินเทอร์เน็ตมีศักยภาพที่จะมีคนทดสอบและใช้งานมากกว่าซอฟต์แวร์ทั่วไป เพราะซอฟต์แวร์บนอินเทอร์เน็ตไม่ได้ยึดติดกับแพลตฟอร์ม เราสามารถใช้งานจากเว็บบราวเซอร์และโปรแกรมต่างค่ายกันใดๆ ก็ได้ ไม่ว่าจะเป็น IE บนวินโดวส์, Firefox บน Linux หรือ mail client บน UNIX อย่าง Solaris ซึ่งมันก็คือระบบเปิดที่กล่าวถึงในบทความ ดังนั้นจึงเหมือนกับที่ผู้เขียนกล่าวไว้คือ เมื่อการพัฒนาซอฟต์แวร์เริ่มซับซ้อนขึ้นเรื่อยๆ เราจะมุ่งสู่ระบบเปิดเพื่อทำให้ทุกคนสามารถเข้ามามีส่วนร่วมในสังคมซอฟต์แวร์ได้ ส่วนกระบวนการพัฒนาที่อิงไปกับโมเดลหรือเฟรมเวิร์คต่างๆ ก็มีวัตถุประสงค์ให้ทุกคนปฏิบัติตามมาตรฐานเดียวเพื่อให้ผู้ดูแลโปรเจคสามารถทำงานได้สะดวกยิ่งขึ้น ดังนั้นการนำเอา TRIZ มาใช้สำหรับสร้างสถาปัตยกรรมใหม่จึงมีความเป็นไปได้ แต่ไม่ใช่เรื่องง่าย และอาจจะไม่มีคุณค่าเชิงพาณิชย์ ดังที่ผู้เขียนได้เกริ่นไว้ในช่วงต้นว่าควรจะเอากระบวนการของ Genrich Altshuller มาวิเคราะห์สิทธิบัตรด้านวิศวกรรมซอฟต์แวร์เพื่อพัฒนาหลักการใหม่ที่มีประโยชน์เทียบเท่ากับหลักการปัจจุบันที่ใช้อยู่จะดีกว่า เพราะการนำศาสตร์ที่ใช้ในแขนงหนึ่ง (กลศาสตร์) มาประยุกต์ใช้กับศาสตร์อีกแขนงหนึ่ง (ซอฟต์แวร์) แม้จะทำได้ก็อาจจะต้องแปลความผลลัพธ์ที่ได้มาอีก ทำให้การทำงานซับซ้อนและเสียเวลามากขึ้น แล้วคุณหละคิดอย่างไร How do u think?

บันทึกนี้เขียนที่ GotoKnow โดย  ใน How do u think?



ความเห็น (2)

เขียนเมื่อ 

แนะนำเว็บไซต์อ้างอิงเพิ่มเติมครับ

http://www.trizthailand.com/
http://gotoknow.org/blog/TRIZ

Trizit Benjaboonyazit
IP: xxx.25.75.140
เขียนเมื่อ