Capability Maturity Model(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)

จะม)/งเน(นไป็ที่��การพั�ฒนางานให(ล)ล/วงเพั�ยงอย/างเดั�ยว หน/วยงานย�งม�ความยากล%าบากในการจ�ดักระบวนการซอฟต�แวร�ที่��เป็�นระบบ ส/งผลให(เก�ดัว�กฤต�การณ์�ในการที่%างานอย5/เสมอ ความส%าเร6จของการพั�ฒนาซอฟตแวร�ในระดั�บน�,ข+,นอย5/ก�บป็ระสบการณ์�และความ สามารถของห�วหน(าโครงการแต/ม�กจะป็ระสบก�บป็7ญหาย)/งเหย�ง และการพั�ฒนาซอฟต�แวร�ม�กจะใช้(เวลาและงบป็ระมาณ์เก�นที่��ก%าหนดัไว( อาจกล/าวไดั(ว/าความสามารถที่��ระดั�บน�,เป็�นความสามารถของบ)คคลมากกว/าของ องค�การ

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

1 .ม� Process ที่��ระบ)ไม/ไดั( (ไม/ม�กระบวนการพั�ฒนาซอฟต�แวร�ที่��เป็�นระบบ)

2. ม�แค/ Input และ Output เที่/าน�,น 3. ขอให(งานออกมาก6พัอ 4. ข+,นอย5/ก�บห�วหน(างานอย/างเดั�ยว 5. ม�แนวค�ดัแค/ว/า เง�นมาก งานดั� 6. งานไม/ร5(ว/าจะออกมาดั�หร�อไม/ ต(องรอผลที่��เสร6จแล(ว

เที่/าน�,น

ระดั�บที่�� 2 ระดั�บที่%าซ%,าไดั( (Repeatable level)

ม�การก%าหนดัข�,นตอนการน%านโยบายไป็ใช้(ม�การน%าการบร�หารการจ�ดัการโครงการเบ�,องต(น (Basic Project Management) จะม�การจ�ดัที่%าเอกสารอย/างเป็�นข�,นตอน และจะสามารถตรวจสอบไดั( กระบวนการที่��ไดั(ผลม�ล�กษัณ์ะเป็�นงานที่��ม�การจ�ดัที่%าเอกสาร ควบค)ม ม�การฝึ:กอบรม ม�การว�ดัผล และ สามารถป็ร�บป็ร)งให(ดั�ข+,นไดั( เราอาจกล/าวไดั(ว/าล�กษัณ์ะของระดั�บน�,ก6ค�อใช้(ผลส%าเร6จของโครงการที่��ผ/านมา เป็�นต�วอย/าง ม�การก%าหนดัมาตรฐานโครงการ และม�การจ�ดัร5ป็แบบองค�กรให(งานโครงการดั%าเน�นไป็ไดั(ดั�

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

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

2. ม�ว�ธี�การตรวจสอบการพั�ฒนาซอฟต�แวร� 3. ม�หน/วยงานอ�สระที่��ควบค)มค)ณ์ภาพั 4. ม�มาตรฐานในการจ�ดัเก6บซอฟต�แวร� 5. ม�การที่%าเอกสารต/าง ๆ 6. ม�การวางแผนการพั�ฒนาซอฟต�แวร�

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

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

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

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

หน/วยงานที่��สามารถว�ดัผลและพัยากรณ์�ผลที่��จะเก�ดัในการที่%างานโครงการซอฟต�แวร�ไดั( อย/างแม/นย%า สามารถพัยากรณ์�แนวโน(มและค)ณ์ภาพัของซอฟต�แวร�ไดั(ดั� ในเม��อสภาวะการที่%างานค/อนข(างลงต�ว เม��อม�โครงการแป็ลกๆเข(ามาให(ที่%า หน/วยงานก6สามารถป็ร�บกระบวนการไดั(เป็�นอย/างดั�

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

หน/วยงานที่��อย5/ในระดั�บน�,เป็�นหน/วยงานที่��เน(นในดั(านการป็ร�บป็ร)งกระบวนการอย5/ตลอดัเวลา โดัยม�เป็>าหมายในการป็>องก�นไม/ให(เก�ดัข(อบกพัร/องข+,น หน/วยงานใช้(ข(อม5ลเก��ยวก�บป็ระส�ที่ธี�ผลของกระบวนการซอฟต�แวร�ในเช้�งว�เคราะห� ต(นที่)นและก%าไรของเที่คโนโลย�ใหม/ๆ เพั��อใช้(เสนอการเป็ล��ยนแป็ลงกระบวนการซอฟต�แวร�ของหน/วยงาน ม�การก%าหนดัว/าว�ตกรรมใดัเหมาะที่��ส)ดัส%าหร�บหน/วยงานที่�มงานซอฟต�แวร�ในระดั�บน�,ที่%าหน(าที่��ว�เคราะห�ข(อบกพัร/องเพั��อหาสาเหต) ม�การป็ระเม�นกระบวนการซอฟต�แวร�เพั��อป็>องก�นไม/ให(เก�ดัข(อบกพัร/องซ%,าอ�ก

กล)/มกระบวนการหล�ก (Key Process Area หร�อ KPA)

สถาบ�น SEI ไดั(ก%าหนดักล)/มกระบวนการหล�ก (Key Process Area หร�อ KPA) ส%าหร�บระดั�บความสามารถแต/ละระดั�บเอาไว(ดั(วย กล)/มกระบวนการหล�กเหล/าน�,ใช้(อธี�บายฟ7งก�ช้�นต/าง ๆ ที่างดั(านว�ศวกรรมซอฟต�แวร�ที่��จะต(องม�ในแต/ละระดั�บ การก%าหนดักล)/มกระบวนการหล�กแต/ละรายการจะต(องจ%าแนกตามสมบ�ต�ต/อไป็น�,

1 .เป็>าหมาย ว�ตถ)ป็ระสงค�หล�กที่�� KPA แต/ละรายการจะต(องบรรล)ให(ไดั(

2. ข(อตกลง ข(อก%าหนดัที่��ระบ)ให(หน/วยงานต(องดั%าเน�นงานให(บรรล)เป็>าหมาย และเป็�นการย�นย�นว/าจะพัยายามที่%าตามเป็>าหมาย

3. ความสามารถ สมบ�ต�ที่��จ%าเป็�นจะต(องม�ที่�,งที่างดั(านองค�กรและในเช้�งเที่คโนโลย�เพั��อให(หน/วยงานดั%าเน�นงานตามข(อตกลง

4. ก�จกรรม ภารก�จที่��จ%าต(องที่%าเพั��อให(บรรล) KPA 5. ว�ธี�การตรวจการดั%าเน�นงาน แนวที่างในการตรวจ

ก�จกรรมว/าดั%าเน�นไป็เช้/นใดั 6. ว�ธี�การตรวจสอบผลการดั%าเน�นงาน แนวที่างในการ

ตรวจสอบการดั%าเน�นงาน KPA ว/าดั%าเน�นการไดั(ถ5กต(องเหมาะสม

กล)/มกระบวนการหล�กที่��ไดั(ก%าหนดัข+,นส%าหร�บการดั%าเน�นงานเก��ยวก�บซอฟต�แวร�ในแต/ละระดั�บความสามารถม�ดั�งต/อไป็น�,ระดั�บที่�� 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 (การบร�หารความต(องการของล5กค(า)1 .การสร(างความเข(าใจของล5กค(าก�บ Team Project ให(ตรงก�น2. การที่%าเอกสาร (Document)และควบค)ม (Control) ความ

ต(องการของล5กค(า 3. ถ(าม�การเป็ล��ยนแป็ลงของล5กค(า Team Project ต(องร�บที่ราบ

ที่%า Document Team ใหม/ 4. ที่%าแผน(Plan) , โครงการ(Product) , ระยะเวลา(Time) ,

รายละเอ�ยดัโครงการ(Detail) ให(ตรงก�บ Requirement 5. RM จะควบค)มการใช้( Tool , Module , Component ให(

ตรงก�น 6. อ)ป็สรรคที่��จะที่%าให( RM ไม/เก�ดั 7. คนที่��ไป็เก6บ Requirement ไม/เข(าใจว�ธี�การเก6บ 8. การเก6บเอกสารของล5กค(ามาไม/ครบ

อ)ป็สรรคที่��จะที่%าให( SPP ไม/เก�ดั

ไม/ม�เวลา ไม/ม�การส��อสาร (Commit) ในแผนน�,น ๆ ข(อม5ลที่��ใช้(รองร�บ (Support) ไม/เพั�ยงพัอ

Software Project Tracking and Oversight (SPTO) การต�ดัตาม ดั5แลและตรวจสอบแผนงานที่��วางไว( ตรวจสอบการที่%างานจร�งที่��ที่%า ก�บ แผน ว/า ตรงก�นไหม 1 .ส��งที่��เข(าไป็ตรวจสอบ

 - Product Size  - Project Effort  - Cost  - Schedule  - Activities ที่��ที่%า - Risk

2. เม��อม�การเบ��ยงเบนไป็จากแผนเดั�ม ต(องที่%าการบ�นที่+กลงในเอกสาร Corrective Action แล(วที่%าการเป็ล��ยนว�ธี�การที่%างาน หร�อ เป็ล��ยนแผนให(เหมาะสมก�บงาน

อ)ป็สรรคที่��จะที่%าให( SPTO ไม/เก�ดั

1 .คนต�ดัตาม (Tracker) ไม/ไดั(เที่รนมาอย/างดั�

2. ไม/ม�เวลาว/างที่��จะที่%า (No Time Tracking)

Software Subcontract Management: SSM (การเล�อกและควบค)มผ5(ร�บช้/วงต/อในการที่%างาน)1 .เล�อกบร�ษั�ที่ผ5(ร�บงานรายย/อย โดัยการตรวจสอบ

บร�ษั�ที่รายย/อย (Subcontract) โดัยดั5ที่�� - Process Capability เช้/น ถ(าบร�ษั�ที่ไดั( CMM ก6ควรเล�อกบร�ษั�ที่ที่��ม� CMM เหม�อนก�น - เคยที่%างานดั(านไหน ม�ความร5(ดั(านไหน

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

3. การตรวจการที่%างานของบร�ษั�ที่ผ5(ร�บงานรายย/อย เช้/น ใช้(ส�อะไร File เก6บเป็�นระเบ�ยบหร�อไม/ โดัยว�ธี� ดั�งน�,  - การส�มภาษัณ์�  - การดั5ที่�� SQA ของบร�ษั�ที่รายย/อย  - การดั5ที่�� SCM ของบร�ษั�ที่รายย/อย = การเก6บ Control

 อ)ป็สรรคที่��จะที่%าให( SSM ไม/เก�ดั 4. ความแตกต/างของบร�ษั�ที่หล�กและบร�ษั�ที่ผ5(ร�บ

งานรายย/อย เช้/น ภาษัา การส��อสารของบร�ษั�ที่หล�กก�บบร�ษั�ที่ผ5(ร�บงานรายย/อยน(อยเก�นไป็

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

1 .ช้/วยดั5ว/าผ�ดัหร�อถ5กข�,นตอนอะไรบ(าง 2. การที่%างานและซอฟต�แวร� ตรงตามที่��ก%าหนดัไว(

หร�อเป็ล/า 3. ที่%ารายงาน SQA ส/งตรงต/อผ5(บร�หาร 4. SQA เป็�นหน/วยงานอ�สระ แยกในผ�งองค�กร 5. SQA ต(องเร��มต�,งแต/แรก และต(องเข(าใจแผน ,

มาตรฐาน(Standards)

อ)ป็สรรคที่��จะที่%าให( SQA ไม/เก�ดั

1. SQA ต(องที่%าเพั��อค)ณ์ภาพั (Quality) จร�ง ๆ

2. SQA จ�บไม/ไดั( ไล/ไม/ที่�น Project Leader

Software Configuration Management: SCM (การพั�จารณ์าที่)กส/วนของการที่%างานซอฟต�แวร�)

1 .ม�ระบบจ�ดัเก6บ ComProgram และเอกสาร 2. ดั5แลการเป็ล��ยนแป็ลงอย/างเป็�นระบบ 3. Baseline = พั�,นฐานของงานที่��ที่%าอย5/ ซอฟต�แวร�

เวอร�ช้�นล/าส)ดั 4. ตกลงก�นว/า Baseline ควรเก6บอะไรบ(าง เช้/น

SourceCode 5. Baseline สามารถเป็ล��ยนไดั( ถ(า Requirement

เป็ล��ยน

6. การเป็ล��ยนแป็ลงแต/ละ Version ต(องเข�ยนลงในเอกสาร

7. การสร(าง Directory ต(องตกลงก�นให(เป็�นมาตรฐานเดั�ยวก�นหมดัที่�,งบร�ษั�ที่ เช้/น File ที่��เก6บโครงการ ใช้(ช้��อตามรห�สโครงการ

8. ม�การจ�ดัที่%าที่��เก6บเอกสารที่�,งหมดัของบร�ษั�ที่ หร�อเร�ยกว/า Libraly System

ป็ระโยช้น�ของ CMM1.ดั(านกระบวนการ

- ที่%าให(องค�กรม�มาตรฐานสากลในการพั�ฒนาระบบงานให(ก�บล5กค(า - องค�กรสามารถควบค)มโครงการของล5กค(าที่�,ง Size Effort Cost Schedule - ผล�ตภ�นฑ์�ที่��ส/งมอบให(ล5กค(าม�ความถ5กต(องและตรงตามความต(องการของล5กค(าที่��ไดั(ตกลงก�นไว( - น%าข(อผ�ดัพัลาดัจากโครงการมาพั�ฒนากระบวนการขององค�กรให(ดั�ย��งข+,น

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

สมาชิ�กในกลุ่�ม CMMวคพ.501

นางสาวสมณฑา ดุมลุ่�กษณ� เลุ่ขที่�� 29นายอรรถพลุ่ นาคปาน เลุ่ขที่�� 32นายเอกพจน� หน#ชิ�วย เลุ่ขที่�� 36