Transcript CMM เป็นมาตรฐานระดับโลกในเรื่องของซอฟต์แวร์ที่

CMM เป็ นมาตรฐานระดับโลกในเรื่องของซอฟต์ แวร์ ที่บริษัทพัฒนา
ซอฟต์ แวร์ (Software House) สามารถนาไปใช้ เพื่อเป็ นแนวทางในการ
ปรั บปรุ งกระบวนการพัฒนาซอฟต์ แวร์ โดยมาตรฐาน CMM ถือกาเนิดขึ้น
จาก Software Engineering Institute (SEI) ของมหาวิทยาลัย Carnegie
Mellon ซึ่งเป็ นมหาวิทยาลัยทีไ่ ด้ รับการยอมรับในระดับสากล ว่ ามีชื่อเสี ยงด้ าน
วิศวกรรมคอมพิวเตอร์ ระดับโลกดังนั้นมาตรฐาน CMM จึงเป็ นมาตรฐานที่ดี
ทีส่ ุ ดและเป็ นทีย่ อมรับมากทีส่ ุ ดสาหรับการพัฒนาซอฟต์ แวร์ ในระดับสากล
มาตรฐาน CMM จะแบ่ งการพัฒนาซอฟต์ แวร์ ออกเป็ น 5 ระดับ คือ
ระดับที่ 1 ระดับตั้งต้ น (Initial level)
 ระดับที่ 2 ระดับทาซ้าได้ (Repeatable level)
ระดับที่ 3 ระดับชัดเจน (Defined Level)
ระดับที่ 4 ระดับจัดการ (Managed Level)
ระดับที่ 5 ระดับเหมาะทีส่ ุ ด (Optimizing Level)
ระดับที่ 1 ระดับตั้งต้ น (Initial level)
จะมุ่ งเน้ นไปที่ ก ารพั ฒ นางานให้ ลุ ล่ วงเพี ย งอย่ างเดี ย ว
หน่ วยงานยังมีความยากลาบากในการจัดกระบวนการซอฟต์ แวร์ ที่ เป็ น
ระบบ ส่ งผลให้ เกิดวิกฤติการณ์ ในการทางานอยู่เสมอ ความสาเร็ จของ
การพั ฒ นาซอฟตแวร์ ในระดั บ นี้ ขึ้ น อยู่ กั บ ประสบการณ์ แ ละความ
สามารถของหัวหน้ าโครงการแต่ มักจะประสบกับปัญหายุ่งเหยิง และการ
พัฒ นาซอฟต์ แวร์ มักจะใช้ เวลาและงบประมาณเกิน ที่กาหนดไว้ อาจ
กล่ าวได้ ว่าความสามารถที่ระดับนี้เป็ นความสามารถของบุคคลมากกว่ า
ของ องค์ การ
CMM Level 1 มีลกั ษณะการพัฒนาซอฟต์ แวร์ ดังนี้
1. มี Process ที่ระบุไม่ ได้ (ไม่ มีกระบวนการพัฒนาซอฟต์ แวร์ ที่เป็ น
2.
3.
4.
5.
6.
ระบบ)
มีแค่ Input และ Output เท่ านั้น
ขอให้ งานออกมาก็พอ
ขึน้ อยู่กบั หัวหน้ างานอย่ างเดียว
มีแนวคิดแค่ ว่า เงินมาก งานดี
งานไม่ รู้ว่าจะออกมาดีหรือไม่ ต้ องรอผลทีเ่ สร็จแล้วเท่ านั้น
ระดับที่ 2 ระดับทาซ้าได้ (Repeatable level)
มีการกาหนดขั้นตอนการนานโยบายไปใช้ มีการนาการบริ หาร
การจัดการโครงการเบือ้ งต้ น (Basic Project Management) จะมีการ
จั ด ท าเอกสารอย่ างเป็ นขั้ นตอน และจะสามารถตรวจสอบได้
กระบวนการที่ได้ ผลมีลักษณะเป็ นงานที่มีการจัดทาเอกสาร ควบคุม มี
การฝึ กอบรม มีการวัดผล และ สามารถปรับปรุ งให้ ดีขึน้ ได้ เราอาจกล่ าว
ได้ ว่าลักษณะของระดับนี้ก็คือใช้ ผลสาเร็ จของโครงการที่ผ่ านมา เป็ น
ตัวอย่ าง มีการกาหนดมาตรฐานโครงการ และมีการจัดรู ปแบบองค์ กรให้
งานโครงการดาเนินไปได้ ดี
CMM Level 2 มีลกั ษณะการพัฒนาซอฟต์ แวร์ ดังนี้
1.
2.
3.
4.
5.
6.
มี Process ทีร่ ะบุได้ (มีกระบวนการพัฒนาซอฟต์ แวร์ ที่เป็ นระบบ)
มีวิธีการตรวจสอบการพัฒนาซอฟต์ แวร์
มีหน่ วยงานอิสระทีค่ วบคุมคุณภาพ
มีมาตรฐานในการจัดเก็บซอฟต์ แวร์
มีการทาเอกสารต่ าง ๆ
มีการวางแผนการพัฒนาซอฟต์ แวร์
ระดับที่ 3 ระดับชัดเจน (Defined Level)
จะมีการบันทึกทาเอกสารเกีย่ วกับกระบวนการมาตรฐานในการ
พั ฒ นาและบ ารุ ง รั ก ษา ซอฟต์ แ วร์ เอาไว้ อี ก ทั้ ง ยั ง มี ก ารท าเอกสาร
เกี่ ย วกั บ งานวิ ศ วกรรมซอฟต์ แ วร์ และกระบวนการจั ด การ ต่ า ง ๆ
โครงการต่ า ง ๆ ที่ ท าในระดั บ นี้ จ ะช่ วยให้ หน่ วยงานปรั บ เปลี่ ย น
กระบวนการซอฟต์ แ วร์ ข องตนตาม ลัก ษณะพิเ ศษของโครงการได้
กระบวนการซอฟต์ แวร์ ที่ปรั บเปลี่ยนแล้ วนี้ ทาง CMM เรี ยกว่ า
กระบวนการซอฟต์ แวร์ ทชี่ ัดเจน (Defined software process)
กระบวนการซอฟต์ แวร์ ที่ชัดเจนจะต้ องมีกระบวนการทาง
วิศวกรรมซอฟต์ แวร์ และ กระบวนการจัดการที่แจ่ มชั ดด้ วย และจะ
แสดงได้ ด้วยการมีเงื่อนไขที่ชัดเจน มีมาตรฐานและวิธีการสาหรั บ
ท างานต่ า ง ๆ มี ก ลไกในการตรวจสอบ มี ก ารก าหนดผลลัพ ธ์ และ
เงื่อนไขการจบโครงการ
ระดับที่ 4 ระดับจัดการ (Managed Level)
หน่ ว ยงานที่ ส ามารถวั ด ผลและพยากรณ์ ผ ลที่ จ ะเกิ ด ในการ
ทางานโครงการซอฟต์ แวร์ ได้ อย่ างแม่ นยา สามารถพยากรณ์ แนวโน้ ม
และคุณภาพของซอฟต์ แวร์ ได้ ดี ในเมื่อสภาวะการทางานค่ อนข้ างลงตัว
เมื่อมีโครงการแปลกๆเข้ ามาให้ ทา หน่ วยงานก็สามารถปรับกระบวนการ
ได้ เป็ นอย่ างดี
ระดับที่ 5 ระดับเหมาะทีส่ ุ ด (Optimizing Level)
หน่ วยงานที่อยู่ในระดับนี้เป็ นหน่ วยงานที่เน้ นในด้ านการปรับปรุ ง
กระบวนการอยู่ ต ลอดเวลา โดยมี เ ป้ าหมายในการป้ องกั น ไม่ ใ ห้ เกิ ด
ข้ อบกพร่ องขึ้น หน่ วยงานใช้ ข้อมูลเกี่ยวกับประสิ ทธิผลของกระบวนการ
ซอฟต์ แวร์ ในเชิ งวิเคราะห์ ต้ นทุนและกาไรของเทคโนโลยีใหม่ ๆ เพื่อใช้
เสนอการเปลีย่ นแปลงกระบวนการซอฟต์ แวร์ ของหน่ วยงาน มีการกาหนด
ว่ าวัตกรรมใดเหมาะที่สุดสาหรับหน่ วยงานทีมงานซอฟต์ แวร์ ในระดับนีท้ า
หน้ า ที่วิ เ คราะห์ ข้ อ บกพร่ อ งเพื่อ หาสาเหตุ มี ก ารประเมิ น กระบวนการ
ซอฟต์ แวร์ เพือ่ ป้องกันไม่ ให้ เกิดข้ อบกพร่ องซ้าอีก
กลุ่มกระบวนการหลัก (Key Process Area หรือ KPA)
สถาบัน SEI ได้ กาหนดกลุ่มกระบวนการหลัก (Key Process
Area หรือ KPA) สาหรับระดับความสามารถแต่ ละระดับเอาไว้ ด้วย กลุ่ม
กระบวนการหลักเหล่ า นี้ใ ช้ อ ธิ บายฟั ง ก์ ชั น ต่ า ง ๆ ทางด้ า นวิศ วกรรม
ซอฟต์ แวร์ ที่จะต้ องมีในแต่ ละระดับ การกาหนดกลุ่มกระบวนการหลัก
แต่ ละรายการจะต้ องจาแนกตามสมบัติต่อไปนี้
1. เป้าหมาย วัตถุประสงค์ หลักที่ KPA แต่ ละรายการจะต้ องบรรลุให้
2.
3.
4.
5.
6.
ได้
ข้ อตกลง ข้ อกาหนดที่ระบุ ใ ห้ หน่ วยงานต้ องด าเนิ น งานให้ บรรลุ
เป้าหมาย และเป็ นการยืนยันว่ าจะพยายามทาตามเป้าหมาย
ความสามารถ สมบัติที่จาเป็ นจะต้ องมีท้งั ทางด้ านองค์ กรและในเชิง
เทคโนโลยีเพือ่ ให้ หน่ วยงานดาเนินงานตามข้ อตกลง
กิจกรรม ภารกิจทีจ่ าต้ องทาเพือ่ ให้ บรรลุ KPA
วิธีการตรวจการดาเนินงาน แนวทางในการตรวจกิจกรรมว่ าดาเนิ น
ไปเช่ นใด
วิธีการตรวจสอบผลการดาเนินงาน แนวทางในการตรวจสอบการ
ดาเนินงาน KPA ว่ าดาเนินการได้ ถูกต้ องเหมาะสม
กลุ่ ม กระบวนการหลั ก ที่ ไ ด้ ก าหนดขึ้ น ส าหรั บ การด าเนิ น งานเกี่ ย วกั บ
ซอฟต์ แวร์ ในแต่ ละระดับความสามารถมีดังต่ อไปนี้
ระดับที่ 1ไม่ มี KPA
ระดับที่ 2มี KPA ทั้งหมด 6 KPA ดังนี้
1. Requirements Management (RM)
2. Software Project Planning (SPP)
3. Software Project Tracking and Oversight (SPTO)
4. Software Subcontract Management (SSM)
5. Software Quality Assurance (SQA)
6. Software Configuration Management (SCM)
Requirements Management: RM (การบริหารความต้ องการของลูกค้ า)
1. การสร้ างความเข้ าใจของลูกค้ ากับ Team Project ให้ ตรงกัน
2. การทาเอกสาร (Document)และควบคุม (Control) ความต้ องการของ
ลูกค้ า
3. ถ้ ามีการเปลี่ยนแปลงของลูกค้ า Team Project ต้ องรั บทราบ ทา
Document Team ใหม่
4. ทาแผน(Plan) , โครงการ(Product) , ระยะเวลา(Time) , รายละเอียด
โครงการ(Detail) ให้ ตรงกับ Requirement
5. RM จะควบคุมการใช้ Tool , Module , Component ให้ ตรงกัน
6. อุปสรรคทีจ่ ะทาให้ RM ไม่ เกิด
7. คนทีไ่ ปเก็บ Requirement ไม่ เข้ าใจวิธีการเก็บ
8. การเก็บเอกสารของลูกค้ ามาไม่ ครบ
อุปสรรคทีจ่ ะทาให้ SPP ไม่ เกิด
 ไม่ มีเวลา
 ไม่ มีการสื่ อสาร (Commit) ในแผนนั้น ๆ
 ข้ อมูลทีใ่ ช้ รองรับ (Support) ไม่ เพียงพอ
Software Project Tracking and Oversight (SPTO) การติดตาม ดูแล
และตรวจสอบแผนงานทีว่ างไว้
ตรวจสอบการทางานจริงทีท่ า กับ แผน ว่ า ตรงกันไหม
1. สิ่ งทีเ่ ข้ าไปตรวจสอบ
- Product Size
- Project Effort
- Cost
- Schedule
- Activities ที่ทา
- Risk
2.
เมื่ อ มี ก ารเบี่ ย งเบนไปจากแผนเดิ ม ต้ อ งท าการบั น ทึ ก ลงใน
เอกสาร Corrective Action แล้ วทาการเปลีย่ นวิธีการทางาน หรือ เปลี่ยน
แผนให้ เหมาะสมกับงาน
อุปสรรคทีจ่ ะทาให้ SPTO ไม่ เกิด
1. คนติดตาม (Tracker) ไม่ ได้ เทรนมาอย่ างดี
2. ไม่ มีเวลาว่ างทีจ่ ะทา (No Time Tracking)
Software Subcontract Management: SSM (การเลือกและควบคุมผู้รับ
ช่ วงต่ อในการทางาน)
1. เลือกบริษัทผู้รับงานรายย่ อย โดยการตรวจสอบบริษัทรายย่ อย
(Subcontract) โดยดูที่
- Process Capability เช่ น ถ้ าบริษัทได้ CMM ก็ควรเลือกบริษัทที่มี
CMM เหมือนกัน
- เคยทางานด้ านไหน มีความรู้ด้านไหน
2. บอกรายละเอียดให้ บริษัทผู้รับงานรายย่ อย มีอะไรบ้ างในงาน
(Statements of Work)
- Requirement
- Standards
- Procedures
- Products to be delivered
3. การตรวจการทางานของบริษัทผู้รับงานรายย่ อย เช่ น ใช้ สีอะไร File เก็บ
เป็ นระเบียบหรือไม่ โดยวิธี ดังนี้
- การสั มภาษณ์
- การดูที่ SQA ของบริษัทรายย่ อย
- การดูที่ SCM ของบริษัทรายย่ อย = การเก็บ Control
อุปสรรคทีจ่ ะทาให้ SSM ไม่ เกิด
1. ความแตกต่ างของบริษัทหลักและบริษัทผู้รับงานรายย่ อย เช่ น ภาษา การ
สื่ อสารของบริษัทหลักกับบริษัทผู้รับงานรายย่ อยน้ อยเกินไป
Software Quality Assurance: SQA (การตรวจสอบคุณภาพของ
ซอฟต์ แวร์ )
1.
2.
3.
4.
5.
ช่ วยดูว่าผิดหรือถูกขั้นตอนอะไรบ้ าง
การทางานและซอฟต์ แวร์ ตรงตามที่กาหนดไว้ หรือเปล่า
ทารายงาน SQA ส่ งตรงต่ อผู้บริหาร
SQA เป็ นหน่ วยงานอิสระ แยกในผังองค์ กร
SQA ต้ องเริ่มตั้งแต่ แรก และต้ องเข้ าใจแผน , มาตรฐาน
(Standards)
อุปสรรคทีจ่ ะทาให้ SQA ไม่ เกิด
1. SQA ต้ องทาเพือ่ คุณภาพ (Quality) จริง ๆ
2. SQA จับไม่ ได้ ไล่ ไม่ ทัน Project Leader
Software Configuration Management: SCM (การพิจารณาทุกส่ วน
ของการทางานซอฟต์ แวร์ )
1. มีระบบจัดเก็บ ComProgram และเอกสาร
2. ดูแลการเปลีย่ นแปลงอย่ างเป็ นระบบ
3. Baseline = พืน้ ฐานของงานทีท่ าอยู่ ซอฟต์ แวร์ เวอร์ ชันล่ าสุ ด
4. ตกลงกันว่ า Baseline ควรเก็บอะไรบ้ าง เช่ น SourceCode
5. Baseline สามารถเปลีย่ นได้ ถ้ า Requirement เปลีย่ น
6. การเปลีย่ นแปลงแต่ ละ Version ต้ องเขียนลงในเอกสาร
7. การสร้ าง Directory ต้ องตกลงกันให้ เป็ นมาตรฐานเดียวกันหมดทั้ง
บริษัท เช่ น File ที่เก็บโครงการ ใช้ ชื่อตามรหัสโครงการ
8. มีการจัดทาทีเ่ ก็บเอกสารทั้งหมดของบริษัท หรือเรียกว่ า Libraly
System
ประโยชน์ ของ CMM
1.ด้ านกระบวนการ
- ทาให้ องค์ กรมีมาตรฐานสากลในการพัฒนาระบบงานให้ กบั ลูกค้า
- องค์ กรสามารถควบคุมโครงการของลูกค้าทั้ง Size Effort Cost
Schedule
- ผลิตภันฑ์ ทสี่ ่ งมอบให้ ลูกค้ ามีความถูกต้ องและตรงตามความต้ องการ
ของลูกค้ าทีไ่ ด้ ตกลงกันไว้
- นาข้ อผิดพลาดจากโครงการมาพัฒนากระบวนการขององค์กรให้ ดียิ่งขึน้
2.ด้ านการตลาด
- สามารถขยายฐานลูกค้ าไปยังต่ างประเทศ
- CMM จะเป็ นModelทีส่ ร้ างความเชื่อมั่นให้ ลกู ค้ า ซึ่งถือว่ าเป็ นข้ อ
ได้ เปรียบในการตลาดเมื่อเปรียบเทียบกับองค์ กรอืน่
สมาชิกในกลุ่ม CMM
วคพ.501
นางสาวสุ มณฑา ดุมลักษณ์ เลขที่ 29
นายอรรถพล นาคปาน เลขที่ 32
นายเอกพจน์ หนูช่วย เลขที่ 36