slide1
Download
Skip this Video
Download Presentation
Capability Maturity Model (CMM)

Loading in 2 Seconds...

play fullscreen
1 / 27

Capability Maturity Model (CMM) - PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on

Capability Maturity Model (CMM).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Capability Maturity Model (CMM)' - premala-susan


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2

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

slide3

มาตรฐาน CMM จะแบ่งการพัฒนาซอฟต์แวร์ออกเป็น 5 ระดับ คือ

ระดับที่ 1 ระดับตั้งต้น (Initial level)

ระดับที่ 2 ระดับทำซ้ำได้ (Repeatable level)

ระดับที่ 3 ระดับชัดเจน (Defined Level)

ระดับที่ 4 ระดับจัดการ (Managed Level)

ระดับที่ 5 ระดับเหมาะที่สุด (Optimizing Level)

slide4

ระดับที่ 1 ระดับตั้งต้น (Initial level)

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

slide5

CMM Level 1 มีลักษณะการพัฒนาซอฟต์แวร์ ดังนี้

มี Process ที่ระบุไม่ได้ (ไม่มีกระบวนการพัฒนาซอฟต์แวร์ที่เป็นระบบ)

มีแค่ Input และ Output เท่านั้น

ขอให้งานออกมาก็พอ

ขึ้นอยู่กับหัวหน้างานอย่างเดียว

มีแนวคิดแค่ว่า เงินมาก งานดี

งานไม่รู้ว่าจะออกมาดีหรือไม่ ต้องรอผลที่เสร็จแล้วเท่านั้น

slide6

ระดับที่ 2 ระดับทำซ้ำได้ (Repeatable level)

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

slide7

CMM Level 2 มีลักษณะการพัฒนาซอฟต์แวร์ ดังนี้

มี Process ที่ระบุได้ (มีกระบวนการพัฒนาซอฟต์แวร์ที่เป็นระบบ)

มีวิธีการตรวจสอบการพัฒนาซอฟต์แวร์

มีหน่วยงานอิสระที่ควบคุมคุณภาพ

มีมาตรฐานในการจัดเก็บซอฟต์แวร์

มีการทำเอกสารต่าง ๆ

มีการวางแผนการพัฒนาซอฟต์แวร์

slide8

ระดับที่ 3 ระดับชัดเจน (Defined Level)

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

slide9

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

slide10

ระดับที่ 4 ระดับจัดการ (Managed Level)

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

slide11

ระดับที่ 5 ระดับเหมาะที่สุด (Optimizing Level)

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

slide12

กลุ่มกระบวนการหลัก (Key Process Area หรือ KPA)

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

slide13

เป้าหมาย วัตถุประสงค์หลักที่ KPA แต่ละรายการจะต้องบรรลุให้ได้

ข้อตกลง ข้อกำหนดที่ระบุให้หน่วยงานต้องดำเนินงานให้บรรลุเป้าหมาย และเป็นการยืนยันว่าจะพยายามทำตามเป้าหมาย

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

กิจกรรม ภารกิจที่จำต้องทำเพื่อให้บรรลุ KPA

วิธีการตรวจการดำเนินงาน แนวทางในการตรวจกิจกรรมว่าดำเนินไปเช่นใด

วิธีการตรวจสอบผลการดำเนินงาน แนวทางในการตรวจสอบการดำเนินงาน KPA ว่าดำเนินการได้ถูกต้องเหมาะสม

slide14

กลุ่มกระบวนการหลักที่ได้กำหนดขึ้นสำหรับการดำเนินงานเกี่ยวกับซอฟต์แวร์ในแต่ละระดับความสามารถมีดังต่อไปนี้กลุ่มกระบวนการหลักที่ได้กำหนดขึ้นสำหรับการดำเนินงานเกี่ยวกับซอฟต์แวร์ในแต่ละระดับความสามารถมีดังต่อไปนี้

ระดับที่ 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)

slide15

Requirements Management: RM (การบริหารความต้องการของลูกค้า)

การสร้างความเข้าใจของลูกค้ากับ Team Project ให้ตรงกัน

การทำเอกสาร (Document)และควบคุม (Control) ความต้องการของลูกค้า

ถ้ามีการเปลี่ยนแปลงของลูกค้า Team Project ต้องรับทราบ ทำ Document Team ใหม่

ทำแผน(Plan) , โครงการ(Product) , ระยะเวลา(Time) , รายละเอียดโครงการ(Detail) ให้ตรงกับ Requirement

RM จะควบคุมการใช้ Tool , Module , Component ให้ตรงกัน

อุปสรรคที่จะทำให้ RM ไม่เกิด

คนที่ไปเก็บ Requirement ไม่เข้าใจวิธีการเก็บ

การเก็บเอกสารของลูกค้ามาไม่ครบ

spp commit support
อุปสรรคที่จะทำให้ SPP ไม่เกิด

ไม่มีเวลา

ไม่มีการสื่อสาร (Commit) ในแผนนั้น ๆ

ข้อมูลที่ใช้รองรับ (Support) ไม่เพียงพอ

slide17

Software Project Tracking and Oversight (SPTO) การติดตาม ดูแลและตรวจสอบแผนงานที่วางไว้

ตรวจสอบการทำงานจริงที่ทำ กับ แผน ว่า ตรงกันไหม

สิ่งที่เข้าไปตรวจสอบ - Product Size  - Project Effort  - Cost  - Schedule  - Activities ที่ทำ - Risk

slide18

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

spto tracker no time tracking
อุปสรรคที่จะทำให้ SPTO ไม่เกิด

คนติดตาม (Tracker) ไม่ได้เทรนมาอย่างดี

ไม่มีเวลาว่างที่จะทำ (No Time Tracking)

slide20

Software Subcontract Management: SSM (การเลือกและควบคุมผู้รับช่วงต่อในการทำงาน)

เลือกบริษัทผู้รับงานรายย่อย โดยการตรวจสอบบริษัทรายย่อย (Subcontract) โดยดูที่ - Process Capability เช่น ถ้าบริษัทได้ CMM ก็ควรเลือกบริษัทที่มี CMM เหมือนกัน - เคยทำงานด้านไหน มีความรู้ด้านไหน

บอกรายละเอียดให้บริษัทผู้รับงานรายย่อย มีอะไรบ้างในงาน (Statements of Work) - Requirement - Standards - Procedures - Products to be delivered

slide21

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

อุปสรรคที่จะทำให้ SSM ไม่เกิด

ความแตกต่างของบริษัทหลักและบริษัทผู้รับงานรายย่อย เช่น ภาษา การสื่อสารของบริษัทหลักกับบริษัทผู้รับงานรายย่อยน้อยเกินไป

slide22

Software Quality Assurance: SQA (การตรวจสอบคุณภาพของซอฟต์แวร์)

ช่วยดูว่าผิดหรือถูกขั้นตอนอะไรบ้าง

การทำงานและซอฟต์แวร์ ตรงตามที่กำหนดไว้หรือเปล่า

ทำรายงาน SQA ส่งตรงต่อผู้บริหาร

SQA เป็นหน่วยงานอิสระ แยกในผังองค์กร

SQA ต้องเริ่มตั้งแต่แรก และต้องเข้าใจแผน , มาตรฐาน(Standards)

sqa sqa quality sqa project leader
อุปสรรคที่จะทำให้ SQA ไม่เกิด

SQA ต้องทำเพื่อคุณภาพ (Quality) จริง ๆ

SQA จับไม่ได้ ไล่ไม่ทัน Project Leader

slide24

Software Configuration Management: SCM (การพิจารณาทุกส่วนของการทำงานซอฟต์แวร์)

มีระบบจัดเก็บ ComProgramและเอกสาร

ดูแลการเปลี่ยนแปลงอย่างเป็นระบบ

Baseline = พื้นฐานของงานที่ทำอยู่ ซอฟต์แวร์เวอร์ชันล่าสุด

ตกลงกันว่า Baseline ควรเก็บอะไรบ้าง เช่น SourceCode

Baseline สามารถเปลี่ยนได้ ถ้า Requirement เปลี่ยน

slide25

การเปลี่ยนแปลงแต่ละ Version ต้องเขียนลงในเอกสาร

การสร้าง Directory ต้องตกลงกันให้เป็นมาตรฐานเดียวกันหมดทั้งบริษัท เช่น File ที่เก็บโครงการ ใช้ชื่อตามรหัสโครงการ

มีการจัดทำที่เก็บเอกสารทั้งหมดของบริษัท หรือเรียกว่าLibraly System

slide26

ประโยชน์ของ CMM

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

2.ด้านการตลาด - สามารถขยายฐานลูกค้าไปยังต่างประเทศ- CMM จะเป็นModelที่สร้างความเชื่อมั่นให้ลูกค้า ซึ่งถือว่าเป็นข้อได้เปรียบในการตลาดเมื่อเปรียบเทียบกับองค์กรอื่น

cmm 501 29 32 36
สมาชิกในกลุ่ม CMM

วคพ.501

นางสาวสุมณฑา ดุมลักษณ์ เลขที่ 29

นายอรรถพล นาคปาน เลขที่ 32

นายเอกพจน์ หนูช่วย เลขที่ 36

ad