Statistic Process Control Techiques to Software development process

Proceeding at: International conference on software engineering 28th (ICSE 2006)

Author :

Mutsumi Komuro
Hitachi Software Eng.
4-12-7 Higashishinagawa
Shinagawa-ku Tokyo, Japan
+81-3-5780-2085
komuro@hitachisoft.jp

paper นี้จะนำประสบการณ์ในการใช้เทคนิค SPC ในกระบวนการพัฒนาซอฟต์แวร์ แสดงตัวอย่างการใช้ SPC ใน Hitachi Software, การวัดผล(measures),กราฟที่ใช้ในการควบคุม (control chart), วิเคราะห์การประเมินผล (analysis judgment) มีการอธิบายลักษณะเฉพาะ (characteristic) ในแต่ละกระบวนการพัฒนาที่มีผลต่อ SPC จากการศึกษาเรียนรู้

Key word :

Statistical Process Control, Peer Review, Effect Analysis, Statistical Analysis

ที่มา

SPC (Statistic Process Control ) เป็นวิธีที่นำมาจัดการกับ process โดยใช้หลักการวิเคราะห์ทางสถิติ (statistical analysis) ประกอบด้วย การกำหนด, การวัด, การควบคุม และการพัฒนา process จึงเป็นที่รู้จักว่าเป็นเครื่องมือที่มีความสามารถในการพัฒนากระบวนการให้ยกระดับคุณภาพและ เพิ่มความสามารถในการผลิต

SPC เป็น TQM ในอุตสาหกรรมการผลิตที่ญี่ปุ่น ที่ถูกนำมาพิจารณาเป็นปัจจัยหลัก จึงทำให้

ในประเทศญี่ปุ่นมีหลายโรงงานอุตสาหกรรมได้นำ TQM (Tatal Quality Management) มาใช้กับสินค้า และ์ประสบความสำเร็จ ถึงแม้ว่าหลายบริษัท์ได้พยายามที่จะนำ CMM และ CMMI ซึ่งมีแนวทางมาจาก TQM (are much influnced by TQM) มาใช้ในกระบวนการพัฒนาซอฟต์แวร์ แต่บริษัทที่ประสบความสำเร็จในการนำ SPC ไปใช้มีจำนวนไม่มาก

ข้อแตกต่างระหว่างอุตสาหกรรมการผลิตและกระบวนการผลิตซอฟต์แวร์คือ human-intensive and creative มากขึ้น เนื่องจากแต่ละการพัฒนาซอฟต์แวร์มีลักษณะเฉพาะ (unique characteristic) และความสามารถหลากหลายต่างกันออกไป ดังนั้นเค้าจึงมีการกำหนดข้อมูลต่างๆก่อนการใช้ SPC ตัวอย่างเช่น มี 25 process areas ใน CMMI ซึ่ง 21 PA จะถูกระบุไว้ที่ maturity level 2 และ 3 และมีเพียง 4 PA ที่เหลือจะอยู่ในส่วนของ level 4 และ 5 ซึ่งเทคนิค SPC จะเข้ามาช่วยสนับสนุน

TQM จะมี 7 เครื่องมือเป็นพื้นฐาน ที่ใช้่ในการวิเคราะห์ทางสถิติ โดยมี control chart สำคัญที่สุด

กิจกรรมที่เป็นตัวอย่าง ในการใช้เทคนิค SCP ได้แก่

1. ค้นหาสถานการณ์ที่อยู่นอกการควบคุม (out-of-control) ภายใต้ขอบเขตที่กำหนด (control limit) หรือความสัมพันธ์ของรูปแบบที่ไม่แน่นอน ถูกแสดงบน control chart
2. การวิเคราะห์หาต้นเหตุที่ทำให้เกิดสถานการณ์ out-of-control
3. การทำให้กระบวนการคงที่ โดยกำจัดสิ่งที่เป็นต้นเหตุออก

การนำไปใช้ในองค์กร

paper นี้อธิบายประสบการณ์ที่ได้นำเทคนิค SPC ไปใช้ใน Hitachi Software Engineering (HSE) ซึ่งมีการพัฒนาซอฟต์แวร์หลายชนิด ขึ้นอยู่กับลูกค้าจำนวนมาก โดยเริ่มมีการพัฒนา process ตั้งแต่ปี 1970

HSE ใช้โมเดลของ CMMI มาจัดการเรื่อง process ตั้งแต่ปี 2001 ซึ่ง HSE แบ่งเป็น 4 กลุ่มหลัก และทุกกลุ่มได้รับ CMMI Level 3 โดย 1 ใน 4 ที่ชื่อว่า ISG (Industrial System group) ได้รับ Level 5 ในปี 2004 ซึ่งประสบการณ์ส่วนมากจะนำมาจาก ISG ที่นำ SPC มาเริ่มต้นในกระบวนการพัฒนา

ISG เป็นกลุ่ม พัฒนาและให้ infomation system และ service สำหรับผู้ผลิตกลุ่มอุตสาหกรรมและกลุ่มกระจายสินค้า รวมไปถึงระบบ embeded system และ information appliance

ความยากในการใช้ SPC เพื่อกระบวนการพัฒนาซอฟต์แวร์

SPC ใช้ในกระบวนการในการพัฒนาซอฟต์แวร์หลายกระบวนการ ได้แก่ การติดตาม (monitor) และการควบคุม (control), peer review และ test process โดยเน้นด้าน process-centric มากกว่า product-centric

ในญี่ปุ่น SPC หรือ TQM เป็นเครื่องมือที่ช่วยยกระดับคุณภาพสินค้าในกลุ่มโรงงานอุตสาหกรรมแต่ไม่นิยมนำมาใช้ในกลุ่มอุตสาหกรรมซอฟต์แวร์ ซึ่ง Kan ได้ชี้ แจงว่า application ที่ใช้ SPC มีความซับซ้อนทำให้ยาก และมีผลกระทบต่อคน (creativity) ในทางตรงกันข้าม Florac และ Carleton ให้ความสำคัญกับคน เครื่องมือ วัตถุดิบ และพลังงาน ในการกำหนดเข้ากับ process ซึ่งความยากนั้นมาจาก characteristic ของกระบวนการในการพัฒนาซอฟต์แวร์

characteristic ของกระบวนการในการพัฒนาซอฟต์แวร์

1. Haman-intensive & Creative : กระบวนการพัฒนาซอฟต์แวร์จะเน้นไปทางกิจกรรมที่เกี่ยวข้องกับคนและงานด้านความคิดสร้างสรรค์(creativity) มากกว่ากระบวนการการผลิต ดังนั้นผลของการวัดกระบวนการพัฒนาซอฟต์แวร์จะไม่คงที่ ซึ่งต่อไปจะปรับปรุงให้คงที่
2. Involve multiple common cause : มีปัจจัยจำนวนมากที่มีผลต่อ performance ของ process ปัจจัยนี้ได้แก่ tools, method, ชนิดของซอฟต์แวร์ และสภาพแวดล้อมในการพัฒนา
3. Hard to optain set of homogeneous data : ยากที่จะจัดการข้อมูลที่มีความหลากหลายเป็นจำนวนมาก และมีผลต่อมูลค่าทางธุรกิจ ซึ่งกระบวนการพัฒนามีหลาย department ที่ต้องที่ต้องผลิตเป็นประจำทุกวันและได้ผลลัพธ์ออกมาเหมือนเดิม ดังนั้นจะเกิดความยากในการกลุ่มข้อมูลที่หลากหลาย

ซึ่ง characteristic ทั้งหมดนี้จะใช้ SPC เป็นแนวทางในการพัฒนา process และทำให้คงที่

นำเสนอประสบการณ์

เทคนิค SPC ได้เลือก process อะไรในกระบวนการพัฒนา ที่เกี่ยวข้องกับ bussiness goal :

ได้ใช้ test process มาตรวจสอบ work product เหมือนกระบวนในอุตสาหกรรมการผลิต

HSE ใช้ matric หลากหลายในกระบวนการทดสอบ (testing process) ได้แก่ bug rate และ test progress S curve

• Bug rate : แสดงอัตราการเิกิดข้อผิดพลาด
• test progress S curve : ทดสอบความก้าวหน้าโดยใชกราฟ S Curve แสดง test case ที่เพิ่มขึ้น

โดยการศึกษาเบื้องต้น ได้สร้าง baseline ของ bug rate ซึ่งเดิมจะมีค่า objective value ในแต่ละส่วนอยู่แล้ว ซึ่งแต่ละส่วนมีลูกค้าและ environment แตกต่างกัน ดังนั้นการสร้าง baseline ต้องใช้ control chart ช่วย เพื่อหาข้อมูลที่ out-of-control โดยดูจาก bug rate ในขั้นตอนการ test ดูจาก Z-chart

สรุปว่า : จากกราฟ bug ที่เกิดขึ้นนั้น จะแก้ไขได้ควรคำนึงที่ขั้นตอนก่อนการ testing ได้แ่ก่ requirement, design, review

ส่วนการวิเคราะห์อื่นๆ ได้แก่การแสดงความสัมพันธ์ระหว่างเฟสที่มีการกำจัดข้อผิดพลาดออกไปแล้วกับคุณภาพที่ได้ โดย HSE ใช้ Matric เป็นตัววัด source code ที่เรียกว่า called early code detection rate (เป็นการกำหนดเปอร์เซ็นต์ที่จะเกิด bug ก่อนการ test)

ได้ผลลัพธ์ว่า ถ้าค่าของ "called early code detection rate" เรากำหนดไว้สูง ค่า "bug rate" ที่เกิดจะต่ำ เนื่องจากได้มีการแก้ไข bug เข้าไปก่อนเฟลการ test โดยการทำ peer review ซึ่งทำให้คุณภาพของ product สูงขึ้น

Peer review เป็นกระบวนการที่นำมาปรับปรุงคุณภาพในกระบวนการพัฒนาซอฟต์แวร์ และ SPC ได้นำมาใช้งาน

โดย peer review ได้นำมาเป็นตัวรับรองคุณภาพของ work product ตลอดจน scep. doc. และ source code และการ monitor และ control กระบวนการ peer review ได้แก่

1. review speed
2. defect density
3. Earky bug detection rate
4. review effiency

โดย 1-3 : เป็นตัววัดการควบคุม ซึ่งมีการแสดงผลออกมาในรูปแบบของ XmR^? และ Z control chart

และ 4. เป็นตัววัดกระบวนการ ซึ่งวิเคราะห์จาก XmR^? chart โดยใช้การทดสอบ 4 แบบ

เอกสารนำเสนอ

• Statistic_Process_Control_Techniques_to.pdf