1 / 27

Capability Maturity Model (CMM)

Capability Maturity Model (CMM).

Download Presentation

Capability Maturity Model (CMM)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Capability Maturity Model (CMM)

  2. CMM เป็นมาตรฐานระดับโลกในเรื่องของซอฟต์แวร์ที่บริษัทพัฒนาซอฟต์แวร์ (Software House) สามารถนำไปใช้ เพื่อเป็นแนวทางในการปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ โดยมาตรฐาน CMM ถือกำเนิดขึ้นจาก Software Engineering Institute (SEI) ของมหาวิทยาลัย Carnegie Mellon ซึ่งเป็นมหาวิทยาลัยที่ได้รับการยอมรับในระดับสากล ว่ามีชื่อเสียงด้านวิศวกรรมคอมพิวเตอร์ระดับโลกดังนั้นมาตรฐาน CMM จึงเป็นมาตรฐานที่ดีที่สุดและเป็นที่ยอมรับมากที่สุดสำหรับการพัฒนาซอฟต์แวร์ในระดับสากล

  3. มาตรฐาน CMM จะแบ่งการพัฒนาซอฟต์แวร์ออกเป็น 5 ระดับ คือ ระดับที่ 1 ระดับตั้งต้น (Initial level) ระดับที่ 2 ระดับทำซ้ำได้ (Repeatable level) ระดับที่ 3 ระดับชัดเจน (Defined Level) ระดับที่ 4 ระดับจัดการ (Managed Level) ระดับที่ 5 ระดับเหมาะที่สุด (Optimizing Level)

  4. ระดับที่ 1 ระดับตั้งต้น (Initial level) จะมุ่งเน้นไปที่การพัฒนางานให้ลุล่วงเพียงอย่างเดียว หน่วยงานยังมีความยากลำบากในการจัดกระบวนการซอฟต์แวร์ที่เป็นระบบ ส่งผลให้เกิดวิกฤติการณ์ในการทำงานอยู่เสมอ ความสำเร็จของการพัฒนาซอฟตแวร์ในระดับนี้ขึ้นอยู่กับประสบการณ์และความ สามารถของหัวหน้าโครงการแต่มักจะประสบกับปัญหายุ่งเหยิง และการพัฒนาซอฟต์แวร์มักจะใช้เวลาและงบประมาณเกินที่กำหนดไว้ อาจกล่าวได้ว่าความสามารถที่ระดับนี้เป็นความสามารถของบุคคลมากกว่าของ องค์การ

  5. CMM Level 1 มีลักษณะการพัฒนาซอฟต์แวร์ ดังนี้ มี Process ที่ระบุไม่ได้ (ไม่มีกระบวนการพัฒนาซอฟต์แวร์ที่เป็นระบบ) มีแค่ Input และ Output เท่านั้น ขอให้งานออกมาก็พอ ขึ้นอยู่กับหัวหน้างานอย่างเดียว มีแนวคิดแค่ว่า เงินมาก งานดี งานไม่รู้ว่าจะออกมาดีหรือไม่ ต้องรอผลที่เสร็จแล้วเท่านั้น

  6. ระดับที่ 2 ระดับทำซ้ำได้ (Repeatable level) มีการกำหนดขั้นตอนการนำนโยบายไปใช้มีการนำการบริหารการจัดการโครงการเบื้องต้น (Basic Project Management) จะมีการจัดทำเอกสารอย่างเป็นขั้นตอน และจะสามารถตรวจสอบได้ กระบวนการที่ได้ผลมีลักษณะเป็นงานที่มีการจัดทำเอกสาร ควบคุม มีการฝึกอบรม มีการวัดผล และ สามารถปรับปรุงให้ดีขึ้นได้ เราอาจกล่าวได้ว่าลักษณะของระดับนี้ก็คือใช้ผลสำเร็จของโครงการที่ผ่านมา เป็นตัวอย่าง มีการกำหนดมาตรฐานโครงการ และมีการจัดรูปแบบองค์กรให้งานโครงการดำเนินไปได้ดี

  7. CMM Level 2 มีลักษณะการพัฒนาซอฟต์แวร์ ดังนี้ มี Process ที่ระบุได้ (มีกระบวนการพัฒนาซอฟต์แวร์ที่เป็นระบบ) มีวิธีการตรวจสอบการพัฒนาซอฟต์แวร์ มีหน่วยงานอิสระที่ควบคุมคุณภาพ มีมาตรฐานในการจัดเก็บซอฟต์แวร์ มีการทำเอกสารต่าง ๆ มีการวางแผนการพัฒนาซอฟต์แวร์

  8. ระดับที่ 3 ระดับชัดเจน (Defined Level) จะมีการบันทึกทำเอกสารเกี่ยวกับกระบวนการมาตรฐานในการพัฒนาและบำรุงรักษา ซอฟต์แวร์เอาไว้ อีกทั้งยังมีการทำเอกสารเกี่ยวกับงานวิศวกรรมซอฟต์แวร์และกระบวนการจัดการ ต่าง ๆโครงการต่าง ๆ ที่ทำในระดับนี้จะช่วยให้หน่วยงานปรับเปลี่ยนกระบวนการซอฟต์แวร์ของตนตาม ลักษณะพิเศษของโครงการได้ กระบวนการซอฟต์แวร์ที่ปรับเปลี่ยนแล้วนี้ ทาง CMM เรียกว่ากระบวนการซอฟต์แวร์ที่ชัดเจน (Defined software process)

  9. กระบวนการซอฟต์แวร์ที่ชัดเจนจะต้องมีกระบวนการทางวิศวกรรมซอฟต์แวร์และ กระบวนการจัดการที่แจ่มชัดด้วย และจะแสดงได้ด้วยการมีเงื่อนไขที่ชัดเจน มีมาตรฐานและวิธีการสำหรับทำงานต่าง ๆ มีกลไกในการตรวจสอบ มีการกำหนดผลลัพธ์ และ เงื่อนไขการจบโครงการ

  10. ระดับที่ 4 ระดับจัดการ (Managed Level) หน่วยงานที่สามารถวัดผลและพยากรณ์ผลที่จะเกิดในการทำงานโครงการซอฟต์แวร์ได้ อย่างแม่นยำ สามารถพยากรณ์แนวโน้มและคุณภาพของซอฟต์แวร์ได้ดี ในเมื่อสภาวะการทำงานค่อนข้างลงตัว เมื่อมีโครงการแปลกๆเข้ามาให้ทำ หน่วยงานก็สามารถปรับกระบวนการได้เป็นอย่างดี

  11. ระดับที่ 5 ระดับเหมาะที่สุด (Optimizing Level) หน่วยงานที่อยู่ในระดับนี้เป็นหน่วยงานที่เน้นในด้านการปรับปรุงกระบวนการอยู่ตลอดเวลา โดยมีเป้าหมายในการป้องกันไม่ให้เกิดข้อบกพร่องขึ้น หน่วยงานใช้ข้อมูลเกี่ยวกับประสิทธิผลของกระบวนการซอฟต์แวร์ในเชิงวิเคราะห์ ต้นทุนและกำไรของเทคโนโลยีใหม่ๆ เพื่อใช้เสนอการเปลี่ยนแปลงกระบวนการซอฟต์แวร์ของหน่วยงาน มีการกำหนดว่าวัตกรรมใดเหมาะที่สุดสำหรับหน่วยงานทีมงานซอฟต์แวร์ในระดับนี้ทำหน้าที่วิเคราะห์ข้อบกพร่องเพื่อหาสาเหตุ มีการประเมินกระบวนการซอฟต์แวร์เพื่อป้องกันไม่ให้เกิดข้อบกพร่องซ้ำอีก

  12. กลุ่มกระบวนการหลัก (Key Process Area หรือ KPA) สถาบัน SEI ได้กำหนดกลุ่มกระบวนการหลัก (Key Process Area หรือ KPA) สำหรับระดับความสามารถแต่ละระดับเอาไว้ด้วย กลุ่มกระบวนการหลักเหล่านี้ใช้อธิบายฟังก์ชันต่าง ๆ ทางด้านวิศวกรรมซอฟต์แวร์ที่จะต้องมีในแต่ละระดับ การกำหนดกลุ่มกระบวนการหลักแต่ละรายการจะต้องจำแนกตามสมบัติต่อไปนี้

  13. เป้าหมาย วัตถุประสงค์หลักที่ KPA แต่ละรายการจะต้องบรรลุให้ได้ ข้อตกลง ข้อกำหนดที่ระบุให้หน่วยงานต้องดำเนินงานให้บรรลุเป้าหมาย และเป็นการยืนยันว่าจะพยายามทำตามเป้าหมาย ความสามารถ สมบัติที่จำเป็นจะต้องมีทั้งทางด้านองค์กรและในเชิงเทคโนโลยีเพื่อให้หน่วยงานดำเนินงานตามข้อตกลง กิจกรรม ภารกิจที่จำต้องทำเพื่อให้บรรลุ KPA วิธีการตรวจการดำเนินงาน แนวทางในการตรวจกิจกรรมว่าดำเนินไปเช่นใด วิธีการตรวจสอบผลการดำเนินงาน แนวทางในการตรวจสอบการดำเนินงาน KPA ว่าดำเนินการได้ถูกต้องเหมาะสม

  14. กลุ่มกระบวนการหลักที่ได้กำหนดขึ้นสำหรับการดำเนินงานเกี่ยวกับซอฟต์แวร์ในแต่ละระดับความสามารถมีดังต่อไปนี้กลุ่มกระบวนการหลักที่ได้กำหนดขึ้นสำหรับการดำเนินงานเกี่ยวกับซอฟต์แวร์ในแต่ละระดับความสามารถมีดังต่อไปนี้ ระดับที่ 1ไม่มี KPA ระดับที่ 2มี KPA ทั้งหมด 6 KPA ดังนี้ Requirements Management (RM) Software Project Planning (SPP) Software Project Tracking and Oversight (SPTO) Software Subcontract Management (SSM) Software Quality Assurance (SQA) Software Configuration Management (SCM)

  15. Requirements Management: RM (การบริหารความต้องการของลูกค้า) การสร้างความเข้าใจของลูกค้ากับ Team Project ให้ตรงกัน การทำเอกสาร (Document)และควบคุม (Control) ความต้องการของลูกค้า ถ้ามีการเปลี่ยนแปลงของลูกค้า Team Project ต้องรับทราบ ทำ Document Team ใหม่ ทำแผน(Plan) , โครงการ(Product) , ระยะเวลา(Time) , รายละเอียดโครงการ(Detail) ให้ตรงกับ Requirement RM จะควบคุมการใช้ Tool , Module , Component ให้ตรงกัน อุปสรรคที่จะทำให้ RM ไม่เกิด คนที่ไปเก็บ Requirement ไม่เข้าใจวิธีการเก็บ การเก็บเอกสารของลูกค้ามาไม่ครบ

  16. อุปสรรคที่จะทำให้ SPP ไม่เกิด ไม่มีเวลา ไม่มีการสื่อสาร (Commit) ในแผนนั้น ๆ ข้อมูลที่ใช้รองรับ (Support) ไม่เพียงพอ

  17. Software Project Tracking and Oversight (SPTO) การติดตาม ดูแลและตรวจสอบแผนงานที่วางไว้ ตรวจสอบการทำงานจริงที่ทำ กับ แผน ว่า ตรงกันไหม สิ่งที่เข้าไปตรวจสอบ - Product Size  - Project Effort  - Cost  - Schedule  - Activities ที่ทำ - Risk

  18. 2. เมื่อมีการเบี่ยงเบนไปจากแผนเดิม ต้องทำการบันทึกลงในเอกสาร Corrective Action แล้วทำการเปลี่ยนวิธีการทำงาน หรือ เปลี่ยนแผนให้เหมาะสมกับงาน

  19. อุปสรรคที่จะทำให้ SPTO ไม่เกิด คนติดตาม (Tracker) ไม่ได้เทรนมาอย่างดี ไม่มีเวลาว่างที่จะทำ (No Time Tracking)

  20. Software Subcontract Management: SSM (การเลือกและควบคุมผู้รับช่วงต่อในการทำงาน) เลือกบริษัทผู้รับงานรายย่อย โดยการตรวจสอบบริษัทรายย่อย (Subcontract) โดยดูที่ - Process Capability เช่น ถ้าบริษัทได้ CMM ก็ควรเลือกบริษัทที่มี CMM เหมือนกัน - เคยทำงานด้านไหน มีความรู้ด้านไหน บอกรายละเอียดให้บริษัทผู้รับงานรายย่อย มีอะไรบ้างในงาน (Statements of Work) - Requirement - Standards - Procedures - Products to be delivered

  21. การตรวจการทำงานของบริษัทผู้รับงานรายย่อย เช่น ใช้สีอะไร File เก็บเป็นระเบียบหรือไม่ โดยวิธี ดังนี้ - การสัมภาษณ์ - การดูที่ SQA ของบริษัทรายย่อย - การดูที่ SCM ของบริษัทรายย่อย = การเก็บ Control อุปสรรคที่จะทำให้ SSM ไม่เกิด ความแตกต่างของบริษัทหลักและบริษัทผู้รับงานรายย่อย เช่น ภาษา การสื่อสารของบริษัทหลักกับบริษัทผู้รับงานรายย่อยน้อยเกินไป

  22. Software Quality Assurance: SQA (การตรวจสอบคุณภาพของซอฟต์แวร์) ช่วยดูว่าผิดหรือถูกขั้นตอนอะไรบ้าง การทำงานและซอฟต์แวร์ ตรงตามที่กำหนดไว้หรือเปล่า ทำรายงาน SQA ส่งตรงต่อผู้บริหาร SQA เป็นหน่วยงานอิสระ แยกในผังองค์กร SQA ต้องเริ่มตั้งแต่แรก และต้องเข้าใจแผน , มาตรฐาน(Standards)

  23. อุปสรรคที่จะทำให้ SQA ไม่เกิด SQA ต้องทำเพื่อคุณภาพ (Quality) จริง ๆ SQA จับไม่ได้ ไล่ไม่ทัน Project Leader

  24. Software Configuration Management: SCM (การพิจารณาทุกส่วนของการทำงานซอฟต์แวร์) มีระบบจัดเก็บ ComProgramและเอกสาร ดูแลการเปลี่ยนแปลงอย่างเป็นระบบ Baseline = พื้นฐานของงานที่ทำอยู่ ซอฟต์แวร์เวอร์ชันล่าสุด ตกลงกันว่า Baseline ควรเก็บอะไรบ้าง เช่น SourceCode Baseline สามารถเปลี่ยนได้ ถ้า Requirement เปลี่ยน

  25. การเปลี่ยนแปลงแต่ละ Version ต้องเขียนลงในเอกสาร การสร้าง Directory ต้องตกลงกันให้เป็นมาตรฐานเดียวกันหมดทั้งบริษัท เช่น File ที่เก็บโครงการ ใช้ชื่อตามรหัสโครงการ มีการจัดทำที่เก็บเอกสารทั้งหมดของบริษัท หรือเรียกว่าLibraly System

  26. ประโยชน์ของ CMM 1.ด้านกระบวนการ- ทำให้องค์กรมีมาตรฐานสากลในการพัฒนาระบบงานให้กับลูกค้า- องค์กรสามารถควบคุมโครงการของลูกค้าทั้ง Size Effort Cost Schedule- ผลิตภันฑ์ที่ส่งมอบให้ลูกค้ามีความถูกต้องและตรงตามความต้องการของลูกค้าที่ได้ตกลงกันไว้- นำข้อผิดพลาดจากโครงการมาพัฒนากระบวนการขององค์กรให้ดียิ่งขึ้น 2.ด้านการตลาด - สามารถขยายฐานลูกค้าไปยังต่างประเทศ- CMM จะเป็นModelที่สร้างความเชื่อมั่นให้ลูกค้า ซึ่งถือว่าเป็นข้อได้เปรียบในการตลาดเมื่อเปรียบเทียบกับองค์กรอื่น

  27. สมาชิกในกลุ่ม CMM วคพ.501 นางสาวสุมณฑา ดุมลักษณ์ เลขที่ 29 นายอรรถพล นาคปาน เลขที่ 32 นายเอกพจน์ หนูช่วย เลขที่ 36

More Related