Generic View of Process มาตรฐานวุฒิภาวะความสามารถระดับองค์กร CMM : The Capability Maturity Model คือ แบบจำลองมาตรฐานที่แสดงวุฒิภาวะความสามารถระดับองค์กร มีชื่อเรียกอีกอย่างหนึ่งว่า SW-CMM (The Capability Maturity Model for Software) ถือกำเนิดจาก Software Engineering Institute (SEI) ของมหาวิทยาลัยคาร์เนกี เมลลอน (Carnegie Mellon University) เป็นมาตรฐานที่กำหนดขึ้นเพื่อวัดคุณภาพและสร้างความเชื่อมั่นในกระบวนการพัฒนาซอฟต์แวร์ของบริษัทพัฒนาซอฟต์แวร์ (Software House)

Generic View of Process ลักษณะของมาตรฐาน CMM มาตรฐานCMM จัดเป็นมาตรฐานที่ได้รับความนิยมระดับสากลในเรื่องของซอฟต์แวร์ที่บริษัทพัฒนาซอฟต์แวร์ สามารถนำไปใช้ เพื่อเป็นแนวทางในการปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ โดยมาตรฐาน CMM แบ่งระดับความสามารถในการพัฒนาซอฟต์แวร์ของบริษัทผู้พัฒนาซอฟต์แวร์ไว้ 5 ระดับ ดังนี้ ความเจริญเติบโตของกระบวนการ 5 ระดับ (แบบขั้นบันได)

Generic View of Process ระดับเริ่มต้น เรียกว่า Initial Level เป็นการพัฒนาเพียงด้านเดียว เป็นระดับที่บริษัทพัฒนาซอฟต์แวร์ต้องอาศัย ความสามารถของบุคลากรเพียงอย่างเดียว ลักษณะการทำงานไม่เป็นทางการมากนัก ยังไม่การควบคุมที่ดี ไม่มีการวางแผนงานที่เป็นระบบ จึงไม่สามารถประเมินคุณภาพของผลงานที่ได้ว่าจะมีคุณภาพดีหรือไม่ และซอฟต์แวร์ที่พัฒนาขึ้นส่วนใหญ่ไม่มีการนำไปพัฒนาต่อ ระดับจัดทำโครงการเบื้องต้น เรียกว่า Repeatable Level ในระดับนี้มีการนำการบริหารการจัดการโครงการเบื้องต้น (Basic Project Management) มาใช้ มีการวางแผนการทำงานอย่างเป็นระบบ มีการจัดทำเอกสาร และสามารถตรวจสอบได้ บริษัทผู้พัฒนาซอฟต์แวร์ที่สามารถเข้าสู่ระดับนี้ได้ จะสามารถพัฒนาซอฟต์แวร์ในแต่ละโครงการที่มีลักษณะแบบเดียวกันให้ประสบผลสำเร็จได้เช่นเดียวกับโครงการที่ทำสำเร็จไปแล้ว

Generic View of Process ระดับที่มีการกำหนดขึ้นอย่างชัดเจน เรียกว่า Defined Level ในระดับนี้เป็นการพัฒนาเพิ่มขึ้นจาก Repeatable Level การเข้าสู่ระดับบริษัทผู้พัฒนาซอฟต์แวร์จะต้องมีการกำหนดแนวทางในการปฏิบัติงานด้านการจัดทำเอกสารและกำหนดมาตรฐานในการปฏิบัติงาน ทั้งในส่วนของการบริหารโครงการ และด้านการพัฒนาซอฟต์แวร์ ได้อย่างเหมาะสม ระดับมีการจัดการ เรียกว่า Managed Level เป็นการพัฒนาเพิ่มขึ้นจาก Defined Level ลักษณะการปฏิบัติในระดับนี้ผู้จัดทำต้องมีการรวบรวมข้อมูล รายละเอียดการปฏิบัติงานต่างๆ ที่เกิดขึ้นไว้ในรูปของสถิติ (Statistical Process Control) เพื่อนำข้อมูลนั้นมาใช้ในการศึกษาวิเคราะห์ผลการทำงาน สามารถวัดผล และควบคุมกระบวนการทางซอฟต์แวร์ได้ ระดับปรับปรุงให้เหมาะสมที่สุด เรียกว่า Optimizing Level เป็นระดับที่ได้นำเอาหลักการจัดการคุณภาพ(Continuous Process Improvement) มาใช้ เพื่อป้องกันไม่ให้เกิดข้อบกพร่องในการปฏิบัติงาน และนำไปสู่การพัฒนาอย่างต่อเนื่อง รวมถึงเพื่อให้บริษัทผู้พัฒนาซอฟต์แวร์สามารถปรับเปลี่ยนตัวเองให้สอดคล้องกับการเปลี่ยนแปลงทางด้านเทคโนโลยีได้

Generic View of Process CMM มีประโยชน์อย่างไร ? การทำงานเป็นระบบมากขึ้น ทุกขั้นตอนต้องการจดบันทึกรายละเอียดระหว่างการทำงานไว้เป็นเอกสาร หรือมีหลักฐานการทำงานที่ตรวจสอบได้โดยง่าย เช่น การบันทึกการเจรจากับลูกค้า เมื่อการทำงานเป็นระบบโอกาสที่จะประสบผลสำเร็จในการทำงานก็มากขึ้น เป็นการสร้างชื่อเสียงให้หน่วยงานได้ และสร้างโอกาสในการรับงานจากลูกค้าเพิ่มขึ้นด้วย การทำงานของหน่วยงานจะมีวัฒนธรรมการทำงานที่เป็นแบบเดียวกัน มีวิธีการปฏิบัติที่เป็นมาตรฐาน ที่สามารถยืดหยุ่น และปรับตัวให้เข้ากับความเปลี่ยนแปลงได้ตลอดเวลา ผู้บริหารมองเห็นสภาพการปฏิบัติงานของโครงการ ที่เป็นนามธรรมได้อย่างชัดเจน สามารถแก้ปัญหาที่เกิดขึ้นแล้วได้อย่างมีประสิทธิภาพ และสามารถเตรียมตัวแก้ปัญหาที่อาจจะเกิดในอนาคตได้เป็นอย่างดีด้วย ประโยชน์ต่อประเทศชาติ หากไทยสามารถพัฒนาบริษัทซอฟต์แวร์ไทย ให้มีวุฒิภาวะความสามารถมากขึ้น จะสามารถรับงานจากต่างประเทศ และทำรายได้เข้าประเทศได้อีกมาก

Generic View of Process กระบวนการซอฟต์แวร์ส่วนบุคคล กระบวนการพัฒนาซอฟต์แวร์สำหรับบุคคล (Personal Software Process: PSP) คือ แบบจำลองกระบวนการจัดการซอฟต์แวร์ที่ถูกพัฒนาโดย Watts S. Humphrey และ สถาบันวิศวกรรมซอฟต์แวร์ (Software Engineering Institute : SEI) มีเป้าหมายใน การจัดระเบียบของวิศวกรซอฟต์แวร์เพื่อจะรับประกันกระบวนการพัฒนาซอฟต์แวร์ process improvement cycle: 1. สร้างความเข้าใจในสถานะกระบวนการพัฒนาปัจจุบัน หรือกระบวนการที่ผ่านมาแล้ว 2. สร้างวิสัยทัศน์ และแรงจูงใจที่ดีในกระบวนการพัฒนา 3. กำหนดรายการของกระบวนการกิจกรรมที่จำเป็นและดีต่อการพัฒนา โดยจัดลำดับ กิจกรรมตามความสำคัญ 4. ผลิตคิดค้นแผนที่จะทำให้กิจกรรมประสบความสำเร็จ 5. จัดการทรัพยากรที่ต้องดำเนินการตามแผนงาน 6. เริ่มดำเนินการข้อ 1 ใหม่ คือ แบบจำลองกระบวนการจัดการซอฟต์แวร์ที่ถูกพัฒนาโดย Watts S. Humphrey และ สถาบันวิศวกรรมซอฟต์แวร์ (Software Engineering Institute : SEI) มีเป้าหมายใน การจัดระเบียบของวิศวกรซอฟต์แวร์เพื่อจะรับประกันกระบวนการพัฒนาซอฟต์แวร์ CMM : มุ่งเน้นการพัฒนาความสามารถในระดับองค์กร PSP : มุ่งเน้นการพัฒนาคุณภาพที่ตัวของวิศวกรเป็นรายบุคคล เพื่อลดข้อบกพร่อง (defect) เพิ่มทักษะในการวางแผนและการประมาณค่า (planning and estimation) ซอฟต์แวร์ ดังนั้น จึงต้องมีการปรับเปลี่ยนกระบวนการที่ไม่มีประสิทธิภาพส่วนบุคคลนั้นให้ดีขึ้น ด้วย กระบวนการซอฟต์แวร์ส่วนบุคคล นักพัฒนาซอฟต์แวร์ทุกคนต่างใช้กระบวนการบางอย่างในการสร้างซอฟต์แวร์คอมพิวเตอร์ ถึงแม้ว่า กระบวนการอาจเป็นแบบส่งเดช ตามความพอใจ เปลี่ยนแปลงได้ ซึ่งบางคนอาจไม่มีประสิทธิภาพ / ประสิทธิผล หรือ อาจไม่ประสบความสำเร็จ แต่ก็ถือเป็นกระบวนการ CMM : มุ่งเน้นการพัฒนาความสามารถในระดับองค์กร PSP : มุ่งเน้นการพัฒนาคุณภาพที่ตัวของวิศวกรเป็นรายบุคคล เพื่อลดข้อบกพร่อง

Generic View of Process แบบจำลองปรับปรุงกระบวนการพัฒนาซอฟต์แวร์สำหรับบุคคล (PSP Step) Watts S. Humphery ได้กล่าวว่าการปรับเปลี่ยนทำให้เกิดประสิทธิภาพส่วนบุคคลต้องผ่านขั้นตอน 4 ระยะ โดยแต่ละระยะต้องมีการฝึกอบรมและใช้เครื่องมือช่วยอย่าง ระมัดระวัง เพราะกระบวนการนี้ให้ความสำคัญกับการวัดส่วนบุคคลด้านการผลิตชิ้นงาน และคุณภาพของผลงาน PSP0 : The Baseline Personal Process PSP1 : Personal Process Management PSP2 : Personal Quality Management PSP3 : Cyclic Personal Process

Generic View of Process PSP Step ขั้นตอนนี้แนะนำและแสดงพื้นฐานเริ่มต้นวัดขนาด เวลา และข้อมูลที่เกี่ยวข้องในระบบ โดยระดับนี้นักวิศวกรต้องแบ่งงานเป็น 3 ส่วน และดำเนินการวิธีร่วมกันตามกรอบงาน 6 กิจกรรม ดังรูปด้านข้างนี้ Postmorte : การตรวจสอบ

Generic View of Process กระบวนการซอฟต์แวร์ส่วนบุคคล ข้อดีจากการใช้ PSP ประมาณขนาดของซอฟต์แวร์แม่นยำขึ้น 2.5 เท่า การประมาณแรงงานแม่นยำขึ้น 1.75 เท่า คุณภาพของกระบวนการ จำนวนของข้อบกพร่องที่ถูกค้นพบก่อนการคอมไฟล์โปรแกรม เพิ่มขึ้น 50% คุณภาพของผลิตภัณฑ์ สามารถค้นพบข้อบกพร่องขณะ ทำ Unit Test พัฒนามากขึ้น 2.5 เท่า การเพิ่มผลิตภาพส่วนบุคคล (Personal Productivity) โดยดูจากค่า LOC/HOUR ได้ข้อสรุปว่า PSP ไม่ได้ส่งผลให้ค่า Productivity สูงขึ้น

Generic View of Process กระบวนการซอฟต์แวร์ส่วนบุคคล ข้อด้อยจากการใช้ PSP ต้นทุนค่าใช้จ่ายที่เพิ่มขึ้น ได้แก่ ค่าฝึกอบรม เวลาที่ใช้ในการเรียนรู้ และทดลองใช้ ความเสี่ยงอัตตาของนักพัฒนาซอฟต์แวร์ และสภาพอารมณ์ที่จะคงรักษาวินัยการพัฒนาซอฟต์แวร์นี้ไว้ การไม่ชอบการบันทึกข้อมูล รู้สึกเป็นภาระ การไม่ชอบแบบฟอร์ม แม่แบบ อึดอัดกับการยึดติดกับมาตรฐานการทำงาน ไม่ค่อยมีเครื่องมือที่ช่วยกระบวนการ PSP

Generic View of Process กระบวนการพัฒนาซอฟต์แวร์สำหรับทีม (Team Software Process: TSP) Watts S. Humphrey ได้ขยายแนวคิดของ PSP เนื่องจากโครงการซอฟต์แวร์ในระดับอุตสาหกรรมต้องเกี่ยวข้องกับผู้ประกอบการหลายฝ่ายมาเป็นกระบวนการซอฟต์แวร์แบบทีม (Team Software Process: TSP) โดยมีเป้าหมายเพื่อสร้างทีโครงการแบบ “บริหารจัดการด้วยตนเอง (Self-directed)” คือ สามารถจัดระเบียบและบริหาร เพื่อให้ได้ซอฟต์แวร์คุณภาพสูงด้วยตนเอง โดยกำหนดวัตถุประสงค์ของ TSP ไว้ดังนี้ 1. สร้างทีมที่บริหารจัดการด้วยตนเอง ซึ่งวางแผนและตรวจตรางาน สร้างเป้าหมาย และเป็นเจ้าของกระบวนการและแผนต่าง ๆ 2. แสดงให้เห็นถึงการแนะนำและกระตุ้นทีม เพื่อช่วยรักษาระดับการทำงานที่ดี 3. เริ่มการปรับปรุงกระบวนการซอฟต์แวร์ โดยมุ่งเน้นตามมาตรฐาน CMM 4. กำหนดแนวทางในการปรับปรุงองค์กรที่มีความครบถ้วนสูง 5. ช่วยให้เกิดการถ่ายทอดด้านทักษะของทีมระดับอุตสาหกรรม

Generic View of Process การวัดระดับของโครงงานซอฟต์แวร์ การวัดระดับความยากง่ายของโครงงานซอฟต์แวร์โดยพิจารณาจากคุณลักษณะ และแบ่ง ออกเป็น 3 ระดับ คือ ระดับต่ำ (low) ระดับกลาง (medium) และระดับสูง (hign) Characteristic Low Moderate High Number of functions performed Small Medium Large Novelty of function Standard application Similar to existing system but with a Few new functions New Theory or approach; never been built before Number of users requiring multi-user or concurrent access 1 Several Many Multi-tasking No Some Yes Interactive VS. Batch Processing Batch or minimal interactive Highly interactive จำนวนของงานที่ทำในระบบ ทฤษฎีใหม่ ๆ หรือวิธีการใหม่ ๆ ที่ไม่คุ้ยเคยหรือสร้างมาก่อน มีจำนวนผู้ใช้ในระบบมาก / มีการประมวลผลแบบพร้อมกัน สามารถประมวลผลได้มากกว่า 1 โปรแกรม ต้องการการตอบสนองกับผู้ใช้แบบใด (ทันที หรือกลุ่ม)

Generic View of Process เวลาที่ใช้ในการตอบสนองที่ยอมรับของผู้ใช้งาน การวัดระดับของโครงงานซอฟต์แวร์ (ต่อ) Characteristic Low Moderate High Response-time requirement Off-line; Non-critical Interactive; Moderate response time acceptable Real-time Need for distributed processing None 2 computers 3 or more computers Amount of data stored Will fit on single disk Requires 2 or more disk Requires system to manage disk access Structure of data Simple data relationships Moderately complex relationships Highly complex relationships Accuracy of data Low degree Moderate degree degree มีความจำเป็นต้องใช้ตัวประมวลผลหลายๆ ตัวเพื่อการทำงาน จำนวนที่จัดเก็บมากน้อยขนาดไหน โครงสร้างของข้อมูลแตกต่างกัน มีความสัมพันธ์ของข้อมูลซับซ้อน ระบบต้องการความถูกต้องของข้อมูล

Generic View of Process ขนาดของรายการที่ติดต่อระหว่างกันมีขนาดไหน การวัดระดับของโครงงานซอฟต์แวร์ (ต่อ) การประมวลผลติดต่อกันในระยะไหน Characteristic Low Moderate High Transaction size Small Medium Large Remote VS. Local Local only Remote Remote access Criticality Can tolerance Tolerance of downtime Several hours of downtime Short periods of downtime No downtime Security needs None Interaction with other systems Some but well-defined Much; possible parallel development Number of phases of development Few Many Need for manual Override No Yes ระบบมีความสำคัญมากน้อยขนาดใหญ่ วิกฤตระดับใด หากระบบเกิดล่ม ยอมรับได้ในระดับใด ต้องใช้ระดับการป้องกันรักษาข้อมูลระดับใด จำนวนระยะของการพัฒนาระบบ มีการติดต่อกับระบบอื่น ๆ หรือไม่ มีการต่อต้าน/ไม่ให้ความร่วมมือของลูกค้า

Generic View of Process การวัดระดับของโครงงานซอฟต์แวร์ (ต่อ) Characteristic Low Moderate High Dependence on hardware Independent of hardware Some Tied to specific hardware constraints Stability of specification Fixed customer requirements Some changes may occur Frequent changes in specification User Sophistication Familiarity with automated system Some familiarity with automated system Naïve Developer sophistication Has developed similar system with similar tools Experience with tools, not with application No experience ความอิสระในการกำหนด HW เสถียรภาพในการกำหนดความต้องการของลูกค้า ประสบการณ์ของผู้ใช้ระบบ ประสบการณ์ของผู้พัฒนาระบบ