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

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: ภาพรวมของกระบวนการที่นิยามขึ้น