โครงงานประจำภาคการศึกษาวิชา กระบวนการวิศวกรรมซอฟต์แวร์และปรับปรุง: ขั้นตอนและวิธีการสำหรับกระบวนการออกแบบรายละเอียดซอฟต์แวร์

1. กระบวนการออกแบบรายละเอียดซอฟต์แวร์
ตามมาตรฐาน ISO 12207 ในระดับความสามารถที่ 3 ตามเกณฑ์มาตรฐาน ISO 15504
กระบวนการมาตรฐานขององค์กร (Organization’s Standard Software Process: OSSP)
รุ่นเอกสาร: 1.0.0
วันที่ปรับแก้: 21 เมษายน 2559
รายงานนี้เป็นส่วนหนึ่งของรายวิชา กระบวนการวิศวกรรมซอฟต์แวร์และปรับปรุง
หลักสูตรวิทยาศาสตรมหาบัณฑิต สาขาวิศวกรรมซอฟต์แวร์ คณะวิศวกรรมศาสตร์ จุฬาลงกรณ์มหาวิทยาลัย ภาคเรียนที่ 2 ปีการศึกษา 2558

2. การนิยามและการปรับปรุงกระบวนการออกแบบรายละเอียดซอฟต์แวร์
ให้เป็นไปตามมาตรฐาน ISO 12207 และได้ระดับความสามารถที่ 3 ตามเกณฑ์มาตรฐาน ISO 15504 ในโครงการ
พัฒนาระบบธุรกรรมทางอินเทอร์เน็ตผ่านโมบายแอปพลิเคชัน
จัดทาโดย
5870972621 นางสาวขวัญดี เพชรกานต์
5870943421 นายปฏิวัติ วิเศษศุกูล
5870946321 นายปรีชา นาคเงิน
5870953721 นางสาวสุดหทัย หมั่นค้า
5870972621 นายสิทธิพงษ์เหล่าโก้ก
5870976121 นางสาวสุพัตรา อินศรี
นาเสนอ
ผศ.นครทิพย์พร้อมพูล
รายงานนี้เป็นส่วนหนึ่งของรายวิชา กระบวนการวิศวกรรมซอฟต์แวร์และปรับปรุง
หลักสูตรวิทยาศาสตรมหาบัณฑิต สาขาวิศวกรรมซอฟต์แวร์ คณะวิศวกรรมศาสตร์ จุฬาลงกรณ์มหาวิทยาลัย ปีการศึกษา 2558

3. ประวัติการแก้ไขเอกสาร
รุ่น วันที่ การแก้ไข
0.0.0 23 มีนาคม 2559 เริ่มต้น
0.1.0 13 เมษายน 2559 แก้ไขรายละเอียดกระบวนการ
0.1.3 13 เมษายน 2559 เปลี่ยนสีหัวข้อและหัวตาราง
0.2.0 13 เมษายน 2559 แก้ไขรายละเอียดกิจกรรม PP-SDD-DESS: ออกแบบรายละเอียดซอฟต์แวร์ (Develop
detailed design)
0.3.0 13 เมษายน 2559 แก้ไขรายละเอียดกิจกรรม PP-SDD-DOCD: จัดทาเเอกสารของการปรับปรุงการ
ออกแบบซอฟต์แวร์ (Document software design)
0.4.0 13 เมษายน 2559 แก้ไขรายละเอียดกิจกรรม PP-SDD-VFTC:ตรวจสอบความถูกต้องของกรณีทดสอบ
และแผนการทดสอบ(Verificationandapprovalofthetestcasesandtest procedures)
0.4.1 17 เมษายน 2559 ทวนสอบข้อมูล
0.5.0 17 เมษายน 2559 เพิ่มเติมเนื้อหา บทที่ 3 รายการตรวจสอบ
1.0.0-rc 20 เมษายน 2559 ตรวจสอบเอกสาร ปรับความสมบูรณ์ของเนื้อหา
1.0.0 21 เมษายน 2559 เอกสารฉบับสมบูรณ์
1.0.1 11 พฤษภาคม
2559
แก้ไขคาผิดรอบแรก
1.1.0 13 พฤษภาคม
2559
เอกสารฉบับสมบูรณ์
การอนุมัติ
วันที่ประกาศใช้ <วันที่ / เดือน / พ.ศ.>
เข้าถึงได้จาก <ชื่อระบบงาน / กลุ่มงาน / กลุ่มข้อมูล / รุ่นเอกสาร>
ผู้บันทึกข้อมูล <ชื่อผู้นาแบบฟอร์มเข้าสู่ระบบ>
แจ้งปรับปรุง <วันที่ / เดือน / พ.ศ.>: <ช่องทางการปรับปรุง>
ผู้ตรวจทาน ผู้อนุมัติ
<ลายมือชื่อ> <ลายมือชื่อ>
(<ชื่อผู้รับตรวจทาน>) (<ชื่อผู้อานาจอนุมัติ>)
<ตาแหน่ง> <ตาแหน่ง>
<วันที่ / เดือน / พ.ศ.> <วันที่ / เดือน / พ.ศ.>

4. I
สารบัญ
บทที่ 1 บทนา.......................................................................................................................................................................1
1.1 วัตถุประสงค์............................................................................................................................................................1
1.2 ขอบเขตของเอกสาร................................................................................................................................................1
1.3 คาย่อและนิยามคาศัพท์ที่ใช้ในเอกสาร....................................................................................................................1
1.4 เอกสารและการอ้างอิง.............................................................................................................................................2
1.4.1 รายการมาตรฐาน และเอกสารอ้างอิง..............................................................................................................2
1.4.2 เอกสารและแผนงานในโครงการ....................................................................................................................3
บทที่ 2 กระบวนการการออกแบบรายละเอียดซอฟต์แวร์ ...................................................................................................4
2.1 กระบวนการออกแบบรายละเอียดซอฟต์แวร์..........................................................................................................5
2.1.1 วัตถุประสงค์...................................................................................................................................................5
2.1.2 ผลลัพธ์............................................................................................................................................................5
2.1.3 บทบาทและหน้าที่ของทีมงาน........................................................................................................................5
2.1.4 ความสามารถที่ต้องการของทีมงาน................................................................................................................7
2.2 กิจกรรมและภาระงาน...........................................................................................................................................10
2.3 ชิ้นงานนาเข้า..........................................................................................................................................................11
2.3.1 รายการชิ้นงานนาเข้าที่จาเป็นในการดาเนินกระบวนการ.............................................................................11
2.3.2 รายการชิ้นงานที่สนับสนุนระดับความสามารถของกระบวนการ................................................................12
2.4 ชิ้นงานส่งออก.......................................................................................................................................................12
2.4.1 รายการชิ้นงานส่งออกที่จาเป็น.....................................................................................................................12
2.4.2 ชิ้นงานสนับสนุนระดับความสามารถกระบวนการ......................................................................................14
2.5 คุณภาพและการประเมินคุณภาพงานออกแบบ.....................................................................................................17
2.6 ภาพรวมกระบวนการ............................................................................................................................................19
2.7 รายละเอียดกิจกรรมในช่วงเริ่มโครงการ (Activities Detailed of Project Initiation Phase).................................20
2.7.1 PP-ADPI-PDEF: การนิยามกระบวนการ (Process Definition)....................................................................20
2.7.2 PP-ADPI-PDEP: การนานิยามกระบวนการออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software Detailed
Design Process Deployment)....................................................................................................................................26
2.7.3 PP-ADPI-VAPR: การทบทวนและอนุมัติกระบวนการ (Verification and Approvement: Process)...........31
2.8 รายละเอียดกิจกรรมในขั้นตอนวางแผน (Planning Phase)...................................................................................32
2.8.1 PP-PLPH-SPP1: การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงแรก (Software Detailed Design Part I)33
2.8.2 PP-PLPH-SPP2: การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงสอง (Software Detailed Design
Planning Part II)........................................................................................................................................................36
2.8.3 PP-PLPH-VADP: การทบทวนและอนุมัติกระบวนการ (Verification and Approvement: Design Plan)...38
2.9 รายละเอียดกิจกรรมในขั้นตอนการติดตามและควบคุมการดาเนินงาน (Monitoring and Control)......................39

5. II
2.9.1 PP-MCTR-PMCD: การติดตามและควบคุมการดาเนินงาน ระดับโครงการ (Monitoring and Control:
Overview)..................................................................................................................................................................40
2.9.2 PP-MCTR-PMCR: การติดตามและควบคุมการดาเนินงาน ในระดับองค์กร (Monitoring and Control:
Organizational) .........................................................................................................................................................43
2.10 รายละเอียดกิจกรรมในขั้นตอนการพัฒนา (Development phase)........................................................................46
2.10.1 PP-DEVP-DESS: ออกแบบรายละเอียดซอฟต์แวร์ (Develop detailed design)...........................................48
2.10.2 PP-DEVP-DOCD: จัดทาเเอกสารของการปรับปรุงการออกแบบซอฟต์แวร์ (Document software design)51
2.10.3 PP-DEVP-UTCP: จัดทาหรือปรับปรุงกรณีทดสอบ และการทดสอบ (Test Cases and Test Procedures)..52
2.10.4 PP-DEVP-VFTC: ตรวจสอบความถูกต้องของกรณีทดสอบ และแผนการทดสอบ (Verification and
approval of the test cases and test procedures).........................................................................................................55
2.10.5 PP-DEVP-UTCR: ปรับปรุงระเบียนตามรอย (Update the Traceability Record)........................................57
2.10.6 PP-DEVP-REVE: ทวนสอบและประเมินแบบรายละเอียดซอฟต์แวร์ (Review and Evaluation for
Software Detailed Desing)........................................................................................................................................58
2.10.7 PP-DEVP-REPO: การจัดเก็บผลลัพธ์ของกระบวนการในที่เก็บข้อมูลของโครงการ (Project Repository)61
2.10.8 PP-DEVP-ADJR: การจัดปรับแผนและรายละเอียดซอฟต์แวร์ (Adjust Plan and Redesign)......................64
2.11 รายละเอียดกิจกรรมในขั้นตอนการประเมินและทบทวนการออกแบบรายละเอียดซอฟต์แวร์ (Software Detailed
Desing Refinement).........................................................................................................................................................66
2.11.1 PP-SDDR-DDER: การประเมินและทบทวนการออกแบบรายละเอียดซอฟต์แวร์ (Detailed Design
Evaluation : Retrospective).......................................................................................................................................66
บทที่ 3 รายการตรวจสอบ (Checklist)..............................................................................................................................70
3.1 วัตถุประสงค์ของรายการตรวจสอบ......................................................................................................................70
3.2 แบบฟอร์มรายการตรวจสอบ................................................................................................................................70
3.3 โครงสร้างรายการตรวจสอบ.................................................................................................................................71
3.4 รายละเอียดรายการตรวจสอบ................................................................................................................................71
3.5 วิธีการนาไปใช้งานรายการตรวจสอบ...................................................................................................................72
3.6 คาแนะนาการใช้งานรายการตรวจสอบ.................................................................................................................72
บทที่ 4 สินทรัพย์กระบวนการ...........................................................................................................................................74
4.1 เครื่องมือที่ใช้.........................................................................................................................................................74
4.1.1 ช่วยนิยามกระบวนการ และจัดสร้างเอกสาร................................................................................................74
4.1.2 โครงสร้างพื้นฐานสาหรับสนับสนุนกระบวนการ.......................................................................................75
4.2 แม่แบบบันทึกข้อมูล..............................................................................................................................................76
4.2.1 แบบบันทึกข้อมูลที่ใช้ภายในกระบวนการ...................................................................................................76
บทที่ 5 ความสอดคล้องกับมาตรฐานอ้างอิง......................................................................................................................77
1) ความสอดคล้องกับมาตรฐาน ISO 12207..............................................................................................................77
2) ความสอดคล้องกับกับมาตรฐาน ISO 15504.........................................................................................................80

6. III
ภาคผนวก ก คาอธิบายสัญลักษณ์......................................................................................................................................ก
ภาคผนวก ข แนะนาเครื่องมือ...........................................................................................................................................ก
ข.1 Microsoft Office 2016............................................................................................................................................ก
ข.1.1 ความสามารถ.................................................................................................................................................ก
ข.1.2 ข้อมูลทั่วไป....................................................................................................................................................ก
ข.2 Microsoft Visio 2016.............................................................................................................................................ข
ข.2.1 ความสามารถ.................................................................................................................................................ข
ข.2.2 ข้อมูลทั่วไป....................................................................................................................................................ข

7. IV
สารบัญรูป
ภาพที่ 2-1 ภาพรวมกระบวนการ...............................................................................................................................................4
ภาพที่ 2-2: ภาพรวมของกระบวนการที่นิยามขึ้น....................................................................................................................19
ภาพที่ 2-3 แผนภาพกิจกรรมในขั้นตอนออกแบบรายละเอียดซอฟต์แวร์ในขั้นตอนสปิ้น.....................................................47

8. V
สารบัญตาราง
ตารางที่ 1 บทบาทในกระบวนการออกแบบรายละเอียดซอฟต์แวร์แบบสกรัม .......................................................................5
ตารางที่ 2 บทบาทอื่น ๆ ที่เกี่ยวข้องในระดับองค์กร.................................................................................................................6
ตารางที่ 3 รายละเอียดบทบาทและความสามารถที่จาเป็นในการดาเนินโครงการ....................................................................7
ตารางที่ 4 รายการกิจกรรมในกระบวนการออกแบบรายละเอียดซอฟต์แวร์..........................................................................10
ตารางที่ 5 รายการชิ้นงานนาเข้าในกระบวนการออกแบบรายละเอียดซอฟต์แวร์..................................................................11
ตารางที่ 6 รายการชิ้นงานที่มีการนามาใช้เพื่อช่วยเสริมระดับคุณภาพของกระบวนการ........................................................12
ตารางที่ 7 รายการผลลัพธ์ในกระบวนการออกแบบรายละเอียดซอฟต์แวร์ ...........................................................................12
ตารางที่ 8 ชิ้นงานที่เกิดเพื่อสนับสนุนความสามารถระดับที่ 2 ตามมาตรฐาน ISO/IEC 15504-5..........................................14
ตารางที่ 9 ชิ้นงานที่เกิดเพื่อสนับสนุนความสามารถระดับที่ 3 ตามมาตรฐาน ISO/IEC 15504-5..........................................15
ตารางที่ 10 เกณฑ์ประเมินคุณภาพสาหรับในกระบวนการออกแบบรายละเอียดซอฟต์แวร์ .................................................17
ตารางที่ 11 เครื่องมือสาหรับสนับสนุนการนิยามกระบวนการ..............................................................................................74
ตารางที่ 12 รายการโครงสร้างพื้นฐาน....................................................................................................................................75
ตารางที่ 13 แม่แบบบันทึกข้อมูลที่ใช้ภายในกระบวนการ......................................................................................................76
ตารางที่ 14 เปรียบเทียบกิจกรรมที่นิยามกับมาตรฐาน ISO 12207.........................................................................................77
ตารางที่ 15 ตารางเปรียบเทียบกิจกรรมที่นิยามกับมาตรฐาน 15504.......................................................................................80

9. VI
คานา
การปรับปรุงกระบวนการทางานนั้น คือความพยายามที่จะเปลี่ยนแปลงวิธีการทางานเดิมที่องค์กรใช้ปฏิบัติอยู่เดิม
ให้มีประสิทธิภาพเพิ่มมากขึ้น เช่น เพิ่มประสิทธิภาพการดาเนินงานของบุคลากร ลดค่าใช้จ่ายที่เกิดขึ้น ประหยัดเวลาการ
ดาเนินงาน ระบุบทบาท หน้าที่การดาเนินการอย่างชัดเจน ตลอดจนปรับปรุงให้กระบวนการเดิมขององค์กรมีความสามารถ
สอดคล้องกับระดับความสามารถที่เป็นมาตรฐานอ้างอิงมากยิ่งขึ้น ซึ่งในการนิยามกระบวนการครั้งนี้ องค์กรได้คัดเลือก
กระบวนการออกแบบรายละเอียดซอฟต์แวร์ ให้เป็นกระบวนการเป้าหมายเพื่อการปรับปรุงกระบวนการ เนื่องมาจาก
องค์กรได้ทราบและตระหนักถึงปัญหาที่เกิดขึ้นในกระบวนการดังกล่าว โดยองค์กรได้ตั้งเป้าหมายของการปรับปรุง
กระบวนการเพื่อให้เป็นไปตามมาตรฐาน ISO/IEC 12207 และได้ระดับความสามารถที่ 3 ตามเกณฑ์มาตรฐาน ISO/IEC
15504
การนิยามกระบวนการในครั้งนี้จึงได้นาผลการวิเคราะห์การประเมินความพร้อมองค์กร และการวิเคราะห์ช่องว่าง
ขององค์กรเทียบเคียงกับรายการคุณลักษณะของระดับความสามารถกระบวนการที่องค์กต้องการ มาใช้ประกอบเป็นข้อมูล
ในการนิยามกระบวนการ โดยที่กระบวนการที่นิยามขึ้นจะอาศัยข้อมูลที่ได้จากโครงการพัฒนาระบบธุรกรรมทาง
อินเทอร์เน็ตผ่านโมบายแอปพลิเคชันซึ่งเป็นโครงการที่ดาเนินการต่อเนื่องอยู่เดิมแล้ว และมีแผนที่จะนาไปทดลองใช้งาน
อย่างเต็มรูปแบบ และขยายนาไปใช้งานทั้งองค์กรในระยะถัดไป
คณะทางาน
13 พฤษภาคม 2559

10. บทนา
กระบวนการออกแบบรายละเอียดซอฟต์แวร์ 1
บทที่ 1 บทนา
1.1 วัตถุประสงค์
วัตถุประสงค์ของการเอกสารฉบับนี้ คือการกาหนดกิจกรรม การดาเนินการพัฒนาซอฟต์แวร์ของโครงการพัฒนา
ซอฟต์แวร์ของธนาคาร โดยผู้ปฏิบัติงานจะใช้เอกสารนี้เพื่อทาความเข้าใจพร้อมทั้งเป็นแม่แบบของการออกแบบ
รายละเอียดซอฟต์แวร์และแผนกิจกรรมพื้นฐานต่างๆที่จะช่วยให้ผู้ปฏิบัติงานนาไปใช้จัดการและควบคุมกระบวนการ ให้
เป็นไปอย่างเป็นระบบ และทาให้การดาเนินงานของโครงการได้อย่างมีประสิทธิภาพและเป็นไปในทิศทางเดียวกัน
โดยนิยามกระบวนการออกแบบซอฟต์แวร์ในเอกสารนี้จะเป็นไปตามมาตรฐาน ISO/IEC 12207 ในความสามารถ
ระดับที่ 3 ตามเกณฑ์การประเมินจากมาตรฐาน ISO/IEC 15504 นอกจากนี้เอกสารฉบับนี้ยังรวมไปถึงข้อมูลหรือเครื่องมือที่
สนับสนุนกระบวนการทางาน เช่น นโยบาย มาตรฐาน แม่แบบ แบบฟอร์ม ตัวอย่างการใช้งาน เครื่องมืออัตโนมัติ โดยที่
หวังว่าผลจากการดาเนินโครงการนี้ จะสามารถนาไปเป็นต้นแบบสาหรับการปรับปรุงกระบวนการอื่น ๆ ในการพัฒนา
ซอฟต์แวร์ให้ครบทั้งวัฏจักรชีวิตซอฟต์แวร์ เพื่อเพิ่มประสิทธิภาพของการทางานและคุณภาพของซอฟต์แวร์ให้ดียิ่งขึ้น
1.2 ขอบเขตของเอกสาร
1) นิยามกระบวนการ แนวทาง และแผนการดาเนินงานในโครงการ ตามระเบียบวิธีแบบสกรัม (Scrum Methodology)
2) บทบาทหน้าที่และความสามารถของบุคคลากรที่จาเป็นในกระบวนการออกแบบรายละเอียดซอฟต์แวร์
3) กระบวนการออกแบบรายละเอียดซอฟต์แวร์ ที่เป็นไปตามมาตรฐานISO/IEC12207 ISO/IEC12207 ISO/IEC
12207ISO/IEC 12207
4) คาอธิบายรายละเอียดการออกแบบซอฟต์แวร์ (SoftwareDesign Description) ที่ได้จากกระบวนการที่สร้างขึ้นจะ
อ้างอิงตามมาตรฐาน IEEE Std 1016
5) การออกแบบซอฟต์แวร์จะใช้วิธีการวิเคราะห์และออกแบบเชิงวัตถุ (Object-oriented analysis and design: OOAD)
และใช้แผนภาพยูเอ็มแอล (Unified Modeling Language : UML) ในการแสดงให้เห็นถึงรายละเอียดของซอฟต์แวร์
6) เอกสาร เครื่องมือ สาหรับสนับสนุนกระบวนการทางาน เช่น แนวนโยบาย แบบฟอร์ม รายการตรวจสอบ การวัด การ
ประเมินผล โดยเอกสารต่าง ๆ จะต้องประกอบด้วย แม่แบบ ตัวอย่างการบันทึก และคาแนะนาการใช้งาน จัดเก็บเป็น
คลังข้อมูล (Repository)
1.3 คาย่อและนิยามคาศัพท์ที่ใช้ในเอกสาร
คาศัพท์/ตัวย่อ ความหมาย
Phase การแบ่งช่วงการทางานของ SDLC ได้แก่ Plan, Design and Develop, Test, Deploy และ
Closure
OSSP Organization's Standard Software Process คือกระบวนการมาตรฐานที่นิยามขึ้นสาหรับองค์กร
ซึ่งผู้ใช้กระบวนการนั้นๆ จาเป็นต้องทราบและดาเนินการในส่วนที่เกี่ยวข้อง
OPAL Organization's Process Asset Library คือคลังข้อมูลสาหรับเอกสารหรือ work product ต่างๆ
ของกระบวนการในระดับองค์กร
Work Product สิ่งที่เกิดขึ้นในการทากระบวนการ เช่น Diagram, Source Code เป็นต้น
Process กระบวนการตามเอกสารนิยามกระบวนการ

11. บทนา
2
คาศัพท์/ตัวย่อ ความหมาย
Audits & Reviews หลักฐานหรือเอกสาร แสดงการตรวจสอบและการวิเคราะห์การทางานในกิจกรรมต่างๆ
1.4 เอกสารและการอ้างอิง
1.4.1 รายการมาตรฐาน และเอกสารอ้างอิง
เอกสารอ้างอิง คาอธิบายและความสาคัญ
ISO/IEC 12207(2008): Systems and software
engineering – Software life cycle process
ใช้เป็นกรอบอ้างอิงในการนิยามกระบวนการ สาหรับโครงการ
นี้ได้เลือกกระบวนการออกแบบรายละเอียดซอฟต์แวร์ จาก
มาตรฐานนี้มาเป็ นกรณีศึกษาในการนิยามและปรับปรุง
กระบวนการ
IEEE 1074 (2006): Standard for Developing a
Software Project Life Cycle Process
กลุ่มกิจกรรมที่ควรมีที่จะนาไปเชื่อมโยงกับแบบจาลองวัฏจักร
ชีวิตซอฟต์แวร์ และ OPAs เพื่อสร้างเป็น SPLCP ซึ่ง โครงการนี้
จะใช้รายการกิจกรรมจากมาตรฐานนี้ เชื่อมโยงกับ
แบบจาลองวัฏจักรชีวิตซอฟต์แวร์แบบสกรัม
ISO/IEC 15504: Information TechnologyProcess
Assessment
มาตรฐานนี้เสนอแนวทางสาหรับประเมินการดาเนินงานการ
พัฒนาซอฟต์แวร์ ซึ่งสาหรับโครงการนี้ จะอาศัยข้อกาหนดจาก
มาตรฐานนี้ในการประเมินความสามารถกระบวนการมาตรฐาน
นี้ประกอบด้วย10 ส่วน โดยที่ส่วนที่สาคัญที่จะใช้ในโครงการนี้
คือส่วนที่ 2 และ 5
ISO/IEC15504-2(2003):InformationTechnology
– Process Assessment Part 2 : Performing an
assessment
ส่วนที่ 2 ของ มาตรฐาน ISO/IEC 15504 ซึ่งได้ให้นิยาม
ข้อกาหนดสาหรับปฏิบัติการตรวจประเมิน สาหรับโครงการนี้
จะใช้เป็ นกรอบในการวัดความสามารถของกระบวนการ
ร่วมกับมาตรฐาน ISO/IEC 12207Capability Assessment
Assessment Assessment
ISO/IEC15504-5(2012):InformationTechnology
– Process Assessment Part 5: An exemplar
Process Assessment Model
ส่วนที่ 2 ของ มาตรฐาน ISO/IEC15504 เป็ นตัวอย่างของ
รูปแบบสาหรับประเมิน ความสามารถของกระบวนการ และ
นาเสนอแนวทางปฏิบัติที่ดี (Best practise) และผลลัพธ์ที่ควรมี
(Work product)
IEEE 2 4 7 7 4 ( 2012) : Systems and Software
Engineering - Life Cycle Management -
Guidelines for Process Description
คาแนะนาสาหรับการให้รายละเอียดกระบวนการ สาหรับ
โครงการนี้จะใช้มาตรฐานนี้ เพื่อเป็ นแนวทางในการให้
คาอธิบายในแต่ละกระบวนการหรือกิจกรรม และใช้เป็น
แนวทางในการระบุรายการหัวข้อที่ควรมี
IEEE 1016 (2009): Information Technology—
Systems Design—Software Design Descriptions
คาแนะนาในการอธิบายรายละเอียดซอฟต์แวร์ สาหรับโครงการ
นี้จะใช้มาตรฐานนี้เป็นแนวทางในการกาหนดหัวข้อรายการที่
ควรจะมี และรูปแบบภาษาที่ควรใช้ในการสื่อสาร ในการสร้าง

12. บทนา
3
เอกสารอ้างอิง คาอธิบายและความสาคัญ
เอกสารรายละเอียดการออกแบบซอฟต์แวร์ (Software Design
Description)
Object-oriented analysis and design (OOAD) การวิเคราะห์และออกแบบระบบเชิงวัตถุ เป็นวิธีการออกแบบที่
องค์ประกอบของระบบด้วยการจาลองแบบเชิงวัตถุ (Object
Model) ซึ่งจะประกอบขึ้นเป็นตัวแทนของระบบสารสนเทศ
Unified Modeling Language (UML) ภาษาแบบจาลอง ที่ใช้อธิบาย แสดงรายละเอียด จาลองการสร้าง
การออกแบบซอฟต์แวร์ที่แทนระบบการทางานจริงนั้นทาได้
โดยง่าย
Scrum guide คู่มือการทางานแบบสกรัม มีจุดประสงค์เพื่อแสดงแบบแผนการ
ทางานที่นามาใช้ในการพัฒนาซอฟต์แวร์และสนับสนุน
ผลิตภัณฑ์ที่มีความซับซ้อน โดยคู่มือนี้จะอธิบายถึงความหมาย
ของคาว่า สกรัม (Scrum) ซึ่งประกอบไปด้วย บทบาทที่มีอยู่ใน
สกรัม เหตุการณ์ต่าง ๆ ส่วนประกอบ (Artifact) และกฎ
ข้อบังคับนี้จะเป็นตัวเชื่อมโยงองค์ประกอบเหล่านี้เข้าด้วยกัน
1.4.2 เอกสารและแผนงานในโครงการ
เอกสารอ้างอิง คาอธิบายและความสาคัญ
ข้อเสนอโครงการ ข้อมูลการศึกษาแนวทางการนิยามกระบวนการในเบื้องต้นขององค์กร ซึ่ง
ประกอบไปด้วย ความต้องการหรือความคาดหวังที่องค์กรมีต่อกระบวนการที่จะ
นิยามขึ้นมา ตลอดจนขอบเขตการดาเนินงาน เพื่อใช้เป็นข้อมูลและแนวทางใน
การดาเนินงานโครงการในขั้นตอนการนิยามกระบวนการ
แนวทางการกาหนดลักษณะเฉพาะ
ของกระบวนการสาหรับองค์กร
ข้อกาหนด กฎข้อบังคับ แนวทางปฏิบัติขององค์กร ตลอดจนกฎระเบียบภายนอก
องค์กรที่มีผลต่อการดาเนินงาน
แนวการดาเนินการภายในกิจกรรม
(Guideline)
แนวทางการดาเนินงานของกิจกรรมภายใต้กระบวนการที่ได้นิยามขึ้น เพื่อให้
บุคลากรสามารถดาเนินกิจกรรมไปในแนวทางเดียวกันทั้งองค์กร
แม่แบบบันทึกข้อมูล (Template) เอกสารข้อกาหนดแสดงรายการข้อมูลที่จาเป็นจะต้องใช้หรือควรจะมีในกิจกรรม
ภายในกระบวนการที่ได้นิยามขึ้น รวมถึงคาอธิบายข้อมูล และตัวอย่างการใช้งาน
แม่แบบบันทึกข้อมูล เพื่อให้บุคลากรสามารถนาแม่แบบบันทึกข้อมูลไปใช้งาน
ได้อย่างถูกต้องและเป็นไปในแนวทางเดียวกันทั้งองค์กร

13. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
กระบวนการออกแบบรายละเอียดซอฟต์แวร์ 4
บทที่ 2 กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
ขั้นตอนนี้เป็นการนิยามกระบวนการออกแบบรายละเอียดซอฟต์แวร์โดยการนิยามกระบวนการนี้จะพิจารณา
องค์ประกอบคือ แนวคิดการพัฒนาซอฟต์แวร์แบบของอไจล์ แนวคิดของการออกแบบเชิงวัตถุ ความต้องการขององค์กร
และมาตรฐานที่อ้างอิง โดยภาพรวมของกระบวนการแสดงดังภาพ โดยแผนภาพนี้แสดงกิจกรรมที่เกี่ยวข้องกับการนิยาม
และปรับปรุงกระบวนการเท่านั้น
ภาพที่ 2-1 ภาพรวมกระบวนการ

14. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
5
2.1 กระบวนการออกแบบรายละเอียดซอฟต์แวร์
2.1.1 วัตถุประสงค์
วัตถุประสงค์ของกระบวนการออกแบบรายละเอียดซอฟต์แวร์ ก็เพื่อให้ข้อมูลการออกแบบซอฟต์แวร์ที่กาลัง
พัฒนา โดยสามารถนาไปทวนสอบกับรายการความต้องการและสถาปัตยกรรมซอฟต์แวร์ ตลอดจนมีรายละเอียดเพียงพอ
สาหรับการพัฒนาและการทดสอบ
2.1.2 ผลลัพธ์
1) รายละเอียดของการออกแบบซอฟต์แวร์ในส่วนต่างๆ และอธิบายส่วนย่อยของซอฟต์แวร์ที่จะพัฒนาขึ้น
2) ส่วนต่อประสาน (Interface) ที่เชื่อมต่อไปยังส่วนอื่น และภายนอกส่วนย่อยของซอฟต์แวร์จะต้องอธิบายไว้
ด้วย
3) รายละเอียดซอฟต์แวร์ ต้องถูกต้องตรงกัน และตรวจสอบย้อนกลับไปยังรายการความต้องการและ
สถาปัตยกรรมที่ออกแบบไว้ได้
2.1.3 บทบาทและหน้าที่ของทีมงาน
ในการดาเนินกระบวนการออกแบบรายละเอียดซอฟต์แวร์จาเป็นต้องมีบทบาทหน้าที่ความรับผิดชอบทั้งในระดับ
โครงการและในระดับองค์กรต่อไปนี้
ตารางที่ 1 บทบาทในกระบวนการออกแบบรายละเอียดซอฟต์แวร์แบบสกรัม
รหัส ทีมงานภายใต้โครงการ หน้าที่รับผิดชอบ
PO เจ้าของผลิตภัณฑ์
(Product Owner)
บุคคลหรือตัวแทนของหน่วยงาน Digital Strategy & Channels เป็นผู้
กาหนดขอบเขตการทางานโครงการที่ทีมจะต้องดาเนินการพัฒนาเพื่อให้
โครงการสาเร็จลุล่วงตามเป้าหมายที่วางไว้ได้
DEV ทีมพัฒนา
(Development Team)
บุคลากรสังกัดหน่วยงาน Mobile and Internet Banking และ Third party ทา
หน้าที่ พัฒนาระบบให้ตรงตามความต้องการ และดาเนินงานตามแผนการ
ทางานที่วางไว้
SM สกรัมมาสเตอร์
(Scrum Mater)
บุคลากรสังกัดหน่วยงาน Mobile and Internet Banking ส่วนงาน
Application Solution ทาหน้าที่ในการดูแลทีมพัฒนา ติดตามและควบคุม
แนวทางการทางานของทีมพัฒนาให้เป็นไปตามแผนการที่วางไว้ตามความ
เหมาะสม และประสานการทางานระหว่างสมาชิกใน Development Team
และ Product Owner

15. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
6
ตารางที่ 2 บทบาทอื่น ๆ ที่เกี่ยวข้องในระดับองค์กร
รหัส ทีมงานภายใต้โครงการ หน้าที่รับผิดชอบ
BS หน่วยงานแสวงหาความเสร็จ
เชิงธุรกิจ (Business Solution)
เป็นหน่วยงานภายในองค์กร ซึ่งเป็นผู้กาหนดแนวทางและเป้าหมายการ
ดาเนินงานทางธุรกิจ เพื่อให้ได้ผลลัพธ์ที่เกิดประโยชน์อันสูงสุดต่อองค์กร
ทาหน้าที่ให้รายละเอียดความต้องการซอฟต์แวร์
TP หน่วยงานภายนอก (Third
Party)
เป็นหน่วยงานที่เกี่ยวข้องกับโครงการในแต่ละ Release ที่ทางทีมจะต้อง
ดาเนินการพัฒนา
PPQA หน่วยงานประกันคุณภาพ
ผลิตภัณฑ์และกระบวนการ
(Process and Product Quality
Assurance)
หน่วยงานที่ทาหน้าที่ติดตามและตรวจสอบกิจกรรมที่เกิดขึ้นภายใน
กระบวนการ สินทรัพย์องค์กรที่เกี่ยวข้องเพื่อให้ได้ระดับความสามารถของ
กระบวนการตามมาตรฐานที่องค์กรต้องการอยู่เสมอ
SCM หน่วยงานบริหารจัดการการ
เปลี่ยนแปลง (Software
Configuration Management)
หน่วยงานซึ่งทาหน้าที่กาหนดรูปแบบรุ่น เงื่อนไขการปล่อยรุ่น ให้รหัส
ลักษณะการจัดเก็บ และกาหนดนโยบายในการปรับปรุงเวอร์ชัน เพื่อลด
ความสับสนและข้อผิดพลาดต่างๆที่เกิดขึ้น อันเนื่องมาจากเกิดความ
แตกต่างในแต่ละเวอร์ชันของซอฟต์แวร์
SEPG กลุ่มงานวิศวกรรมซอฟต์แวร์
กระบวนการ (Software
Engineering Process Group)
กาหนดกระบวนการมาตรฐานองค์ดาเนินการนิยามมาตรฐานองค์กร และ
ติดตามการใช้งานกระบวนการภายในองค์กร
ELG คณะผู้บริ หาร (Executive
Leader Group)
พิจารณาและอนุมัติกระบวนการ โดยรับร่างของกระบวนการที่นิยามขึ้นมา
จากคณะทางาน เพื่อให้นาไปประกาศใช้งานภายในองค์กรต่อไป
SE ผู้เชี่ยวชาญกระบวนการ
(SDLC Expert)
บุคลากรทั้งภายในองค์กร หรือภายนอกองค์กรซึ่งมีความรู้ ความเชี่ยวชาญ
เกี่ยวกับกระบวนพัฒนาซอฟต์แวร์ที่ต้องการจะปรับปรุง
RA ผู้ ดู แ ล ค ลั ง ท รั พ ย า ก ร
(Repository Administrator)
ดูแลคลังเอกสารให้เกิดความสอดคล้องกันในการนาไปใช้งาน บารุงรักษา
รายการเอกสารทั้งหมดให้ผู้ใช้งานสามารถนาไปใช้งานได้อย่างถูกต้องรวม
ไปถึงการหน้าที่สื่อสารกับผู้ใช้งานเอกสารในองค์กรด้วยช่องทางที่
เหมาะสม เมื่อมีการปรับปรุงรุ่นของเอกสาร
TW นักเขียนเอกสารเชิงเทคนิค
(Technical Writer)
นักเขียนเอกสารเชิงเทคนิคทาหน้าที่ช่วยเหลือสกรัมทีมในการจัดทาเอกสาร
ต่าง ๆ เพื่อให้ทีมโพกัสในงานพัฒนาซอฟต์แวร์เป็นหลัก
AN นักวิเคราะห์ระบบ (System
Analyst)
วิเคราะห์ระบบที่จะพัฒนาขึ้น เพื่อแยกย่อยส่วนประกอบ หรือควบรวมการ
ทางานเข้าด้วยเพื่อให้ง่ายต่อการพัฒนา ตลอดจนเสนอแนะเทคโนโลยีที่
จาเป็นในการทางาน
DESS นักอออกแบบระบบ (System
Designer)
ออกแบบส่วนประกอบซอฟต์แวร์ทั้งแบบระดับสูง และระดับล่าง ซึ่งเพียง
พอที่จะนาการออกแบบนั้นไปพัฒนาต่อได้

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

17. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
8
รหัส บทบาท ความสามารถที่ต้องการ
PO เจ้าของผลิตภัณฑ์ 1) สามารถสร้างวิสัยทัศน์ (Vision) และเป้าหมาย (Goal) ที่ชัดเจนของ Product
2) สามารถสื่อสารวิสัยทัศน์และเป้าหมายนั้นให้ผู้ที่เกี่ยวข้อง (Stakeholders) ทราบ
อย่างสม่าเสมอ
3) สามารถจัดลาดับความสาคัญของงานที่จะทา (Prioritization) ให้เหมาะสม
4) สร้างและดูแล Product Backlog ให้อยู่ในสภาพพร้อมใช้งานเสมอ
5) มีส่วนร่วมกับทีมในการทากิจกรรมต่างๆของ Scrum เช่น Sprint Planning, Sprint
Review and Retrospective และอื่นๆ
DEV ทีมพัฒนา ทีมพัฒนาจะต้องมีบุคลากรที่มีทักษะดังต่อไปนี้
1) มีทักษะการพัฒนาซอฟต์แวร์ด้วยแนวคิดเชิงวัตถุ
2) สามารถพัฒนาซอฟต์แวร์ที่ทดสอบได้ (Testable code) เข้าใจและดาเนินการ
พัฒนาภายใต้แนวคิด Test-Driven Development หรือ TDD
3) เข้าใจแนวคิด และการใช้งานภาษา UML
4) มีทักษะด้านการใช้งานซอฟต์แวร์สาหรับควบคุมรุ่นของซอฟต์แวร์ (Versioning
Control)
5) มีทักษะการทดสอบซอฟต์แวร์ เพื่อหาข้อผิดพลาดอย่างเป็นระบบ
6) ออกแบบโครงร่างของซอฟต์แวร์ที่สอดคล้องตามแนวคิดการออกแบบเชิงวัตถุ
(Object-Oriented Analysis and Design)
7) สามารถออกแบบส่วนต่อประสานผู้ใช้งาน (User Interface) ที่สอดคล้องกับ
ลักษณะการใช้งานของผู้ใช้(User Experience) แต่ละแพลตฟอร์มการทางานได้
8) สามารถทางานร่วมกันเป็นกลุ่มได้และเข้าใจลักษณะทางานของอาไจล์
9) กระตือรือร้นที่จะเรียนรู้สิ่งใหม่ เช่น ภาษาสาหรับการพัฒนา เครื่องมือการทางาน
เสมอ
SM สกรัมมาสเตอร์ 1) เข้าใจหลักแนวคิดของสกรัม
2) มีหลักฐานที่เชื่อถือได้หรือประสบการณ์การทางาน ที่แสดงให้เห็นว่ามีความรู้
ความสามารถเกี่ยวกับสกรัมในระดับ Scrum Master เป็นอย่างดี
BS หน่วยงานแสวงหา
ความเสร็จเชิงธุรกิจ
1) เข้าใจกระบวนการทางานและลักษณะทางธุรกิจของหน่วยงานเป็นอย่างดี
2) เข้าใจเทคโนโลยีและมาตรฐานที่เกี่ยวข้องกับการดาเนินงานขององค์กรเป็นอย่าง
ดี
3) สามารถประยุกต์งานเทคโนโลยีเพื่อนามาเสริมประสิทธิภาพในการดาเนินธุรกิจ
ขององค์การได้อย่างมีประสิทธิภาพ
TP หน่วยงานภายนอก 1) เข้าใจแนวคิด และการใช้งานภาษา UML

18. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
9
รหัส บทบาท ความสามารถที่ต้องการ
2) มีทักษะด้านการใช้งานซอฟต์แวร์สาหรับควบคุมรุ่นของซอฟต์แวร์ (Versioning
Control)
3) สามารถพัฒนาซอฟต์แวร์ที่ทดสอบได้ (Testable code) เข้าใจและดาเนินการ
พัฒนาภายใต้แนวคิด Test-Driven Development หรือ TDD
PPQA หน่วยงานประกัน
คุณภาพผลิตภัณฑ์
และกระบวนการ
1) การมีมุมมองหรือการตระหนักถึงเรื่องคุณภาพของกระบวนการ ตลอดจน
ผลิตภัณฑ์ที่เกิดขึ้นอันเนื่องมาจากกระบวนการ
2) เข้าใจมาตรฐานด้านกระบวนการรวมถึงการตรวจวัดกระบวนการที่เกี่ยวข้องเป็น
อย่างดี และมีประสบการณ์การทางานที่เกี่ยวข้อง
SCM หน่วยงานบริหาร
จัดการการ
เปลี่ยนแปลง
1) ใช้งานซอฟต์แวร์สาหรับควบคุมรุ่นของซอฟต์แวร์ได้อย่างมีประสิทธิภาพ
2) เข้าใช้วิธีการที่เป็นมาตรฐาน ตลอดจนมีประสบการณ์การจัดด้านการจัดการ
ซอฟต์แวร์
SEPG กลุ่มงานวิศวกรรม
ซอฟต์แวร์
กระบวนการ
1) เข้าใจมาตรฐานการนิยามกระบวนการ และแบบจาลองการดาเนินการที่ใช้อ้างอิง
ตลอดจนรายการกิจกรรมตามมาตรฐาน
2) เข้าใจมาตรวัดของกระบวนการที่เป็นมาตรฐาน
3) เข้าใจกระบวนการการดาเนินงานเชิงธุรกิจขององค์กร
ELG คณะผู้บริหาร 1) มีความรู้ความสามารถ ตลอดจนประสบการณ์การทางาน ในกลุ่มงานที่เกี่ยวข้อง
กับลักษณะการดาเนินการเชิงธุรกิจขององค์กร ตลอดจนสามารถบริหารองค์กร
ได้อย่างมีประสิทธิภาพ
RA ผู้ดูแลคลังทรัพยากร 1) ใช้งานซอฟต์แวร์สาหรับควบคุมรุ่นของซอฟต์แวร์ได้อย่างมีประสิทธิภาพ
2) สามารถบริหารจัดการการเปลี่ยนแปลง และควบคุมรุ่นของผลิตภัณฑ์ได้อย่างมี
ประสิทธิภาพ
3) เข้าใจกระบวนการสื่อสารภายในองค์กรเป็นอย่างดี
TW นักเขียนเอกสารเชิง
เทคนิค
1) มีความรู้และประสบการณ์ในการพัฒนาซอฟต์แวร์และการบารุงรักษาซอฟต์แวร์
2) มีความรู้ความสามารถในการใช้แผนภาพ UML เป็นอย่างดี
3) มีความรู้ความสามารถในการพัฒนา
4) มีทักษณะในการจับประเด็น
5) มีทักษะทางด้านภาษาไทย และ อังกฤษอยู่ในเกณฑ์ดี
6) มีทักษะในการจัดทาเอกสารรายงาน

19. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
10
2.2 กิจกรรมและภาระงาน
กระบวนการออกแบบรายละเอียดซอฟต์แวร์จะมีกิจกรรมดังตารางต่อไปนี้
ตารางที่ 4 รายการกิจกรรมในกระบวนการออกแบบรายละเอียดซอฟต์แวร์
# รายการกิจกรรม สกรัมเฟส
1 ขั้นตอนตรียมการก่อนเริ่มโครงการ (Initiation Phase)
1.1 PP-ADPI-PDEF: การนิยามกระบวนการ (Process Definition) Sprint 0
1.2 PP-ADPI-PDEP: การนานิยามกระบวนการออกแบบรายละเอียดซอฟต์แวร์ไปใช้
(Software Detailed Design Process Deployment)
2 ขั้นตอนวางแผน (Planning Phase)
2.1 PP-PLPH-SPP1: การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
Sprint Planing Part I
และ
Refinement2.2 PP-DEVP-ADJR: การจัดปรับแผนและรายละเอียดซอฟต์แวร์ (Adjust Plan and
Redesign)
2.3 PP-PLPH-SPP2: การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงสอง (Software
Detailed Design Planning Part II)
Sprint Planing Part II
2.4 PP-DEVP-ADJR: การจัดปรับแผนและรายละเอียดซอฟต์แวร์ (Adjust Plan and
Redesign)
3 ขั้นตอนการดาเนินงาน (Execute Phase)
3.1 PP-DEVP-DESS: ออกแบบรายละเอียดซอฟต์แวร์ (Develop detailed design) Sprint
3.2 PP-DEVP-DOCD: จัดทาเเอกสารของการปรับปรุงการออกแบบซอฟต์แวร์
(Document software design)
3.3 PP-DEVP-UTCP: จัดทาหรือปรับปรุงกรณีทดสอบ และการทดสอบ (Test Cases
and Test Procedures)
3.4 PP-DEVP-VFTC: ตรวจสอบความถูกต้องของกรณีทดสอบ และแผนการทดสอบ
(Verification and approval of the test cases and test procedures)
3.5 PP-DEVP-UTCR: ปรับปรุงระเบียนตามรอย (Update the Traceability Record)
3.6 PP-DEVP-REVE: ทวนสอบและประเมินแบบรายละเอียดซอฟต์แวร์
3.7 PP-DEVP-REPO: การจัดเก็บผลลัพธ์ของกระบวนการในที่เก็บข้อมูลของ
โครงการ (Project Repository)
4 ขั้นตอนการควบคุมติดตาม (Monitoring and Control Phase)
4.1 PP-MCTR-PMCD: การติดตามและควบคุมการดาเนินงาน ระดับโครงการ
(Monitoring and Control: Overview)
Sprint
4.2 PP-MCTR-PMCR: การติดตามและควบคุมการดาเนินงาน ในระดับองค์กร
5 ขั้นตอนตรวจประเมินการออกแบบ (Evaluation Phase)

20. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
11
# รายการกิจกรรม สกรัมเฟส
5.1 PP-SDDR-DDER: การประเมินและทบทวนการออกแบบรายละเอียดซอฟต์แวร์
(Detailed Design Evaluation : Retrospective)
Restrospective
2.3 ชิ้นงานนาเข้า
2.3.1 รายการชิ้นงานนาเข้าที่จาเป็นในการดาเนินกระบวนการ
ตารางที่ 5 รายการชิ้นงานนาเข้าในกระบวนการออกแบบรายละเอียดซอฟต์แวร์
รหัส ชื่อ คาอธิบาย แหล่งข้อมูล
SRS ข้อกาหนดความต้องการ
(Software Requirements
Specification)
เอกสารข้อกาหนดความต้องการของซอฟต์แวร์
อย่างเป็ นทางการ ที่จะบอกให้ทีมพัฒนา
ซอฟต์แวร์ทราบว่าต้องพัฒนนาอะไรบ้าง
รายละเอียดของเอกสารขึ้นอยู่กับระบบที่จะทา
การพัฒนา และกระบวนการที่ใช้
Produck Backlog
UIDS ส่วนต่อประสานกับผู้ใช้
(User Interface Design)
การออกแบบส่วนต่อประสานระหว่างผู้ใช้กับ
คอมพิวเตอร์ ซึ่งมีกระบวนการที่เริ่มจากการ
รวบรวมข้อมูลที่เกี่ยวข้อง เพื่อมาร่วมกันพัฒนา
กระบวนการออกแบบพัฒนาส่วนต่อประสาน
ให้ใช้งานได้อย่างมีประสิทธิภาพ
-
SWAD สถาปัตยกรรมซอฟต์แวร์
(Software Architectural Design)
โ ค ร ง สร้ าง ข อ ง สถ าปั ต ย กร ร ม แ ล ะ
ความสัมพันธ์ระหว่างกันของส่วนต่างๆ ที่
ประกอบกันเป็นระบบ ทาให้เห็นภาพรวมของ
ระบบทั้งหมดในระดับ High Level
-
PRJP แผนงานโครงการ
(Project Plan)
เป็ นเอกสารกาหนดภาพรวมของโครงการ
รวมถึงขั้นตอนการทางาน กิจกรรมที่ต้อง
ดาเนินการในโครงการ พร้อมกาหนดเวลาที่ใช้
ในแต่ละกิจกรรม
-

21. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
12
2.3.2 รายการชิ้นงานที่สนับสนุนระดับความสามารถของกระบวนการ
ตารางที่ 6 รายการชิ้นงานที่มีการนามาใช้เพื่อช่วยเสริมระดับคุณภาพของกระบวนการ
รหัส ชื่อ คาอธิบาย ชื่อชิ้นงานในสกรัม
ORPL ข้อบังคับ ระเบียบวิธีปฏิบัติของ
องค์กร (Organization Policy)
ข้อบังคับ ระเบียบวิธีปฏิบัติ หรือแนวทางการ
ดาเนินงาน ที่องค์กรยึดถือปฏิบัติ
ISTD มาตรฐานการดาเนิ นงาน
(International Standard)
แนวทาง หรือขั้นตอนการดาเนินงานที่เกี่ยวข้อง
และนามาใช้อ้างอิงนในกระบวนการ ซึ่งใช้เป็น
มาตรฐานสากล
SDMT แนวคิดการพัฒนาซอฟต์แวร์
(Software Development
Methodology)
กรอบงานหรือแนวคิดการในการพัฒนา
ซอฟต์แวร์ ตลอดจนแนวทางการปฏิบัติงาน
สาหรับอ้างอิง และเกี่ยวข้องกับการดาเนินงาน
ในกระบวนการที่ต้องการปรับปรุง (SDLC
Framework, Development Methodology)
OPAs สินทรัพย์กระบวนการขององค์กร
(Organizational Process Assets)
ผลการดาเนินงานที่ผ่านมาขององค์กร แบบ
บันทึกรายการข้อมูล แนวทางการดาเนินงาน
ตลอดจนข้อมูลอื่นๆ ที่สนับสนุนการ
ดาเนินงาน
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์ (Software Detailed
Design Plan)
แผนการออกแบบที่สอดคล้องกับแนวทาง
ปฏิบัติการมาตรฐานซึ่งองค์กรยึดถือปฏิบัติ
STRQ รายการความต้องการของผู้มีส่วน
ได้ส่วนเสีย (Stakeholder
Requirements)
รายการความต้องการจากผู้มีส่วนได้ส่วนเสีย
กับกระบวนการทางาน และส่งผลต่อการ
ดาเนินการกระบวนการ
Product backlog
2.4 ชิ้นงานส่งออก
2.4.1 รายการชิ้นงานส่งออกที่จาเป็น
ตารางที่ 7 รายการผลลัพธ์ในกระบวนการออกแบบรายละเอียดซอฟต์แวร์
รหัส ชื่อ คาอธิบาย ปลายทาง
SDDS รายละเอียดซอฟต์แวร์
(Software Design
Description)
- รายละเอียดของการออกแบบซอฟต์แวร์ในส่วน
ต่างๆ และอธิบายส่วนย่อยของซอฟต์แวร์ที่จะ
พัฒนาขึ้น ส่วนต่อประสาน (Interface) ที่เชื่อม
ต่อไปยังส่วนอื่นภายนอกส่วนย่อยของซอฟต์แวร์
จะต้องอธิบายไว้ด้วย และรายละเอียดซอฟต์แวร์
Software
Implementation

22. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
13
รหัส ชื่อ คาอธิบาย ปลายทาง
ต้องถูกต้องตรงกันและตรวจสอบย้อนกลับไปยัง
รายการความต้องการและสถาปัตยกรรมที่
ออกแบบไว้ได้
ข้อมูลการออกแบบต้องประกอบด้วย
- การออกแบบฐานข้อมูล
- การออกแบบซอฟต์แวร์ระดับล่าง
- ส่วนต่อประสาน(Interface) ที่เชื่อมต่อไปยังส่วน
อื่น
- ส่วนต่อประสาน (Interface) ที่เชื่อมภายใน
TCRC ระเบียนตามรอย
(Traceability Record)
- แสดงความสัมพันธ์ระหว่างนข้อกาหนดความ
ต้องการ ซอฟต์แวร์ การออกแบบองค์ประกอบ
ส่วนประกอบ (elements) กรณีทดสอบและ
ขั้นตอนการทดสอบ
- ระบุข้อกาหนดข้อกาหนดความต้องการที่ต้องการ
ติดตาม (traced)
- สามารถตรวจสอบย้อนกลับทั้งทั้งแบบจากหน้า
ไปหลัง และย้อนกลับของความเชื่อมโยงระหว่า
ข้อกาหนดในการออกแบบซอฟต์แวร์
องค์ประกอบส่วนประกอบ กรณีทดสอบ และขั้น
ตอนการทดสอบ
- สามารถตรวจสอบไปถึง ความต้องการที่ไม่ใช่
หน้าที่หลัก (Nonfunctional requirement) ได้
- สามารถตรวจสอบไปถึง ความต้องการที่เป็น
หน้าที่หลัก (Functional requirement) ได้
- มีการกาหนดสถานะดังนี้: Verified , Baselined
และ Updated
Software
Implementation
TCTP ก ร ณี ท ด ส อ บ แ ล ะ
ขั้นตอนการทดสอบ
(Test Cases and Test
Procedures)
กรณีทดสอบอาจรวมถึง:
- ระบุข้อมูลกรณีทดสอบ
- รายการทดสอบข้อกาหนดของอินพุต
ข้อกาหนดของผลลัพธ์
- สภาพแวดล้อมที่จาเป็น (Environmental needs)
- กาหนดความต้องการของขั้นตอนพิเศษ
- ความสัมพันธ์ของอินเทอร์เฟส (Interface
dependencies)
ขั้นตอนการทดสอบ:
Software
Implementation

23. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
14
รหัส ชื่อ คาอธิบาย ปลายทาง
- ชื่อของการทดสอบ
- ทดสอบคาอธิบาย
- วันสิ้นสุดการทดสอบ
- ระบุว่ามีปัญหาการใช้งาน
ระบุบุคคลที่เสร็จสิ้นการทดสอบระบุข้อกาหนด
เบื้องต้น
ระบุขั้นตอนของกระบวนการรวมถึงหมายเลข
ขั้นตอน การดาเนินการที่จาเป็น โดยการทดสอบ
และผลลัพธ์คาดไว้
มีการกาหนดสถานะดังนี้: Verified และ baselined
2.4.2 ชิ้นงานสนับสนุนระดับความสามารถกระบวนการ
ตารางที่ 8 ชิ้นงานที่เกิดเพื่อสนับสนุนความสามารถระดับที่ 2 ตามมาตรฐาน ISO/IEC 15504-5
รหัส ชื่อ คาอธิบาย ปลายทาง
SDDP แผนการออกแบบ
รายละเอียดซอฟต์แวร์
PP-PLPH-SPP1: การวางแผนออกแบบรายละเอียด
ซอฟต์แวร์ช่วงแรก (Software Detailed Design Part I)
Project Management
VLRS ผลการตรวจประเมิน
(Validation Results)
ซึ่งจะต้องประด้วยข้อมูลดังนี้:
- รายชื่อผู้มีส่วนรวม
- วันที่ตรวจประเมิน
- สถานที่
- ช่วงเวลา
- รายการตรวจสอบ (Validation check-list)
- รายการที่ผ่านการประเมิน
- รายการที่ไม่ผ่านการประเมิน
- รายการที่ยังไม่ได้ประเมิน
- ข้อผิดผลาดที่จรวจพบ
คาแนะนาในการแก้ไข
Project Management
Software
Implementation
CMDB Configuration
Management Database
ซึ่งจะต้องประด้วยข้อมูลดังนี้:
- ข้อกาหนดความต้องการ
- รายละเอียดซอฟต์แวร์
- ตารางตรวจสอบย้อนกลับ
- ส่วนประกอบซอฟต์แวร์
- ซอฟต์แวร์ส่วนย่อย
- กรณีทดสอบและกระบวนการทดสอบ (Test
Cases and Test Procedures)
Software
Implementation

24. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
15
รหัส ชื่อ คาอธิบาย ปลายทาง
- รายงานผลการทดสอบ (Test Report)
- Product Operation Guide
- Software User Documentation
- Maintenance Documentation
มีการกาหนดสถานะดังนี้: Delivered และ Accepted.
AMG วิธีการจัดการกับ
สินทรัพย์ขององค์กร
(Assets management
guideline)
แนวทางการดาเนินงานในขั้นตอนการจัดการ
ผลิตภัณฑ์ ข้อมูลที่เกิดขึ้นภายในโครงการ ตลอดจน
ข้อมูลที่ใช้สนับสนุนการดาเนินงาน เช่น แบบบันทึก
ข้อมูล
PP-ADPI-PDEF: การ
นิยามกระบวนการ
(Process Definition)
RPA Role-related process
activity
หน้าที่ที่เกี่ยวข้องกับการดาเนินงานในกระบวนการที่
ได้นิยามขึ้นมา ซึ่งประกอบไปด้วยคาอธิบายการ
ดาเนินงาน และคุณลักษณะของบุคลากรที่เหมาะสม
ในการดาเนินงานนั้นๆ (Role-related process activity)
PP-ADPI-PDEP: การ
นานิยามกระบวนการ
ออกแบบรายละเอียด
ซอฟต์แวร์ไปใช้
(Software Detailed
Design Process
Deployment)
PND วางแผนการประชุม
Daily Scrum
(Planning Daily)
รายการหัวข้อในการประชุม Daily Scrum ของทีมใน
แต่ละวัน
PP-MCTR-PMCD:
การติดตามและ
ควบคุมการ
ดาเนินงาน ระดับ
โครงการ
(Monitoring and
Control: Overview)
ตารางที่ 9 ชิ้นงานที่เกิดเพื่อสนับสนุนความสามารถระดับที่ 3 ตามมาตรฐาน ISO/IEC 15504-5
รหัส ชื่อ คาอธิบาย ปลายทาง
PG กระบวนการเป้าหมายที่
ต้องการปรับปรุง
(Process Gap)
รายการกิจกรรมหรือคุณลักษณะของกระบวนการ
เป้าหมายที่องค์กรต้องการบรรลุ แต่ยังไม่ปรากฎใน
กระบวนการเป้าหมายที่ต้องการปรับปรุง (Process
Gap)
RPA Role-related process
activity
หน้าที่ที่เกี่ยวข้องกับการดาเนินงานในกระบวนการที่
ได้นิยามขึ้นมา ซึ่งประกอบไปด้วยคาอธิบายการ
ดาเนินงาน และคุณลักษณะของบุคลากรที่เหมาะสม
ในการดาเนินงานนั้นๆ (Role-related process activity)
PP-ADPI-PDEP: การ
นานิยามกระบวนการ
ออกแบบรายละเอียด
ซอฟต์แวร์ไปใช้

25. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
16
รหัส ชื่อ คาอธิบาย ปลายทาง
(Software Detailed
Design Process
Deployment)
ADP กระบวนการที่ผ่านการ
อนุมัติใช้งาน
(Approved Defined
Process)
รายการกระบวนการใหม่ที่ได้นิยามขึ้นเพื่อปรับปรุง
กระบวนการเดิม และสอดคล้องกับตัวชี้วัดที่ได้
จัดเตรียมเอาไว้ ซึ่งผ่านการอนุมัติจากคณะผู้บริหาร
เรียบร้อยแล้ว (Approved Defined Process)
PP-ADPI-PDEP: การ
นานิยามกระบวนการ
ออกแบบรายละเอียด
ซอฟต์แวร์ไปใช้
(Software Detailed
Design Process
Deployment)
PORP แหล่งเก็บข้อมูล
กระบวนการ
ระบบสาหรับจัดเก็บข้อมูล Project
LERN ความรู้และปัญหา
พร้อมแนวทางแก้ไข ที่
เกิดขึ้นในกิจกรรม
แนวทางปฏิบัติที่ดี ที่สามารถแก้ไขปัญหา หรือสิ่งที่ได้
เรียนรู้ระหว่างการปฏิบัติงาน
PP-SDDR-DDER:
การประเมินและ
ทบทวนการออกแบบ
รายละเอียด
ซอฟต์แวร์ (Detailed
Design Evaluation :
Retrospective)
FDB ข้อเสนอแนะการ
ปฏิบัติงาน (Feedback)
ข้อเสนอแนะ แนวทางการแก้ไข หรือแนวทางปฏิบัติที่
ดีที่เกิดขึ้นระหว่างการดาเนินงานกิจกรรมภายใน
กระบวนการ
PP-SDDR-DDER:
การประเมินและ
ทบทวนการออกแบบ
รายละเอียด
ซอฟต์แวร์ (Detailed
Design Evaluation :
Retrospective)
RDM รายงานสรุปการประชุม
Daily Scrum
(Report Daily Scrum
Meeting)
แสดงถึงรายละเอียดผลการประชุม Daily Scrum เพื่อ
เป็ นประโยชน์ในการตรวจสอบการทางานของ
Development Team
Monitoring and
Control
PP-MCTR-PMCR:
การติดตามและ
ควบคุมการ
ดาเนินงาน ในระดับ
องค์กร
ISL รายการปัญหาที่เกิดขึ้น
(Issue List)
ข้อมูลสรุปรายการปัญหาที่เกิดขึ้นในการทางานแต่ละ
วัน
Monitoring and
Control

26. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
17
รหัส ชื่อ คาอธิบาย ปลายทาง
PP-MCTR-PMCR:
การติดตามและ
ควบคุมการ
ดาเนินงาน ในระดับ
องค์กร
PGR รายงานความก้าวหน้า
ของการดาเนินงาน
(Progress Report
(Burndown Chart))
ต้องประกอบด้วยข้อมูลดังนี้:
- ข้อมูลการทางานที่ได้ดาเนินงานที่ได้เสร็จลุล่วง
แล้ว
- สรุปข้อสาคัญของงาน เช่น ขั้นตอนที่ทา
ปัญหา ข้อแนะนา อ้างอิง เป็นต้น
- รายละเอียดแผนงานที่จะทา ทางเลือก ความ
เสี่ยง โอกาส
- รายละเอียดความต้องการเพิ่มเติม
Monitoring and
Control
PP-MCTR-PMCR:
การติดตามและ
ควบคุมการ
ดาเนินงาน ในระดับ
องค์กร
SQAR รายงานการประกัน
คุณภาพซอฟต์แวร์
(Software Quality
Assurance Report)
ผลการตรวจสอบคุณภาพการดาเนินการ PP-SDDR-DDER:
การประเมินและ
ทบทวนการออกแบบ
รายละเอียด
ซอฟต์แวร์ (Detailed
Design Evaluation :
Retrospective)
2.5 คุณภาพและการประเมินคุณภาพงานออกแบบ
ตารางที่ 10 เกณฑ์ประเมินคุณภาพสาหรับในกระบวนการออกแบบรายละเอียดซอฟต์แวร์
เกณฑ์คุณภาพ รายละเอียด
เกณฑ์คุณภาพ (Quality Attribute / Non-Functional
Requirement)
1) การทางานของระบบ (หน้าที่ทั่วไป ความ
ปลอดภัย)
2) ความสามารถในการใช้งาน(ใช้งานง่าย เรียนรู้ได้
เร็ว)
3) ความน่าเชื่อถือ (ความผิดพลาด ความถูกต้องของ
ผลลัพธ์)

27. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
18
เกณฑ์คุณภาพ รายละเอียด
4) ประสิทธิภาพ (ความเร็วในการประมวลผล
ระยะเวลาตอบสนอง)
5) ความสามารถในการสนับสนุนการใช้งาน (การ
บารุงรักษา การปรับปรุง การทางานข้ามระบบ)
การวิเคราะห์และประเมินคุณภาพ (Analysis and
Evaluation)
1) ทบทวนงานออกแบบซอฟต์แวร์
2) วิเคราะห์งานออกแบบ
3) การตรวจสอบความสอดคล้อง
4) การประเมินความเป็นไปได้ในการพัฒนาทดสอบ
และ ดูแลรักษา
5) การประเมินตามหลักการออกแบบเชิงวัตถุ
การวัด (Measurement) 1) Coupling วัดความสัมพันธ์ระหว่าง 2 โมดูล มี
ความขึ้นต่อกันมากน้อยเพียงใด (ยิ่งน้อย ยิ่งดี)
2) Cohesion ระดับการยึดเกาะกันของหน้าที่ใน
โมดูล (ยิ่งมาก ยิ่งดี)

28. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
19
2.6 ภาพรวมกระบวนการ
ภาพที่ 2-2: ภาพรวมของกระบวนการที่นิยามขึ้น

29. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
20
การนิยามกระบวนการนั้นมีกิจกรรมอื่นๆ ที่เกี่ยวเนื่องกันเพื่อให้ได้ผลลัพธ์ตามที่องค์กรคาดหวัง ภาพที่ 2-2 แสดง
ถึงความสัมพันธ์ภายในกระบวนการสาหรับ 1 สปรินท์การทางาน ในขั้นตอนการนิยามกระบวนการนั้นจะประกอบไปด้วย
หลายกิจกรรม ดังมีละเอียดของแต่ละกิจกรรมดังต่อไปนี้
2.7 รายละเอียดกิจกรรมในช่วงเริ่มโครงการ (Activities Detailed of Project Initiation Phase)
2.7.1 PP-ADPI-PDEF: การนิยามกระบวนการ (Process Definition)
กระบวนการในการทางานนั้น ย่อมต้องมีการเปลี่ยนแปลงและปรับปรุงให้เข้ากับลักษณะงาน วิธีการดาเนินงาน
หรือความคาดหวังขององค์กร ดังนั้นเพื่อให้กระบวนการนั้นตอบสนองกับความต้องการเหล่านั้น จึงจาเป็นต้องนิยาม
กระบวนการที่สอดคล้องกับมาตรฐาน ลักษณะงาน วิธีการดาเนินงาน ตลอดจนความคาดหวังขององค์กร ซึ่งจะมีรายการ
กิจกรรมดังข้อมูลด้านล่าง
หมายเลขอ้างอิง PP-ADPI-PDEF
ชื่อกิจกรรม การนิยามกระบวนการ (Process Definition)
วัตถุประสงค์ 1. เพื่อศึกษาข้อกาหนดในการดาเนินงานที่องค์กรกาหนดไว้และ/หรือ ข้อกาหนดขององค์กร
อื่น ๆ ภายนอกที่ส่งผลต่อการดาเนินงานขององค์กรภายใน
2. ศึกษาทรัพย์สินกระบวนการขององค์กรที่มีอยู่เดิม เพื่อนามาปรับใช้งานกับกระบวนการที่
จะนิยามขึ้นมาใหม่โดยคณะทางาน และเสนอให้กับผู้บริหารสูงสุดเพื่อขออนุมัติให้นาไป
ประกาศใช้งานต่อไป
ผลลัพธ์ 1. ทราบรายการของข้อกาหนดทั้งภายในองค์กร และภายนอกองค์กรที่ส่งผลกระทบต่อการ
ดาเนินงาน
2. บทบาทหน้าที่ของบุคลากรที่ชัดเจนยิ่งขึ้น
3. ได้ตัวชี้วัดกระบวนการที่เป็นเป้าหมายในการดาเนินงาน
4. ทราบรายการกิจกรรมที่ยังคงขาดหายไปเมื่อเทียบกับตัวชี้วัดเป้าหมาย
5. นิยามกระบวนการที่เหมาะสมกับลักษณะการทางานขององค์กร
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
ELG คณะผู้บริหาร พิจารณา และอนุมัติกระบวนการ โดยรับร่างของ
กระบวนการที่นิยามขึ้นมาจากคณะทางาน เพื่อให้นาไป
ประกาศใช้งานภายในองค์กรต่อไป
SEPG กลุ่มงาน
วิศวกรรม
วิเคราะห์ความต้องการ ช่องว่างขององค์กรจากเป้าหมาย
ที่วางไว้และสถานะปัจจุบันของกระบวนการ ตลอดจน

30. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
21
ซอฟต์แวร์
กระบวนการ
ทรัพยากรกระบวนการ ข้อกาหนด เพื่อนามาใช้เป็นข้อมูล
ในการนิยามกระบวนการให้เหมาะสมกับโครงการ
DEV ทีมพัฒนา บุคลากรภายในหน่วยงานที่มีความเกี่ยวข้องกับ
กระบวนการทางาน
RA ผู้ดูแลคลัง
ทรัพยากร
ดูแลคลังเอกสารให้เกิดความสอดคล้องกันในการ
นาไปใช้งาน บารุงรักษารายการเอกสารทั้งหมดให้
ผู้ใช้งานสามารถนาไปใช้งานได้อย่างถูกต้อง รวมไปถึง
การหน้าที่สื่อสารกับผู้ใช้งานเอกสารในองค์กรด้วย
ช่องทางที่เหมาะสม เมื่อมีการปรับปรุงรุ่นของเอกสาร
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
ORP รายการความต้องการในการปรับปรุง
กระบวนการขององค์กร ข้อบังคับ ระเบียบวิธี
ปฏิบัติขององค์กร และกฏหมายที่เกี่ยวข้อง
(Organization Requirements and Policy)
ข้อมูลภายนอก, ฝ่ายบริหารงาน
ขององค์กร
SDM กรอบงานหรือแนวคิดการในการพัฒนา
ซอฟต์แวร์ ตลอดจนแนวทางการปฏิบัติงาน
สาหรับอ้างอิง และเกี่ยวข้องกับการดาเนินงาน
ในกระบวนการที่ต้องการปรับปรุง (SDLC
Framework, Development Methodology)
ข้อมูลภายนอก
STD มาตรฐานสากลเพื่อใช้อ้างอิงในการนิยาม
กระบวนการ เช่น ISE/IEC 15504, IEEE
12207
ข้อมูลภายนอก

31. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
22
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
AMG วิธีการหรือคาแนะนาในการใช้งานและ
จัดการกับสินทรัพย์กระบวนการขององค์กร
(Asset management guideline)
Process deploymentPP-ADPI-
PDEP: การนานิยาม
กระบวนการออกแบบ
รายละเอียดซอฟต์แวร์ไปใช้
(Software Detailed Design
Process Deployment)
RPA หน้าที่ที่เกี่ยวข้องกับการดาเนินงานใน
กระบวนการที่ได้นิยามขึ้นมา ซึ่งประกอบไป
ด้วยคาอธิบายการดาเนินงานและคุณลักษณะ
ของบุคลากรที่เหมาะสมในการดาเนินงาน
นั้นๆ (Role-related process activity)
Process deploymentPP-ADPI-
PDEP: การนานิยาม
กระบวนการออกแบบ
รายละเอียดซอฟต์แวร์ไปใช้
(Software Detailed Design
Process Deployment)
DPA สินทรัพย์ที่เกิดขึ้ นโดยสอดคล้องกับ
กระบวนการที่ได้นิยามขึ้นมา (Defined
process’sassets)เช่น แนวทางการดาเนินงาน
แบบบันทึกข้อมูล หรือข้อกาหนดในในการ
ดาเนินงาน
Process deploymentPP-ADPI-
PDEP: การนานิยาม
กระบวนการออกแบบ
รายละเอียดซอฟต์แวร์ไปใช้
(Software Detailed Design
Process Deployment)
PG คาอธิบายกระบวนการ แสดงถึงขั้นตอนการ
ทางานของกระบวนการ เพียงพอที่จะนาไป
ปฏิบัติตามได้ และสอดคล้องกับข้อกาหนด
ตลอดจนระเบียบวิธีปฏิบัติเดิมขององค์กร
(Process guideline)
Process deploymentPP-ADPI-
PDEP: การนานิยาม
กระบวนการออกแบบ
รายละเอียดซอฟต์แวร์ไปใช้
(Software Detailed Design
Process Deployment)
PDP รายการกระบวนการใหม่ที่ได้นิยามขึ้น
เฉพาะเจาะจงกับกระบวนการเป้าหมายเพื่อ
ปรับปรุงกระบวนการเดิม และสอดคล้องกับ
ตัวชี้วัดที่ได้จัดเตรียมเอาไว้ซึ่งผ่านการอนุมัติ
จากคณะผู้บริหารเรียบร้อยแล้ว
PP-ADPI-PDEP: การนานิยาม
กระบวนการออกแบบ
รายละเอียดซอฟต์แวร์ไปใช้
(Software Detailed Design
Process Deployment)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. มีความต้องการที่จะปรับปรุงกระบวนการ
เงื่อนไขการจบสิ้น
(Exit criteria)
1. ได้รับนิยามกระบวนการที่เหมาะสมกับการดาเนินงานขององค์กร
2. นิยามกระบวนการได้รับอนุมัติจากคณะผู้บริหาร

32. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
23
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. การศึกษากระบวนการมาตรฐานเดิมที่เกี่ยวข้อง (Studyingexists related standard
process)
1.1. ศึกษากระบวนการที่เป็นมาตรฐานหรือกระบวนการที่ได้นิยามไว้แล้ว ซึ่งเกี่ยวข้อง
กับกระบวนการที่สนใจ เพื่อนาข้อมูลที่ได้มาตัดสินใจ นากระบวนการนั้นมาใช้งาน
โดยทันที ด้วยขั้นตอนในกระบวนการ PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้ (Software Detailed Design Process
Deployment)
1.2. หากไม่พบกระบวนการที่เกี่ยวข้อง หรือต้องการนากระบวนการมาปรับปรุงให้
เหมาะสมกับองค์กร จึงควรนิยามกระบวนการตามที่ต้องการด้วยกิจกรรมถัดไป
SPEG

33. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
24
2. การศึกษาข้อกาหนด เป้าหมาย และกระบวนการจัดการนาเอาทรัพยากรมาใช้งานอีกครั้ง
(Study of regulations, goal and process of reuse assets management)
2.1. ศึกษาข้อกาหนดในการดาเนินงานที่จาเป็น ทั้งข้อกาหนดที่สร้างขึ้นเพื่อใช้งาน
ภายในองค์กร และข้อกาหนด มาตรฐาน หรือกฎหมาย ที่องค์กรควร/ต้องปฏิบัติ
ตาม
2.2. ศึกษาเป้าหมายของการดาเนินงานที่องค์กรต้องการปรับปรุง ด้วยการประเมินที่
เหมาะสม เพื่อให้ทราบถึงรายการกิจกรรมที่ควรจะต้องนิยาม หรือดาเนินการ
เพิ่มเติมจากกระบวนการเดิมขององค์กร ให้ได้ผลลัพธ์ตามกระบวนการที่องค์กร
คาดหวัง
2.3. ศึกษาวิธีการบริหารจัดการสินทรัพย์กระบวนการขององค์กร เพื่อให้ได้มาซึ่ง
แนวทางหรือกระบวนการจัดการสินทรัพย์ที่องค์กรปฏิบัติอยู่เดิม
3. สรุปผลการศึกษา รายการข้อมูล ผลลัพธ์ที่ได้ ตลอดจนข้อมูลที่เกี่ยวข้อง รวมถึงตัวชี้วัดที่
ต้องใช้เพื่อบ่งชี้ถึงความสาเร็จของการปรับนิยามกระบวนการ
4. ศึกษาสินทรัพย์กระบวนการ (Study for organizational process assets)
4.1. ศึกษาสินทรัพย์กระบวนการขององค์กรที่เกี่ยวข้องกับกระบวนการที่ต้องนิยาม เพื่อ
วิเคราะห์หาแนวทางการพัฒนา
4.2. จัดลาดับความสาคัญและเป้าหมายที่ต้องการพัฒนาของกระบวนการ
SEPG
5. วิเคราะห์และออกแบบบทบาทหน้าที่ที่เกี่ยวข้องกับกิจกรรมภายในกระบวนการ
(Analysis and design of role-related process activity)
5.1. สร้างรายการกิจกรรมที่ต้องดาเนินการภายในกระบวนการพัฒนาเดิม พร้อมหน้าที่
และบทบาทการที่รับผิดชอบดาเนินการในแต่ละกิจกรรม พร้อมทั้งวิเคราะห์
คุณลักษณะของกิจกรรมและหน้าที่
5.2. เพิ่มหรือปรับกิจกรรมเพื่อให้กระบวนการนั้นสอดรับกับเป้าหมายที่หน่วยงาน
ต้องการ
5.3. เพิ่มหรือปรับบทบาทหน้าที่ในกระบวนการพัฒนาเดิม ให้สอดประสานกับกิจกรรม
ที่มีการเปลี่ยนแปลง
5.4. สรุปรายการกิจกรรมและบทบาทที่เปลี่ยนแปลง
SEPG, DEV
6. นิยามรายละเอียดการดาเนินงานของกิจกรรมที่เปลี่ยนแปลง (Define details in each
arisen activities)
6.1. นิยามรายละเอียดของกิจกรรมที่มีการเปลี่ยนแปลง โดยรายละเอียดของกิจกรรมที่
ต้องนิยามขึ้น ควรจะสอดคล้องกับตัวชี้วัดที่ได้กาหนดขึ้น
SEPG

34. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
25
6.2. นิยามรายละเอียดของการดาเนินงานสาหรับบทบาทที่มีการเปลี่ยนแปลง โดย
รายละเอียดบทบาทหน้าที่ที่ต้องนิยามขึ้นนี้ จะต้องสอดคล้องกับกระบวนการ กฎ
ข้อบังคับของที่จาเป็นหรือน่าจะต้องปฏิบัติ และลักษณะการดาเนินงานขององค์กร
6.3. กาหนดรายการของสินทรัพย์กระบวนการ และโครงสร้างพื้นฐานที่สนับสนุนการ
ทางานของกระบวนการที่ได้นิยามขึ้น ตลอดจนขั้นตอนและแนวทางการใช้งาน
6.4. สรุปผลการนิยามกระบวนการ
7. ทบทวนการบวนการที่นิยามขึ้น เทียบเคียงกับมาตรฐานที่เกี่ยวข้อง (Review of the
defined process comparting standard)
7.1. ทารายการของกิจกรรมที่นิยามขึ้น และตัวชี้วัดที่กาหนดทั้งหมด
7.2. ประเมินกระบวนการที่ได้นิยามขึ้น เทียบกับรายการตัวชี้วัดที่สอดคล้องกันกับ
กระบวนการ และจัดเตรียมข้อมูลสาหรับนาเสนอ
7.3. รวบรวมข้อมูลตัวชี้วัดที่คงเหลือ เพื่อหาแนวทางการพัฒนาปรับปรุง และกลับไปทา
ขั้นตอนที่ 3 (PD3)
SEPG
8. นาเสนอกระบวนการที่ได้นิยามขึ้น (Present defined process)
8.1. นัดประชุมกลุ่มผู้บริหารผู้เกี่ยวข้องกับการอนุมัติกระบวนการที่ได้นิยามขึ้น ควรจะ
ให้ข้อมูลกระบวนการที่ได้นิยามขึ้นกับกลุ่มผู้บริหารล่วงหน้า
8.2. นาเสนอข้อมูลกระบวนการที่ได้นิยามขึ้น
8.3. รวบรวมข้อคิดเห็นจากผู้บริหารเพื่อนามาปรับปรุงกระบวนการในส่วนที่ยังขาด
หายไป
8.4. รอผลลัพธ์การตัดสินใจจากผู้บริหาร
8.4.1. ในกรณีที่ผู้บริหารอนุมัติ: ส่งข้อมูลกระบวนการที่ได้นิยามขึ้นมานี้เข้าสู่คลัง
ทรัพยากรขององค์กร
8.4.2. ในกรณีที่ผู้บริหารยังไม่อนุมัติ: รวบรวมข้อมูลความเห็น และนากลับไป
ปรับปรุงในขั้นตอนที่ 5 (PD5)
ELG, SEPG
9. บารุงรักษารุ่นของเอกสาร (Maintain document version)
9.1. ลงทะเบียนข้อมูลของเอกสารเข้าสู่คลังทรัพยากร ตามขั้นตอน หรือข้อกาหนดใน
การดาเนินงานขององค์กร
9.2. กาหนดหมายเลขรุ่นของเอกสารตามขั้นตอน หรือข้อกาหนดในการดาเนินงานของ
องค์กร
9.3. ในกรณีที่เป็นเอสารใหม่ ที่จัดเก็บเข้าสู่คลังทรัพยากรเป็นครั้งแรก ควรที่จะจัดกลุ่ม
ตามความสัมพันธ์ที่เกี่ยวข้องของเอกสาร โดยสอดคล้องกับระเบียบวิธีปฏิบัติของ
องค์กร
RA
10. ประกาศใช้งานเอกสารที่ปรับปรุงใหม่ (New document version announcement)
10.1. ทารายการผู้เกี่ยวข้องกับการเปลี่ยนแปลงรุ่นของเอกสาร
10.2. แจ้งประกาศการปรับปรุงรุ่นของเอกสารไปยังผู้เกี่ยวข้องกับการเปลี่ยนแปลง
ทั้งหมด ด้วยช่องทางที่เหมาะสม สอดคล้องตามระเบียบวิธีปฏิบัติ
RA

35. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
26
10.3. ควรที่จะแสดงรายการเอกสารที่มีการปรับปรุงล่าสุดไว้ที่หน้าแรกของคลัง
ทรัพยากร เพื่อสนับสนุนให้บุคลากรในองค์กรสามารถเข้าถึงเอกสารได้ง่าย
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-GAF แบบวิเคราะห์ช่องว่าง (Gap Analysis form) Template
TP-PDF แบบบันทึกข้อมูลนิยามกระบวนการ (Process Definition
form)
Template
คุณภาพที่คาดหวัง
(Quality expectation)
- กระบวนการที่ได้มีความสอดคล้องกับลักษณะการปฏิบัติงานขององค์กร
- กระบวนการที่นิยามขึ้นสอดคล้องตามระดับความสามารถที่องค์กรต้องการ
การวัดผลกิจกรรม
(Process measure)
- ตรวจสอบความสอดคล้องกับลักษณะการปฏิบัติงานขององค์กรด้วยการทวนสอบกับ
ข้อกาหนดการปฏิบัติงานที่เกี่ยวข้อง
- ตรวจสอบความสอดคล้องกับตัวแบบจาลองที่ใช้อ้างอิงสาหรับการวัดผลกระบวนการ
ตตตามระดับความสามารถที่ต้องการ
2.7.2 PP-ADPI-PDEP: การนานิยามกระบวนการออกแบบรายละเอียดซอฟต์แวร์ไปใช้ (SoftwareDetailed Design
Process Deployment)
หมายเลขอ้างอิง PP-ADPI-PDEP
ชื่อกิจกรรม การนานิยามกระบวนการออกแบบรายละเอียดซอฟต์แวร์ไปใช้ (Software Detailed Design
Process Deployment)
วัตถุประสงค์ กระบวนการที่นิยามขึ้นถูกไปใช้ในโครงการ โดยใช้การจัดอบรมเพื่อรับฟังความคิดเห็นจากผู้ที่
มีส่วนเกี่ยวข้อง และนาไปปรับปรุงกระบวนการเพื่อให้ได้กระบวนการที่เหมาะสมกับโครงการ
และสามารถนาไปใช้งานได้จริง
ผลลัพธ์ ผลลัพธ์ของกิจจกรรมคือแผนการนากระบวนการไปใช้งาน ทีมงานผู้รับผิดชอบการนา
กระบวนการไปใช้งาน และนิยามกระบวนการที่ได้รับการปรับปรุง
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
ELG กลุ่มผู้บริหาร
ระดับสูง
เป็นผู้เริ่มกิจกรรมและติดตามผลการดาเนินงาน

36. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
27
SEPG กลุ่มวิศวกรรม
ซอฟต์แวร์
กระบวนการ
เป็นผู้ดาเนินกิจกรรมหลักเพื่อให้ได้มาซึ่งการนาเอานิยาม
กระบวนการไปใช้
RA ผู้ดูแลคลัง
ทรัพยากร
ดูแลคลังเอกสารให้เกิดความสอดคล้องกันในการนาไปใช้
งาน บารุงรักษารายการเอกสารทั้งหมดให้ผู้ใช้งานสามารถ
นาไปใช้งานได้อย่างถูกต้อง รวมไปถึงการหน้าที่สื่อสาร
กับผู้ใช้งานเอกสารในองค์กรด้วยช่องทางที่เหมาะสม เมื่อ
มีการปรับปรุงรุ่นของเอกสาร
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SDDP เอกสารรายละเอียดกระบวนการตาม
มาตรฐานองค์กร
นิยามกระบวนการ
PP- ADPI- PDEF: ก า ร นิ ย า ม
กระบวนการ (Process Definition)
AMG วิธีการหรือคาแนะนาในการใช้งาน
และจัดการกับสินทรัพย์กระบวนการ
ขององค์กร (Asset management
guideline)
PP- ADPI- PDEF: ก า ร นิ ย า ม
กระบวนการ (Process Definition)
RPA หน้าที่ที่เกี่ยวข้องกับการดาเนินงานใน
กระบวนการที่ได้นิยามขึ้นมา ซึ่ง
ประกอบไปด้วยคาอธิบายการ
ดาเนินงาน และคุณลักษณะของ
บุคลากรที่เหมาะสมในการดาเนินงาน
นั้นๆ (Role-related process activity)
PP- ADPI- PDEF: ก า ร นิ ย า ม
กระบวนการ (Process Definition)
DPA สินทรัพย์ที่เกิดขึ้นโดยสอดคล้องกับ
กระบวนการที่ได้นิยามขึ้นมา (Defined
process’s assets) เช่น แนวทางการ
ดาเนินงาน แบบบันทึกข้อมูล หรือ
ข้อกาหนดในในการดาเนินงาน
PP- ADPI- PDEF: ก า ร นิ ย า ม
กระบวนการ (Process Definition)
PG คาอธิบายกระบวนการ แสดงถึง
ขั้นตอนการทางานของกระบวนการ
เพียงพอที่จะนาไปปฏิบัติตามได้และ
สอดคล้องกับข้อกาหนด ตลอดจน
ระเบียบวิธีปฏิบัติเดิมขององค์กร
(Process guideline)
PP- ADPI- PDEF: ก า ร นิ ย า ม
กระบวนการ (Process Definition)

37. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
28
PDP Project’s defined process
รายการกระบวนการใหม่ที่ได้นิยามขึ้น
เฉพาะเจาะจงกับกระบวนการเป้าหมาย
เพื่อปรับปรุงกระบวนการเดิม และ
สอดคล้องกับตัวชี้วัดที่ได้จัดเตรียม
เอาไว้ซึ่งผ่านการอนุมัติจากคณะ
ผู้บริหารเรียบร้อยแล้ว
PP- ADPI- PDEF: ก า ร นิ ย า ม
กระบวนการ (Process Definition)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
SDDP เอกสารรายละเอียดกระบวนการตาม
มาตรฐานองค์กรที่ได้รับการแก้ไขแล้ว
นิยามกระบวนการ
PAT ทีมงานปรับปรุงกระบวนการ -
PORP แหล่งเก็บข้อมูลกระบวนการ -
LERN ความรู้และปัญหา พร้อมแนวทางแก้ไข
ที่เกิดขึ้นในกิจกรรม
นิยามกระบวนการ
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. มอบหมายงานให้กับทีมงาน สมาชิกที่เกี่ยวข้องกับบทบาท ตามแผนงานของโครงการ
2. รับข้อมูลนาเข้าจากที่จัดเก็บข้อมูลโครงการได้แก่
2.1 SDDP: เอกสารรายละเอียดกระบวนการตามมาตรฐานองค์กร
เงื่อนไขการจบสิ้น
(Exit criteria)
1. เอกสารรายละเอียดกระบวนการตามมาตรฐานองค์กรที่ได้รับการแก้ไขถูกจัดทาขึ้น (ถ้ามี)
2. ทาการจัดตั้งทีมงานปรับปรุงกระบวนการ
3. จัดทาแหล่งเก็บข้อมูลกระบวนการ
4. จัดเก็บเอกสารเอกสารรายละเอียดกระบวนการลงแหล่งข้อมูลตามข้อกาหนดขององค์กร
กระบวนการทางาน

38. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
29
กิจกรรม ผู้รับผิดชอบ
1. นิยามการนาเอากระบวนการไปใช้
1.1. นิยามส่วนของกระบวนการที่สามารถมาใช้ใหม่ได้
1.2. สินทรัพย์กระบวนการ
1.3. ตั้งเป้าหมายการนาเอากระบวนการไปใช้
ELG, SEPG
2. จัดหาทีมงานปรับปรุงกระบวนการ
2.1. กาหนดรายละเอียดของงาน
2.2. กาหนดหน้าที่และความรับผิดชอบ
SEPG
3. จัดการประชุมเริ่มกิจกรรม SEPG

39. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
30
3.1. จัดสรรทรัพยากรและเงินทุน
3.2. จัดโครงสร้างโครงการ และสภาพแวดล้อมการทางาน
3.3. จัดตาแหน่งทีมงาน และความรับผิดชอบ
SEPG
4. จัดทาแผนการดาเนินงานการนาเอากระบวนการไปใช้ SEPG
5. จัดการประชุมเชิงปฏิบัติการและการฝึกอบรมทีมงานในโครงการ SEPG
6. ปรับปรุงกระบวนการ และสินทรัพย์กระบวนการตามความเห็นของทีมงาน SEPG
7. ทาการลงความเห็นเพื่ออนุมัติกระบวนการที่ถูกแก้ไข ELG, SEPG
8. บันทึกนิยามกระบวนการลงแหล่งข้อมูล RA
9. นาเอากระบวนการที่นิยามขึ้นไปใช้งานจริงในโครงการ SEPG
10. ทาการลงความเห็นเพื่อไม่อนุมัติกระบวนการที่ถูกแก้ไข
10.1 บันทึกบทเรียนและความรู้ที่ได้ลงแหล่งข้อมูล
ELG, SEPG
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
RE-PRRE Process Repository Repository
PO-CMP Configuration Management Policy Policy
คุณภาพที่คาดหวัง
(Quality expectation)
- กระบวนการที่นิยามขึ้นต้องไม่ขัดกับขั้นตอนปฏิบัติขององค์กรที่มีอยู่เดิม
- สามารถปฏิบัติได้จริง
การวัดผลกิจกรรม
(Process measure)
- สอบถามความเห็นจากบุคลากรระดับปฏิบัติงาน ผู้มีส่วนเกี่ยวข้องกับกระบวนการที่ได้
นิยามขึ้น

40. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
31
2.7.3 PP-ADPI-VAPR: การทบทวนและอนุมัติกระบวนการ (Verification and Approvement: Process)
หมายเลขอ้างอิง PP-PLPH-VAPR
ชื่อกิจกรรม การทบทวนและอนุมัติกระบวนการ (Verification and Approvement: Process)
วัตถุประสงค์ ทบทวนผลของการดาเนินงานจากกระบวนการขึ้นถึงความเหมาะสมกับแนวทางการดาเนินงาน
ขององค์กร
ผลลัพธ์ ได้แผนการออกแบบรายละเอียดซอฟต์แวร์ที่เหมาะสม
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
ELG คณะผู้บริหาร อนุมัติกระบวนการ
SEPG กลุ่มงานวิศวกรรม
ซอฟต์แวร์
กระบวนการ
นาเสนอผลการวิเคราะห์ข้อมูลกระบวนการ
RA ผู้ดูแลคลังทรัพยากร จักเก็บข้อมูลกระบวนการที่ได้นิยามขึ้นเข้าสู่คลัง
ทรัพยากร
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์
PP- ADPI- PDEP: ก า ร น า นิ ย า ม
กระบวนการออกแบบรายละเอียด
ซอฟต์แวร์ไปใช้ (Software Detailed
Design Process Deployment)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก
(Software Detailed Design Part I)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. ได้รับข้อมูลการดาเนินกระบวนการหลังจาก PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software Detailed Design Process Deployment)
2. วิเคราะห์ข้อมูลเพื่อนาเสนอกับคณะผู้บริหารเรียบร้อยแล้ว
เงื่อนไขการจบสิ้น
(Exit criteria)
1. คณะผู้บริหารให้ความเห็น (อนุมัติหรือยกเลิก)

41. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
32
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. สรุปข้อมูลการวิเคราะห์ผลของการนาเอากระบวนการไปใช้งานภายในองค์กร ซึ่งควร
ประกอบไปด้วย ความเห็นของพนักงานที่มีต่อกระบวนการ และผลการประเมินระดับ
ความสามารถของกระบวนการสอบเทียบกับเป้าหมายของโครงการ แล้วจึงส่งผลการ
วิเคราะห์ให้กับคณะผู้บริหารที่เกี่ยวข้องพร้อมคาเชิญประชุมเพื่อร่วมตัดสินใจ
SEPG
2. ประชุมคณะผู้บริหารเพื่อนาเสนอผลการวิเคราะห์ข้อมูลการนากระบวนการที่ได้นิยาม
ไปใช้งาน
SEPG
3. พิจารณาผลการวิเคราะห์ข้อมูลการนากระบวนการไปใช้งาน และให้ความเห็นเพื่อ
นาไปปรับแก้
ELG
4. พิจารณาการดาเนินการ
- อนุมัติการใช้งาน: ส่งแผนการออกแบบเข้าจัดเก็บข้อมูลในคลังทรัพยากร
- ไม่อนุมัติการใช้งาน: นาแผนการออกแบบรายละเอียดซอฟต์แวร์ไปนิยามใหม่อีก
ครั้ง (PP-ADPI-PDEP:การนานิยามกระบวนการออกแบบรายละเอียดซอฟต์แวร์ไป
ใช้(Software Detailed Design Process Deployment))
ELG
5. จัดเตรียมข้อมูลสาหรับแผนการออกแบบรายละเอียดซอฟต์แวร์ และนาเข้าจัดเก็บยัง
คลังทรัพยากร ตลอดจนแจ้งประกาศการปรับปรุงเวอร์ชันไปยังผู้เกี่ยวข้องในองค์กร
RA
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
PR-OPS Organizational Standard Process Specification (ไม่บังคับ) Process
PO-OP Organizational Policy Policy
GL-SDDG แนวทางการออกแบบรายละเอียดซอฟต์แวร์ (Software
Detailed Design Guideline)
Guideline
คุณภาพที่คาดหวัง
(Quality expectation)
- แผนการออกแบบรายละเอียดซอฟต์แวร์นั้นสามารถนาไปปฏิบัติงานได้จริงภายใน
องค์กร
- แผนการออกแบบรายละเอียดซอฟต์แวร์เป็นไปตามความคาดหวังขององค์กร
2.8 รายละเอียดกิจกรรมในขั้นตอนวางแผน (Planning Phase)
เพื่อจัดทาแผนสาหรับดาเนินงานการออกแบบรายละเอียดซอฟต์แวร์ และต้องจัดหาวิธีการสื่อสารที่มี
ประสิทธิภาพเพื่อให้การทางานเป็นไปตามแผนของการออกแบบรายละเอียดซอฟต์แวร์ โดยขั้นตอนของการวางแผน
จะต้องมีการกาหนดขอบเขต , ผลลัพธ์ , กรอบงานของการพัฒนา , กาหนดเวลาของลาดับงานการพัฒนา และกาหนด

42. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
33
รายละเอียดปลีกย่อยในการออกแบบรายละเอียดซอฟต์แวร์ได้ซึ่งการจัดทาแผนสาหรับการดาเนินงานนั้นจะต้องมีการ
กาหนดเงื่อนไขต่างๆ ที่จะทาให้ถึงเป้าหมาย และความต้องการทรัพยากรที่จะทาให้การออกแบบรายละเอียดซอฟต์แวร์
ประสบความสาเร็จ แล้วจึงจัดทาเอกสารการออกแบบรายละเอียดซอฟต์แวร์ที่ตรงกับรายการความต้องการ และสามารถ
นาไปพัฒนาต่อได้อย่างมีประสิทธิภาพ
2.8.1 PP-PLPH-SPP1: การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงแรก (Software Detailed Design Part I)
หมายเลขอ้างอิง PP-PLPH-SPP1
ชื่อกิจกรรม การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงแรก (Software Detailed Desing Part I)
วัตถุประสงค์ 1. เพื่อกาหนดขอบเขตของการออกแบบรายละเอียดซอฟต์แวร์
2. กาหนดผลลัพธ์ของการออกแบบรายละเอียดซอฟต์แวร์ ของการพัฒนาซอฟต์แวร์ และการ
ส่งมอบงาน
3. การสร้างกาหนดเวลาของลาดับงานในการออกแบบรายละเอียดซอฟต์แวร์ ประกอบไปด้วย
เงื่อนไขต่างๆที่จะทาให้ถึงเป้าหมาย และความต้องการทรัพยากรที่จะทาให้การออกแบบ
รายละเอียดซอฟต์แวร์ประสบความสาเร็จ
ผลลัพธ์ ผลของความสาเร็จที่จะนาไปใช้ของกระบวนการการวางแผนโครงการ
a) ได้รับข้อมูล Sprint backlog
b) มีการคาดการทรัพยากรที่ใช้สาหรับพัฒนาตามรายการ Sprint backlog
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
PO เจ้าของผลิตภัณฑ์ วางแผนและจัดการโครงการในด้านต่างๆ
DEV ทีมพัฒนา ทาการวิเคราะห์ และออกแบบรายละเอียดซอฟต์แวร์
TW นักเขียนเอกสาร
เชิงเทคนิค
บันทึกการออกแบบและข้อมูลที่เกิดขึ้น
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
PPD ข้อมูลคุณลักษณะกระบวนการ
(Process Performance Data)
ข้อมูลภายนอก
SRS เอกสารความต้องการทางซอฟต์แวร์
(Software Requirement Specification)
ข้อมูลภายนอก
PBL รายการงานที่ต้องทาในกระบวนการ
(Product Backlog)

43. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
34
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์ (Software Detail Design
Plan)
PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง
( Software Detailed Design Planning
Part II)
SCH ตารางงาน (Schedule) PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง
( Software Detailed Design Planning
Part II)
SBL สปรินท์แบคล็อก (Sprint Backlog) PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง
( Software Detailed Design Planning
Part II)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. โครงการต้องได้รับการอนุมัติอย่างเป็นเอกสารที่ลงนามจากผู้มีอานาจขององค์กร
2. ต้องมีทรัพยากรที่จะนามาใช้ในการพัฒนาสปรินท์แบคล็อก
เงื่อนไขการจบสิ้น
(Exit criteria)
1. การกาหนดขอบเขตของสปรินท์แบคล็อกที่จะพัฒนาอย่างชัดเจน
2. แผนการดาเนินงานการออกแบบรายละเอียดซอฟต์แวร์ที่ได้ต้องไม่ขัดกับนโยบายของ
องค์กร
3. แผนการดาเนินงานการออกแบบรายละเอียดซอฟต์แวร์ต้องได้รับการอนุมัติอย่างเป็น
เอกสารที่ลงนามจากผู้มีอานาจขององค์กร
4. ได้รับการออกแบบระดับสูง (High-leveldesing) ที่ออกแบบด้วยภาษา UML ซึ่งสอดคล้อง
ตามหลักการออกแบบเชิงวัตถุที่ดี
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. พิจารณารายการของ ชิ้นงานภายในโปรดัคแบคล็อก (Productbacklog item) ภายใน
โปรดัคแบคล็อกเพื่อหารายการที่ผู้ใช้งานให้ความสนใจในช่วงการพัฒนานี้
PO
2. เรียงลาดับความสาคัญของชิ้นงานภายในโปรดัคแบคล็อกตามลาดับความสาคัญที่
ผู้ใช้งานให้ความสนใจ
PO
3. ให้รายละเอียดโดยภาพรวมของชิ้นงานภายในโปรดัคแบคล็อก PO, DEV
4. ศึกษาปัจจัยต่าง ๆ ที่จะส่งผลกระทบต่อแผนการพัฒนาการออกแบบรายละเอียด
ซอฟต์แวร์
DEV
5. ประเมินระยะเวลาในการทางานของแต่ละชิ้นงานภายในโปรดัคแบคล็อก PO, DEV

44. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
35
6. จัดทารายการชิ้นงานภายในโปรดัคแบคล็อก PO, TW
7. ออกแบบส่วนประกอบซอฟต์แวร์ระดับสูง และการเชื่อมต่อระหว่างส่วนประกอบ ตาม
รายการชิ้นงานภายในโปรคัดแบคล็อก
DEV, TW
8. จัดสรรทรัพยากร และบทบาทหน้าที่ความรับผิดชอบในการพัฒนาการออกแบบ
รายละเอียดซอฟต์แวร์
PO, DEV, TW
9. จัดทาเอกสารแผนสาหรับพัฒนา ,เอกสารระยะเวลาการพัฒนา ,เอกสารการบริหาร
ทรัพยากร และเอกสารการกาหนดบทบาทหน้าที่ความรับผิดชอบ
TW
10. ทวนสอบความถูกต้องของเอกสาร DEV, TW
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-SRS Software Requirement Specification Template
TP-TM Traceability Matrix Template
คุณภาพที่คาดหวัง
(Quality expectation)
- แผนการดาเนินงานสามารถนาไปใช้งานได้อย่างมีประสิทธิภาพ
- แผนการดาเนินงานเป็นไปตามนโยบายขององค์กร
- รายละเอียดแผนการดาเนินงานที่ได้เป็นไปตามรายการความต้องการ
การวัดผลกิจกรรม
(Process measure)
- สปรินท์แบคล็อกที่ได้รับจะต้องสามารถระบุได้ว่ามาจากรายการความต้องการใด

45. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
36
2.8.2 PP-PLPH-SPP2: การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงสอง (SoftwareDetailed Design Planning
Part II)
หมายเลขอ้างอิง PP-PLPH-SPP2
ชื่อกิจกรรม การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงสอง (Sprint Detailed Desing Planning Part II)
วัตถุประสงค์ 1. จัดทาแผนดาเนินงาน และวิธีเชื่อมต่อกันระหว่างส่วนประกอบของซอฟต์แวร์ที่เกี่ยวข้อง
ด้วยหลักการการออกแบบเชิงวัตถุระดับล่าง
2. กาหนดผู้รับผิดชอบต่อการออกแบบรายละเอียดซอฟต์แวร์
ผลลัพธ์ ผลของความสาเร็จที่จะนาไปใช้ของกระบวนการการวางแผนโครงการ
a) มีผู้รับผิดชอบการดาเนินงานของแต่ละชิ้นงานภายในสปรินท์แบคล็อก
b) จัดทา วิธีการใช้งานของผู้ใช้(User Stories) จากชิ้นงานของสปรินท์แบคล็อก
c) เอกสารการออกแบบรายละเอียดซอฟต์แวร์ที่สามารถนาไปพัฒนาต่อได้
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
DEV ทีมพัฒนา ทาการวิเคราะห์ และออกแบบรายละเอียดซอฟต์แวร์
TW นักเขียนเอกสารเชิง
เทคนิค
บันทึกการออกแบบและข้อมูลที่เกิดขึ้น
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SBL สปรินท์แบคล็อก PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก
(Software Detailed Design Part I)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์
PP-DEVP-ADJR:การจัดปรับแผนและ
รายละเอียดซอฟต์แวร์ (AdjustPlan
and Redesign)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. เริ่มต้นดาเนินการหลังจากกิจกรรม PP-PLPH-SPP1: การวางแผนออกแบบรายละเอียด
ซอฟต์แวร์ช่วงแรก (Software Detailed Design Part I) ดาเนินการแล้วเสร็จ
เงื่อนไขการจบสิ้น
(Exit criteria)
1. ได้รับ SDDP ที่สอกคล้องกับแนวทางการการออกแบบโครงสร้างเชิงวัตถุ
2. SDDP บรรจุโครงสร้างระดับสูงของรายการในสปริ้นแบคล็อกครบทุกรายการ

46. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
37
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. การระบุเป้าหมาย หรือวัตถุประสงค์ที่ชัดเจนของชิ้นงานในสปรินท์แบคล็อกส่วนของ
ภาพรวมทั้งหมดในการออกแบบรายละเอียดซอฟต์แวร์ (Software Detail Design)
DEV
2. สร้างลักษณะการใช้งานของผู้ใช้ในแต่ละรายการของชิ้นงานในสปรินท์แบคล็อก DEV
3. ออกแบบรายละเอียดซอฟต์แวร์ของชิ้นงานในสปรินท์แบคล็อกตามลักษณะการใช้งาน
ของผู้ใช้
DEV
4. ศึกษาปัจจัยต่างๆที่จะส่งผลกระทบต่อแผนการพัฒนาการออกแบบรายละเอียด
ซอฟต์แวร์ของสปรินท์แบคล็อก
DEV
5. กาหนดแผนสาหรับพัฒนาสปรินท์แบคล็อกในส่วนการออกแบบรายละเอียดซอฟต์แวร์ DEV
6. จัดสรรทรัพยากร และบทบาทหน้าที่ความรับผิดชอบในการพัฒนาการออกแบบ
รายละเอียดซอฟต์แวร์ของสปรินท์แบคล็อก
DEV
7. จัดทาเอกสารแผนสาหรับพัฒนา, เอกสารระยะเวลาการพัฒนา, เอกสารการบริหาร
ทรัพยากร และเอกสารการกาหนดบทบาทหน้าที่ความรับผิดชอบ
TW
8. ทวนสอบความถูกต้องของเอกสาร DEV
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
PR-OPS Organizational Standard Process Specification (ไม่บังคับ) Process
PO-OP Organizational Policy Policy
GL-SDDG แนวทางการออกแบบรายละเอียดซอฟต์แวร์ (Software
Detailed Design Guideline)
Guideline
คุณภาพที่คาดหวัง
(Quality expectation)
- แผนการดาเนินงานสามารถนาไปใช้งานได้อย่างมีประสิทธิภาพ
- แผนการดาเนินงานเป็นไปตามนโยบายขององค์กร
- รายละเอียดแผนการดาเนินงานที่ได้เป็นไปตามรายการความต้องการ
การวัดผลกิจกรรม
(Process measure)
- SDDP ที่ได้นั้นสอดคล้องกับแนวคิดการวิเคราะห์และพัฒนาเชิงวัตถุ
- SDDP ที่ได้รับนั้นสามารถนาไปปฏิบัติงานได้

47. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
38
2.8.3 PP-PLPH-VADP: การทบทวนและอนุมัติกระบวนการ (Verification and Approvement: Design Plan)
หมายเลขอ้างอิง PP-PLPH-VAPR
ชื่อกิจกรรม การทบทวนและอนุมัติกระบวนการ (Verification and Approvement: Design Plan)
วัตถุประสงค์ ทบทวนผลของการดาเนินงานจากกระบวนการขึ้นถึงความเหมาะสมกับแนวทางการดาเนินงาน
ขององค์กร
ผลลัพธ์ แผนการออกแบบรายละเอียดซอฟต์แวร์ที่เหมาะสม
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
ELG คณะผู้บริหาร อนุมัติกระบวนการ
SEPG กลุ่มงานวิศวกรรม
ซอฟต์แวร์
กระบวนการ
นาเสนอผลการวิเคราะห์ข้อมูลกระบวนการ
RA ผู้ดูแลคลังทรัพยากร จักเก็บข้อมูลกระบวนการที่ได้นิยามขึ้นเข้าสู่คลัง
ทรัพยากร
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์
PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง
(Software Detailed Design Planning
Part II)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์
PP-DEVP-DESS: ออกแบบ
รายละเอียดซอฟต์แวร์ (Develop
detailed design)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. ได้รับข้อมูลการดาเนินกระบวนการหลังจาก PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง (Software Detailed Design Planning Part II)
2. วิเคราะห์ข้อมูลเพื่อนาเสนอกับคณะผู้บริหารเรียบร้อยแล้ว
เงื่อนไขการจบสิ้น
(Exit criteria)
1. คณะผู้บริหารให้ความเห็น (อนุมัติหรือยกเลิก)

48. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
39
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. สรุปข้อมูลการวิเคราะห์ผลของแผนการออกแบบรายละเอียดซอฟต์แวร์ที่ได้รับ แล้วจึง
ส่งผลการวิเคราะห์ให้กับคณะผู้บริหารที่เกี่ยวข้องพร้อมคาเชิญประชุมเพื่อร่วม
ตัดสินใจ
SEPG
2. ประชุมคณะผู้บริหารเพื่อนาเสนอผลการวิเคราะห์ข้อมูลการนากระบวนการที่ได้นิยาม
ไปใช้งาน
SEPG
3. พิจารณาผลการวิเคราะห์ข้อมูลการนากระบวนการไปใช้งาน และให้ความเห็นเพื่อ
นาไปปรับแก้
ELG
4. พิจารณาการดาเนินการ
- อนุมัติการใช้งาน: ส่งแผนการออกแบบเข้าจัดเก็บข้อมูลในคลังทรัพยากร
- ไม่อนุมัติการใช้งาน: นาแผนการออกแบบรายละเอียดซอฟต์แวร์ไปนิยามใหม่อีก
ครั้ง (PP-PLPH-SPP1: การวางแผนออกแบบรายละเอียดซอฟต์แวร์ช่วงแรก
(Software Detailed Design Part I))
ELG
5. จัดเตรียมข้อมูลสาหรับแผนการออกแบบรายละเอียดซอฟต์แวร์ และนาเข้าจัดเก็บยัง
คลังทรัพยากร ตลอดจนแจ้งประกาศการปรับปรุงเวอร์ชันไปยังผู้เกี่ยวข้องในองค์กร
RA
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
PR-OPS Organizational Standard Process Specification (ไม่บังคับ) Process
PO-OP Organizational Policy Policy
GL-SDDG แนวทางการออกแบบรายละเอียดซอฟต์แวร์ (Software
Detailed Design Guideline)
Guideline
คุณภาพที่คาดหวัง
(Quality expectation)
- แผนการออกแบบรายละเอียดซอฟต์แวร์นั้นสามารถนาไปพัฒนาได้จริง
2.9 รายละเอียดกิจกรรมในขั้นตอนการติดตามและควบคุมการดาเนินงาน (Monitoring and Control)
ขั้นตอนการติดตามและควบคุมการดาเนินงานของโครงการนั้นมีความสาคัญต่อคุณภาพงานของการพัฒนาระบบ
ที่ต้องดาเนินการออกแบบรายละเอียดซอฟต์แวร์อย่างมาก โดยขั้นตอนดังกล่าวนี้จะแบ่งออกเป็น 2 ส่วนงานด้วยกันคือ
ส่วนงานประชุม Daily Scrum และส่วนงาน Refinement
รายละเอียดกิจกรรมในขั้นตอนการติดตามและควบคุมการดาเนินกงานแสดงข้อมูลดังรายละเอียดตารางด้านล่าง
ต่อไปนี้

49. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
40
2.9.1 PP-MCTR-PMCD: การติดตามและควบคุมการดาเนินงาน ระดับโครงการ (Monitoringand Control:
Overview)
หมายเลขอ้างอิง PP-MCTR-PMCD
ชื่อกิจกรรม การติดตามและควบคุมการดาเนินงาน ส่วนงาน ระดับโครงการ (Monitoringand Control:
Overview)
วัตถุประสงค์ ติดตามและดาเนินการตรวจสอบสถานะของโครงการที่ได้จัดทาขึ้น และให้ได้ผลลัพธ์ตรงตาม
แผนงานของโครงการ รวมถึงทาให้ได้ทราบถึงความก้าวหน้าของโครงการส่งผลให้ทีมงาน
พัฒนาและเจ้าของผู้บริหารสามารถจัดหาการป้องกันล่วงหน้าหรือแนวทางแก้ไข หากโครงการที่
ทาอยู่มีแนวโน้มออกจากแผนงานของโครงการที่กาหนดไว้
ผลลัพธ์ แผนการนากระบวนการไปใช้งาน ทีมงานผู้รับผิดชอบการนากระบวนการไปใช้งาน และนิยาม
กระบวนการที่ได้รับการปรับปรุง
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
SM สกรัม
มาสเตอร์
วางแผนกาหนดหัวข้อเรื่องสาหรับการประชุม Daily Scrum
ติดตามสถานะของโครงการ และจัดทาแผนงานใหม่
DEV ทีมพัฒนา เป็นผู้ดาเนินกิจกรรมหลักในการประชุมเพื่อแจ้งผลการทางาน
งานที่จะดาเนินการต่อ และปัญหาที่เกิดขึ้น
TW นักเขียน
เอกสารเชิง
เทคนิค
เป็นผู้จัดเตรียมข้อมูลที่ได้จากการประชุม เพื่อมาจัดทาเอกสารใช้
ในการทวนสอบ และติดตามผลได้
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SRS ข้อกาหนดความต้องการ Repository
UID ข้อมูลส่วนต่อประสานกับผู้ใช้ Repository
PND ข้อมูลการวางแผนการประชุม Daily
Scrum
Daily Scrum
PJP แผนงานโครงการ Repository

50. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
41
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
RDM รายงานสรุปการประชุม Daily Scrum Daily Scrum
ISL รายการปัญหาที่เกิดขึ้น PP-MCTR-PMCR: การติดตามและ
ควบคุมการดาเนินงาน ในระดับองค์กร
(Monitoring and Control:
Organizational)
ROC รายการร้องขอการเปลี่ยนแปลง
รายละเอียดของความต้องการ
PP-MCTR-PMCR: การติดตามและ
ควบคุมการดาเนินงาน ในระดับองค์กร
(Monitoring and Control:
Organizational)
PGR รายงานความก้าวหน้าของการ
ดาเนินงาน
PP-MCTR-PMCR: การติดตามและ
ควบคุมการดาเนินงาน ในระดับองค์กร
(Monitoring and Control:
Organizational)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. เป็นระยะ ๆ จนกว่าโครงการจะสิ้นสุดตามที่วางแผนไว้
2. รับข้อมูลนาเข้าจากที่จัดเก็บข้อมูลโครงการได้แก่
2.1 SRS: เอกสารรายละเอียดข้อกาหนดความต้องการ
2.2 UID: เอกสารส่วนต่อประสานกับผู้ใช้
เงื่อนไขการจบสิ้น
(Exit criteria)
1. ประเด็นปัญหาต่าง ๆ ได้รับการแก้ไขเรียบร้อยแล้ว
2. คาร้องขอแก้ไขได้รับการปฏิบัติอย่างถูกต้อง ครบถ้วน
3. จัดทาเอกสารรายงานความก้าวหน้าของการดาเนินงาน
กระบวนการทางาน

51. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
42
กิจกรรม ผู้รับผิดชอบ
1. กาหนดการวางแผนรายการที่จะประชุม Daily Scrum
1.1. กาหนดหัวข้อเรื่องในการประชุม
กาหนดรายละเอียดของงาน
SM
2. จัดการประชุม Daily Scrum เพื่อแลกเปลี่ยนการดาเนินงานในการออกแบบรายละเอียด
ของซอฟต์แวร์
2.1. ชี้แจงรายละเอียดการดาเนินงานวันก่อนหน้า
2.2. ชี้แจงรายละเอียดการดาเนินงานวันนี้
2.3. ชี้แจ้งปัญหาที่เกิดขึ้นจากการดาเนินงาน
DEV
3. จัดทารายละเอียดสถานะปัจุบันของโครงการ
3.1. กาหนดรายละเอียดของโครงการ
3.2. จัดทาลาดับความสาคัญของงาน
3.3. จัดทารายการปัญหาที่เกิดขึ้น
DEV
4. ระบุแนวทางในการดาเนินการแก้ไขที่เหมาะสมในการแก้ไขปัญหาที่เกิดขึ้นในโครงการ DEV
5. ปรับปรุงแผนงานที่เกิดขึ้นให้เหมาะสม และมอบหมายงานให้กับทีมงานพัฒนา SM
รายการที่จาเป็นต้องใช้

52. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
43
รหัส ชื่อ ประเภท
RE-RDM Report Daily Scrum Meeting Repository
TP-ISL Issue List Template
คุณภาพที่คาดหวัง
(Quality expectation)
1. รายละเอียดการเปลี่ยนแปลงความต้องการที่สามารถนาไปใช้กับโครงการได้อย่างมี
ประสิทธิภาพ
2. รายละเอียดงานที่ได้ต้องดาเนินการแก้ไข
การวัดผลกิจกรรม
(Process measure)
1. การปรับแผนงานโครงการ
2.9.2 PP-MCTR-PMCR: การติดตามและควบคุมการดาเนินงาน ในระดับองค์กร (Monitoring and Control:
Organizational)
หมายเลขอ้างอิง PP-MCTR-PMCR
ชื่อกิจกรรม การติดตามและควบคุมการดาเนินงานในระดับองค์กร(MonitoringandControl:Organizational)
วัตถุประสงค์ เพื่อติดตามและดาเนินการตรวจสอบสถานะของโครงการในส่วนงาน Refinement เพื่อให้ได้
ผลลัพธ์แนวทางในการแก้ไขปัญหาในด้านต่างๆ อาทิเช่น คน กระบวนงาน รวมถึงสามารถจัดหา
การป้องกันล่วงหน้าหรือแนวทางแก้ไข หากโครงการที่ทาอยู่มีแนวโน้มออกจากแผนงานของ
โครงการที่กาหนดไว้
ผลลัพธ์ รายละเอียดข้อมูลปัญหา และแนวทางแก้ไขที่จะเป็นประโยชน์ต่อการพัฒนาออกแบบ
รายละเอียดซอฟต์แวร์
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
SM สกรัม
มาสเตอร์
วางแผนกาหนดหัวข้อเรื่องสาหรับการประชุม Daily Scrum
ติดตามสถานะของโครงการ และจัดทาแผนงานใหม่
DEV ทีมพัฒนา เป็นผู้ดาเนินกิจกรรมหลักในการประชุมเพื่อแจ้งผลการทางาน
งานที่จะดาเนินการต่อ และปัญหาที่เกิดขึ้น
TW นักเขียน
เอกสารเชิง
เทคนิค
เป็นผู้ดาเนินการตรวจสอบรายละเอียดข้อมูลรายการปัญหาที่
เกิดขึ้น
ข้อมูลนาเข้า

53. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
44
รหัส รายการข้อมูล กิจกรรมต้นทาง
ISL รายการปัญหาที่เกิดขึ้น PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก
(Software Detailed Design Part I)
ROC รายการร้องขอการเปลี่ยนแปลง
รายละเอียดของความต้องการ
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก
(Software Detailed Design Part I)
PGR รายงานความก้าวหน้าของการ
ดาเนินงาน
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก
(Software Detailed Design Part I)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
MOM รายงานการประชุม PP-DEVP-ADJR:การจัดปรับแผนและ
รายละเอียดซอฟต์แวร์ (AdjustPlan
and Redesign)
TCR ระเบียนตามรอย
(Traceability Record)
PP-DEVP-ADJR:การจัดปรับแผนและ
รายละเอียดซอฟต์แวร์ (AdjustPlan
and Redesign)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. เข้าตรวจสอบเป็นระยะ จนกระทั่งสิ้นสุดโครงการ
2. รับข้อมูลนาเข้าจากที่จัดเก็บข้อมูลโครงการได้แก่
2.1 ISL: รายการปัญหาที่เกิดขึ้น
เงื่อนไขการจบสิ้น
(Exit criteria)
1. ประเด็นปัญหาต่าง ๆ ได้รับการแก้ไขเรียบร้อยแล้ว
2. จัดทาเอกสารระเบียนตามรอย
กระบวนการทางาน

54. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
45
กิจกรรม ผู้รับผิดชอบ
1. ระบุปัญหาที่เกิดขึ้นจากการออกแบบรายละเอียดซอฟต์แวร์ SM
2. จัดประเภทปัญหาที่เกิดขึ้น
2.1. กาหนดปัญหาด้านบุคคล
2.2. กาหนดปัญหาด้านกระบวนการ
SM
3. จัดการประชุมรวมกัน เพื่อปรึกษาและหาแนวทางแก้ไข DEV
4. ระบุแนวทางในการดาเนินการแก้ไขที่เหมาะสมในการแก้ไขปัญหาที่เกิดขึ้นในโครงการ DEV
5. จัดทาแนวทางแก้ไขปัญหาที่เกิดขึ้น เพื่อเป็นประโยชน์ในการพัฒนาโครงการ SM
6. ทาการทวนสอบปัญหาที่เกิดขึ้นกับข้อกาหนดความต้องการของระบบ PO
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-RDM Report Daily Scrum Meeting Template
TP-ISL Issue List Template

55. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
46
คุณภาพที่คาดหวัง
(Quality expectation)
1. รายละเอียดงานที่ได้ต้องดาเนินการแก้ไข พร้อมทั้งแนวทางที่ใช้ในการแก้ไขปัญหา
2. รายการทวนสอบความต้องการเพื่อให้ตรงตามข้อกาหนดความต้องการของซอฟต์แวร์
การวัดผลกิจกรรม
(Process measure)
-
2.10 รายละเอียดกิจกรรมในขั้นตอนการพัฒนา (Development phase)
การออกแบบซอฟต์แวร์นั้นจะเริ่มจากการออกแบบในระดับสูงซึ่งจะไม่มีการลงรายละเอียดไว้ก่อนล่วงหน้า
จากนั้นจะเริ่มมีการออกแบบรายละเอียดซอฟต์แวร์เฉพาะสาหรับสปิ้นนั้น ๆ เท่านั้นโดยไม่คานึงถึงฟังก์ชัน ของ สปิ้นใน
อนาคตมากนัก ดังนั้นในทุกๆรอบของสปิ้นจะมีการพิจารณาถึงการออกแบบในสปิ้นที่ผ่านมา การออกแบบในระดับสูง
และฟังก์ชั้นงาน เพื่อทาการออกแบบหรือแก้ไขการออกแบบให้เหมาะสมกับฟังก์ชันงานสาหรับสปิ้นนั้น ๆ
กิจกรรมในขั้นตอนการออกแบบรายละเอียดซอฟต์แวร์แสดงดังภาพต่อไปนี้

56. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
47
ภาพที่ 2-3 แผนภาพกิจกรรมในขั้นตอนออกแบบรายละเอียดซอฟต์แวร์ในขั้นตอนสปิ้น

57. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
กระบวนการออกแบบรายละเอียดซอฟต์แวร์ 48
2.10.1 PP-DEVP-DESS: ออกแบบรายละเอียดซอฟต์แวร์ (Develop detailed design)
หมายเลขอ้างอิง PP-DEVP-DESS
ชื่อกิจกรรม ออกแบบรายละเอียดซอฟต์แวร์ (Develop detailed design)
วัตถุประสงค์ วัตถุประสงค์ของกิจกรรมคือการออกแบบรายละเอียดซอฟต์แวร์ที่ตอบสนองต่อข้อกาหนดความ
ต้องการของซอฟต์แวร์ โดยแบบรายละเอียดซอฟแวร์ที่ได้นั้นควรประกอบด้วยหน่วยย่อยของ
ซอฟต์แวร์ และส่วนต่อประสานภายนอก ที่มีความละเอียดเพียงพอที่จะนาไปพัฒนาและสร้าง
แบบทดสอบได้
ผลลัพธ์ ผลลัพธ์ของกิจจกรรมคือแบบรายละเอียดซอฟต์แวร์ที่สอดคล้องกับข้อกาหมดความต้องการและ
สามารถตามรอยได้
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
DEV(DESS) นักอออกแบบ
ระบบ
วิเคราะห์ข้อกาหนดความต้องการและออกแบบ
รายละเอียดซอฟต์แวร์
SM สกรัมมาสเตอร์ ผู้คอยสังเกตการณ์และอานวยความสะดวกด้านต่าง ๆ
ให้กับทีมพัฒนา
TW นักเขียนเอกสาร
เชิงเทคนิค
สร้างเอกสารจัดเก็บแบบรายละเอียดซอฟต์แวร์
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SRS ข้อกาหนดความต้องการซอฟต์แวร์ Requirements Elicitation (External)
SAD สถาปัตยกรรมซอฟต์แวร์ Architectural Design (External)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
DAF โมเดลหรือแผนภาพต่าง ๆ (Design
Artifact)
PP-DEVP-DOCD: จัดทาเเอกสารของ
การปรับปรุงการออกแบบซอฟต์แวร์
(Document software design)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. รับข้อมูลนาเข้าจากที่จัดเก็บข้อมูลโครงการได้แก่
1.1. SRS:ข้อกาหนดความต้องการซอฟต์แวร์
1.2. SAD:แบบสถาปัตยกรรมซอฟต์แวร์
เงื่อนไขการจบสิ้น
(Exit criteria)
1. แบบรายละเอียดซอฟต์แวร์และรายการตามรอยถูกจัดทาขึ้น
2. จัดเก็บเอกสารแบบรายละเอียดซอฟต์แวร์ และเอกสารรายการตามรอยลงคลังข้อมูลตาม
นโยบายการบริหารจัดเก็บข้อมูล (Configuration Management Policy)

58. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
49
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. ทีมงานวิเคราะห์ข้อกาหนดความต้องการและการออกแบบในระดับสูงดังต่อไปนี้
1.1. วิเคราะห์ข้อกาหนดความต้องการแบบสถาปัตยกรรม และแบบรายละเอียดซอฟต์แวร์ก่อน
หน้า เพื่อนามาใช้ในการออกแบบซอฟต์แวร์ในสปรินท์
1.2. ระบุส่วนประกอบซอฟต์แวร์ที่เกี่ยวข้องกับงานที่จะพัฒนาในสปรินท์
1.3. ระบุความคาดหวังต่อการออกแบบซอฟแวร์ของผู้มีส่วนได้ส่วนเสีย
1.4. ระบุมุมมองที่จะสามารถครอบคลุมกับความคาดหวังของผู้มีส่วนได้ส่วนเสีย
1.5. ระบุประเภทผู้ใช้งาน และสิทธิ์การเข้าใช้งานซอฟต์แวร์
1.6. กาหนดเงื่อนไขการยอมรับ
DEV(DESS)
2. ออกแบบส่วนต่อประสานกับผู้ใช้(UI) DEV(DESS)
3. ทีมงานให้รายละเอียดซอฟต์แวร์ ซึ่งประกอบไปด้วย
3.1. ระบุส่วนประกอบซอฟต์แวร์ออกเป็น
3.1.1. Subsystem
3.1.2. Component
3.1.3. Class
3.1.4. กาหนดส่วนต่อประสาน (Interface) ทั้งภายในและภายนอกองค์ประกอบซอฟต์แวร์
3.2. อธิบายรายละเอียดซอฟต์แวร์ตามมุมมองการออกแบบที่ได้กาหนดไว้
3.3. อธิบายในรายละเอียดลักษณะและการทางานของส่วนต่อประสานตามข้อกาหนดความ
ต้องการ
DEV(DESS)
3.4. ออกแบบและอธิบายโครงสร้างข้อมูล วิธีการเข้าถึงและการปรับปรับปรุงโดยแบ่งเป็น
3.4.1. ข้อมูลที่อยู่ในรูปแบบฐานข้อมูล
3.4.2. ข้อมูลที่ไม่ได้อยู่ในรูปแบบฐานข้อมูล
3.4.3. ข้อมูลที่เป็นบริการจากภายนอก
DEV(DESS)
4. นักเขียนเอกสารเชิงเทคนิคจัดทาเอกสารแบบรายละเอียดซอฟต์แวร์ TW,
DEV(DESS)
5. ตรวจสอบรายละเอียดซอฟต์แวร์
5.1. ตรวจสอบทุกองค์ประกอบของการออกแบบสามารถโยงไปถึงความต้องการ
5.2. ตรวจสอบทุกองค์ประกอบของการออกแบบสามารถโยงไปถึงความต้องการที่ไม่ใช่หน้าที่
หลัก
5.3. ตรวจสอบทุกความต้องการเป็นตัวแทนในการออกแบบซอฟต์แวร์
5.4. ตรวจสอบรายละเอียดของแต่ละองค์ประกอบสอดคล้องกับข้อ จากัด ที่กาหนดโดย
สถาปัตยกรรม
DEV(DESS)
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท

59. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
50
PL-DDP Detail Design Policy Policy
CH-DDC Detail Design Checklist Checklist
คุณภาพที่คาดหวัง
(Quality expectation)
1. องค์ประกอบของซอฟต์แวร์จะต้องมีการกาหนดรหัสอ้างอิง
2. องค์ประกอบของซอฟแวร์จะต้องมีอย่างน้อย 1 อินเตอร์เฟส
3. องค์ประกอบของซอฟต์แวร์จะต้องสามารถตรวจสอบย้อนกลับไปหาข้อกาหนดความ
ต้องการได้
4. มีระดับความสัมพันธ์ระหว่าง 2 โมดูล มีความขึ้นต่อกัน (Coupling) น้อยมีระดับระดับการ
ยึดเกาะกันของหน้าที่ในโมดูล (Cohesion) มาก
การวัดผลกิจกรรม
(Process measure)
- การออกแบบไม่ควรใช้เวลาเกินสามวัน สาหรับสปรินท์ที่มีระยะเวลา 3 สัปดาห์
คาแนะนา คาแนะนาในการออกแบบส่วนต่อประสานกับผู้ใช้:
1. ให้ผู้ใช้ควบคุมการทางานบางอย่างได้
1.1. ไม่ควรบังคับให้ผู้ใช้โต้ตอบกับระบบโดยไม่จาเป็น
1.2. อนุญาตให้ผู้ใช้โต้ตอบกับระบบได้มากกว่า 1 ทาง
1.3. อนุญาตให้ผู้ใช้สลับการทางานหรือยกเลิกบางอย่างได้
1.4. เตรียมเครื่องมือสร้างการทางานแบบอัตโนมัติให้กับผู้ใช้
1.5. ไม่ควรให้ผู้ใช้ติดต่อกับระบบปฏิบัติการด้วยการพิมพ์คาสั่งโดยตรง
2. ลดปริมาณของสิ่งที่ผู้ใช้ต้องจดจาลง
2.1. กาหนดค่าเริ่มต้นการใช้งานที่เหมาะสม
2.2. ใช้คีย์ลัด ที่สื่อความหมายและจาง่าย
2.3. แสดงสถานะการทางานของผู้ใช้ในกระบวนการต่างๆ
2.4. แสดงรายละเอียดการใช้งานพอสังเขป
3. ส่วนประสานต้องสอดคล้องกัน
4. ต้องไม่คัดกับสิ่งที่ผู้ใช้คาดหวัง คานึงถึงความพึงพอใจของผู้ใช้ที่มีต่อระบบ (user
experience)
คาแนะนาในการออกแบบ:
1. ควรเลือกวิธีการการนาเสนอมุมมองที่ครอบคลุมกับความคาดหวังของผู้เกี่ยวข้องที่ต้องนา
การออกแบบไปใช้งานต่อ
2. แสดงให้เห็นถึงรูปแบบสถาปัตยกรรมได้อย่างชัดเจน
3. มีลักษณะเป็นโมดูล
4. ออกแบบส่วนประกอบที่อิสระต่อกัน
5. ใช้ระเบียบวิธีการเดียวกันทุกขั้นตอน
6. สื่อความหมายชัดเจน มีมาตรฐาน
7. ควรมีโครงสร้างที่ดี เพื่อแก้ไขง่าย ต้นทุนต่า

60. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
51
คาแนะนาในการออกแบบฐานข้อมูล:
1. รวบรวมข้อมูลที่เกี่ยวข้องกับระบบ มาสร้างในรูปแบบของ ตารางข้อมูล
2. หาความสัมพันธ์ของข้อมูลแต่ละตาราง
3. ลดความซ้าซ้อนของข้อมูล
4. สร้างคีย์หลักใหม่ แทนคีย์ร่วม
5. แปลงชื่อคอลัมน์ของตารางเป็นสดมภ์ในฐานข้อมูล
6. แปลงชื่อตารางเป็น ชื่อตารางในฐานข้อมูล
คาแนะนาในการออกแบบซอฟต์แวร์:
1. เนื้อหาในส่วนนี้ กรุณาศึกษาเพิ่มเติมได้จาก เล่มคู่มือ ภาคผนวก ก
2.10.2 PP-DEVP-DOCD: จัดทาเเอกสารของการปรับปรุงการออกแบบซอฟต์แวร์ (Document software design)
หมายเลขอ้างอิง PP-DEVP-DOCD
ชื่อกิจกรรม จัดทาเเอกสารของการปรับปรุงการออกแบบซอฟต์แวร์ (Document software design)
วัตถุประสงค์ การจัดทาเอกสารรายละเอียดซอฟต์แวร์ ที่เป็นไปตาม IEEE 1016
ผลลัพธ์ แบบรายละเอียดซอฟต์แวร์ที่สอดคล้องกับข้อกาหมดความต้องการและสามารถตามรอยได้
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
DEV (DESS) นักอออกแบบระบบ ยืนยันเอกสารการออกแบบรายละเอียดซอฟต์แวร์
TW นักเขียนเอกสารเชิง
เทคนิค
สร้างเอกสารจัดเก็บแบบรายละเอียดซอฟต์แวร์
และเอกสารรายการตามรอย
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
DAF โมเดลหรือแผนภาพต่าง ๆ (Design
Artifact)
PP-DEVP-DESS: ออกแบบ
รายละเอียดซอฟต์แวร์ (Develop
detailed design)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง

61. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
52
SDD เอกสารรายละเอียดซอฟต์แวร์
(Software Design) PP-DEVP-UTCP: จัดทาหรือปรับปรุง
กรณีทดสอบ และการทดสอบ (Test
Cases and Test Procedures)
PP-DEVP-UTCR: ปรับปรุง
ระเบียนตามรอย (Update the
Traceability Record)
PP-DEVP-REVE: ทวนสอบและ
ประเมินแบบรายละเอียดซอฟต์แวร์
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. จัดเตรียมข้อมูล โมเดลหรือแผนภาพต่าง ๆ (Design Artifact) ที่ได้รับการออกแบบจากทีม
พัฒนา
เงื่อนไขการจบสิ้น
(Exit criteria)
1. เอกสารการออกแบบรายละเอียดซอฟต์แวร์ได้รับการอนุมัติจากทีมงาน (นักออกกแบบ
ซอฟต์แวร์)
2. จัดเก็บเอกสารการออกแบบรายละเอียดซอฟต์แวร์ไว้บนที่จัดเก็บข้อมูลโครงการ
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. จัดทาหรือปรับปรุงเอกสารการออกแบบรายละเอียดซอฟต์แวร์ TW
2. ทีมงานยืนยันอนุมัติเอกสารการออกแบบรายละเอียดซอฟต์แวร์ DEV(DESS)
3. จัดเก็บเอกสารการออกแบบรายละเอียดซอฟต์แวร์ไว้บนที่จัดเก็บข้อมูลโครงการ TW
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-SDD แม่แบบเอกสารรายละเอียดซอฟต์แวร์ Template
คุณภาพที่คาดหวัง
(Quality expectation)
1. แบบรายละเอียดซอฟต์แวร์ที่สอดคล้องกับข้อกาหมดความต้องการและสามารถตามรอย
ได้
2. แบบรายละเอียดซอฟต์แวร์ที่เป็นไปตามมาตรฐาน IEEE 1016
2.10.3 PP-DEVP-UTCP: จัดทาหรือปรับปรุงกรณีทดสอบ และการทดสอบ (Test Cases and Test Procedures)
หมายเลขอ้างอิง PP-DEVP-UTCP
ชื่อกิจกรรม จัดทาหรือปรับปรุงกรณีทดสอบ และการทดสอบ (Test Cases and Test Procedures) สาหรับการ
ทดสอบเพื่อผนวกเข้าด้วยกัน (Integration Testing) ที่สัมพันธ์กับข้อกาหนดความต้องการและ
การออกแบบ

62. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
53
วัตถุประสงค์ วัตถุประสงค์ของกิจกรรมนี้คือการสร้างหรือปรับปรุงกรณีทดสอบและกระบวนการทดสอบของ
การทดสอบการรวมซอฟต์แวร์ ตามข้อกาหนดความต้องการและแบบรายละเอียดซอฟต์แวร์
ผลลัพธ์ เอกสารรายงานกรณีทดสอบและกระบวนการทดสอบของการรวมซอฟต์แวร์
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
DEV
(DESS)
ทีมพัฒนา
(นักออกแบบ)
จัดทา หรือปรับปรุงกรณีทดสอบ และกระบวนการทดสอบ
ของการรวมซอฟต์แวร์
TW นักเขียนเอกสาร
เชิงเทคนิค
จัดทาเอกสารกรณีทดสอบ และเอกสารกระบวนการทดสอบ
ของการรวมซอฟต์แวร์ฉบับทางการ
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SRS ข้อกาหนดความต้องการซอฟต์แวร์ Requirements Elicitation (External)
SDD แบบรายละเอียดซอฟต์แวร์ PP-DEVP-DOCD: จัดทาเเอกสารของ
การปรับปรุงการออกแบบซอฟต์แวร์
(Document software design)
TC&TP เอกสารกรณีทดสอบและกระบวนการ
ทดสอบ (ถ้ามี)
PP-DEVP-DESS: ออกแบบ
รายละเอียดซอฟต์แวร์ (Develop
detailed design)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
TC&TP เอกสารกรณีทดสอบและเอกสาร
กระบวนการทดสอบ ที่ได้รับการแก้ไข
แล้ว
PP-DEVP-VFTC: ตรวจสอบความถูก
ต้องของกรณีทดสอบ และแผนการ
ทดสอบ (Verification and approval of
the test cases and test procedures)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. จัดเตรียมข้อมูลที่จาเป็นดังนี้
1.1. ข้อกาหนดความต้องการ
1.2. แบบของซอฟต์แวร์
1.3. กรณีทดสอบและขั้นตอนการทดสอบ
เงื่อนไขการจบสิ้น
(Exit criteria)
1. ทาการสร้างหรือปรับปรุงกรณีทดสอบและขั้นตอนการทดสอบตามข้อกาหนดความต้องการ
และแบบรายละเอียดซอฟต์แวร์
2. กรณีทดสอบและขั้นตอนการทดสอบพร้อมสาหรับขั้นตอนการตรวจสอบ
กระบวนการทางาน

63. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
54
กิจกรรม ผู้รับผิดชอบ
1. จัดทาหรือปรับปรุงกรณีทดสอบ และการทดสอบ (Test Cases and Test Procedures) สาหรับ
การทดสอบเพื่อผนวกเข้าด้วยกันที่สัมพันธ์กับข้อกาหนดความต้องการและการออกแบบ
1.1. กรณีที่มีข้อมูลการทดสอบไม่มากให้รวมไว้ในเอกสารการทดสอบนั้น
1.2. แต่หากข้อมูลการทดสอบไม่สามารถแสดงในเอกสารได้(เช่นฐานข้อมูลขนาดใหญ่) ก็
ควรจะมีการระบุและอ้างวิธีการเข้าถึงข้อมูลเหล่านั้น
2. กาหนดขั้นตอนการทดสอบและผู้รับผิดชอบ
DEV (DESS)
3. รวบรวมข้อมูลและจัดทาเป็นเอกสารอย่างเป็นทางการตามแม่แบบที่กาหนดไว้ TW
4. ตรวจสอบเอกสารที่นักเขียนเอกสารเชิงเทคนิคจัดทาอีกครั้งเพื่อเตรียมพร้อมสาหรับขั้นตอน
การทวนสอบ
DEV (DESS)
รายการที่จาเป็นต้อง
ใช้ รหัส ชื่อ ประเภท
TP-TCP แบบบันทึกกรณีทดสอบและขั้นตอนการ
ทดสอบ
Template
คุณภาพที่คาดหวัง
(Quality
expectation)
- มีการสร้างกรณีทดสอบที่คลอบคลุมอย่างน้อย 90%
การวัดผลกิจกรรม
(Process measure)
-

64. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
55
2.10.4 PP-DEVP-VFTC: ตรวจสอบความถูกต้องของกรณีทดสอบ และแผนการทดสอบ (Verification and approval
of the test cases and test procedures)
หมายเลขอ้างอิง PP-DEVP-VFTC
ชื่อกิจกรรม การตรวจสอบความถูกต้องของกรณีทดสอบ และแผนการทดสอบ (Verification and
approval of the test cases and test procedures)
วัตถุประสงค์ เพื่อตรวจสอบความสอดคล้องระหว่างข้อกาหนดความต้องการ การออกแบบระดับสูง และ
การออกแบบรายละเอียดซอฟต์แวร์ กับกรณีทดสอบที่สร้างขึ้นหรือที่ไม่การแก้ไขในระหว่าง
การออกแบบ รายการทั้งหมดจะต้องได้รับการยืนยันจาก นักออกวิเคราะห์และออกแบบ
ระบบ
ผลลัพธ์ กรณีที่สอบและวิธีการดาเนินการที่ได้ถูกต้องสอดคล้องกับข้อกาหนดความต้องการและการ
ออกแบบ
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
DEV
(DESS)
ทีมพัฒนา (นัก
ออกแบบ)
วิเคราะห์ข้อกาหนดความต้องการและออกแบบ
รายละเอียดซอฟต์แวร์ และมีอานาจที่จะอนุมัติการ
ตรวจสอบในขั้นตอนนี้
SM สกรัมมาสเตอร์ ผู้คอยสังเกตการณ์และอานวยความสะดวกด้านต่าง
ๆ ให้กับทีมพัฒนา
TW นักเขียนเอกสาร
เชิงเทคนิค
สร้างเอกสารจัดเก็บแบบรายละเอียดซอฟต์แวร์และ
เอกสารรายการตามรอย
SQA ผู้ตรวจสอบ
คุณภาพ
ทาหน้าที่ควบคุมคุณภาพของทั้งกระบวนการทางาน
และผลิตภันฑ์ให้เป็นไปตามแผนและข้อกาหนด
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SRS ข้อกาหนดความต้องการซอฟต์แวร์ Requirements Elicitation (External)
SDD เอกสารแบบรายละเอียดซอฟต์แวร์ PP-DEVP-DOCD: จัดทาเเอกสา
รของการปรับปรุงการออกแบบ
ซอฟต์แวร์ (Document software
design)
TC&TP เอกสารกรณีทดสอบและเอกสาร
กระบวนการทดสอบ
PP-DEVP-UTCP: จัดทาหรือ
ปรับปรุงกรณีทดสอบ และการ
ทดสอบ (Test Cases and Test
Procedures)

65. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
56
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
VRSR ผลการตรวจประเมิน PP-DEVP-REPO: การจัดเก็บผลลัพธ์
ของกระบวนการในที่เก็บข้อมูลของ
โครงการ (Project Repository)
PP-DEVP-REVE: ทวนสอบและ
ประเมินแบบรายละเอียดซอฟต์แวร์
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
- เอกสารกรณีทดสอบและขั้นตอนการทดสอบมีการปรับปรุงแก้ไข และผ่านการทวน
สอบจากทีมพัฒนาแล้ว และมีความสมบูรณ์พร้อมสาหรับการตรวจสอบ
- รับเอกสารที่ต้องตรวจสอบ และ แบบบันทึกจาก Repository
เงื่อนไขการจบสิ้น
(Exit criteria)
- กรณีทดสอบและขั้นตอนการทดสอบได้รับการยืนยันจากทีมพัฒนา และนักวิเคราะห์
ระบบ
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. ตรวจสอบบันทึกตรวจสอบย้อนกลับ (Traceability Record):
1.1. มีข้อมูลและองค์ประกอบของการออกแบบซอฟแวร์อยู่หรือไม่
1.2. มีข้อมูลความสัมพันธ์ระหว่างความต้องการและองค์ประกอบของการออกแบบ
ซอฟแวร์อยู่หรือไม่
DEV
2. ทีมงานโครงการ ดาเนินการตัดสินใจว่าจะดาเนินการตรวจสอบต่อไปหรือไม่
2.1. หากบันทึกตรวจสอบย้อนกลับไม่สมบูรณ์
2.1.1. นักเขียนเอกสารเชิงเทคนิคจัดทาเอกสารบันทึกผลการตรวจสอบความ
สอดคล้อง
2.1.2. ทีมงานโครงการเริ่มต้นการปรับปรุงบันทึกตรวจสอบย้อนกลับ
DEV, TW
3. จัดทาหรือปรับปรุงใบตรวจสอบ QA
4. ทีมงานโครงการดาเนินการตรวจสอบการกรณีทดสอบ (โดยอาศัยบันทึกตรวจสอบ
ย้อนกลับ) :
4.1. มีความสอดคล้องกับความต้องการที่ระบุไว้
4.2. มีความสอดคล้องกับซอฟต์แวร์ตามที่ได้ออกแบบได้ไว้
4.3. เป็นไปตามข้อกาหนดในแบบประเมินและใบตรวจสอบ
4.4. บันทึกคาแนะนาและแนวทางการแก้ไขในแบบประเมิน
DEV,QA
5. นักเขียนเอกสารเชิงเทคนิคจัดทาเอกสารบันทึกผลการตรวจสอบความสอดคล้อง และ
ดาเนินการแก้ไขปรับปรุงเอกสารจนกว่าเอกสารจะได้รับการยืนยันจากทีมงานโครงการ
DEV, TW

66. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
57
6. ทวนสอบและยืนยันความถูกต้องของผลการตรวจสอบความสอดคล้องกับเจ้าของผลิตภัณฑ์
ยืนยันอีกครั้งอีกครั้ง
DEV, PO
7. หากจาเป็นที่ต้องเปลี่ยนแปลงเอกสารการออกแบบที่สาคัญ ให้นักเขียนเอกสารเชิงเทคนิค
เริ่มต้นการร้องขอการเปลี่ยนแปลง ไปยังทีมพัฒนาซอฟต์แวร์เพื่อเสนอให้เจ้าของผลิตภัณฑ์
ยืนยันอีกครั้ง
TW, PO, SM,
DEV
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
CH-TCH รายการตรวจสอบความสอดคล้อง Checklisk
TP-TCR บันทึกตรวจสอบย้อนกลับ Template
คุณภาพที่คาดหวัง
(Quality expectation)
1. กรณีทดสอบสอดคล้องและครอบคลุมกับข้อกาหนดความต้องการและการ
ออกแบบ
2.10.5 PP-DEVP-UTCR: ปรับปรุงระเบียนตามรอย (Update the Traceability Record)
หมายเลขอ้างอิง PP-DEVP-UTCR
ชื่อกิจกรรม ปรับปรุงระเบียนตามรอย (Update the Traceability Record)
วัตถุประสงค์ การสร้างระเบียนตามร้อยเพื่อใช้ในการตรวจสอบย้อนกลับไปมาระหว่างการออกแบบ กรณี
ทดสอบ และข้อกาหนดได้
ผลลัพธ์ ระเบียนตามรอยที่สามารถใช้ตามรอยระหว่างการออกแบบ กรณีทดสอบ และข้อกาหนดได้
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
DEV ทีมพัฒนาซอฟต์แวร์ ทาการตรวจสอบความเป็นไปได้ของแบบรายละเอียด
ซอฟต์แวร์
SQA ทีมควบคุมคุณภาพ ทาการตรวจสอบเอกสารว่าถูกต้อง ครบถ้วนหรือไม่
SPM ผู้จัดการซอฟต์แวร์ รับรายงานการตรวจสอบแบบรายละเอียดซอฟต์แวร์
และตัดสินใจว่าอนุมัติหรือไม่
TW นักเขียนเอกสารเชิง
เทคนิค
จัดทาเอกสารร้องขอการเปลี่ยนแปลง
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SDD แบบรายละเอียดซอฟต์แวร์ ออกแบบรายละเอียดซอฟต์แวร์
TCR เอกสารรายการตามรอยเดิม (ถ้ามี) ออกแบบรายละเอียดซอฟต์แวร์
ASD แบบสถาปัตยกรรม

67. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
58
TC&TP กรณีทดสอบและขั้นตอนการทดา
อบ
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
TCR เอกสารรายการตามรอยที่สร้างขึ้นหรือ
ได้รับการปรับปรุง
-
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. มอบหมายงานให้กับทีมงาน สมาชิกที่เกี่ยวข้องกับบทบาท ตามแผนงานของโครงการ
2. รับข้อกาหนดความต้องการจากคลังข้อมูล
3. รับรายละเอียดการออกแบบจากคลังข้อมูล
4. รับบันทึกติดการตามรอยจากคลังข้อมูล
เงื่อนไขการจบสิ้น
(Exit criteria)
1. จาดทารายงานการตรวจสอบแบบรายละเอียดซอฟต์แวร์เรียบร้อย
2. จักทาเอกสารร้องขอการปรับปรุงเรียบร้อย (หากพบข้อผิดพลาด)
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. ทีมพัฒนาซอฟต์แวร์ปรับปรุงระเบียนตามรอย ดังนี้
1.1. ตามกรณีทดสอบและขั้นตอนทดสอบใหม่
1.2. ตามรอยตามแบบรายละเอียดซอฟต์แวร์ที่พัฒนาขึ้น
DEV
2. ทีมพัฒนาซอฟต์แวร์ตรวจสอบระเบียนตามรอยให้มั่นใจว่า
2.1. การออกแบบและกรณีทดสอบนั้นเชื่อมโยงไปถึงข้อกาหนดความต้องการ
2.2. ทุก ๆ ข้อกาหนดความต้องการทั้งหมดเชื่อมโยงถึงการออกแบบ
2.3. ทุก ๆ ข้อกาหนดความต้องการทั้งหมดเชื่อมโยงถึงกรณีทดสอบ
DEV
3. ระบุให้ชัดเจนว่าระเบียนตามร้อยนี้เชื่อมโยงกับแบบซอฟแวร์และข้อกาหนดใด DEV
4. จัดทาเป็นเอกสารที่เรียบร้อยสมบูรณ์ และส่งเข้าไปจัดเก็บไว้ในคลังข้อมูลของโครงการ TW
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-VRP Detail Design Verification Report Template
TP-CR Change Request Document Template
2.10.6 PP-DEVP-REVE: ทวนสอบและประเมินแบบรายละเอียดซอฟต์แวร์ (Review and Evaluationfor Software
Detailed Desing)
หมายเลขอ้างอิง PP-SDD-REVE

68. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
59
ชื่อกิจกรรม ทวนสอบและประเมินแบบรายละเอียดซอฟต์แวร์ (Review and Evaluation for Software
Detailed Design)
วัตถุประสงค์ ตรวจสอบความสอดคล้องของการออกแบบรายละเอียดซอฟต์แวร์ กับการวิเคราะห์ความ
ต้องการของซอฟต์แวร์ (Software Requirements Analysis) และการออกแบบสถาปัตยกรรม
ซอฟต์แวร์ (Software Architectural Design) โดยการใช้ข้อมูลจากระเบียนตามรอย เป็นหลัก
ผลลัพธ์ ได้รายละเอียดซอฟต์แวร์ที่ถูกต้องตรงกัน และตรวจสอบย้อนกลับไปยัง รายการความต้องการ
และสถาปัตยกรรมที่ออกแบบไว้ได้และมีความเป็นไปได้ในการพัฒนา การทดสอบ และการ
ดูแลรักษา รวมไปถึงเป็นไปตามหลักการออกที่ดี
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
PO เจ้าของผลิตภัณฑ์ ผู้อนุมัติเอกสารการออกแบบรายละเอียดซอฟต์แวร์
SM สกรัมมาสเตอร์ ผู้คอยสังเกตุการณ์อานวยความสะดวกด้านต่าง ๆ
ให้กับทีม
TW นักเขียนเอกสารเชิง
เทคนิค
จัดทาเอกสารการออกแบบ เอกสารการทวนสอบ และ
บันทึกรายงานการประชุมของโครงการในวาระต่าง ๆ
DEV ทีมพัฒนาซอฟต์แวร์ วิเคราะห์การออกแบบ ตรวจสอบความสอดคล้อง และ
ผู้ทวนสอบ
SQA ผู้ตรวจสอบคุณภาพ ทาการตรวจสอบเอกสารว่าถูกต้อง ครบถ้วนหรือไม่
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
TCB Traceability Record PP-DEVP-UTCR: ปรับปรุงระเบียน
ตามรอย (Update the Traceability
Record)
RSR Requirement specifications Requirements Elicitation (External)
SDD Detailed Design (Diagrams) PP-DEVP-UTCP: จัดทาหรือปรับปรุง
กรณีทดสอบ และการทดสอบ (Test
Cases and Test Procedures)
ARD Architectural Design (Diagram) Architectural Design (External)

69. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
60
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
TCB Traceability Record ที่ปรับปรุง
(ถ้าจาป็น)
PP-DEVP-REPO: การจัดเก็บผลลัพธ์
ของกระบวนการในที่เก็บข้อมูลของ
โครงการ (Project Repository)
VLD Validation Results - Project Management (External)
CHA Change Request (ถ้ามี) - Project Management (External)
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. เตรียมข้อมูลที่จะดาเนินการตรวจสอบได้แก่
1.1. Requirement Specifications
1.2. Detailed Design
1.3. Architectural Design
1.4. Traceability Record
เงื่อนไขการจบสิ้น
(Exit criteria)
1. ความสอดคล้องของการออกแบบได้รับการยืนยันจากทีมพัฒนาซอฟต์แวร์ และได้รับการ
ยืนยันจากเจ้าของผลิตภัณฑ์
2. จัดเก็บข้อมูลผลลัพธ์ คือ ข้อมูลการตามรอย, ผลการตรวจสอบ และ คาร้องขอเปลี่ยนแปลง
ใน คลังข้อมูล และดาเนินการตาม นโยบายการบริหารจัดการข้อมูล
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. ทีมควบคุมคุณภาพดาเนินการตรวจสอบว่าบันทึกตรวจสอบย้อนกลับ:
1.1. มีข้อมูลและองค์ประกอบของการออกแบบซอฟแวร์อยู่หรือไม่
1.2. มีข้อมูลความสัมพันธ์ระหว่างความต้องการและองค์ประกอบของการออกแบบซอฟแวร์
อยู่หรือไม่
SQA ,DEV,SM,
PO
2. ตัดสินใจว่าจะดาเนินการตรวจสอบต่อไปหรือไม่ SQA
3. ทีมควบคุมคุณภาพดาเนินการตรวจสอบการออกแบบรายละเอียดซอฟต์แวร์
(โดยอาศัยบันทึกตรวจสอบย้อนกลับ) :
3.1. มีความสอดคล้องกับความต้องการที่ระบุไว้
3.2. มีความสอดคล้องกับการออกแบบสถาปัตยกรรมที่ระบุไว้
3.3. มีความสอดคล้องภายในระหว่างส่วนประกอบของซอฟต์แวร์ตามที่ได้ระบุไว้
SQA,DEV,SM,
PO
4. ทีมควบคุมคุณภาพตรวจสอบความเป็นไปได้ของแบบรายละเอียดซอฟต์แวร์ตามใบตรวจสอบ
โดยมีทีมงานโครงการเข้าร่วมด้วย
4.1. ตรวจสอบความเป็นไปได้ในการพัฒนา
4.2. ตรวจสอบความเป็นไปได้ในการดูแลรักษา
4.3. ตรวจสอบความเป็นได้ไปในการทดสอบ
4.4. บันทึกผลการตรวจสอบและแนวทางการปรับปรุงในแบบประเมิน
SQA ,DEV,SM,
PO
5. ทวนสอบและยืนยันความถูกต้องของผลการตรวจสอบกับเจ้าของผลิตภัณฑ์ยืนยันอีกครั้งอีกครั้ง DEV, PO

70. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
61
6. หากจาเป็นที่ต้องเปลี่ยนแปลงเอกสารการออกแบบที่สาคัญ ให้ทีมควบคุมคุณภาพเริ่มต้นการ
ร้องขอการเปลี่ยนแปลง ไปยังทีมพัฒนาซอฟต์แวร์เพื่อเสนอให้เจ้าของผลิตภัณฑ์ยืนยันอีกครั้ง
SQA
7. ทาการอนุมัติแบบรายละเอียดซอฟต์แวร์ PO
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-TCM Traceability Matrix Template
TP-VRP Validation Results Report Template Template
TP-CHR Change Request Template
RE-PRP Project Repository Repository
PO-CMP Configuration Management Policy Policy
คุณภาพที่คาดหวัง
(Quality expectation)
-
การวัดผลกิจกรรม
(Process measure)
- กิจกรรมควรใช้เวลา ไม่เกิน 90 นาที
2.10.7 PP-DEVP-REPO: การจัดเก็บผลลัพธ์ของกระบวนการในที่เก็บข้อมูลของโครงการ (Project Repository)
หมายเลขอ้างอิง PP-DEVP-REPO
ชื่อกิจกรรม การจัดเก็บผลลัพธ์ของกระบวนการในที่เก็บข้อมูลของโครงการ (Project Repository)
วัตถุประสงค์ 1) เพื่อนาผลลัพธ์ที่ได้จากกระบวนการออกแบบรายละเอียดซอฟต์แวร์ ไปสร้างเป็น
บรรทัดฐาน เก็บไว้ที่คลังข้อมูลโครงการโดยประกอบด้วย
a. ข้อมูลการออกแบบซอฟต์แวร์
b. ข้อมูลการตามรอย
c. กรณีทดสอบ
d. กระบวนงานการทดสอบ
2) จัดการปรับเปลี่ยนของผลลัพธ์เพื่อให้สามารถบารุงรักษาความถูกต้องของผลลัพธ์
เหล่านั้นได้และ
3) เพื่อให้ผู้มีส่วนได้ส่วนเสียสามารถเข้าถึงการออกแบบรายละเอียดซอฟต์แวร์และ
เอกสารที่เกี่ยวข้องได้ตามสิทธิ์ที่ได้รับ
ผลลัพธ์ ได้บรรทัดฐานของการออกแบบรายละเอียดซอฟต์แวร์ และเอกสารที่เกี่ยวข้องและมีการการ
จัดการและความคุมการเปลี่ยนแปลงต่าง ๆ ตามนโยบายที่ได้กาหนดไว้

71. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
62
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
RA Repository
Administrator
ผู้ที่มีหน้าที่ในการจัดการคลังข้อมูลของโครงการและ
ควบคุมการเปลี่ยนแปลงโดยจะดาเนินการตามคาร้อง
ขอให้มีการเปลี่ยนแปลง
SM สกรัม มาสเตอร์
(Scrum Master)
ผู้คอยสังเกตุการณ์อานวยความสะดวกด้านต่าง ๆ
ให้กับทีม
TW นักเขียนเอกสารเชิง
เทคนิค
ทาหน้าที่สนับสนุนทีมพัฒนา เพื่ออานวยความสะดวก
ในการนาเอกสารและผลลัพธ์จากกระบวนการ
ออกแบบซอฟต์แวร์ จัดเก็บในคลังข้อมูลของโครงการ
DEV ทีมพัฒนาซอฟต์แวร์
(Development)
เป็นผู้ดาเนินการตรวจสอบและยืนยันรายการผลลัพธ์
ทั้งหมดที่จะถูกจัดเก็บไว้ในคลังข้อมูลของโครงการ
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
TCR ข้อมูลตามรอยที่ปรับปรุง
(ถ้าจาป็น)
PP-DEVP-UTCR: ปรับปรุงระเบียน
ตามรอย (Update the Traceability
Record)
VLD ผลการทวนสอบ
PP-DEVP-REVE: ทวนสอบและ
ประเมินแบบรายละเอียดซอฟต์แวร์
TC&TP กรณีทดสอบและขั้นตอนการทดสอบ PP-DEVP-UTCP: จัดทาหรือปรับปรุง
กรณีทดสอบ และการทดสอบ (Test
Cases and Test Procedures)
SSD แบบรายละเอียดซอฟต์แวร์ PP-DEVP-DOCD: จัดทาเเอกสารของ
การปรับปรุงการออกแบบซอฟต์แวร์
(Document software design)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
ORP รายงานการดาเนินงาน PP-MCTR-PMCR: การติดตามและ
ควบคุมการดาเนินงาน ในระดับองค์กร
(Monitoring and Control:
Organizational)

72. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
63
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. ผลลัพธ์จากการออกแบบที่ต้องการจัดเก็บได้รับการตรวจประเมินและได้รับการอนุมัติให้
สามารถนาไปจัดทาเป็นได้
เงื่อนไขการจบสิ้น
(Exit criteria)
1. ผลลัพธ์ที่ได้จากกระบวนการออกแบบรายละเอียดซอฟต์แวร์ ไปสร้างเป็นบรรทัดฐานเก็บ
ไว้ที่คลังข้อมูลโครงการ
2. ได้รับการอนุมัติจากผู้ดูแลคลังทรัพยากร
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. ตรวจสอบรายการทั้งหมดที่จะถูกจัดเก็บ DEV
2. ทบทวนนโยบายการบริหารจัดการเปลี่ยนแปลงของข้อมูล DEV
3. กาหนดรายละเอียดของรายการทั้งหมดดังนี้
3.1. กาหนดรหัสหรือหมายเลขที่เป็นเป็นเอกลักษณ์ให้แต่ละรายการข้อมูล
3.2. ให้รายละเอียดคาอธิบายของแต่ละรายการ
3.3. กาหนดประวัติการแก้ไข: ทุกครั้งที่มีการแก้ไขไว้ดังนี้
3.3.1. Owner: ใครเป็นเจ้าของแฟ้มข้อมูล (ในกรณีที่ถ้ามีการแก้ไข ต้องแจ้งเตือนผู้ใช้งาน)
3.3.2. Current version: หมายเลขรุ่นปัจจุบันอะไรของข้อมูล
3.3.3. Last modified: วันที่แก้ครั้งสุดท้าย
3.3.4. Last modified by: ผู้แก้ไขคนล่าสุด
3.3.5. What’s modified: รายการการแก้ไขข้อมูล
3.3.6. Comment: สรุปสิ่งที่ปรับเปลี่ยน และบันทึกข้อมูลการปรับแก้
DEV
4. นาผลลัพธ์ที่ได้จากกระบวนการออกแบบรายละเอียดซอฟต์แวร์ ไป เก็บไว้ที่คลังข้อมูลโครงการ
โดยใช้Configuration Management Tool ประกอบด้วย
4.1. ข้อมูลการออกแบบซอฟต์แวร์
4.2. ข้อมูลการตามรอย
4.3. กรณีทดสอบ
4.4. กระบวนงานการทดสอบ
TW
5. ตรวจสอบคาขอและอนุมัติคาขอเพื่อให้ข้อมูลทั้งหมดถูกจัดเก็บในที่จัดเก็บข้อมูลโครงการ RA
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
CMT Configuration Management Tool Tool

73. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
64
2.10.8 PP-DEVP-ADJR: การจัดปรับแผนและรายละเอียดซอฟต์แวร์ (Adjust Plan and Redesign)
หมายเลขอ้างอิง PP-DEVP-ADJR
ชื่อกิจกรรม การปรับแผนสาหรับและรายละเอียดซอฟต์แวร์ (Adjust Plan and Redesign)
วัตถุประสงค์ เพื่อให้แผนการและรายละเอียดซอฟต์แวร์มีความเหมาะสมกับการดาเนินงานในกระบวนการ
และองค์การ และสามารถทางานร่วมกันได้อย่างมีประสิทธิภาพมากยิ่งขึ้น
ผลลัพธ์ แผนการดาเนินงานผลของความสาเร็จที่จะนาไปใช้ของกระบวนการการวางแผนโครงการ
- แผนการและรายละเอียดซอฟต์แวร์มีความเหมาะสมในการปฏิบัติงานมากยิ่งขึ้น
- แผนการดาเนินงานและรายละเอียดซอฟต์แวร์มีความสอดคล้องกันมากยิ่งขึ้น
- สามารถกาหนดผู้มีส่วนได้ส่วนเสียกับสปรินท์แบคล็อกได้อย่างชัดเจนตามการ
เปลี่ยนแปลงรายการความต้องการ
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
DEV ทีมพัฒนา ทาการวิเคราะห์ และออกแบบรายละเอียดซอฟต์แวร์
TW นักเขียนเอกสารเชิง
เทคนิค
ปรับแก้ไขเอกสารแผนการออกแบบรายละเอียด
ซอฟต์แวร์และสร้างเอกสารคาอธิบายแผนการออกแบบ
รายละเอียดซอฟต์แวร์
PPQA หน่วยงานประกัน
คุณภาพผลิตภัณฑ์
และกระบวนการ
ติดตามการปรับปรุงที่เกิดขึ้นเพื่อไม่ให้ขัดแย้งกับ
กระบวนการหรือแนวทางการปฏิบัติงานขององค์กร
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
SBL สปรินท์แบคล็อก PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก
(Software Detailed Design Part I)
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
SDDP แผนการออกแบบรายละเอียด
ซอฟต์แวร์ (Software Detail Design
Plan) ที่มีการปรับปรุง
PP-DEVP-DESS: ออกแบบ
รายละเอียดซอฟต์แวร์ (Develop
detailed design)
SDD ค า อ ธิ บ า ย แ ผ น ก า ร อ อ ก แ บ บ
รายละเอียดซอฟต์แวร์ (Software
Detailed Design Description)
PP-DEVP-DESS: ออกแบบ
รายละเอียดซอฟต์แวร์ (Develop
detailed design)

74. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
65
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. โครงการต้องได้รับการอนุมัติอย่างเป็นเอกสารที่ลงนามจากผู้มีอานาจขององค์กร
2. ต้องมีทรัพยากรที่จะนามาใช้ในการพัฒนาสปรินท์แบคล็อก
3. ต้องมีเอกสารการขอเปลี่ยนแปลงรายการความต้องการ
เงื่อนไขการจบสิ้น
(Exit criteria)
1. แผนการดาเนินงานการออกแบบรายละเอียดซอฟต์แวร์ที่ได้ต้องมีรายละเอียดที่เป็นไปตาม
เอกสารที่ลงนามจากผู้มีอานาจขององค์กร
2. แผนการดาเนินงานการออกแบบรายละเอียดซอฟต์แวร์ที่ได้ต้องไม่ขัดกับนโยบายของ
องค์กร
3. แผนการดาเนินงานการออกแบบรายละเอียดซอฟต์แวร์ต้องได้รับการอนุมัติอย่างเป็น
เอกสารที่ลงนามจากผู้มีอานาจขององค์กร
4. ไม่พบแผนการดาเนินงานที่ขัดแย้งกันกับแนวทางการออกแบบรายละเอียดซอฟต์แวร์
กระบวนการทางาน
กิจกรรม ผู้รับผิดชอบ
1. ทบทวนแผนการออกแบบรายละเอียดซอฟต์แวร์เทียบกับแนวทางการออกแบบ
รายละเอียดซอฟต์แวร์ที่องค์กรกาหนดไว้
DEV
1.1. หากในขั้นตอนการทบทวนพบรายการข้อมูลที่ขัดแย้งกันปรับปรุงรายการนั้น
ให้สอดคล้องกับการดาเนินการ
TW
1.2. ปรับแก้ไขแผนภาพแสดงแบบจาลองการทางานให้สอดคล้องกับรายการข้อมูล
ที่มีการปรับแก้
TW
1.3. ทวนสอบความถูกต้องของการออกแบบรายละเอียดซอฟต์แวร์ของแต่ละ
รายการขั้นตอนการใช้งาน (User Stories) ใหม่
DEV
2. เรียงลาดับความสาคัญ และระบุรายละเอียดของแต่ละลักษณะการใช้งานของผู้ใช้
ตามความเหมาะสม
DEV
3. นาเอกสารการออกแบบรายละเอียดซอฟต์แวร์ส่งให้ทางทีมพัฒนา DEV
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-TCM แบบบันทึกการตามรอย Template
PO-SDDG ข้อกาหนดการออกแบบ Policy
GL-SDDG แนวทางการออกแบบรายละเอียดซอฟต์แวร์ (Software
Detailed Design Guideline)
Guideline
คุณภาพที่คาดหวัง
(Quality expectation)
1. แผนการดาเนินงานสามารถนาไปใช้งานได้อย่างมีประสิทธิภาพ
2. แผนการดาเนินงานเป็นไปตามนโยบายขององค์กร
3. รายละเอียดแผนการดาเนินงานที่ได้เป็นไปตามรายการความต้องการ

75. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
66
2.11 รายละเอียดกิจกรรมในขั้นตอนการประเมินและทบทวนการออกแบบรายละเอียดซอฟต์แวร์ (SoftwareDetailed
Desing Refinement)
การออกแบบรายเละเอียดซอฟต์แวร์นั้นอาจจะประกอบไปด้วยข้อมูลที่จาเป็นที่ต้องวิเคราะห์และจัดทาขึ้นเป็น
จานวนมาก ดังนั้นเพื่อให้การออกแบบรายละเอียดนั้นตอบสนองเป็นไปตามความต้องการของผู้ใช้งาน แนวทางที่องค์กร
ต้องการ ตลอดจนเพื่อให้ได้ผลลัพธ์ของการออกแบบรายละเอียดซอฟต์แวร์ตามที่ต้องการ จึงควรมีขั้นตอนเพื่อประเมินและ
ทบทวนขึ้นเพื่อให้ผลิตภัณฑ์สอดคล้องกับความต้องการที่ตั้งเป้าไว้
2.11.1 PP-SDDR-DDER:การประเมินและทบทวนการออกแบบรายละเอียดซอฟต์แวร์ (Detailed Design Evaluation :
Retrospective)
หมายเลขอ้างอิง PP-SDDR-DDER
ชื่อกิจกรรม การประเมินและทบทวนการออกแบบรายละเอียดซอฟต์แวร์ (Detailed Design Evaluation :
Retrospective)
วัตถุประสงค์ วิเคราะห์กระบวนการทางานที่ต้องแก้ไขปรับปรุงข้อบกพร่องและจัดทาแนวทางปฏิบัติในการ
ควบคุมกระบวนการของการออกแบบรายละเอียดซอฟต์แวร์แต่ละสปรินท์ให้ดีขึ้น
ผลลัพธ์ 1. มีการพัฒนากาหนดกลยุทธ์ในการจัดการแก้ไขปัญหา
2. มีการระบุ จาแนก และบันทึกปัญหาในกระบวนการออกแบบซอฟท์แวร์แต่ละสปรินท์
3. มีการวิเคราะห์และประเมินการระบุการแก้ปัญหาที่การยอมรับได้ร่วมกัน
4. มีการดาเนินการแนวทางการแก้ไขปัญหา
5. มีการสรุปปิดประเด็นปัญหาที่ติดตาม
6. มีการจัดทารายงานสถานะ แนวทางการแก้ไขปัญหาทั้งหมดให้ทุกคนในทีมทราบ
บทบาทและความ
รับผิดชอบ รหัส บทบาท หน้าที่
SM สกรัม
มาสเตอร์
เป็นผู้ริเริ่มกิจกรรมจัดการวางแผนนัดหมายประสานงานสมาชิก
ในทีม รวบรวม สรุปปัญหาในการดาเนินโครงการ
DEV ทีมพัฒนา เป็ นผู้ดาเนินกิจกรรมหลักในโครงการ แจ้งปัญหาผลการ
ดาเนินการทบทวนกระบวนการออกแบบซอฟท์แวร์
SQA ผู้ควบคุม
คุณภาพ
เป็นผู้ควบคุมให้การดาเนินการโครงการมีคุณภาพตามมาตรฐาน
TW นักเขียน
เอกสารทาง
เทคนิค
เป็นผู้จัดทาเอกสารแนวทางการปรับปรุง ควบคุมกระบวนการ
ออกแบบรายละเอียดซอฟท์แวร์ เช่น บทเรียนที่ได้รับ
PO เจ้าของ
ผลิตภัณฑ์
เป็ นผู้มีส่วนร่วมในการตัดสินใจ จัดลาดับความสาคัญของ
กระบวนงานต่างๆ

76. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
67
ข้อมูลนาเข้า
รหัส รายการข้อมูล กิจกรรมต้นทาง
ISL รายการปัญหาที่เกิดขึ้นในการ
ดาเนินงาน (Issue List)
ข้อมูลปัญหาที่ทีมพัฒนาประสบ
ระหว่างการทางาน
ข้อมูลส่งออก
รหัส รายการข้อมูล กิจกรรมปลายทาง
FDB ข้อเสนอแนะการปฏิบัติงาน
(Feedback)
การปรับปรุงกระบวนงาน
LERN บทเรียนจากการปฏิบัติงาน
(Lesson Learned)
การปรับปรุงกระบวนงาน
เงื่อนไขก่อนเริ่มต้น
(Entry criteria)
1. เป็นขั้นตอนหลังจากเสร็จสิ้นแต่ละช่วงสปรินท์แบคล็อก
2. นัดประชุมผู้เกี่ยวข้องในการดาเนินงานโครงการ
3. รับข้อมูลนาเข้ารายการปัญหาจากกระบวนการติดตามและควบคุมการดาเนินงาน
เงื่อนไขการจบสิ้น
(Exit criteria)
1. มีการประชุมวิเคราะห์ปัญหาอย่างครบถ้วนร่วมกัน
2. สรุปแนวทางและวิธีการปรับปรุงกระบวนการออกแบบรายละเอียดซอฟท์แวร์
3. จัดทาเอกสารแนวทางการแก้ไขปัญหาให้ทุกคนในทีมรับทราบ ส่งต่อข้อมูลส่งออก ได้แก่
3.1 ข้อเสนอแนะการปฏิบัติงาน
3.2 บทเรียนจากการปฏิบัติงาน
กระบวนการทางาน

77. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
68
กิจกรรม ผู้รับผิดชอบ
1. ระบุปัญหาโดยดูจากรายงานผลการปฏิบัติงานหัวข้อปัญหาที่พบในสปรินท์แบคล็อค SM
2. จาแนกปัญหาและจัดลาดับความสาคัญของปัญหาที่พบจากกระบวนการพัฒนา
ซอฟท์แวร์
SM
3. จัดประชุมผู้ที่เกี่ยวข้องเพื่อประเมินและทบทวนสรุปปัญหา SM, DEV,
SQA
4. กาหนดวิธีปรับปรุงและสรุปแนวทางการแก้ไขของกระบวนการออกแบบรายละเอียด
ซอฟต์แวร์
SQA
5. ทวนสอบหัวข้อและแนวทางในการปรับปรุงกระบวนการออกแบบรายละเอียด
ซอฟต์แวร์
SM
6. จัดทาหรือปรับปรุงแก้ไขเอกสารรายงานการประชุมการประเมินและทบทวนสรุปปัญหา TW
7. ตรวจสอบอนุมัติเนื้อหารายงานการประชุม PO
8. จัดทาเอกสารคู่มือแนวทางการแก้ไขปัญหา ข้อเสนอแนะการปฏิบัติงานและบทเรียนจาก
การปฏิบัติงานของกระบวนการออกแบบรายละเอียดซอฟต์แวร์
PO, TW
รายการที่จาเป็นต้องใช้
รหัส ชื่อ ประเภท
TP-ISL แบบบันทึกรายการปัญหา Template

78. กระบวนการการออกแบบรายละเอียดซอฟต์แวร์
69
TP-QAR แม่แบบรายงานประกันคุณภาพ Tempate
คุณภาพที่คาดหวัง
(Quality expectation)
ข้อเสนอแนะการปฏิบัติงานและบทเรียนจากการปฏิบัติงานสามารถนาไปใช้เพื่อพัฒนาและ
ปรับปรุงกระบวนการออกแบบรายละเอียดซอฟต์แวร์ต่อไปได้อย่างมีประสิทธิภาพ

79. รายการตรวจสอบ (Checklist)
70
บทที่ 3 รายการตรวจสอบ (Checklist)
3.1 วัตถุประสงค์ของรายการตรวจสอบ
เพื่อใช้สาหรับการตรวจสอบคุณภาพ และควบคุมคุณภาพการออกแบบซอฟต์แวร์ของโครงการ เพื่อให้ซอฟต์แวร์
มีคุณภาพ และตรงตามความต้องการของลูกค้า และแผนงานที่กาหนด รวมทั้งรูปแบบมาตรฐานต่าง ๆ ที่ได้กาหนดเอาไว้
ด้วย
3.2 แบบฟอร์มรายการตรวจสอบ
การแนบแบบบันทึกรายการตรวจสอบไว้ด้านหลังรายงานแผ่นนี้ เสมอ
<<ชื่อ โครงการ>>
Checklist Summary Report
หัวข้อการตรวจทาน: <<ชื่อการตรวจสอบ>>
วันที่ทาการตรวจทาน: <<วัน เดือน ปี พ.ศ.>>
ผู้ตรวจทาน: <<ชื่อนามสกุล>>
ผลการตรวจทาน และข้อบกพร่องที่พบ:
<<สรุปผลการตรวจสอบ และระบุข้อบกพร่องเป็นข้อ ๆ >>
แนวทางการแก้ไข:
<<ระบุแนวทางการแก้ไข ตามข้อบกพร้อมที่พบ>>
ข้อเสนอแนะ:
<<ระบุคาแนะนาอื่น ๆ ถ้ามี>>

80. รายการตรวจสอบ (Checklist)
71
3.3 โครงสร้างรายการตรวจสอบ
รายการตรวจสอบ ผ่าน ไม่ผ่าน
1. ความมุ่งหมายของการนาเสนอแบบจาลองมีความชัดเจน
2. แบบจาลองมีระดับการนาเสนอจากข้อมูลความละเอียดน้อยลงไปหารายละเอียดมากอย่าง
เหมาะสมหรือไม่ และไม่ซับซ้อนเกินความจาเป็นต่อสถานภาพการพัฒนาในปัจจุบัน
3. การใช้แบบจาลองมีประสิทธิผลต่อการใช้เป็นเครื่องมือในการทาความเข้าใจปัญหาของระบบ
4. ผลการออกแบบสามารถทาความเข้าใจได้และแก้ไขปรับปรุงได้ง่าย
5. ผลการออกแบบสามารถทาได้จริงหรือไม่ในระยะเวลาของโครงการ
6. เหตุผลของแต่ละลาดับชั้นมีการระบุไว้อย่างชัดเจน
7. ขอบเขตของแต่ละลาดับชั้นสอดคล้องกับความต้องการของการออกแบบ
8. แต่ละลาดับชั้นได้มีคุณลักษณะเฉพาะที่มีประเภทของบริการที่แตกต่างกันและเป็นประโยชน์ที่การ
จาลองแบบ (Abstraction) ซึ่งทาให้ง่ายต่อการเข้าใจในความซับซ้อนของระบบ
9. ความมุ่งหมายของการนาเสนอแบบจาลองมีความชัดเจนหรือไม่
10. แบบจาลองมีระดับการนาเสนอจากข้อมูลความละเอียดน้อยลงไปหารายละเอียดมากอย่าง
เหมาะสม และไม่ซับซ้อนเกินความจาเป็นต่อสถานภาพการพัฒนาในปัจจุบัน
11. การใช้แบบจาลองมีประสิทธิผลต่อการใช้เป็นเครื่องมือทาให้การทาความเข้าใจปัญหาของระบบ
หรือไม่
3.4 รายละเอียดรายการตรวจสอบ
รายการตรวจสอบ ผ่าน ไม่ผ่าน
1. ระบบย่อยที่ได้จากการออกแบบสะท้อนถึงหน้าที่ความรับผิดชอบอย่างชัดเจน
2. ชื่อของแต่ละระบบย่อยจะต้องไม่ซ้าและมีความหมายเป็นเอกลักษณ์สื่อถึงหน้าที่อย่างชัดเจน
3. ระบบย่อยเผยแพร่บริการผ่านส่วนต่อประสาน มีตรรกกะแสดงถึงบริการของระบบย่อยอย่าง
ชัดเจน
4. ระบบย่อยแต่ละระบบมีผู้ดูแลรับผิดชอบในการพัฒนาและดูแลรักษาอย่างชัดเจน
5. การพัฒนาระบบย่อยจะต้องมีส่วนต่อประสานอย่างน้อยหนึ่งส่วนต่อประสานหนึ่งรายการ
6. ส่วนต่อประสานมีความชัดเจนในคาอธิบายและรายละเอียดการขึ้นต่อกันหรือ ส่วนต่อประสาน
อื่นอย่างชัดเจน
7. การพึ่งของส่วนต่อประสานในแต่ละระบบย่อยจะต้องผ่านส่วนต่อปรานเท่านั้น
8. ข้อมูลที่จะช่วยผู้เรียกใช้ส่วนต่อประสานอย่างมีประสิทธิภาพจะต้องได้รับการบันทึกไว้ใน
เอกสารและอยู่ในที่ที่ผู้เรียกใช้สะดวกที่จะอ่านทาความเข้าใจได้ง่าย
9. รายละเอียดการทางานภายในของระบบย่อยถูกเก็บรวบรวมซ่อนไว้ภายในด้านหลังของส่วนต่อ
ประสาน

81. รายการตรวจสอบ (Checklist)
72
รายการตรวจสอบ ผ่าน ไม่ผ่าน
10. ทุกองค์ประกอบของการออกแบบรายละเอียดสามารถตรวจสอบย้อนกลับไปยังองค์ประกอบทาง
สถาปัตยกรรม
11. การออกแบบรายละเอียดมีความสอดคล้องกับสถาปัตยกรรมและความต้องการ
12. องค์ประกอบของการออกแบบรายละเอียดเป็ นแบบโมดูล (high cohesion, low coupling,
appropriate use of abstract interfaces)
13.
14. การออกแบบมีข้อมูลเพียงพอต่อการพัฒนาและทดสอบ
3.5 วิธีการนาไปใช้งานรายการตรวจสอบ
Instructions
วิธีการ
1. ผู้ตรวจสอบควรศึกษาวัตถุประสงค์ข้อนั้น ๆ ก่อนการตรวจอบ
2. ทาเครื่องหมาย ถูก ในช่องผ่านไม่ผ่านในแต่ละหัวข้อเท่านั้น
3. บันทึกข้อมูลในรายงานสรุปการทวนสอบ ทุกครั้ง
การบันทึก Checklist Summary Report
หัวข้อการตรวจทาน: กาหนดหัวข้อการตรวจสอบเช่น
- การตรวจสอบรายงานการออกแบบรายละเอียด
- การตรวจสอบการออกแบบสถาปัตยกรรม
วันที่ทาการตรวจทาน: กาหนดวันที่เป็น วัน เดือน ปี (พ.ศ.) ที่ทาการตรวจสอบ
ผู้ตรวจทาน: ระบุ ชื่อ นามสกุลของผู้ตรวจสอบ
ผลการตรวจทาน และข้อบกพร่องที่พบ: สรุปผลการตรวจสอบ และระบุข้อบกพร่องเป็นข้อ ๆ
แนวทางการแก้ไข: ระบุแนวทางการแก้ไข ตามข้อบกพร้อมที่พบ
ข้อเสนอแนะ: ระบุคาแนะนาอื่น ๆ ถ้ามี
3.6 คาแนะนาการใช้งานรายการตรวจสอบ
1. เข้าไปตรวจติดตามเพื่อดูว่าการออกแบบได้ถูกออกแบบตามเทคนิคและวิธีการที่กาหนด
2. เข้าไปตรวจสอบเอกสารการออกแบบ (Software Design Document) ว่าได้ระบุคอมโพเนนต์หลักพร้อมทั้ง
หน้าที่การทางาน, ข้อมูลน้าเข้า และส่งออกของคอมโพเนนต์หลักเหล่านั้น
3. เข้าไปตรวจสอบดูว่า AD อธิบายถึงโครงสร้างของการเชื่อมต่อระหว่างคอมโพเนนต์
4. เข้าไปตรวจสอบเอกสารรายการออกแบบรายละเอียดที่ว่า ได้การออกแบบเป็นส่วนขยายอย่างมีตรรกะ จาก
โครงสร้างซอฟต์แวร์ที่ระบุไว้ใน ADD
5. เข้าไปตรวจสอบการออกแบบว่าสามารถสอบกลับไปที่ข้อกาหนดได้
6. เข้าไปตรวจสอบเอกสารการออกแบบว่าได้มีการระบุทรัพยากรที่ต้องการ

82. รายการตรวจสอบ (Checklist)
73
7. เข้าร่วมการทวนสอบเอกสารการออกแบบเพื่อดูว่าการผลการทวนสอบเป็นไปตามกระบวนการที่กาหนด

83. สินทรัพย์กระบวนการ
กระบวนการออกแบบรายละเอียดซอฟต์แวร์ 74
บทที่ 4 สินทรัพย์กระบวนการ
4.1 เครื่องมือที่ใช้
4.1.1 ช่วยนิยามกระบวนการ และจัดสร้างเอกสาร
ตารางที่ 11 เครื่องมือสาหรับสนับสนุนการนิยามกระบวนการ
รหัส ชื่อ คาอธิบาย กระบวนการที่ใช้งาน
TD-WORD Misoft Office 2016 ชุดโปรแกรมสานักงานสาหรับสร้างเอกสาร
นาเสนอกลุ่มผู้บริหาร และแนะนาผู้ใช้งาน
ในช่วงขั้นตอนการนิยามกระบวนการ
PP-ADPI-PDEF: การ
นิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การ
นานิยามกระบวนการ
ออกแบบรายละเอียด
ซอฟต์แวร์ไปใช้
(Software Detailed
Design Process
Deployment)
TD-ONED Microsoft OneDrive ใช้ส่งต่อข้อมูล แก้ไขเอก และจัดการรุ่นของ
เอกสาร ร่วมกันภายในกลุ่ม SEPG
PP-ADPI-PDEF: การ
นิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนา
นิยามกระบวนการ
ออกแบบรายละเอียด
ซอฟต์แวร์ไปใช้
(Software Detailed
Design Process
Deployment)
TI-SPICE SPiCE 1-2-1 ใช้ตรวจสอบและติดตามระดับความสามารถ
ของกระบวนการที่ได้นิยามขึ้น ตั้งแต่ช่วงก่อน
การนิยามกระบวนการ การนากระบวนการไป
ใช้งานภายในองค์กร ไปจนกระทั้ ง
ตั้งแต่เริ่มต้นก่อนการ
นิยามกระบวนการ ไป
จนกระทั่งบรรลุเป้าหมาย

84. สินทรัพย์กระบวนการ
75
รหัส ชื่อ คาอธิบาย กระบวนการที่ใช้งาน
กระบวนการมีความสามารถถึงระดับที่องค์กร
ต้องการ
TI-VISIO Microsoft Visio 2016 ช่วยสร้างแผนภาพแบบจาลอง หรือแสดง
กิจกรรมและผู้มีส่วนเกี่ยวข้องกับกิจกรรม
ภายในกระบวนการที่ได้นิยามขึ้น
PP-ADPI-PDEF: การ
นิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนา
นิยามกระบวนการ
ออกแบบรายละเอียด
ซอฟต์แวร์ไปใช้
(Software Detailed
Design Process
Deployment)
4.1.2 โครงสร้างพื้นฐานสาหรับสนับสนุนกระบวนการ
ตารางที่ 12 รายการโครงสร้างพื้นฐาน
รหัส ชื่อ คาอธิบาย กระบวนการที่ใช้งาน
TS-GITS git ซอฟต์แวร์สาหรับติดตามการเปลี่ยนแปลง
ของรายการข้อมูลที่ เกิ ดขึ้ นภายใน
กระบวนการ เช่น แม่แบบบันทึกข้อมูล ซอร์
สโค้ด
ตลอดทั้งกระบวนการ
TS-ALFR Alfresco เว็บแอปพลิเคชันสาเร็จรูปทาหน้าที่จัดการ
เอกสาร และรายการข้อมูลภายใน
กระบวนการที่ได้นิยามขึ้น ตลอดจนใช้
เผยแพร่หรือจัดเก็บสินทรัพย์กระบวนการของ
องค์กร
ตลอดทั้งกระบวนการ

85. สินทรัพย์กระบวนการ
76
4.2 แม่แบบบันทึกข้อมูล
4.2.1 แบบบันทึกข้อมูลที่ใช้ภายในกระบวนการ
ตารางที่ 13 แม่แบบบันทึกข้อมูลที่ใช้ภายในกระบวนการ
รหัส ชื่อ คาอธิบาย
TP-CHEK รายการตรวจสอบข้อมูล
(Checklist)
แม่แบบบันทึกข้อมูลสาหรับตรวจสอบรายการของกิจกรรม ผลลัพธ์
กระบวนการ ข้อมูลนาเข้า หรืออื่นๆ ที่สนใจ เทียบกับแบบรูปที่ใช้
อ้างอิง เพื่อให้ทราบได้ว่ารายการข้อมูลเหล่านั้นครบถ้วนตามที่ขาดหวัง
ไว้แล้วหรือไม่
TP-TMTP แม่แบบตามรอยการ
เปลี่ยนแปลง (Traceability
Metrix Template)
แม่แบบบันทึกข้อมูลสาหรับใช้บันทึกกิจกรรมต้นทางที่เกิดขึ้น รายการ
ของกิจกรรมที่เกี่ยวเนื่องกับกิจกรรมก่อนหน้า
TP-SDDT Software Detailed Design
Template
แม่แบบบันทึกข้อมูลที่ใช้สาหรับบันทึกข้อมูลการออกแบบ
TP-PRAT Process Assessment
Template
แม่แบบบันทึกข้อมูลสาหรับใช้ประเมินระดับคุณภาพของกระบวนการ
โดยอ้างตัวชี้วัดกระบวนการตามระดับความสามารถที่องค์กร
ตั้งเป้าหมายไว้
TP-CHRT Change Request Template แม่แบบบันทึกข้อมูลสาหรับเสนอการเปลี่ยนแปลงข้อมูลภายใน
กระบวนการ
TP-MERT Meeting Report Template แม่แบบบันทึกข้อมูลสาหรับบันทึกข้อมูลการประชุมเพื่อใช้ติดตามการ
ดาเนินงานของบุคลากร
TP-INRT Incident Report Template แม่แบบบันทึกข้อมูลผลการเพื่อแจ้งข้อผิดพลาดที่พบ
TP-VART Validation Report
template
แม่แบบบันทึกข้อมูลสาหรับบันทึกข้อมูลการทวนสอบรายการข้อมูล
TP-PRBT Product backlog Template แม่แบบบันทึกข้อมูลรายการความต้องการที่จัดเก็บ
TP-COIT Configuration
Identification Template
แม่แบบบันทึกข้อมูลเพื่อระบุการปรับปรุงรุ่น

86. ความสอดคล้องกับมาตรฐานอ้างอิง
77
บทที่ 5 ความสอดคล้องกับมาตรฐานอ้างอิง
ในส่วนนี้เป็นแบบประเมินโครงการเพื่อทบทวนว่ากระบวนการที่นิยามขึ้นนั้นเป็นไปตามข้อกาหนดของ
มาตรฐาน ISO/IEC 12207และ ISO/IEC 15504 หรือไม่ ซึ่งแสดงรายการเปรียบเทียบกิจกรรมที่ได้นิยามขึ้นและผลลัพธ์ต่าง
ๆ ดังตารางต่อไปนี้
1) ความสอดคล้องกับมาตรฐาน ISO 12207
การออกแบบรายละเอียดซอฟต์แวร์ (Software Detailed Design): ซอฟต์แวร์แต่ละรายการ (Software item) หรือ
แม้กระทั่งส่วนจัดการที่ใช้ในกรณีที่ระบุไว้ประกอบไปด้วยงานต่างๆ ดังตารางต่อไปนี้
ตารางที่ 14 เปรียบเทียบกิจกรรมที่นิยามกับมาตรฐาน ISO 12207
Clause of ISO/IEC 12207 Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
7.1.4.3.1.1 นักพัฒนจะต้องสร้างเค้าโครงอย่าง
ละเอียด (Detailed design) สาหรับซอฟต์แวร์แต่
ละส่วนสาหรับรายการซอฟต์แวร์นั้น ซึ่งส่วน
ของซอฟต์แวร์ก็ควรจะต้องปรับแต่งให้อยู่ใน
สภาพที่หน่วยย่อยของซอฟต์แวร์จะนาไปพัฒนา
โค้ด คอมไพล์และทดสอบได้และควรจะต้อง
มั่นใจว่ารายการความต้องการของซอฟต์แวร์
ส่วนนั้นไปปรากฏในส่วนย่อยของซอฟต์แวร์
ด้วย ซึ่งเค้าโครงอย่างละเอียดนี้ควรจัดทาเป็น
เอกสาร
F PP-SDD-DESS: ออกแบบ
รายละเอียดซอฟต์แวร์
โมเดลหรือแผนภาพ
(Design Artifact)
ประกอบด้วย
- User Interface
- Component
- Detailed Class
- Interface
7.1.4.3.1.2 นักพัฒนาสร้าง จัดทาเอกสาร
รายละเอียดซอฟต์แวร์สาหรับการเชื่อมต่อกับ
ส่วนอื่นๆ ภายนอกซอฟต์แวร์ ระหว่าง
ส่วนประกอบซอฟต์แวร์ด้วยกันเอง และระหว่าง
ส่วนย่อยของซอฟต์แวร์ ซึ่งเค้าโครงอย่าง
ละเอียดสาหรับการเชื่อมต่อนี้ควรจะนาไป
พัฒนาซอฟต์แวร์ได้โดยไม่ต้องใช้ข้อมูลอื่นๆ
เพิ่มเติม
F PP-SDD-DOCD: จัดทา
เเอกสารการออกแบบ
ซอฟต์แวร์ (Software
Design Description)
- เอกสารรายละเอียด
ซอฟต์แวร์ (SDD)
7.1.4.3.1.3 นักพัฒนาจะต้องสร้างและจัดทา
เอกสารเค้าโครงอย่างละเอียดสาหรับฐานข้อมูล
F PP-SDD-DESS: ออกแบบ
รายละเอียดซอฟต์แวร์
แบบจาลองหรือแผนภาพ
การออกแบบฐานข้อมูล

87. ความสอดคล้องกับมาตรฐานอ้างอิง
78
7.1.4.3.1.4 นักพัฒนาจะต้องกาหนดและจัดทา
เอกสารสาหรับรายการความต้องการในการ
ทดสอบ กาหนดการณ์ในการทดสอบหน่วยย่อย
ของซอฟต์แวร์ โดยที่รายการความต้องการใน
การทดสอบนี้พึงเน้นไปรายการข้อจากัดของ
หน่วยย่อยของซอฟต์แวร์นั้นๆ
F PP-SDD-UTCP: จัดทาหรือ
ปรับปรุง กรณีทดสอบและ
ขั้นตอนทดสอบ (Update
Test Cases and Test
Procedures)
PP-SDD-VFTC: ทวนสอบ
และอนุมัติกรณีทดสอบและ
ขั้นตอนทดสอบ
(Verification and Approval
Test Cases and Test
Procedures)
กรณีทดสอบและ
ขั้นตอนการทดสอบ
(TC&TP)
7.1.4.3.1.5 นักพัฒนาจะต้องปรับปรุงรายการ
ความต้องการในการทดสอบ และตารางเวลา
สาหรับการผนวกซอฟต์แวร์ (Software
Integration)
F PP-SDD-UTCP: จัดทาหรือ
ปรับปรุง กรณีทดสอบและ
ขั้นตอนทดสอบ (Update
Test Cases and Test
Procedures)
PP-SDD-VFTC: ทวนสอบ
และอนุมัติกรณีทดสอบและ
ขั้นตอนทดสอบ
(Verification and Approval
Test Cases and Test
Procedures)
กรณีทดสอบและ
ขั้นตอนการทดสอบ
(TC&TP)
7.1.4.3.1.6 นักพัฒจะต้องประเมินผลเค้าโครง
อย่างละเอียดของซอฟต์แวร์ (Software Detailed
Design) และรายการความต้องการในการ
ทดสอบ เทียบกับเงื่อนไขดังต่อไปนี้ ผลของการ
ทดสอบควรจะถูกบันทึกไว้
a) รายการนั้นสามารถตรวจสอบย้อนกลับไปยัง
ความต้องการได้
b) สอดคล้องกันภายนอกของเค้าโครง
สถาปัตยกรรม (Architectural design)
c) สอดคล้องกันภายในระหว่างส่วนของ
ซอฟต์แวร์และหน่วยย่อของซอฟต์แวร์
d) ใช้วิธีการออกแบบและมาตรฐานที่เหมาะสม
e) ต้องทดสอบได้จริง
F PP-SDD-REVE: ทวนสอบ
และประเมินแบบ
รายละเอียดซอฟต์แวร์
(Verification and Approval
Test Detailed Design)
ผลการตรวจประเมิน
(VLR)
- ความสอดคล้อง
- ความเป็นไปได้ใน
การพัฒนา
- ความเป็นไปได้ใน
การดูแลรักษา
- ความเป็นไปได้ใน
การทดสอบ
- เป็นไปตามหลักการ
ออกแบบที่ดี
- ความสามารถในการ
ตามรอย

88. ความสอดคล้องกับมาตรฐานอ้างอิง
79
f) ต้องดาเนินการและบารุงรักษาได้จริง
7.1.4.3.1.7 นักพัฒนาจะตรวจสอบการ
ดาเนินการตามกระบวนการทบทวนซอฟต์แวร์
(Software Review Process) (7.2.6 หน้า 74)
PP-SDD-REVE: ทวนสอบ
และประเมินแบบ
รายละเอียดซอฟต์แวร์
(Verification and Approval
Test Detailed Design)

89. ความสอดคล้องกับมาตรฐานอ้างอิง
80
2) ความสอดคล้องกับกับมาตรฐาน ISO 15504
ตารางที่ 15 ตารางเปรียบเทียบกิจกรรมที่นิยามกับมาตรฐาน 15504
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
PA 1.1 Achievements
a) the process achieves its
defined outcomes.
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-DEVP-DOCD: จัดทาเเอกสารของการ
ปรับปรุงการออกแบบซอฟต์แวร์ (Document
software design)
PP-DEVP-UTCP: จัดทาหรือปรับปรุงกรณี
ทดสอบ และการทดสอบ (Test Cases and Test
Procedures)
- แบบจาลอง
หรือแผนภาพ
ต่างๆ
- เอกสาร
รายละเอียด
ซอฟต์แวร์
- เอกสารกรณี
ทดสอบและ
เอกสาร
กระบวนการ
ทดสอบ
PA 2.1 Achievements
a) objectives for the performance
of the process are identified;
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
- แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
- สปรินท์
แบคล็อก
b) performance of the process is
planned and monitored;
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
PP-MCTR-PMCR: การติดตามและควบคุมการ
ดาเนินงาน ในระดับองค์กร (Monitoring and
Control: Organizational)
- ตารางงาน
- รายงาน
ความก้าวหน้า
ของการ
ดาเนินงาน

90. ความสอดคล้องกับมาตรฐานอ้างอิง
81
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
c) performance of the process is
adjusted to meet plans;
F
PP-SDDR-DDER: การประเมินและทบทวนการ
ออกแบบรายละเอียดซอฟต์แวร์ (Detailed
Design Evaluation : Retrospective)
- ข้อเสนอแนะ
การปฏิบัติงาน
- บทเรียนจาก
การปฏิบัติงาน
d) responsibilities and authorities
for performing the process are
defined, assigned and
communicated;
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
e) resources and information
necessary for performing the
process are identified, made
available, allocated and used;
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
f) interfaces between the
involved parties are managed to
ensure both effective
communication and also clear
assignment of responsibility.
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
PA 2.1 Ressources
Human ressources with identified
objectives, responsibilities and
authorities;
[PA 2.1 Achievement a, d, e, f]
F
PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง (Software
Detailed Design Planning Part II)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
Facilities and infrastructure
resources;
[PA 2.1 Achievement a, d, e, f]
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์

91. ความสอดคล้องกับมาตรฐานอ้างอิง
82
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
Project planning, management
and control tools, including time
and cost
reporting;
[PA 2.1 Achievement b, c]
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
PP-MCTR-PMCR: การติดตามและควบคุมการ
ดาเนินงาน ในระดับองค์กร (Monitoring and
Control: Organizational)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
Workflow management system;
[PA 2.1 Achievement d, f]
F
PP-MCTR-PMCR: การติดตามและควบคุมการ
ดาเนินงาน ในระดับองค์กร (Monitoring and
Control: Organizational)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
Email and/or other
communication mechanisms;
[PA 2.1 Achievement d, f]
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
Information and/or experience
repository;
[PA 2.1 Achievement b, e]
F
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
แผนการ
ออกแบบ
รายละเอียด
ซอฟต์แวร์
Problem and issues management
mechanisms.
[PA 2.1 Achievement c]
F
PP-MCTR-PMCR: การติดตามและควบคุมการ
ดาเนินงาน ในระดับองค์กร (Monitoring and
Control: Organizational)
- เอกสารรายงาน
ปัญหา
- เอกสารร้องขอ
การเปลี่ยนแปลง
PA 2.2 Achievements
a) requirements for the work
products of the process are
defined;
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
สปรินท์
แบคล็อก
b) requirements for
documentation and control of the
work products are defined;
F
PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง (Software
Detailed Design Planning Part II)
สปรินท์
แบคล็อก

92. ความสอดคล้องกับมาตรฐานอ้างอิง
83
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
c) work products are
appropriately identified,
documented, and controlled;
F
PP-DEVP-DOCD: จัดทาเเอกสารของการ
ปรับปรุงการออกแบบซอฟต์แวร์ (Document
software design)
PP-DEVP-UTCP: จัดทาหรือปรับปรุงกรณี
ทดสอบ และการทดสอบ (Test Cases and Test
Procedures)
PP-DEVP-UTCR: ปรับปรุงระเบียนตามรอย
(Update the Traceability Record)
PP-DEVP-REPO: การจัดเก็บผลลัพธ์ของ
กระบวนการในที่เก็บข้อมูลของโครงการ
(Project Repository)
- เอกสาร
รายละเอียด
ซอฟต์แวร์
- เอกสารกรณี
ทดสอบและ
เอกสาร
กระบวนการ
ทดสอบ
- เอกสารการ
ตามรอย
-รายงานการ
ดาเนินงานเกร
เก็บข้อมูล
d) work products are reviewed in
accordance with planned
arrangements and adjusted as
necessary to meet requirements.
F
PP-DEVP-REVE: ทวนสอบและประเมินแบบ
รายละเอียดซอฟต์แวร์ (Review and Evaluation
for Software Detailed Desing)
PP-DEVP-VFTC: ตรวจสอบความถูกต้องของ
กรณีทดสอบ และแผนการทดสอบ (Verification
and approval of the test cases and test
procedures)
PP-DEVP-ADJR: การจัดปรับแผนและ
รายละเอียดซอฟต์แวร์ (Adjust Plan and
Redesign)
ผลการตรวจ
ประเมิน
PA 2.2 Resources
Requirement management
method / toolset;
[PA 2.2 Achievement a, b, c]
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
สปรินท์
แบคล็อก
Configuration management
system;
[PA 2.2 Achievement b, c]
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
เอกสารคู่มือการ
จัดการโครงแบบ
ข้อมูล

93. ความสอดคล้องกับมาตรฐานอ้างอิง
84
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
Documentation elaboration and
support tool;
[PA 2.2 Achievement b, c]
F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
เอกสารคู่มือการ
จัดการโครงแบบ
ข้อมูล
Document identification and
control procedure;
[PA 2.2 Achievement b, c]
F
PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง (Software
Detailed Design Planning Part II)
PP-DEVP-REPO: การจัดเก็บผลลัพธ์ของ
กระบวนการในที่เก็บข้อมูลของโครงการ
(Project Repository)
เอกสารคู่มือการ
จัดการโครงแบบ
ข้อมูล
Work product review methods
and experiences;
[PA 2.2 Achievement d]
F
PP-DEVP-REVE: ทวนสอบและประเมินแบบ
รายละเอียดซอฟต์แวร์ (Review and Evaluation
for Software Detailed Desing)
เอกสารคู่มือการ
จัดการโครงแบบ
ข้อมูล
Review management method /
toolset; [PA 2.2 Achievement d] F
PP-PLPH-SPP1: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงแรก (Software
Detailed Design Part I)
เอกสารคู่มือการ
จัดการโครงแบบ
ข้อมูล
Intranets, extranets and/or other
communication mechanisms;
[PA 2.2 Achievement b, c]
F
PP-PLPH-SPP2: การวางแผนออกแบบ
รายละเอียดซอฟต์แวร์ช่วงสอง (Software
Detailed Design Planning Part II)
เอกสารคู่มือการ
จัดการโครงแบบ
ข้อมูล
Problem and issue management
mechanisms.
[PA 2.2 Achievement d]
F
PP-MCTR-PMCR: การติดตามและควบคุมการ
ดาเนินงาน ในระดับองค์กร (Monitoring and
Control: Organizational)
- เอกสารรายงาน
ปัญหา
- เอกสารร้องขอ
การเปลี่ยนแปลง
PA 3.1 Achievements
a) a standard process, including
appropriate tailoring guidelines,
is defined that describes the
fundamental elements that must
be incorporated into a defined
process;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
เอกสารคู่มือการ
ปรับ
กระบวนการให้
เหมาะสมกับ
ลักษณะเฉพาะ
ของโครงการ

94. ความสอดคล้องกับมาตรฐานอ้างอิง
85
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
b) the sequence and interaction of
the standard process with other
processes is determined;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
เอกสารนิยาม
กระบวนการ
c) required competencies and
roles for performing a process are
identified as part of the standard
process;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
รายชื่อทีมงาน
และความ
รับผิดชอบ
d) required infrastructure and
work environment for performing
a process are identified as part of
the standard process;
F
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
โครงสร้าง
พื้นฐานและ
สภาพแวดล้อม
การทางาน
PA 3.1 Ressources
Process modeling methods /
tools;
[PA 3.1 Achievement a, b, c, d]
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
เอกสารนิยาม
กระบวนการ
Training material and courses.
[PA 3.1 Achievement a, b, c]
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
เอกสารคู่มือการ
นาเอา
กระบวนการไป
ใช้
Resource management system.
[PA 3.1 Achievement b, c]
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
เอกสารคู่มือการ
นาเอา
กระบวนการไป
ใช้
Process infrastructure.
[PA 3.1 Achievement a, b]
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
เอกสารคู่มือการ
นาเอา
กระบวนการไป
ใช้

95. ความสอดคล้องกับมาตรฐานอ้างอิง
86
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
Audit and trend analysis tools.
[PA 3.1 Achievement e]
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
เอกสารคู่มือการ
นาเอา
กระบวนการไป
ใช้
Process monitoring method.
[PA 3.1 Achievement e] F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
เอกสารนิยาม
กระบวนการ
PA 3.2 Achievements
a) a defined process is deployed
based upon an appropriately
selected and/or tailored standard
process;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
b) required roles, responsibilities
and authorities for performing the
defined process are assigned and
communicated;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
เอกสารคู่มือการ
นาเอา
กระบวนการไป
ใช้
c) personnel performing the
defined process are competent on
the basis of appropriate
education, training, and
experience;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
รายชื่อบทบาท
หน้าที่และความ
รับผิดชอบ
d) required resources and
information necessary for
performing the defined process
are made available, allocated and
used;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
รายชื่อบทบาท
หน้าที่และความ
รับผิดชอบ

96. ความสอดคล้องกับมาตรฐานอ้างอิง
87
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
e) required infrastructure and
work environment for performing
the defined process are made
available, managed and
maintained;
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
รายการสินทรัพย์
กระบวนการ
f) appropriate data are collected
and analysed as a basis for
understanding the behaviour of,
and to demonstrate the suitability
and effectiveness of the process,
and to evaluate where continuous
improvement of the process can
be made.
F
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
- เอกสาร
รายละเอียด
กระบวนการตาม
มาตรฐานองค์กร
ที่ได้รับการ
แก้ไขแล้ว
- ความรู้และ
ปัญหา พร้อม
แนวทางแก้ไข ที่
เกิดขึ้นใน
กิจกรรม
PA 3.2 Resources
Feedback mechanisms (customer,
staff, other stakeholders);
[PA 3.2 Achievement f]
F
PP-MCTR-PMCR: การติดตามและควบคุมการ
ดาเนินงาน ในระดับองค์กร (Monitoring and
Control: Organizational)
เอกสาร
รายละเอียด
กระบวนการ
Process repository;
[PA 3.2 Achievement a, b] F
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
เอกสาร
รายละเอียด
กระบวนการ
Resource management system;
[PA 3.2 Achievement b, c, d] F
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
เอกสาร
รายละเอียด
กระบวนการ
Knowledge management system.
[PA 3.2 Achievement d] F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
เอกสาร
รายละเอียด
กระบวนการ

97. ความสอดคล้องกับมาตรฐานอ้างอิง
88
Achievements
Coverage
F/P/N
Title of the Task and Step
(Map to)
Outcome
(Map to)
Problem and change management
system;
[PA 3.2 Achievement f]
F
PP-MCTR-PMCR: การติดตามและควบคุมการ
ดาเนินงาน ในระดับองค์กร (Monitoring and
Control: Organizational)
รายงานการ
ประชุม
Working environment and
infrastructure;
[PA 3.2 Achievement e]
F
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
เอกสาร
รายละเอียด
กระบวนการ
Data collection analysis system.
[PA 3.2 Achievement f] F
PP-ADPI-PDEP: การนานิยามกระบวนการ
ออกแบบรายละเอียดซอฟต์แวร์ไปใช้(Software
Detailed Design Process Deployment)
คู่มือการประเมิน
กระบวนการ
Process assessment framework;
[PA 4.1 Achievement f] F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
คู่มือการประเมิน
กระบวนการ
Audit / review system.
[PA 3.2 Achievement f]
F
PP-ADPI-PDEF: การนิยามกระบวนการ
(Process Definition)
คู่มือการประเมิน
กระบวนการ

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

99. แนะนาเครื่องมือ
กระบวนการออกแบบรายละเอียดซอฟต์แวร์ ก
ภาคผนวก ข แนะนาเครื่องมือ
ข.1 Microsoft Office 2016
ชุดโปรแกรมสานักงาน (Office Suite) นั้นถือได้ว่าเป็นเครื่องมือสาคัญในการสร้างเอกสารประกอบการนิยาม
กระบวนการ จัดทาแนวปฏิบัติงานและเอกสารประกอบการนิยาม ทั้งนี้ชุดโปรแกรมสานักงานนั้นมีหลากหลายให้เหลือ
ตามความเหมาะสมของหน่วยงาน ทั้งนี้ในการนิยามกระบวนการนี้ได้คัดเลือกแล้วว่าชุดสานักงาน MicrosoftOffice 2016
ซึ่งพัฒนาโดยบริษัทไมโครซอฟท์ (Microsoft) นั้นมีความเหมาะสมกับการดาเนินงานมากที่สุด เนื่องจากในขั้นตอนการ
ดาเนินงานนั้น จาเป็นจะต้องมีบุคลากรเข้ามาแก้ไขเอกสารร่วมกัน ซึ่งชุดโปรแกรม MicrosoftOffice 2016 นั้นมี
ความสามารถโดดเด่นมากในกลุ่มชุดโปรแกรมสานักงาน จึงส่งผลให้เลือกชุดโปรแกรม MicrosoftOffice 2016 นั้น
เหมาะสม
ข.1.1 ความสามารถ
ชุดโปรแกรม Microsoft Office 2016 ที่ใช้งานในการนิยามประกอบไปด้วย
- Word: โปรแกรมประมวลผลคา (WordProcessing) สาหรับจัดทาเอกสารคู่มือประกอบการนิยามกระบวนการ
แนวทางการดาเนินงาน กระบวนการมาตรฐานองค์กร
- Excel: โปรแกรมแผนงานคานวณ (SpreadSheet) สาหรับแสดงและติดตามการดาเนินงานระดับความสามารถ
ของโครงการ จัดทาแบบประเมินเบื้องต้นตลอดจนคานวณเพื่อหาระดับความสามารถของกระบวนการที่ได้นิยาม
ขึ้น
- PowerPoint: โปรแกรมนาเสนอ (Presentation) เพื่อสารุปข้อมูลการดาเนินงาน
- OneNote: โปรแกรมจดบันทึกอรรถประโยชน์สาหรับใช้งานเพื่อจัดเก็บข้อมูลที่เกิดขึ้นอย่างไม่เป็นทางการและ
อาจนาไปใช้เป็นข้อมูลประกอบการดาเนินการปรับปรุงกระบวนการ
ข.1.2 ข้อมูลทั่วไป
รายการข้อมูล คาอธิบาย
นักพัฒนา Microsoft (ไมโครซอฟท์)
เริ่มใช้งาน 1 สิงหาคม 2532 (26 ปีก่อนหน้านี้)
รุ่นปัจจุบัน 2016 (15.20.0) เมื่อวันที่ 16 มีนาคม 2559
ระบบปฏิบัติการที่รองรับ Windows 10
OS X 10.11
ภาษาที่รองรับ อังกฤษ, ไทย และภาษาอื่นๆ

100. แนะนาเครื่องมือ
ข
รายการข้อมูล คาอธิบาย
ลิขสิทธิ์ ซอฟต์แวร์เพื่อการค้า
เว็บไซต์ Office.microsoft.com
ข.2 Microsoft Visio 2016
Visio เป็นเครื่องมือที่เสริมการทางานของ MicrosoftOffice ในการช่วยให้สร้างแผนภูมิ แผนผัง ตารางแสดง
โครงสร้างองค์กร แผนภูมิทางการตลาด ตารางเวลา และอื่นๆ ได้อย่างง่ายดาย รวมทั้งช่วยเพิ่มประสิทธิภาพในการสื่อสาร
โดยช่วยให้แต่ละแผนกสามารถดูแผนภูมิหรือตารางในรูปแบบไฟล์ที่แตกต่างกันตามต้องการได้ เช่น ไฟล์ที่ส่งทางอีเมล์,
ระบบอินทราเน็ต และ อินเทอร์เน็ต เป็นต้น และยังช่วยให้ผู้จัดทาเอกสารสร้างภาพกราฟฟิกใหม่ๆ แปลกๆ ได้สะดวก เพื่อ
เพิ่มสีสัน ความชัดเจนให้กับข้อมูลต่างๆ ได้เป็นอย่างดี ช่วยประหยัดเวลาในการสร้างเอกสาร
ข.2.1 ความสามารถ
ชุดโปรแกรม Microsoft Office 2016 ที่ใช้งานในการนิยามประกอบไปด้วย
- สร้างไดอะแกรมได้
- เชื่อมโยงข้อมูลเข้ากับการแสดงแผนภาพและโมเดลต่าง ๆ
- สามารถลิงก์ไปยังแหล่งข้อมูลได้หลายแหล่ง ทั้ง MicrosoftExcel, MicrosoftExcel Services, Active Directory,
MicrosoftSQL Server, MicrosoftSQL Azure,MicrosoftSharePoint Lists และ MicrosoftBusiness Connectivity
Services
- ใช้กราฟิกข้อมูล เช่น ไอคอน สี และข้อความ เพื่อช่วยปรับปรุงและช่วยให้การแสดงภาพจากข้อมูลที่ซับซ้อน
เข้าใจได้ง่ายขึ้น
-
ข.2.2 ข้อมูลทั่วไป
รายการข้อมูล คาอธิบาย
นักพัฒนา Microsoft (ไมโครซอฟท์)
เริ่มใช้งาน 1 สิงหาคม 2532 (26 ปีก่อนหน้านี้)
รุ่นปัจจุบัน 2016 (15.20.0) เมื่อวันที่ 16 มีนาคม 2559
ระบบปฏิบัติการที่รองรับ Windows 10
OS X 10.11

101. แนะนาเครื่องมือ
ค
รายการข้อมูล คาอธิบาย
ภาษาที่รองรับ อังกฤษ, ไทย และภาษาอื่นๆ
ลิขสิทธิ์ ซอฟต์แวร์เพื่อการค้า
เว็บไซต์ Office.microsoft.com