โครงงานประจำภาคการศึกษาวิชา กระบวนการวิศวกรรมซอฟต์แวร์และปรับปรุง: แบบบันทึกข้อมูลและแม่แบบเอกสารประกอบการใช้งาน

1. แบบบันทึกข้อมูล
(Template)
นำเสนอ
ผศ.นครทิพย์พร้อมพูล
จัดทำโดย
5870902621 นำงสำวขวัญดี เพชรกำนต์
5870943421 นำยปฏิวัติ วิเศษศุกูล
5870946321 นำยปรีชำ นำคเงิน
5870973221 นำงสำวสุดหทัย หมั่นค้ำ
5870972621 นำยสิทธิพงษ์เหล่ำโก้ก
5870976121 นำงสำวสุพัตรำ อินศรี
รำยงำนนี้เป็นส่วนหนึ่งของรำยวิชำ กระบวนกำรวิศวกรรมซอฟต์แวร์และปรับปรุง
หลักสูตรวิทยำศำสตรมหำบัณฑิต สำขำวิศวกรรมซอฟต์แวร์ คณะวิศวกรรมศำสตร์ จุฬำลงกรณ์มหำวิทยำลัย ภำคเรียนที่ 2 ปีกำรศึกษำ 2558

2. 1
สารบัญ
บทที่ 1 บทนา.......................................................................................................................................................................5
ที่มำและควำมสำคัญ................................................................................................................................................5
วัตถุประสงค์............................................................................................................................................................5
แนวทำงกำรจัดทำแม่แบบบันทึกข้อมูล...................................................................................................................5
ขอบเขต....................................................................................................................................................................5
บทที่ 2 รายการตรวจสอบ (Checklist)................................................................................................................................6
วัตถุประสงค์............................................................................................................................................................6
ประโยชน์.................................................................................................................................................................6
ส่วนรำยกำรตรวจสอบ ............................................................................................................................................6
ส่วนกำรบันทึกแบบประเมิน...................................................................................................................................6
วิธีกำรใช้งำน ...........................................................................................................................................................6
บทที่ 3 การตรวจสอบย้อนกลับ (Traceability Metrix)...................................................................................................10
วัตถุประสงค์..........................................................................................................................................................10
ประโยชน์...............................................................................................................................................................10
กำรใช้งำนแบบฟอร์มตำมรอย...............................................................................................................................10
วิธีกำรใช้งำน .........................................................................................................................................................11
ตัวอย่ำงกำรใช้งำนแบบบันทึกกำรตำมรอยในโครงกำรพัฒนำซอฟต์แวร์............................................................12
บทที่ 4 การออกแบบรายละเอียดซอฟต์แวร์ (Software Detailed Design).......................................................................13
วัตถุประสงค์..........................................................................................................................................................13
ประโยชน์...............................................................................................................................................................13
วิธีกำรใช้งำน .........................................................................................................................................................13
ตัวอย่ำงเอกสำรประกอบกำรออกแบบรำยละเอียดซอฟต์แวร์..............................................................................15
บทที่ 5 แบบสารวจความพร้อมขององค์กรต่อการเปลี่ยนแปลงด้านการปรับปรุงกระบวนการ (Organization Readiness
Assessment)............................................................................................................................................................................18
วัตถุประสงค์..........................................................................................................................................................18
ประโยชน์...............................................................................................................................................................18
วิธีกำรใช้งำน .........................................................................................................................................................18
ตัวอย่ำงแบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุงกระบวนกำร..........................24
บทที่ 6 การวิเคราะห์ช่องว่าง (Gap-Analysis)..................................................................................................................29
วัตถุประสงค์..........................................................................................................................................................29
ประโยชน์...............................................................................................................................................................29
วิธีกำรใช้งำน .........................................................................................................................................................29

3. 2
บทที่ 7 การขอเปลี่ยนแปลงรายการความต้องการซอฟต์แวร์ (Change request).............................................................33
วัตถุประสงค์..........................................................................................................................................................33
ประโยชน์...............................................................................................................................................................33
วิธีกำรนำไปใช้งำน................................................................................................................................................33
7.3.1 Introduction Section.....................................................................................................................................33
7.3.2 Change Request Detail Section....................................................................................................................33
7.3.3 Impact Analysis Section...............................................................................................................................34
7.3.4 Regression Test Plan Section.......................................................................................................................34
7.3.5 Effort Estimate Section.................................................................................................................................34
ตัวอย่ำงกำรใช้งำนแบบฟอร์มกำรขอเปลี่ยนแปลงรำยกำรควำมต้องกำรซอฟต์แวร์ ............................................35
บทที่ 8 รายงานการประชุม (Meeting report)..................................................................................................................38
วัตถุประสงค์..........................................................................................................................................................38
ประโยชน์...............................................................................................................................................................38
วิธีกำรใช้งำน .........................................................................................................................................................38
ตัวอย่ำงกำรใช้งำนรำยงำนกำรประชุม..................................................................................................................40
บทที่ 9 แบบฟอร์มแจ้งเหตุการณ์ไม่ปกติสาหรับซอฟต์แวร์ (Incident template)...........................................................41
วัตถุประสงค์..........................................................................................................................................................41
ประโยชน์...............................................................................................................................................................41
วิธีกำรใช้งำน .........................................................................................................................................................41
9.3.1 Information of Originator (ข้อมูลของผู้แจ้งเหตุกำรณ์ไม่ปกติที่เกิดขึ้น)......................................................41
9.3.2 Details of the Incident (รำยละเอียดของเหตุกำรณ์ไม่ปกติที่เกิดขึ้น)...........................................................41
9.3.3 Impact from Incident (ผลกระทบจำกเหตุกำรณ์ที่เกิดขึ้น)...........................................................................41
9.3.4 Analysis Solution of Incident (วิเครำะห์กำรแก้ปัญหำ)...............................................................................42
9.3.5 Resolution Solution of Incident (รำยละเอียดของวิธีกำรแก้ปัญหำ)............................................................42
9.3.6 Verification Solution of Incident (ทวนสอบวิธีกำรแก้ปัญหำ)....................................................................42
9.3.7 Responsibility (คนที่รับผิดชอบ)..................................................................................................................42
9.3.8 Conclusion (สรุปเหตุกำรณ์ไม่ปกติที่เกิดขึ้น ผลกระทบจำกเหตุกำรณ์ และวิธีกำรแก้ปัญหำ)....................42
9.3.9 Attachment List (เอกสำรแนบเพิ่มเติม)........................................................................................................42
บทที่ 10 แม่แบบกรณีทดสอบ (Testcase Template)..........................................................................................................47
วัตถุประสงค์..........................................................................................................................................................47
ประโยชน์...............................................................................................................................................................47
วิธีกำรใช้งำน .........................................................................................................................................................47
ตัวอย่ำงกำรใช้งำนเอกสำรกรณีทดสอบแม่แบบกรณีทดสอบ..............................................................................49

4. 3
สารบัญตาราง
ตำรำงที่ 1 : ตัวอย่ำงกำรใช้งำนแบบประเมิน.............................................................................................................................7
ตำรำงที่ 2 : ตัวอย่ำงกำรใช้งำนแบบบันทึกกำรตำมรอยในโครงกำรพัฒนำซอฟต์แวร์ ............................................................8
ตำรำงที่ 3 : ตัวอย่ำงกำรใช้งำนแบบบันทึกกำรตำมรอยในโครงกำรพัฒนำซอฟต์แวร์ ..........................................................12
ตำรำงที่ 4 : ตัวอย่ำงแบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุงกระบวนกำร.........................19
ตำรำงที่ 5 : ตัวอย่ำงกำรใช้งำนแบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุงกระบวนกำร........24
ตำรำงที่ 6 : ปัจจัยมีกำรกำหนดระดับกำรพิจำรณำควำมสำเร็จ...............................................................................................29
ตำรำงที่ 7 : ตัวอย่ำงเอกสำรกำรวิเครำะห์ช่องว่ำง...................................................................................................................30
ตำรำงที่ 8 : ตัวอย่ำงกำรใช้งำนแบบฟอร์มกำรขอเปลี่ยนแปลงรำยกำรควำมต้องกำรซอฟต์แวร์...........................................35
ตำรำงที่ 9 : ตัวอย่ำงรำยงำนกำรประชุม..................................................................................................................................39
ตำรำงที่ 10 : ตัวอย่ำงกำรใช้งำนรำยงำนกำรประชุม...............................................................................................................40
ตำรำงที่ 11 : ตัวอย่ำงแบบฟอร์มแจ้งเหตุกำรณ์ไม่ปกติสำหรับซอฟต์แวร์ .............................................................................43
ตำรำงที่ 12 : ตัวอย่ำงวิธีกำรใช้งำนแบบฟอร์มแจ้งเหตุกำรณ์ไม่ปกติสำหรับซอฟต์แวร์........................................................45
ตำรำงที่ 13 : ตัวอย่ำงเอกสำรแม่แบบกรณีทดสอบ.................................................................................................................48
ตำรำงที่ 14 : ตัวอย่ำงกำรใช้งำนเอกสำรกรณีทดสอบแม่แบบกรณีทดสอบ...........................................................................49

5. 4
ประวัติการแก้ไขเอกสาร
Version วันที่ การแก้ไข
1 17/04 เริ่มต้น
2 11/05 ปรับปรุงรูปแบบเอกสำร แก้คำผิด ตรวจสอบควำมถูกต้องของเอกสำร
3 12/05 เพิ่มรำยกำร Non-Requirement ของแบบบันทึกข้อมูลกำรตรวจสอบย้อนกลับ แก้ไขสำรบัญ
4 13/05 ตรวจสอบควำมถูกต้องของเอกสำร และปรับแก้ไขเพิ่มเติม
5 13/05 ตรวจสอบและแก้ไขควำมถูกต้องรอบสุดท้ำย

6. บทนา
5
บทที่ 1 บทนา
ที่มาและความสาคัญ
ในกำรพัฒนำกระบวนกำรซอฟต์แวร์นั้น จำเป็นต้องมีกำรสื่อสำร กำรจัดทำเอกสำรต่ำงๆ อย่ำงหลีกเลี่ยงไม่ได้ ซึ่ง
กำรมีแบบบันทึกข้อมูลที่เป็นมำตรฐำนสำมำรถลดควำมซ้ำซ้อนลดควำมสับสนในกำรติดต่อสื่อสำรสำมำรถเข้ำใจได้ง่ำย
มีขอบเขตในกำรดำเนินงำน และสำมำรถทวนสอบได้เพื่อเป็นกำรควบคุมให้แบบบันทึกข้อมูลไปในทำงเดียวกันและเพื่อ
ควำมเข้ำใจที่ตรงกันจึงจัดทำเอกสำรคู่มือแบบบันทึกข้อมูลฉบับนี้ขึ้นมำ
วัตถุประสงค์
1) เพื่อให้องค์กรรวมถึงหน่วยงำนและโครงกำรต่ำงๆมีแบบบันทึกข้อมูลที่เป็นมำตรฐำนสำหรับกำรพัฒนำกระบวนกำร
ซอฟต์แวร์ในแต่ละโครงกำร
2) เพื่อนำเสนอแนวทำงปฏิบัติในกำรทำแบบบันทึกข้อมูล
แนวทางการจัดทาแม่แบบบันทึกข้อมูล
กำรจัดทำแม่แบบสำหรับบันทึกข้อมูลประกอบกำรบวนกำรที่ได้นิยำมขึ้นนั้นได้อำศัยรำยกำรข้อมูลตำมที่กำหนด
ไว้ภำยใน Annex B ของมำตรฐำน ISO/IEC15504-5 ซึ่งได้กล่ำวถึงรำยกำรข้อมูลที่ควรจะปรำกฏอยู่ในผลิตภัณฑ์ (Work
Product) เช่น รำยกำรควำมรู้ (02-00: Knowledge Item) ควรจะประกอบไปด้วย ข้อมูลประสบกำรณ์ที่บรรจุ สิ่งที่ต้องกำร
แบ่งปัน (Documented for sharing)และ ข้อมูลควบคุมและบำรุงรักษำ (Controlledand maintained) ดังนั้นกำรจัดทำแม่แบบ
บันทึกข้อมูลในกระบวนกำรจึงได้ยึดเอำรำยกำรข้อมูลข้ำงต้นเป็นแนวทำงในกำรจัดทำแม่แบบบันทึกข้อมูล
ขอบเขต
เอกสำรฉบับนี้จัดทำขึ้นเพื่อสร้ำงแบบบันทึกข้อมูล ใช้ในกระบวนกำรบันทึกเอกสำรต่ำงๆในกำรพัฒนำ
ซอฟต์แวร์ โดยจะมีแบบบันทึกข้อมูลดังนี้
บทที่ 2 รำยกำรตรวจสอบ (Checklist)
บทที่ 3 กำรตรวจสอบย้อนกลับ (Traceability Metrix)
บทที่ 4 กำรออกแบบรำยละเอียดซอฟต์แวร์ (Software Detailed Design)
บทที่ 5 แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุงกระบวนกำร (Organization Readiness
Assessment)
บทที่ 6 กำรวิเครำะห์ช่องว่ำง (Gap-Analysis)
บทที่ 7 กำรขอเปลี่ยนแปลงรำยกำรควำมต้องกำรซอฟต์แวร์ (Change request)
บทที่ 8 รำยงำนกำรประชุม (Meeting report)
บทที่ 9 แบบฟอร์มแจ้งเหตุกำรณ์ไม่ปกติสำหรับซอฟต์แวร์ (Incident template)
บทที่ 10 แม่แบบกรณีทดสอบ (Testcase Template)

7. รำยกำรตรวจสอบ (Checklist)
6
บทที่ 2 รายการตรวจสอบ (Checklist)
ในขั้นตอนกำรพัฒนำซอฟต์แวร์นั้น หำกต้องกำรประเมินแบบซอฟต์แวร์จะต้องมีกำรประเมินตำมใบตรวจสอบ
เพื่อใช้เป็นเครื่องมือตรวจสอบคุณภำพของแบบซอฟต์แวร์ ซึ่งจะทำให้กำรพัฒนำซอฟต์แวร์นั้นเป็นไปตำมข้อกำหนดที่
ต้องกำร และไม่ผิดเพี้ยนไปมำกเท่ำที่ควร ดังนั้นเพื่อให้เกิดประสิทธิภำพในกำรทำงำนมำกที่สุด จึงได้สร้ำงแบบประเมิน
สำหรับบันทึกผลกำรประเมินเพื่อให้ทรำบได้ว่ำส่วนของซอฟต์แวร์นี้สอดรับกับข้อกำหนดด้ำนคุณภำพ โดยที่แต่ละสดมน์
นั้นจะมีควำมหมำย ดังนี้
วัตถุประสงค์
เพื่อใช้เป็นเครื่องมือตรวจสอบคุณภำพของแบบซอฟต์แวร์ ซึ่งจะทำให้กำรพัฒนำซอฟต์แวร์นั้นเป็นไปตำม
ข้อกำหนดที่ต้องกำร และไม่ผิดเพี้ยนไปมำกเท่ำที่ควร
ประโยชน์
1) สำมำรถทำกำรทวนสอบเอกสำรกำรออกแบบรำยละเอียดซอฟต์แวร์ในภำยหลังได้
2) เพื่อให้กำรปฏิบัติงำนเป็นไปในแนวทำงเดียวกัน
3) เพื่อให้ทีมพัฒนำสำมำรถทำงำนได้ง่ำยขึ้น
ส่วนรายการตรวจสอบ
1) รำยกำรตรวจสอบ: เป็นรำยกำรที่แสดงถึงข้อกำหนดต่ำง ๆ ที่ใช้ในกำรประเมินแบบซอฟต์แวร์
2) ผ่ำน: สำหรับให้ผู้ประเมินทำเครื่องหมำยถูก ในกรณีที่ผู้ประเมินเห็นว่ำแบบซอฟต์แวร์นั้นเป็นไปตำมข้อกำหนด
3) ไม่ผ่ำน: สำหรับให้ผู้ประเมินทำเครื่องหมำยถูก ในกรณีที่ผู้ประเมินเห็นว่ำแบบซอฟต์แวร์นั้นไม่เป็นไปตำม
ข้อกำหนด
4) หมำยเหตุ: สำหรับให้ผู้ประเมินบันทึกหมำยเหตุเพิ่มเติมหรือเสนอคำแนะนำสำหรับปรับปรุงเพื่อให้เป็นไปตำม
ข้อกำหนด
ส่วนการบันทึกแบบประเมิน
1) หัวข้อกำรตรวจทำน: กำหนดหัวข้อกำรตรวจสอบ เช่น กำรตรวจสอบรำยงำนกำรออกแบบรำยละเอียดกำรตรวจสอบ
กำรออกแบบสถำปัตยกรรม
2) วันที่ทำกำรตรวจทำน: กำหนดวันที่เป็น วัน เดือน ปี (พ.ศ.) ที่ทำกำรตรวจสอบ
3) ผู้ตรวจทำน: ระบุ ชื่อ นำมสกุลของผู้ตรวจสอบ
4) ผลกำรตรวจทำน และข้อบกพร่องที่พบ: สรุปผลกำรตรวจสอบ และระบุข้อบกพร่องเป็นข้อ ๆ
5) แนวทำงกำรแก้ไข: ระบุแนวทำงกำรแก้ไข ตำมข้อบกพร้อมที่พบ
6) ข้อเสนอแนะ: ระบุคำแนะนำอื่น ๆ ถ้ำมี
วิธีการใช้งาน
1) ผู้ตรวจสอบควรศึกษำวัตถุประสงค์ข้อนั้น ๆ ก่อนกำรตรวจสอบ

8. รำยกำรตรวจสอบ (Checklist)
7
2) สำหรับกำรตรวจสอบแบบจำลองให้ผู้ประเมินใช้ตำรำง รำยกำรตรวจสอบคุณภำพของโมเดลหรือแผนภำพแบบ
ซอฟต์แวร์ แยกตำมแบบจำลองหรือแผนภำพที่ต้องกำรประเมิน
3) สำหรับกำรตรวจสอบเอกสำรแบบซอฟต์แวร์ให้ผู้ประเมินใช้ตำรำง รำยกำรตรวจสอบคุณภำพของแบบกำรออกแบบ
ซอฟต์แวร์ (Software Detailed Document)
4) ผู้ประเมินสำมำรถทำกำรประเมินทั้งข้อ 2 และ 3 ได้ในกำรประเมิน 1 ครั้ง
5) ทำเครื่องหมำย ถูก ในช่องผ่ำนไม่ผ่ำนในแต่ละหัวข้อเท่ำนั้น
6) เมื่อบันทึกข้อมูลในรำยกำรตรวจสอบแล้ว ผู้ประเมินต้องบันทึกข้อมูลในแบบประเมิน ทุกครั้งและรวมเอกสำรทั้งใบ
ประเมิน และ รำยกำรตรวจสอบไว้ด้วยกัน
ตำรำงที่ 1 : ตัวอย่ำงกำรใช้งำนแบบประเมิน
ระบบธุรกรรมทางอินเทอร์เน็ตผ่านโมบายแอปพลิเคชัน
Checklist Summary Report
หัวข้อการตรวจทาน: กำรตรวจสอบเอกสำรกำรออกแบบรำยละเอียดซอฟต์แวร์
วันที่ทาการตรวจทาน: วันที่ 20 มกรำคม 2559
ผู้ตรวจทาน: ปฏิวัติ วิเศษศุกล
ผลการตรวจทาน และข้อบกพร่องที่พบ:
1. รำยกำรตรวจสอบยังพบว่ำมีเอกสำรที่มีข้อมูลไม่ครบถ้วน
2. องค์ประกอบของซอฟต์แวร์ ยังขำดกำรตรวจสอบย้อนกลับ
แนวทางการแก้ไข:
1. ให้ทีมงำนโครงกำรกลับไปทบทวนและปรับปรุงเอกสำรกำรออกแบบใหม่อีกครั้ง
ข้อเสนอแนะ:
ควรตรวจสอบให้แน่ใจว่ำทุกๆองค์ประกอบของซอฟต์แวร์ได้ถูกระบุไว้ในตำรำงตรวจสอบย้อนกลับ และ
เชื่อมโยงไปยังรำยกำรควำมต้องกำร และกำรออกแบบสถำปัตยกรรม

9. รายการตรวจสอบ (Checklist)
8
ตำรำงที่ 2 : ตัวอย่ำงกำรใช้งำนแบบบันทึกกำรตำมรอยในโครงกำรพัฒนำซอฟต์แวร์
ข้อ รายการตรวจสอบ ผ่าน ไม่ผ่าน หมายเหตุ
1 ระบบย่อยที่ได้ระบุออกมำจำกกำรออกแบบสะท้อนถึงหน้ำที่ควำม
รับผิดชอบอย่ำงชัดเจน

2 ชื่อของแต่ละระบบย่อยจะต้องไม่ซ้ำและมีควำมหมำยเป็นเอกลักษณ์สื่อถึง
หน้ำที่อย่ำงชัดเจน

3 ระบบย่อยเผยแพร่บริกำรผ่ำน Interface มีตรรกกะแสดงถึงบริกำรของ
ระบบย่อยอย่ำงชัดเจน

4 ระบบย่อยแต่ละระบบมีผู้ดูแลรับผิดชอบในกำรพัฒนำและดูแลรักษำอย่ำง
ชัดเจน

5 กำรพัฒนำระบบย่อยจะต้องมี Interface อย่ำงน้อยหนึ่ง Interface  ไ ม่ ป ร า ก ฏ
ผู้รับผิดชอบ
6 Interface มีควำมชัดเจนในคำอธิบำยและรำยละเอียดกำรพึ่งพำทรัพยำกร
หรือ Interface อื่น ๆ อย่ำงชัดเจน
 แผนภาพไม่
ชัดเจน
7 กำรพึ่งของ Interface ในแต่ละระบบย่อยจะต้องผ่ำน Interface เท่ำนั้น  มีการเข้าถึง
Object
โดยตรง โดย
ไม่ผ่าน
Interface
8 ข้อมูลที่จะช่วยผู้เรียกใช้Interface อย่ำงมีประสิทธิภำพจะต้องได้รับกำร
บันทึกไว้ในเอกสำรและอยู่ในที่ที่ผู้เรียกใช้สะดวกที่จะอ่ำนทำควำมเข้ำใจ
ได้ง่ำย

9 รำยละเอียดกำรทำงำนภำยในของระบบย่อยถูกเก็บรวบรวมซ่อนไว้ภำยใน
ด้ำนหลังของ interface

10 ระบบย่อยที่ได้ระบุออกมำจำกกำรออกแบบสะท้อนถึงหน้ำที่ควำม
รับผิดชอบอย่ำงชัดเจน

11 ชื่อของแต่ละระบบย่อยจะต้องไม่ซ้ำและมีควำมหมำยเป็นเอกลักษณ์สื่อถึง
หน้ำที่อย่ำงชัดเจน


10. รำยกำรตรวจสอบ (Checklist)
9
ข้อ รายการตรวจสอบ ผ่าน ไม่ผ่าน หมายเหตุ
12 ระบบย่อยเผยแพร่บริกำรผ่ำน Interface มีตรรกกะแสดงถึงบริกำรของ
ระบบย่อยอย่ำงชัดเจน

13 ระบบย่อยแต่ละระบบมีผู้ดูแลรับผิดชอบในกำรพัฒนำและดูแลรักษำอย่ำง
ชัดเจน

14 กำรพัฒนำระบบย่อยจะต้องมี Interface อย่ำงน้อยหนึ่ง Interface 
15 Interface มีควำมชัดเจนในกำรอธิบำยและรำยละเอียดกำรพึ่งพำทรัพยำกร
หรือ Interface อื่นๆอย่ำงชัดเจน

16 ทุกองค์ประกอบของกำรออกแบบรำยละเอียดสำมำรถตรวจสอบย้อนกลับ
ไปยังองค์ประกอบทำงสถำปัตยกรรม

17 กำรออกแบบรำยละเอียดมีควำมสอดคล้องกับสถำปัตยกรรมและควำม
ต้องกำร

18 องค์ประกอบของกำรออกแบบรำยละเอียดเป็ นแบบโมดูล (High
cohesion, Low coupling, Appropriate use of abstract interfaces)

19 กำรออกแบบมีข้อมูลเพียงพอต่อกำรพัฒนำและทดสอบ 

11. การตรวจสอบย้อนกลับ (Traceability Metrix)
10
บทที่ 3 การตรวจสอบย้อนกลับ (Traceability Metrix)
เอกสำรที่ใช้แสดงควำมสัมพันธ์ระหว่ำงรำยกำรควำมต้องกำรของระบบกับกำรทดสอบระบบย่อย ในส่วนของ
รำยละเอียดกำรออกแบบซอฟต์แวร์โดยเป็นควำมสัมพันธ์ แบบหลำยต่อหลำย (Manyto Many) อีกทั้งยังเป็นเครื่องมือที่
ช่วยทบทวนว่ำได้คิดหรือพิจำรณำครบถ้วนทุกประเด็นแล้ว ควำมสำมำรถในกำรตรวจสอบย้อนกลับที่เกี่ยวข้องกับ
ข้อกำหนดควำมต้องกำรของรำยละเอียดกำรออกแบบซอฟต์แวร์
วัตถุประสงค์
1) เพื่อให้เข้ำใจข้อกำหนดควำมต้องกำรของรำยละเอียดกำรออกแบบซอฟต์แวร์
2) สำมำรถบริหำรขอบเขตและกำรเปลี่ยนแปลงรำยกำรควำมต้องกำรในส่วนรำยละเอียดกำรออกแบบซอฟต์แวร์
3) เพื่อประเมินผลกระทบจำกควำมผิดพลำดจำกกำรทดสอบระบบที่เกี่ยวข้องกับควำมต้องกำรของระบบ
ประโยชน์
1) สำมำรถตรวจสอบให้แน่ใจว่ำทุกรำยกำรควำมต้องกำรได้ทำกำรพัฒนำครบหมด
2) สำมำรถช่วยในกำรทบทวนรำยกำรควำมต้องกำรว่ำได้ออกแบบรำยละเอียดซอฟต์แวร์ได้ครบถ้วนหรือไม่
3) ในครั้งต่อไปสำมำรถวำงแผลแลปรับปรุง รวมถึงกำรบันทึกรำยกำรควำมต้องกำรทั้งหมดพร้อมกับกำรทดสอบระบบได้
การใช้งานแบบฟอร์มตามรอย
ในขั้นตอนกำรพัฒนำซอฟต์แวร์นั้น หำกทรำบได้ว่ำส่วนหนึ่งส่วนใดของกำรพัฒนำนั้นเกิดมำจำกควำมต้องกำร
หรือเป้ำหมำยใดแล้วนั้น ก็จะทำให้กำรพัฒนำซอฟต์แวร์นั้นตรงกับควำมต้องกำร และไม่ผิดเพี้ยนไปมำกเท่ำที่ควร ดังนั้น
เพื่อให้เกิดประสิทธิภำพในกำรทำงำนมำกที่สุด จึงได้สร้ำงตำรำงตำมรอยสำหรับบันทึกข้อมูลกำรพัฒนำที่เกิดขึ้นเพื่อให้
ทรำบได้ว่ำส่วนของซอฟต์แวร์นี้สอดรับกับควำมต้องกำรใด โดยที่แต่ละสดมน์นั้นจะมีควำมหมำย ดังนี้
1) Requirement Source: จะใส่ข้อมูลแหล่งที่มำของควำมต้องกำรในภำพรวม ซึ่งใช้สื่อสำรกับผู้มีส่วนได้ส่วนเสีย หรือ
แบบจำลองกำรใช้งำน เช่น เป้ำหมำยทำงธุรกิจ กรณีกำรใช้งำน
2) ProductRequirements: รำยกำรควำมต้องกำรที่ปรำกฏอยู่ในผลิตภัณฑ์ ซึ่งรำยกำรควำมต้องกำรนี้จะสะท้อนมำจำก
ควำมต้องกำรใน ข้อที่ 1)
3) Non-Requirements: รำยกำรควำมต้องกำรที่ไม่ใช้กำรทำงำนหลักของโปรแกรม ซึ่งมีควำมสำคัญกับระบบงำน
4) HLDSection #หรือHighLevelDesignSection#:รหัสพร้อมชื่อของเค้ำโครงระดับบนที่ตอบรับกับควำมต้องกำรข้ำงต้น
5) LLD Section # หรือ Low Level Design Section #: รหัสและชื่อของเค้ำโครงระดับล่ำงที่แตกออกมำจำกเค้ำโครง
ระดับบน
6) Code Unit: ใส่รำยกำรของซอร์สโค้ดที่ตอบรับกับเค้ำโครงระดับล่ำง
7) UTS Case # หรือ Unit Test Specification Case #: รหัสของข้อกำหนดสำหรับกำรทดสอบในหน่วยย่อยที่เกี่ยวข้อง
8) STS Case # หรือ System Test Specification Case #: รหัสของข้อกำหนดสำหรับกำรทดสอบในระบบที่เกี่ยวข้อง
9) Priority: ระดับควำมสำคัญของรำยกำรควำมต้องกำร โดยแบ่งเป็น 3 ระดับ High, Medium, Low
10) User Manual: คู่มือกำรใช้งำนซอฟต์แวร์ที่มี

12. กำรตรวจสอบย้อนกลับ (Traceability Metrix)
11
วิธีการใช้งาน
1) แบบจำลองกำรใช้งำน (Use-case diagram) หรือข้อมูลต้นทำงอื่นๆ อันจะนำมำใช้สร้ำงเป็นรำยกำรควำมต้องกำร
ให้ใส่ไว้ในช่องด้ำนซ้ำยสุด
2) จำกสดมภ์แรกด้ำนซ้ำยมือ ถัดไปทำงด้ำนขวำเป็นรำยกำรควำมต้องกำร กำรออกแบบ หรือผลกำรทำงำนที่เกิดขึ้น
เพื่อสนับสนุนข้อมูลทำงด้ำนซ้ำยของกันและกัน
3) แต่ละช่องตำรำง ควรใส่ข้อมูลเท่ำที่จำเป็นซึ่งเพียงพอสำหรับกำรบ่งชี้ไปยังรำยกำรควำมต้อกำร ส่วนรับผิดชอบ หรือ
รำยกำรข้อกำหนดในกำรทำงำนได้อย่ำงชัดเจน
4) ในกรณีที่มีส่วนย่อยมำกกว่ำ 1 ส่วนประกอบที่ทำหน้ำที่สนับสนุนรำยกำรควำมต้องกำรก่อนหน้ำ สำมำรถแตกแถว
ตำรำงออกเป็น 2 แถว ด้ำนในได้
5) ตำรำงนี้เป็นตำรำงที่จัดทำเพื่อสนับสนุนข้อมูลกำรตำมรอยในโครงกำรพัฒนำซอฟต์แวร์ หำกจำเป็นที่จะต้องใช้
รำยละเอียดในกิจกรรมนั้นๆ ควรสร้ำงแบบฟอร์มที่เหมำะสมสำหรับกิจกรรมนั้นๆ เพิ่มเติม เช่น แบบฟอร์ม
ข้อกำหนดกำรทดสอบในหน่วยย่อยของซอฟต์แวร์ (Unit Test Specification)

13. การตรวจสอบย้อนกลับ (Traceability Metrix)
12
ตัวอย่างการใช้งานแบบบันทึกการตามรอยในโครงการพัฒนาซอฟต์แวร์
ตำรำงที่ 3 : ตัวอย่ำงกำรใช้งำนแบบบันทึกกำรตำมรอยในโครงกำรพัฒนำซอฟต์แวร์
Requirement Sources
Product
Requirements
Non-
Requirement
HLD
Section #
LLD
Section #
Code Unit UTS Case # STS Case # Priority User Manual
Business Rule #1 R00120 Credit Card
Type
NR00100
Performance
4.1 Parse
Mag Strip
4.1.1 Read
Card Type
Read_Card_Type.h
Read_Card_Type.c
UT 4.1.032
UT 4.1.033
UT 4.1.038
UT 4.1.043
ST 120.020
ST 120.021
ST 120.022
High Chapter 5, Section 12
4.1.2 Verify
Card Type
Ver_Card_Type.h
Ver_Card_Type.c
Ver_Card_Types.dat
UT 4.2.012
UT 4.2.013
UT 4.2.016
UT 4.2.037
UT 4.2.045
ST 120.035
ST 120.036
ST 120.037
High Chapter 5, Section 12
Use Case #132 step 6 R00230 Read Gas
Flow
NR00220
Speed Payment
7.2.2 Gas
Flow Meter
Interface
7.2.2 Read
Gas Flow
Indicator
Read_Gas_Flow.c UT 7.2.043
UT 7.2.044
ST 230.002
ST 230.003
Medium Chapter 7, Section 21.1.2
R00231 Calculate
Gas Price
NR00221
Calculate
7.3
Calculate
Gas price
7.3
Calculate
Gas price
Cal_Gas_Price.c UT 7.3.005
UT 7.3.006
UT 7.3.007
ST 231.001
ST 231.002
ST 231.003
Low Chapter 7, Section 21.1.3

14. การออกแบบรายละเอียดซอฟต์แวร์ (Software Detailed Design)
13
บทที่ 4 การออกแบบรายละเอียดซอฟต์แวร์ (Software Detailed Design)
ในส่วนของกำรพัฒนำเมื่อต้องมีกำรออกแบบรำยละเอียดซอฟต์แวร์ให้ตรงตำมรำยกำรควำมต้องกำรของผู้ใช้
แนวทำงกำรปฏิบัติที่ดีควรมีเอกสำรประกอบกำรออกแบบรำยละเอียดซอฟต์แวร์ให้ทำงทีมพัฒนำนำไปใช้เพื่อให้กำร
ทำงำนเป็นไปในแนวทำงเดียวกัน และสำมำรถทวนสอบจำกเอกสำรได้
วัตถุประสงค์
เพื่อเป็นเอกสำรประกอบกำรออกแบบรำยละเอียดซอฟต์แวร์ที่ประกำศใช้เป็นมำตรฐำนในกระบวนกำรพัฒนำ
ซอฟต์แวร์ในองค์กร เพื่อให้กำรปฏิบัติงำนเป็นไปในแนวทำงเดียวกัน
ประโยชน์
1) สำมำรถทำกำรทวนสอบเอกสำรกำรออกแบบรำยละเอียดซอฟต์แวร์ในภำยหลังได้
2) เพื่อให้กำปฏิบัติงำนเป็นไปในแนวทำงเดียวกัน
3) เพื่อให้ทีมพัฒนำสำมำถทำงำนได้ง่ำยขึ้น
วิธีการใช้งาน
แบบรายละเอียดซอฟต์แวร์ส่วนของ <ชื่อหน่วย>
บทนา
<ในส่วนนี้อธิบำยถึงกระบวนกำรออกแบบรำยละเอียดซอฟต์แวร์ของโครงกำร>
วัตถุประสงค์
<.ในส่วนนี้อธิบำยถึงวัตถุประสงค์ในกำรออกแบบรำยละเอียดซอฟต์แวร์ภำยในเอกสำร ซึ่งอำจจะกล่ำวถึง
วัตถุประสงค์หรือข้อกำหนดควำมต้องกำรที่ก่อให้เกิดกำรออกแบบในส่วนนี้ขึ้น>
ภาพรวมของเอกสาร
<ในส่วนนี้อธิบำยถึงรำยละเอียดของแบบรำยละเอียดซอฟต์แวร์ที่กล่ำวถึงภำยในเอกสำรนี้ว่ำประกอบด้วยส่วน
ใดบ้ำง และอยู่ภำยใต้ส่วนใดของซอฟต์แวร์>
รายการเอกสารที่เกี่ยวข้อง
รหัสเอกสาร ชื่อเอกสาร ประเภทเอกสาร
<รหัส> <ชื่อเอกสำร> <ประเภท>

15. กำรออกแบบรำยละเอียดซอฟต์แวร์ (Software Detailed Design)
14
ภาพรวมแบบโครงสร้างซอฟต์แวร์
<ในส่วนนี้อธิบำยภำพรวมของแบบโครงสร้ำงซอฟต์แวร์ที่เกี่ยวข้อง โดยอำจใช้คำอธิบำยถึงควำมเกี่ยวข้องและ
ส่วนต่อประสำนที่ใช้กับส่วนของซอฟต์แวร์ หรือใช้แผนภำพ UML พร้อมคำอธิบำย หรืออำจใช้กำรอ้ำงอิงไปยังเอกสำรที่
เกี่ยวข้อง เพื่อให้เห็นภำพรวมของแบบรำยละเอียดซอฟต์แวร์>
แบบรายละเอียดซอฟต์แวร์
<ในส่วนนี้อธิบำยถึงภำพรวมของแบบรำยละเอียดซอฟต์แวร์ ซึ่งควรอยู่ในระดับ sub-system packageหรือmodule>
<ใช้แผนภำพ UML ที่เกี่ยวข้อง เช่น Class Diagram Deployment Diagram เป็นต้นเพื่อช่วยอธิบำย>
ส่วนต่อประสานของซอฟต์แวร์
<รำยกำรของส่วนต่อประสำนของหน่วยซอฟต์แวร์นี้และข้อมูลนำเข้ำ ข้อมูลส่งออก>
ลาดับที่ ชื่อส่วนต่อประสาน ข้อมูลนาเข้า ข้อมูลส่งออก
<ลาดับ> <ชื่อของส่วนต่อประสำน> <รำยกำรข้อมูลนำเข้ำ> <รำยกำรข้อมูลส่งออก>
รายละเอียดของหน่วยย่อย หน่วยที่ <หมายเลข> <ชื่อ>
<ในส่วนนี้จะอธิบำยถึงหน่วยย่อยต่ำงๆของซอฟต์แวร์ที่เป็นส่วนประกอบของ packageหรือmoduleที่ได้กล่ำวไว้
โดยที่หน่วยย่อยเหล่ำนี้ควรอยู่ในระดับ module หรือ class>
แบบของหน่วยซอฟต์แวร์
<อธิบำยถึงหน่วยซอฟต์แวร์ อำจใช้แผนภำพ UML ในกำรอธิบำยเช่น Package Diagram Class Diagram เป็นต้น>
ส่วนต่อประสานของหน่วยซอฟต์แวร์
<รำยกำรของส่วนต่อประสำนของหน่วยย่อยซอฟต์แวร์นี้และข้อมูลนำเข้ำ ข้อมูลส่งออก>
ลาดับที่ ชื่อส่วนต่อประสาน ข้อมูลนาเข้า ข้อมูลส่งออก
<ลาดับ> <ชื่อของส่วนต่อประสำน> <รำยกำรข้อมูลนำเข้ำ> <รำยกำรข้อมูลส่งออก>
กระบวนการทางานและอัลกอริทึม
<อธิบำยถึงกระบวนกำรทำงำนของหน่วยซอฟต์แวร์โดยใช้แผนภำพ UML เช่น Collaboration Diagram
SequenceDiagram เป็นต้น หรืออธิบำยถึงอัลกอริทึมที่ที่ใช้โดยสังเขป อำจเขียนเป็นซูโดโค้ดเพื่อให้สำมำรถ
ตรวจสอบได้>
ข้อกาหนดความต้องการที่เกี่ยวข้องด้าน Functional
<ตำรำงรำยกำรข้อกำหนดควำมต้องกำรที่ก่อให้เกิดกำรออกแบบของหน่วยย่อยซอฟต์แวร์นี้ขึ้นมำ>
รหัส ข้อกาหนดความต้องการ
<รหัส> <คำอธิบำยของข้อกำหนดควำมต้องกำร>

16. กำรออกแบบรำยละเอียดซอฟต์แวร์ (Software Detailed Design)
15
ข้อกาหนดความต้องการที่เกี่ยวข้องด้าน Non-Functional
<ตำรำงรำยกำรข้อกำหนดควำมต้องกำรที่ก่อให้เกิดกำรออกแบบของหน่วยย่อยซอฟต์แวร์นี้ขึ้นมำ>
รหัส ข้อกาหนดความต้องการ
<รหัส> <คำอธิบำยของข้อกำหนดควำมต้องกำร>
รายการทดสอบที่เกี่ยวข้อง
<ตำรำงรำยกำรทดสอบที่เกิดขึ้นจำกแบบของหน่วยย่อยซอฟต์แวร์นี้>
รหัส รายการทดสอบ
<รหัส> <คำอธิบำยของรำยกำรทดสอบ>
ตัวอย่างเอกสารประกอบการออกแบบรายละเอียดซอฟต์แวร์
บทนา
กำรออกแบบภำยในโครงกำรใช้กระบวนกำรกำรออกแบบเชิงวัตถุเป็นแนวทำง โดยเน้นที่กำรจัดกำร coupling
และ cohesion ภำยในแบบตั่งแต่กระบวนกำรออกแบบเพื่อลดปัญหำที่จะเกิดขึ้นในอนำคต
วัตถุประสงค์
1. เพื่อให้ใด้แบบในกำรพัฒนำระบบสั่งซื้อสินค้ำ ผ่ำนเว็บไชต์
2. เพื่อให้ได้ระบบที่รองรับกำรใช้งำนที่มีรำยกำรสั่งซื้อ 10,000 รำยกำรต่อนำที
3. เพื่อให้ระบบที่พัฒนำขึ้นผ่ำนมำตรฐำนกำรรับรองควำมปลอดภัยขององค์กร
ภาพรวมของเอกสาร
เอกสำรฉบับนี้อธิบำยถึงกำรออกแบบส่วนของกำรสั่งซื้อ ซึ่งเชื่อมต่อกับระบบกำรค้นข้อมูลในฐำนข้อมูล
รายการเอกสารที่เกี่ยวข้อง
รหัสเอกสาร ชื่อเอกสาร ประเภทเอกสาร
REQ-MA-05 ข้อกำหนดควำมต้องกำร เอกสำรควำมต้องกำร
TES-MA-05 รำยกำรทดสอบส่วนกำรติดต่อฐำนข้อมูล เอกสำรกำรทดสอบ

17. กำรออกแบบรำยละเอียดซอฟต์แวร์ (Software Detailed Design)
16
ภาพรวมแบบโครงสร้างซอฟต์แวร์
ภำพที่ 1 ภำพรวมโครงสร้ำง
ส่วนของซอฟต์แวร์ส่วนนี้เป็นกำรทำงำนในส่วนของกำรสั่งซื้อและติดต่อกับฐำนข้อมูล โดยประกอบไปด้วย 6
ส่วนดังภำพ
แบบรายละเอียดซอฟต์แวร์
ส่วนต่อประสานของซอฟต์แวร์
ลาดับที่ ชื่อส่วนต่อประสาน ข้อมูลนาเข้า ข้อมูลส่งออก
1 getProductDetails productID -
2 addProductToCart productID -
รายละเอียดของหน่วยย่อย หน่วยที่ 1 ตะกร้าสินค้า
แบบของหน่วยซอฟต์แวร์
ภำพที่ 2 ตะกร้ำสินค้ำ
เป็นส่วนของกำรเก็บรำยกำรสินค้ำก่อนที่จะสั่งซื้อโดยใช้ข้อมูลจำกฐำนข้อมูล ผู้ใช้สำมำรถ เพิ่มหรือลดสินค้ำจำก
รำยกำรสินค้ำได้

18. กำรออกแบบรำยละเอียดซอฟต์แวร์ (Software Detailed Design)
17
ส่วนต่อประสานของหน่วยซอฟต์แวร์
ลาดับที่ ชื่อส่วนต่อประสาน ข้อมูลนาเข้า ข้อมูลส่งออก
1 placeOrder productID -
2 cancelOrder productID -
กระบวนการทางานและอัลกอริทึม
ภำพที่ 3 กระบวนกำรเพิ่มสินค้ำลงตะกร้ำ
ข้อกาหนดความต้องการที่เกี่ยวข้องด้าน Functional
รหัส ข้อกาหนดความต้องการ
REQ-MA-05-04 ผู้ใช้สำมำรถเพิ่มสินค้ำลงตะกร้ำสินค้ำจำกรำยกำรสินค้ำที่มีได้
REQ-MA-05-06 ผู้ใช้สำมำรถลบสินค้ำจำกตะกร้ำสินค้ำจำกรำยกำรสินค้ำที่เพิ่มไว้ได้
ข้อกาหนดความต้องการที่เกี่ยวข้องด้าน Non- Functional
รหัส ข้อกาหนดความต้องการ
REQ-MA-05-01 ระบบที่พัฒนำขึ้นต้องมีมำตรฐำนควำมปลอดภัยตำมเกณฑ์มำตรฐำนขององค์กร
REQ-MA-05-07 ระบบสำมำรถรองรับกำรใช้งำน 10,000 รำยกำรต่อนำที
รายการทดสอบที่เกี่ยวข้อง
รหัส รายการทดสอบ
TES-MA-05-01 ทดสอบกำรเชื่อมต่อฐำนข้อมูล
TES-MA-05-02 ทดสอบกำรเพิ่มสินค้ำจำกตะกร้ำสินค้ำ
TES-MA-05-03 ทดสอบกำรลบสินค้ำจำกตะกร้ำสินค้ำ

19. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
18
บทที่ 5 แบบสารวจความพร้อมขององค์กรต่อการเปลี่ยนแปลงด้านการปรับปรุง
กระบวนการ (Organization Readiness Assessment)
กำรปรับปรุงกระบวนกำรนั้นส่งผลให้เกิดกำรเปลี่ยนแปลงทั้งองค์กร จำเป็นต้องอำศัยควำมร่วมมือกันของ
ทุกหน่วยงำนภำยในองค์กร ดังนั้นหำกต้องกำรประเมินว่ำองค์กรพร้อมที่จะเปลี่ยนแปลงมำกน้อยแค่ไหนนั้น ก็ต้องศึกษำ
ควำมพร้อมของหน่วยงำนหรือมุมมองที่มีส่วนสำคัญในกำรเปลี่ยนแปลงภำยในองค์กร
วัตถุประสงค์
เพื่อใช้เป็นแนวทำงในกำรศึกษำและบันทึกผลกำรประเมินควำมพร้อมขององค์กำรต่อกำรเปลี่ยนแปลงที่เกิดจำก
กำรปรับปรุงกระบวนกำร
ประโยชน์
เพื่อศึกษำควำมพร้อมของหน่วยงำนหรือมุมมองที่มีส่วนสำคัญในกำรเปลี่ยนแปลงภำยในองค์กร
วิธีการใช้งาน
1) ผู้ประเมินควรศึกษำปัจจัยในข้อนั้นจำกข้อมูลที่ปรำกฏอยู่ภำยในองค์กรอย่ำงรอบด้ำน
2) พิจำรณำข้อมูลที่เกี่ยวข้องและสรุปผลเพื่อให้น้ำหนักกับแต่ละปัจจัย
3) ทำเครื่องหมำยกำกบำท “X” ในช่องน้ำหนักที่เหมำะสมกับปัจจัยที่พิจำรณำ
4) หำกน้ำหนักที่เหมำะสมนั้นมีค่ำมำกกว่ำ 0 นั่นหมำยควำมว่ำรำยกำรที่พิจำรณำนั้นแสดงคุณสมบัติในข้อที่มีน้ำหนัก
น้อยกว่ำอย่ำงครบถ้วนด้วย
คาอธิบาย
แบบสำรวจนี้ประกอบไปด้วย 5 ส่วนด้วยกัน คือ
1) รำยกำรประเมินควำมพร้อมขององค์กร
2) รำยกำรควำมมุ่งมั่นและควำมพร้อมของผู้สนับสนุน
3) รำยกำรประเมินควำมมุ่งมั่นและควำมพร้อมของผู้ผลักดันกำรเปลี่ยนแปลง
4) รำยกำรประเมินด้ำนควำมเชี่ยวชำญและประสบกำรณ์องค์กร
5) ข้อเสนอแนะเพิ่มเติม
แต่ละปัจจัยจะมี 6 น้ำหนัก ได้แก่
1) ไม่มีกระบวนกำร มำตรกำร หรือพฤติกรรมที่แสดงให้เห็นได้มำก่อน
2) ระบุขั้นตอน วิธีกำร หน้ำที่ปฏิบัติ หรือแสดงให้เห็นว่ำมีกำรกระทำ ในองค์กรอยู่แล้ว หำกแต่ยังไม่ได้กำหนดกำร
หน้ำที่ ผู้รับผิดชอบอย่ำงชัดเจน
3) ขั้นตอน วิธีกำร หน้ำที่ปฏิบัติ หรือพฤติกรรม มีกำรจัดกำร อันได้แก่ บันทึกผลลัพธ์ และทำรำยงำนจัดเก็บไว้
4) ขั้นตอน วิธีกำร หน้ำที่ปฏิบัติ หรือพฤติกรรม มีกำรกำหนดและประกำศบทบำท หน้ำที่ควำมรับผิดชอบอย่ำงชัดเจน
และกำหนดกำรทำงำนกับขั้นตอนหรือกระบวนกำรอื่นๆ เพื่อให้เกิดกำรบูรณำกำร

20. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
19
5) ขั้นตอน วิธีกำร หน้ำที่ปฏิบัติ หรือพฤติกรรม ได้รับกำรบันทึกผลกำร ตรวจวัดอย่ำงเหมำะสม จนสำมำรถนำมำ
ประเมินเพื่อควบคุมได้
6) สำมำรถนำเอำผลของ ขั้นตอน วิธีกำร หน้ำที่ปฏิบัติ หรือพฤติกรรม ที่บันทึกไว้มำปรับปรุงกำรทำงำน
ตำรำงที่ 4 : ตัวอย่ำงแบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุงกระบวนกำร
ตอนที่ 1: รายการประเมินความพร้อมขององค์กร
รายการคาถาม 5 4 3 2 1 0
1. Management Issues
1.1 New senior management
1.2 New skills or employee retention
1.3 Culture change effort
1.4 Performance appraisal
1.5 Major reorganization or downsizing
2. Process Changes
2.1 New customer services program
2.2 Ongoing quality initiative
2.3 New Quality initiative
2.4 Productivity improvement project
2.5 History on pass improvement projects
3. Operational and Legal
3.1 New Technology introduction
3.2 Major construction project
3.3 Working extra-time
3.4 Strike
3.5 Majjor Litigation

21. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
20
ตอนที่ 2: รายการความมุ่งมั่นและความพร้อมของผู้สนับสนุน
รายการคาถาม 5 4 3 2 1 0
1. Whate the Sponsor(s) Expresses
1.1 Expressed how SPI relates to company strategy
1.2 Expressed strong personal commitment to SPI
1.3 Communicates clear and understandable message
1.4 Communicates the impact to affected individuals
1.5 Communicates objectives of SPI to organization
1.6 Promotes problem solving attitude
1.7 Publically expresses behaviours that must changes
1.8 Communicates to encourage direct feedback
2. Observable Sponsor Characteristics
2.1 Strong motivation to implement SPI
2.2 Believes in the business benefits of SPI
2.3 Shows strong support if SPI to direct reports
2.4 Demonstrates personal changes aligned with SPI
2.5 Demonstrates willingness to pay the price for SPI
2.6 Strong and tenacious in pursuing the SPI activities
2.7 Invests effort to build support for the CPI effort
2.8 Has good relationship with change implement
2.9 Has good relationship with people affect by SPI
2.10 Has a good track record in past change initiatives
3. How Sponsor Acts
3.1 Commits the neccessary resources to SPI
3.2 Establishes incentives to reinforce change
3.3 Emphasizes rewards for achieving change
3.4 Focuses on reinforcement on direct reports
3.5 Emphasizes formal and information recognition
3.6 Links rewards to the achievement of change
3.7 Establishes mechanisms for data gathering to
monitor progress of changes
3.8 Makes clear how to report SPI progress
3.9 Makes old behaviours difficult to perform
3.10 Makes new behaviours easier to perform

22. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
21
ตอนที่ 3: รายการประเมินความมุ่งมั่นและความพร้อมของผู้ผลักดันการเปลี่ยนแปลง
รายการคาถาม 5 4 3 2 1 0
1. What Change Agent Expresses
1.1 Believes on the rewards of SPI
1.2 Understands the disruption that change will
bring
1.3 Is committed to the goals of the SPI project
1.4 Expresses interest in being responsible for SPI
1.5 Is optimistic about the potential SPI results
1.6 Expresses confidence in Sponsor’scommitment
1.7 Believes in a positive personal future through
SPI
1.8 Express enthusiasm about the SPI initiative
1.9 Is happy with time and resources available for
SPI
2. Observable Change Agent Charactersitics
2.1 Has a successful history in the organization
2.2 Is reviewd as competent in current position
2.3 Experience working with different groups
2.4 Experience working with all levels of
management
2.5 Knowledgeable of perspectives/needs of
sponsor
2.6 Has trust, respect, and credibility with the
sponsor
2.7 Is viewed as a real asset to the SPI project
2.8 Knowledgeable of the perspectives and needs
of affected people in SPI initiative
2.9 Affected people respect and trust the change
agent
2.10 Effectively manages resistance to change
2.11 Works well with structure of the organization
2.12 Understands the organization’s culture
2.13 Has a working “change” principle
2.14 Possesses high level of analytical skills

23. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
22
รายการคาถาม 5 4 3 2 1 0
2.15 Understandsthe value of human and business
issues
2.16 Has excellent communication skills
2.17 Is a team player
2.18 Is proactive, sets goals, and achieves them
2.19 Enjoys challenge and uncertainty
2.20 Feels comfortable working with sponsor
3. How Change Agent Acts
3.1Hassufficient time to dedicate tothe SPIproject
3.2 Exerts sufficient authority to make changes
3.3 Energizes the organization to promote changes
3.4 Has access to sufficient resources for SPI
initiative
3.5 Knows when and how to use power and
influence
3.6 Generates a high level of team work
3.7 Has vested personal commitment to the SPI
project
3.8 Is proactively seeking creative solutions
3.9 Is proactively informing sponsor about SPI
progress
3.10 Has properly planned SPI project

24. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
23
ตอนที่ 4: รายการประเมินด้านความเชี่ยวชาญและประสบการณ์องค์กร
รายการคาถาม 5 4 3 2 1 0
1. Sponsor Expertise/Experience
1.1 Experience in change management
1.2 Knowledgeof SPI technology (CMMI, IEEE...)
1.3 Experience in continuous process improment
2. Change Agent Expertise/Experience
2.1 Knowledge/expertise in change management
2.2 Expertise of SPI technology (CMMI, IEEE...)
2.3 Experience of SPI technology (CMMI, IEEE...)
2.4 Change Agent experience in change
management
2.5 Experience in continuous process improvement
3. Organizational Expertise/Experience
3.1 Expertise of SPI technology (CMMI, IEEE...)
3.2ExperienceofSPITechnology(CMMI,IEEE...)
3.3 Experience on participating in change
management
3.4 Expertise in continuous process improvement
3.5 Experience in continuous process improvement
ตอนที่ 5: ข้อเสนอแนะ หรือบันทึกอื่นๆ

25. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
24
ตัวอย่างแบบสารวจความพร้อมขององค์กรต่อการเปลี่ยนแปลงด้านการปรับปรุงกระบวนการ
ตำรำงที่ 5 : ตัวอย่ำงกำรใช้งำนแบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุงกระบวนกำร
ตอนที่ 1: รายการประเมินความพร้อมขององค์กร
รายการคาถาม 5 4 3 2 1 0
1. Management Issues
1.1 New senior management /
1.2 New skills or employee retention /
1.3 Culture change effort /
1.4 Performance appraisal /
1.5 Major reorganization or downsizing /
2. Process Changes
2.1 New customer services program /
2.2 Ongoing quality initiative /
2.3 New Quality initiative /
2.4 Productivity improvement project /
2.5 History on pass improvement projects /
3. Operational and Legal
3.1 New Technology introduction /
3.2 Major construction project /
3.3 Working extra-time /
3.4 Strike /
3.5 Majjor Litigation /

26. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
25
ตอนที่ 2: รายการความมุ่งมั่นและความพร้อมของผู้สนับสนุน
รายการคาถาม 5 4 3 2 1 0
1. Whate the Sponsor(s) Expresses
1.1 Expressed how SPI relates to company strategy /
1.2 Expressed strong personal commitment to SPI /
1.3 Communicates clear and understandable message /
1.4 Communicates the impact to affected individuals /
1.5 Communicates objectives of SPI to organization /
1.6 Promotes problem solving attitude /
1.7 Publically expresses behaviours that must changes /
1.8 Communicates to encourage direct feedback /
2. Observable Sponsor Characteristics
2.1 Strong motivation to implement SPI /
2.2 Believes in the business benefits of SPI /
2.3 Shows strong support if SPI to direct reports /
2.4 Demonstrates personal changes aligned with SPI /
2.5 Demonstrates willingness to pay the price for SPI /
2.6 Strong and tenacious in pursuing the SPI activities /
2.7 Invests effort to build support for the CPI effort /
2.8 Has good relationship with change implement /
2.9 Has good relationship with people affect by SPI /
2.10 Has a good track record in past change initiatives /
3. How Sponsor Acts
3.1 Commits the neccessary resources to SPI /
3.2 Establishes incentives to reinforce change /
3.3 Emphasizes rewards for achieving change /
3.4 Focuses on reinforcement on direct reports /
3.5 Emphasizes formal and information recognition /
3.6 Links rewards to the achievement of change /
3.7 Establishes mechanisms for data gathering to
monitor progress of changes
/
3.8 Makes clear how to report SPI progress /
3.9 Makes old behaviours difficult to perform /
3.10 Makes new behaviours easier to perform /

27. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
26
ตอนที่ 3: รายการประเมินความมุ่งมั่นและความพร้อมของผู้ผลักดันการเปลี่ยนแปลง
รำยกำรคำถำม 5 4 3 2 1 0
1. What Change Agent Expresses
1.1 Believes on the rewards of SPI /
1.2 Understands the disruption that change will
bring
/
1.3 Is committed to the goals of the SPI project /
1.4 Expresses interest in being responsible for SPI /
1.5 Is optimistic about the potential SPI results /
1.6 Expresses confidence in Sponsor’scommitment /
1.7 Believes in a positive personal future through
SPI
/
1.8 Express enthusiasm about the SPI initiative /
1.9 Is happy with time and resources available for
SPI
/
2. Observable Change Agent Charactersitics
2.1 Has a successful history in the organization /
2.2 Is reviewd as competent in current position /
2.3 Experience working with different groups /
2.4 Experience working with all levels of
management
/
2.5 Knowledgeable of perspectives/needs of
sponsor
/
2.6 Has trust, respect, and credibility with the
sponsor
/
2.7 Is viewed as a real asset to the SPI project /
2.8 Knowledgeable of the perspectives and needs
of affected people in SPI initiative
/
2.9 Affected people respect and trust the change
agent
/
2.10 Effectively manages resistance to change /
2.11 Works well with structure of the organization /
2.12 Understands the organization’s culture /
2.13 Has a working “change” principle /
2.14 Possesses high level of analytical skills /

28. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
27
รำยกำรคำถำม 5 4 3 2 1 0
2.15 Understandsthe value of human and business
issues
/
2.16 Has excellent communication skills /
2.17 Is a team player /
2.18 Is proactive, sets goals, and achieves them /
2.19 Enjoys challenge and uncertainty /
2.20 Feels comfortable working with sponsor /
3. How Change Agent Acts
3.1Hassufficient time to dedicate tothe SPIproject /
3.2 Exerts sufficient authority to make changes /
3.3 Energizes the organization to promote changes /
3.4 Has access to sufficient resources for SPI
initiative
/
3.5 Knows when and how to use power and
influence
/
3.6 Generates a high level of team work /
3.7 Has vested personal commitment to the SPI
project
/
3.8 Is proactively seeking creative solutions /
3.9 Is proactively informing sponsor about SPI
progress
/
3.10 Has properly planned SPI project /

29. แบบสำรวจควำมพร้อมขององค์กรต่อกำรเปลี่ยนแปลงด้ำนกำรปรับปรุง
กระบวนกำร (Organization Readiness Assessment)
28
ตอนที่ 4: รายการประเมินด้านความเชี่ยวชาญและประสบการณ์องค์กร
รำยกำรคำถำม 5 4 3 2 1 0
1. Sponsor Expertise/Experience
1.1 Experience in change management /
1.2 Knowledgeof SPI technology (CMMI, IEEE...) /
1.3 Experience in continuous process improment /
2. Change Agent Expertise/Experience
2.1 Knowledge/expertise in change management /
2.2 Expertise of SPI technology (CMMI, IEEE...) /
2.3 Experience of SPI technology (CMMI, IEEE...) /
2.4 Change Agent experience in change
management
/
2.5 Experience in continuous process improvement /
3. Organizational Expertise/Experience
3.1 Expertise of SPI technology (CMMI, IEEE...) /
3.2ExperienceofSPITechnology(CMMI,IEEE...) /
3.3 Experience on participating in change
management
/
3.4 Expertise in continuous process improvement /
3.5 Experience in continuous process improvement /
ตอนที่ 5: ข้อเสนอแนะ หรือบันทึกอื่นๆ

30. กำรวิเครำะห์ช่องว่ำง (Gap-Analysis)
29
บทที่ 6 การวิเคราะห์ช่องว่าง (Gap-Analysis)
จุดมุ่งหมำยในกำรประเมินควำมสำมำรถของกระบวนกำรนั้นคือกำรตรวจประเมินเบื้องต้นเพื่อหำควำมแตกต่ำง
(Gap Analysis) ของระบบกำรทำงำนที่เป็นอยู่ปัจจุบันขององค์กรกับข้อกำหนดของมำตรฐำนที่ต้องกำรจัดทำซึ่งจะทำให้
ทรำบว่ำต้องเพิ่มกิจกรรมเข้ำไป เพื่อให้กระบวนกำรทำงำนสอดคล้องตำมข้อกำหนดของมำตรฐำน และจะใช้วัด
ควำมสำมำรถของกระบวนกำรอีกครั้ง หลังจำกที่ได้ดำเนินกำรปรับปรุงกระบวนกำรเสร็จสมบูรณ์
วัตถุประสงค์
เพื่อตรวจประเมินเบื้องต้นเพื่อหำควำมแตกต่ำง (Gap Analysis) ของระบบกำรทำงำนที่เป็นอยู่ปัจจุบันขององค์กร
กับข้อกำหนดของมำตรฐำนที่ต้องกำรจัดทำ
ประโยชน์
เพื่อให้กระบวนกำรทำงำนสอดคล้องตำมข้อกำหนดของมำตรฐำน และจะใช้วัดควำมสำมำรถของกระบวนกำร
อีกครั้ง หลังจำกที่ได้ดำเนินกำรปรับปรุงกระบวนกำรเสร็จสมบูรณ์
วิธีการใช้งาน
1) ผู้ประเมินควรศึกษำปัจจัยในข้อนั้นจำกข้อมูลที่ปรำกฏอยู่ภำยในองค์กรอย่ำงรอบด้ำน
2) พิจำรณำข้อมูลที่เกี่ยวข้องและสรุปผลเพื่อให้น้ำหนักกับแต่ละปัจจัย
3) ทำเครื่องหมำย F L P N ในช่องน้ำหนักที่เหมำะสมกับปัจจัยที่พิจำรณำ
คาอธิบาย
แบบสำรวจนี้ประกอบไปด้วย 4 ส่วนด้วยกัน คือ
1) รำยกำรประเมินด้ำนกระบวนกำรระดับที่ 1 ตำมกระบวนกำรออกแบบรำยละเอียดซอฟต์แวร์
2) รำยกำรประเมินกระบวนกำรระดับที่ 2 ด้ำนกำรจัดกำร
3) รำยกำรประเมินกระบวนกำรระดับที่ 3 ด้ำนกำรยอมรับและใช้งำนร่วมกัน
4) ข้อเสนอแนะเพิ่มเติม
แต่ละปัจจัยมีกำรกำหนดระดับกำรพิจำรณำควำมสำเร็จ 4 ระดับ ดังตำรำงที่ 6
ตำรำงที่ 6 : ปัจจัยมีกำรกำหนดระดับกำรพิจำรณำควำมสำเร็จ
Grade Rating Achievements
F ประสบควำมสำเร็จมำก
(Fully achieved)
86-100% ระบบสมบูรณ์หรือประสิทธิภำพ เกือบ เสร็จสมบูรณ์
L ประสบควำมสำเร็จพอสมควร
(Largely achieved)
51-85% ระบบมีควำมสำเร็จแต่บำงส่วนมีประสิทธิภำพต่ำ
P ประสบควำมสำเร็จบำงส่วน
(Partially achieved)
16-50% สำเร็จบำงส่วน ไม่มีกำรควบคุมกระบวนกำร
N ไม่สำเร็จ
(Not achieved)
0-15% สำเร็จน้อยหรือไม่สำเร็จ

31. กำรวิเครำะห์ช่องว่ำง (Gap-Analysis)
30
ตำรำงที่ 7 : ตัวอย่ำงเอกสำรกำรวิเครำะห์ช่องว่ำง
ตอนที่ 1 : รายการประเมินด้านกระบวนการออกแบบรายละเอียดซอฟต์แวร์ตามมาตรฐาน ISO 12207
หัวข้อ เป้าหมาย
ผลการ
ประเมิน
1. มีกำรกำหนดขอบเขตและวัตถุประสงค์ของกระบวนกำร เพื่อให้ผลลัพธ์ของกระบวนกำรอยู่
ภำยใต้ขอบเขตและวัตถุประสงค์ที่วำงไว้
1.1 PA 1.1 มีกระบวนกำรในกำรออกแบบรำยละเอียดซอฟต์แวร์
1.1.1 มีกำรพัฒนำออกแบบรำยละเอียดซอฟต์แวร์ N
1.1.2 มีกำรกำหนดอินเทอร์เฟซของหน่วยย่อยของซอฟต์แวร์ L
1.1.3 มีกำรวิเครำะห์ควำมสำมำรถในกำรทดสอบย้อนกลับ ของกำรออกแบบรำยละเอียด
ซอฟต์แวร์
N
1.1.4 มีกำรตรวจสอบควำมสอคล้อง N
ตอนที่ 1.1 : รายการประเมินด้านข้อมูลนาเข้ากระบวนการ
หัวข้อ เป้าหมาย
ผลการ
ประเมิน
1.2.1 มีข้อมูลกำรออกแบบซอฟต์แวร์ระดับสูง F
1.2.2 มีข้อกำหนดส่วนต่อประสำนระดับสูง F
1.2.3 มีข้อกำหนดควำมต้องกำร F
ตอนที่ 1.2 : รายการประเมินด้านผลลัพธ์กระบวนการ
หัวข้อ เป้าหมาย
ผลการ
ประเมิน
1.3.1 มีผลลัพธ์เป็นกำรออกแบบฐำนข้อมูล F
1.3.2 มีผลลัพธ์เป็นกำรออกแบบซอฟต์แวร์ระดับล่ำง N
1.3.3 มีผลลัพธ์เป็นบันทึกกำรตรวจสอบย้อนกลับ N
1.3.4 มีผลลัพธ์เป็นข้อกำหนดกำรทดสอบ N

32. กำรวิเครำะห์ช่องว่ำง (Gap-Analysis)
31
ตอนที่ 2 : กระประเมินระดับที่ 2 ด้านการจัดการและควบคุม
หัวข้อ เป้าหมาย
ผลการ
ประเมิน
2. มีกำรควบคุมและติดตำมกำรทำงำนของกระบวนกำร เพื่อให้เป็นไปตำมขั้นตอนและ
มำตรำฐำนที่วำงแผนไว้และได้ผลลัพธ์ที่ตำมที่ต้องกำร ซึ่งมีเกณฑ์ในกำรประเมินดังนี้
2.1 PA 2.1 Performance management
2.1.1 มีกำรกำหนดวัตถุประสงค์สำหรับประสิทธิภำพเของซอฟต์แวร์และบริกำร P
2.1.2 มีกำรวำงแผนและติดตำมประสิทธิภำพของซอฟต์แวร์และบริกำรให้เป็ นไปตำม
วัตถุประสงค์
L
2.1.3 กำรกำรปรับ ประสิทธิภำพของกระบวนกำร P
2.1.4 มีกำรนิยำมบทบำทหน้ำที่ควำมรับผิดชอบในกำรแต่ละกระบวนกำรและกิจกรรม F
2.1.5 มีกำรกำหนดทรัพยกรที่ต้องใช้ในกำรดำเนินงำนตำมแผน F
2.1.6 มีกำรกำหนดวิธีกำรติดต่อประสำนงำนระหว่ำงผู้เกี่ยวข้องกับกระบวนกำร L
2.2 PA2.2 Work product management
2.2.1 มีกำรอธิบำยถึงควำมต้องกำรสำหรับผลลัพธ์ของกระบวนกำร P
2.2.2 มีกำรนิยำมควำมต้องกำรสำหรับกำรจัดทำเอกสำรและกำรควบคุมผลลัพธ์ของกระบวนกำร N
2.2.3 มีกำรกำหนด เอกสำร และ กำรควบคุม สำหรับผลลัพธ์ของกระบวนกำร N
2.2.4 มีกำรรีวิวและปรับปรุงผลลัพธ์ของกระบวนกำรให้ตรงตำมควำมต้องกำรที่ระบุไว้ N

33. กำรวิเครำะห์ช่องว่ำง (Gap-Analysis)
32
ตอนที่ 3 : การประเมินระดับที่ 3 ด้านการยอมรับและใช้งานร่วมกัน
หัวข้อ เป้าหมาย
ผลการ
ประเมิน
3. มีกำรควบคุมและกำรจัดกำรขั้นตอนกำรดำเนินงำนของกำรบวนกำรโดยยึดหลักของกำร
บวนกำรทำงด้ำนวิศวกรรมซอฟต์แวร์ที่ดี โดยมีมำตรำฐำนเป็นที่ยอมรับและบรรลุเป้ำหมำย
ของกระบวนกำร
3.1 PA3.1 Process Definition
3.1.1 มีกำรนิยำมขั้นตอนที่เป็นมำตรฐำนที่สำมำรถสนับสนุนกำรนำกระบวนกำรที่กำหนดไว้ไป
ใช้งำน
P
3.1.2 มีกำรกำหนดลำดับและกำรมีปฏิสัมพันธ์ระหว่ำงกระบวนกำรเพื่อให้เกิดกำรทำงำนร่วมกัน
อย่ำงบูรณำกำร
P
3.1.3 มีกำรระบุบทบำทและควำมสำมำรถในกำรดำเนินกำรกระบวนกำรมำตรฐำน N
3.1.4 มีกำรระบุโครงสร้ำงพื้นฐำนที่จำเป็นและสภำพแวดล้อมกำรทำงำนสำหรับดำเนินกำร
กระบวนกำรมำตรฐำน. (เช่น facility, tool, network, method)
L
3.1.5 มีกำรกำหนดวิธีกำรที่เหมำะสมในกำรตรวจสอบประสิทธิภำพและควำมเหมำะสมของ
กระบวนกำรมำตรฐำน
P
3.2 PA3.2 Process Deployment
3.2.2 มีกำรใช้งำนกระบวนกำรที่ได้นิยำมซึ่งเหมำะสมกับบริบทควำมต้องกำรกำรใช้งำนมำตรฐำน
กระบวนกำร
N
3.2.2 มีกำรกำหนดและประชำสัมพันธ์หน้ำที่ ควำมรับผิดชอบ และบทบำทสำหรับกำรดำเนินกำร
กระบวนกำรที่นิยำม
N
3.2.3 มีกำรตรวจสอบจนแน่ใจถึงสมรรถนะเพียงพอสำหรับกำรดำเนินกระบวนกำรที่นิยำม N
3.2.4 จัดเตรียมทรัพยำกรและข้อมูลเพื่อสนับสนุนกำรปฏิบัติกิจกรรมตำมที่นิยำม N
3.2.5 มีกำรจัดเตรียมโครงสร้ำงพื้นฐำนสำหรับกระบวนกำรเพื่อรองรับกำรปฏิบัติกิจกรรมตำมที่
นิยำม
N
3.2.6 มีกำรรวบรวมและวิเครำะห์ข้อมูลกำรดำเนินงำนของกิจกรรมและแสดงให้เห็นได้ว่ำ
เหมำะสมและมีประสิทธิภำพ
N
ตอนที่ 4: ข้อเสนอแนะ หรือบันทึกอื่นๆ