คู่มือ 29110 ภาครัฐ

คู่มอื ปฏิบตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครัฐ

คำนำ

การบริหารจัดการโครงการของหน่วยงานภาครัฐในการจัดซ้ือจัดจ้างระบบสารสนเทศ เพ่ือให้เกิด
ประโยชน์สูงสุด เร่ิมจากกระบวนการพิจารณาองค์ประกอบต่างๆ ท่ีเหมาะสมควบคู่ไปกับการบริหารจัดการท่ี
นามาตรฐาน ISO/IEC 29110 มาประยุกต์ใช้ โดยนากระบวนการบริการไอซีที ภายใต้กรอบมาตรฐาน
ISO/IEC 20000 หรือ ITIL มาปรับใช้เป็นกระบวนการพ้ืนฐานในการบริหารจัดการโครงการ (Project
Management) และการพัฒนาระบบและซอฟต์แวร์ (System & Software Implementation) ภายใต้
กรอบการบริหารจดั การ การจดั ซ้ือจดั จา้ งภาครัฐให้มปี ระสิทธภิ าพยง่ิ ขนึ้

คู่มือฉบับน้ีมีวัตถุประสงค์เพื่อการนาไปใช้หลังจากดาเนินการจัดซื้อจัดจ้างแล้วเสร็จ และดาเนินการ
ลงนามในสญั ญาเรียบรอ้ ยแล้ว จึงนากระบวนการบรหิ ารจดั การตามมาตรฐาน ISO/IEC 29110 ใช้ติดตามและ
กากับดูแลการดาเนินงานโครงการ ให้เป็นไปตามวัตถุประสงค์ของโครงการ และเพ่ือใช้เป็นเอกสารอ้างอิงใน
การปรับปรุงกระบวนการปฏิบัติงานตามขั้นตอนกระบวนการวิศวกรรมระบบและซอฟต์แวร์ โดยเฉพาะการ
พัฒนาระบบสารสนเทศของราชการไทยอย่างเป็นระบบ ภายใต้กรอบมาตรฐาน ISO/IEC 29110 (มอก.
29110) คู่มือฉบับน้ีเหมาะสาหรับผู้มีหน้าที่ในการบริหารจัดการโครงการด้านไอที การพัฒนาระบบและ
ซอฟต์แวรแ์ ละใช้กากับตดิ ตามการดาเนนิ งานในการพฒั นาระบบสารสนเทศ

สานักส่งเสริมอุตสาหกรรมเทคโนโลยีสารสนเทศและการส่ือสาร กระทรวงเทคโนโลยีสารสนเทศ
และการสื่อสาร เป็นหน่วยงานที่รับผิดชอบในการส่งเสริมอุตสาหกรรมเทคโนโลยีสารสนเท ศและการ
ส่ือสาร ตระหนักถึงความสาคัญในการส่งเสริมให้หน่วยงานภาครัฐพัฒนาองค์กร ให้มีกระบวนการพัฒนา
ซอฟต์แวร์เป็นไปตามมาตรฐานสากล สามารถตรวจรับงานในกระบวนการพัฒนาซอฟต์แวร์ได้อย่างมี
ประสิทธิภาพ ในการนี้ จึงได้จัดทาคู่มือฉบับนี้ข้ึนเพ่ือเผยแพร่ความรู้ ความเข้าใจในกระบวนการพัฒนา
ซอฟต์แวร์ตามมาตรฐาน ISO/IEC 29110 โดยหวังเป็นอย่างยิ่งว่าคู่มือฉบับนี้จะเป็นประโยชน์ต่อหน่วยงาน
ภาครัฐ เพื่อนาไปปรับปรุงกระบวนการดาเนินงานขององค์กรและยกระดับกระบวนการพัฒนาซอฟต์แวร์สู่
มาตรฐาน ISO/IEC 29110

สานกั ส่งเสริมอตุ สาหกรรมเทคโนโลยสี ารสนเทศและการส่ือสาร
กระทรวงเทคโนโลยีสารสนเทศและการส่ือสาร

คู่มือปฏิบตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครฐั หนา้
1–1
สารบญั 1–5
1–8
บทท่ี 1 มาตรฐาน ISO/IEC 29110
1.1 ประวตั คิ วามเป็นมาของมาตรฐาน ISO/IEC 29110 2–1
1.2 มาตรฐาน ISO/IEC 29110 2–1
1.3 ประโยชนข์ องมาตรฐาน ISO/IEC 29110 และการนาไปใช้ 2–2
2–3
บทที่ 2 ขั้นตอนการบริหารจัดการโครงการ (Project Management) 2–15
2.1 วตั ถุประสงค์ 2–17
2.2 ขอบเขตกระบวนการ
2.3 นยิ าม 3–1
2.4 ข้ันตอนการทางาน 3–1
2.5 ผังการไหลของกระบวนการบริหารจัดการโครงการ 3–2
2.6 เอกสารอา้ งองิ และสง่ิ ทเ่ี กี่ยวข้อง 3–3
3–21
บทท่ี 3 ข้ันตอนการพฒั นาระบบและซอฟต์แวร์ 3–23
(System & Software Implementation)
3.1 วัตถปุ ระสงค์ 4-1
3.2 ขอบเขตของกระบวนการ 4-5
3.3 นิยาม
3.4 ข้นั ตอนการทางาน
3.5 ผังการไหลของกระบวนการพัฒนาระบบและซอฟต์แวร์
3.6 เอกสารอ้างอิงและสง่ิ ท่เี กี่ยวขอ้ ง

บทที่ 4 การนามาตรฐาน ISO/IEC 29110 มาประยุกตใ์ ช้ในหน่วยงาน
4.1 สาหรับหนว่ ยงานที่พัฒนาเอง
4.2 สาหรับหนว่ ยงานทใี่ ชต้ รวจรับการจดั ซอื้ จดั จา้ ง

ภาคผนวก ก เอกสารอา้ งอิงและสงิ่ ท่เี กี่ยวข้องในข้นั ตอนการบริหารจดั การโครงการ
(Project Management)
- Proj_Statement_of_Work (ขอบเขตของโครงการ)
- Proj_Project_Plan (แผนการดาเนนิ โครงการ)
- Proj_Meeting_Report (รายงานการประชุม)
- Proj_Verification_Result (บนั ทึกการตรวจสอบตามข้อกาหนดของมาตรฐาน)
- Proj_Progress_Report (รายงานความก้าวหนา้ ของโครงการ)
- Proj_Service_Desk_Request (บันทึกขอเปลี่ยนแปลงความตอ้ งการ)

คู่มือปฏิบตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครฐั

- Proj_Correction_Register (เอกสารสรุปปญั หาท่พี บระหวา่ งดาเนินโครงการ)
- Proj_Acceptance_Record (บนั ทึกการสง่ มอบงาน)
ภาคผนวก ข เอกสารอา้ งอิงและสิ่งทเ่ี กี่ยวขอ้ งในขัน้ ตอนการพัฒนาระบบและซอฟต์แวร์
(Software Implementation)
- Proj_Project_Plan (แผนการดาเนนิ โครงการ)
- Proj_Validation_Result (บันทึกการยนื ยันความต้องการกบั ผูใ้ ช้งาน)
- Proj_Requirement_Spec (เอกสารสรปุ ความตอ้ งการของระบบงาน)
- Proj_Verification_Result (บันทึกการตรวจสอบตามข้อกาหนดของมาตรฐาน)
- Proj_SystemSoftware_Design (เอกสารการออกแบบระบบ)
- Proj_Traceability_Record (เอกสารบนั ทึกการตรวจสอบย้อนกลบั ของระบบ)
- Proj_Test_Cases (เอกสารแสดงตวั อย่างชุดข้อมลู ที่ใช้ทดสอบ)
- Proj_Service_Desk_Request (บันทกึ ขอเปลย่ี นแปลงความตอ้ งการ)
- Proj_Software_Component (เอกสารแสดงส่วนประกอบต่างๆ ของโปรแกรม)
- Proj_Test_Report (บันทึกผลการทดสอบระบบ)
- Proj_Admin_Manual (เอกสารคู่มอื ปฏิบัติงานสาหรบั ผดู้ แู ลระบบ)
- Proj_User_Manual (เอกสารคมู่ อื การใช้งานสาหรบั ผ้ใู ช้)
- Proj_Maintenance_Document (เอกสารค่มู ือการบารงุ รักษาระบบ)
ภาคผนวก ค ตวั อย่างเอกสารข้อกาหนดขอบเขต (Term of Reference)

คู่มือปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครัฐ

สารบญั ตาราง

ตารางที่ 2-1 คานิยามและความหมายที่เก่ยี วขอ้ ง หน้า
ตารางที่ 2-2 แนวทางในการวางแผนโครงการ (Project Planing) ตามมาตรฐาน ISO/IEC 29110 2–2
ตารางที่ 2-3 แนวทางในการดาเนินการตามแผนของโครงการ (Project Plan Execution) 2–5
2–9
ตามมาตรฐาน ISO/IEC 29110
ตารางที่ 2-4 แนวทางในการประเมินและควบคมุ โครงการ (Project Assessment and Control) 2–12

ตามมาตรฐาน ISO/IEC 29110 2–13
ตารางที่ 2-5 แนวทางในการสนิ้ สุดหรือปดิ โครงการ (Project Closure) ตามมาตรฐาน ISO/IEC 29110 2–15
ตารางที่ 2-6 ผังการไหลของกระบวนการบริหารจดั การโครงการ 3–2
ตารางท่ี 3-1 คานิยามและความหมายทเ่ี กีย่ วขอ้ ง 3–4
ตารางท่ี 3-2 แนวทางในการเรม่ิ การพฒั นาซอฟตแ์ วร์ (Software Implementation Initiation)
3–5
ตามมาตรฐาน ISO/IEC 29110
ตารางที่ 3-3 แนวทางในการวิเคราะห์ความต้องการของซอฟต์แวร์ (Software Requirement Analysis) 3–8

ตามมาตรฐาน ISO/IEC 29110 3–12
ตารางที่ 3-4 แนวทางในการออกแบบสถาปัตยกรรมและการออกแบบซอฟต์แวร์ 3–15

(Software Architecture Design) ตามมาตรฐาน ISO/IEC 29110 3–19
ตารางท่ี 3-5 แนวทางในการพัฒนาซอฟตแ์ วร์ (Software Construction) ตามมาตรฐาน ISO/IEC 29110 3–21
ตารางท่ี 3-6 แนวทางในการทดสอบการเชื่อมโยงระบบและซอฟตแ์ วร์ (System & Software

Integration Test) ตามมาตรฐาน ISO/IEC 29110
ตารางที่ 3-7 แนวทางในการสง่ มอบซอฟต์แวร์ (Product Delivery) ตามมาตรฐาน ISO/IEC 29110
ตารางที่ 3-8 ผงั การไหลของกระบวนการพัฒนาระบบและซอฟตแ์ วร์

คมู่ ือปฏบิ ัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครัฐ

สารบัญภาพ

ภาพที่ 1-1 โครงสรา้ งของ Sub Committee 7 หน้า
ภาพท่ี 1-2 Quality Standard Repository ของ ISO/IEC ดา้ น Software 1–2
ภาพท่ี 1-3 ประกาศกระทรวงอุตสาหกรรม มาตรฐานเลขที่ มอก. 29110 1–3
ภาพที่ 1-4 มาตรฐานสากล ISO/IEC 29110 Profile 1–4
ภาพที่ 1-5 Basic profile guide processes 1–5
ภาพท่ี 2-1 Project Management Process 1–6
ภาพท่ี 2-2 Project Management Process (Apply) 2-3
ภาพท่ี 3-1 Software Implementation Process 2-14
ภาพที่ 3-2 System and Software Implementation Process 3–3
ภาพที่ 4-1 แสดงข้ันตอนการนาไปใช้สาหรับหนว่ ยงานทพ่ี ัฒนาเอง 3–20
ภาพที่ 4-2 ขน้ั ตอนการนาไปใช้สาหรบั หนว่ ยงานทใ่ี ช้ตรวจรบั การจัดซือ้ จดั จ้าง 4-2
4-6

คูม่ อื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครฐั

บทท่ี 1
มาตรฐาน ISO/IEC 29110

1.1 ประวตั คิ วามเปน็ มาของมาตรฐาน ISO/IEC 29110
กลไกสาคัญในการพัฒนาอุตสาหกรรมซอฟต์แวร์ ได้ให้ความสาคัญในการพัฒนากระบวนการและ

การควบคุมคุณภาพของกระบวนการ ให้ตรงตามหลักเกณฑ์สากลท่ีได้กาหนดขึ้นร่วมกัน อันนาไปสู่
กระบวนการมาตรฐานกลาง เพื่อสื่อสารแลกเปลี่ยนการทางานในแต่ละขั้นตอนร่วมกัน มาตรฐานซอฟต์แวร์
จะผลักดันให้องค์กรมีกระบวนการพัฒนาและบริหารที่ชัดเจนและครอบคลุมการทางานในทุกๆ ด้านรวมถึง
ช่วยสร้างความสาเร็จในโครงการ ด้วยการบริหารความเส่ียงและสร้างกระบวนการบริหารท่ีเป็นระบบ
มาตรฐานซอฟต์แวร์ยังระบุถึงการพัฒนาด้านบุคลากร โดยกาหนดบทบาทและหน้าที่ของบุคลากรในกิจกรรม
ตา่ งๆ ทางดา้ นวศิ วกรรมซอฟต์แวร์อยา่ งชัดเจน การปฏิบัติงานตามกระบวนการที่กาหนดไว้ในมาตรฐานทาให้
เกดิ ประสิทธภิ าพในการทางานรว่ มกนั และสรา้ งความรว่ มมือในระดับองคก์ รใหเ้ กิดข้นึ ได้

วิวัฒนาการด้านมาตรฐานซอฟต์แวร์ของประเทศไทย ได้พัฒนาจนเป็นที่ยอมรับในระดับสากลจาก
การที่นักวิชาการของประเทศไทย เป็นผ้รู ิเริม่ การพัฒนามาตรฐานวิศวกรรมซอฟต์แวร์สาหรับองค์กรขนาดเล็ก
หรือ SME จากมาตรฐานไทย TQS (Thai Quality Software) จนสามารถขยายผลเปน็ ตน้ แบบของ มาตรฐาน
ISO/IEC 29110 Software Engineering Lifecycle Profiles for Very Small Entities (VSEs) ได้ในท่ีสุด
มปี ระวตั คิ วามเปน็ มา ดังน้ี

(1) ปี พ.ศ. 2542 เริ่มมีกระบวนการทางด้านวิศวกรรมซอฟต์แวร์ในประเทศไทย โดยมีการนา
มาตรฐาน CMM เข้ามาเผยแพรใ่ นประเทศ

(2) ปี พ.ศ. 2543 มีการจัดฝึกอบรม Lead Assessor สาหรับประเมิน CMM และมีโครงการเข้า
รว่ มประเมินเบือ้ งต้น 3 บริษทั โดยมบี รษิ ัทท่ีผ่านเพยี ง 1 บรษิ ัท ขอถอนตวั 1 บริษัท และยกเลิก 1 บรษิ ทั

(3) ปี พ.ศ. 2544 ด้วยความร่วมมือจากสถาบันคีนัน และผู้เชี่ยวชาญทางด้านวิศวกรรมซอฟต์แวร์
ท้ังในประเทศและต่างประเทศได้พัฒนามาตรฐาน TQS (Thai Quality Software) เพื่อให้เกิดการพัฒนา
คุณภาพมาตรฐานข้นึ ในประเทศไทย โดยประยุกต์จากมาตรฐาน ISO/IEC 12207

(4) ปี พ.ศ. 2545 บรษิ ัทจานวนไม่น้อยกวา่ 40 บรษิ ัท ได้ผ่านการรับรองมาตรฐาน TQS โดยได้รับ
การสนับสนุนจากกรมส่งเสริมอุตสาหกรรม และทาง Software Park ให้การสนับสนุนกับบริษัททางด้าน
มาตรฐาน CMM

(5) ปี พ.ศ. 2546 สานักงานมาตรฐานผลิตภัณฑ์อุตสาหกรรม (สมอ.) ได้จัดตั้งคณะกรรมการ
วิชาการท่ี 967 วิศวกรรมซอฟตแ์ วรแ์ ละระบบขน้ึ เพื่อดูแลมาตรฐานในระดบั ชาติ

บทท่ี 1 มาตรฐาน ISO/IEC 29110 1-1

คูม่ ือปฏบิ ัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครัฐ

(6) ปี พ.ศ. 2547 มีการยกร่างมาตรฐานซอฟต์แวร์สาหรับองค์กรขนาดเล็ก VSE (Very Small
Enterprise) ระดับนานาชาติ และขับเคลื่อนให้เกิดมาตรฐานใหม่ (New Work Item) โดยได้จัดตั้งกลุ่ม
WG 24 (Working Group ท่ี 24) ภายใต้ SC7 (Sub Committee 7) เพ่ือยกร่าง โดยมีประเทศไทยเป็น
ประธานกลุม่ (ภาพที่ 1-1)

ภาพที่ 1-1 โครงสร้างของ Sub Committee 7
(อ้างอิง Other WG/SC7 ของ www.center4vse.net)

มาตรฐาน ISO/IEC 29110 เป็นมาตรฐานด้านการพัฒนาซอฟต์แวร์ฉบับใหม่ของ ISO และถูก
ออกแบบมาให้รองรับกับกระบวนการในการพัฒนาซอฟต์แวร์ขององค์กรขนาดเล็ก มาตรฐานจึงถูกพัฒนาข้ึน
ในแนวคดิ การตัดทอนกระบวนการใหเ้ หลือเฉพาะกระบวนการท่ีจาเป็นเทา่ นั้น โดยนาต้นแบบมาจากมาตรฐาน
ISO/IEC 12207 ซงึ่ เปน็ มาตรฐานกระบวนการวัฏจกั รชวี ติ ขององค์กรขนาดใหญ่ (ภาพที่ 1-2)

บทที่ 1 มาตรฐาน ISO/IEC 29110 1-2

ค่มู ือปฏิบตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครฐั

ภาพท่ี 1-2 Quality Standard Repository ของ ISO/IEC ด้าน Software
(อา้ งอิง Standards published by ISO/IEC JTC 1/SC7)

(7) ปี พ.ศ. 2548 ประเทศไทยส่งผู้เช่ียวชาญเข้าร่วมในการประชุมระดับสากลของ ISO SC7 เพ่ือ
ทาการพัฒนามาตรฐาน ISO/IEC 29110 ทีป่ ระเทศอิตาลี

(8) ปี พ.ศ. 2549 ประเทศไทยเป็นเจ้าภาพในการจัดประชุม Conference ระดับสากลของ ISO
SC7 ท่กี รงุ เทพฯ เพ่ือยกร่างมาตรฐาน ซงึ่ เป็นการประชุมทม่ี ีนักวชิ าการและผ้สู นใจเขา้ รว่ มมากท่สี ุด

(9) ปี พ.ศ. 2550 มีการจัดฝึกอบรม Lead Assessor ตามมาตรฐาน ISO/IEC 15504 โดย Griffin
University, Australia จานวน 13 คน สาหรับการเป็นผู้ประเมินระดับสากล ภายใต้การดูแลของ
คณะกรรมการวชิ าการที่ 967 สานักงานมาตรฐานผลติ ภณั ฑอ์ ตุ สาหกรรม

(10) ปี พ.ศ. 2551 มีบริษัทผ่านการประเมินมาตรฐาน TQS ด้วยมาตรฐานการประเมิน ISO/IEC
15504 จานวน 81 ราย โดยได้รับการสนับสนุนจากสานักงานส่งเสริมอุตสาหกรรมซอฟต์แวร์แห่งชาติ
(องคก์ ารมหาชน) และสภาอตุ สาหกรรมแหง่ ประเทศไทย

(11) ปี พ.ศ. 2552 มาตรฐาน ISO/IEC 29110 มีการยกร่างสุดท้ายเป็น FDIS (Final Draft
International Standard) และ FPDTR ในขณะเดยี วกันมบี รษิ ัทมากกวา่ 50 ราย ยื่นขอการสนับสนุนเข้ารับ
การประเมินตามกระบวนการมาตรฐาน ISO/IEC 29110 และมีการส่งเสริมการใช้มาตรฐาน ISO/IEC 29110
ให้เป็นมาตรฐานกลาง สาหรับ 17 ประเทศในกลุ่ม APEC เพ่ือส่งเสริมและพัฒนาความร่วมมือในการพัฒนา

บทที่ 1 มาตรฐาน ISO/IEC 29110 1-3

คู่มอื ปฏบิ ัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหน่วยงานภาครัฐ

ธุรกิจซอฟต์แวร์สาหรับ SME และ Micro Enterprises ซ่ึงเป็นโครงการต้นแบบพัฒนาโดย มูลนิธิสถาบันเพ่ือ
พฒั นานวัตกรรมสนบั สนุนงบประมาณโดย APEC ในการใหค้ วามรู้และความเข้าใจ ในกระบวนการและการนา
วศิ วกรรมซอฟต์แวรแ์ ละระบบไปประยุกต์ใช้ เหมาะสมกับการพัฒนาองค์กร มุ่งเน้น 3 ประเทศ ได้แก่ จีน ซิลี
มาเลเซยี เพ่มิ เติมจากประเทศไทยซึ่งเป็นประเทศต้นแบบมาตรฐาน ISO/IEC 29110

(12) ปี พ.ศ. 2553 มาตรฐาน ISO/IEC 29110 ประกาศใช้เป็นมาตรฐานสากล International
Standard และตั้งแต่นั้นจนถึงปัจจุบันมีบริษัทจานวนไม่น้อยขอรับการสนับสนุนการตรวจประเมินตาม
กระบวนการมาตรฐาน ISO/IEC 29110 จากสานักงานส่งเสริมอุตสาหกรรมซอฟต์แวร์แห่งชาติ (องค์การ
มหาชน) และ สภาอุตสาหกรรมแห่งประเทศไทย

(13) ปี พ.ศ. 2554 มีการทาบันทึกความร่วมมือระหว่างสานักงานปลัดกระทรวงเทคโนโลยี
สารสนเทศและการส่ือสาร สานักงานมาตรฐานผลิตภัณฑ์อุตสาหกรรม สานักงานส่งเสริมอุตสาหกรรม
ซอฟต์แวร์แห่งชาติ (องค์การมหาชน) และมูลนิธิสถาบันเพ่ือพัฒนานวัตกรรม เพื่อผลักดันมาตรฐาน ISO/IEC
29110 ให้เป็นไปในเชงิ บรู ณาการอยา่ งเป็นระบบและตอ่ เนื่อง

(14) ปี พ.ศ. 2557 มาตรฐาน ISO/IEC 29110 ในการประชุมท่ีประเทศเปรู มีการยกร่างและ
พัฒนามาตรฐานที่เกี่ยวข้องกับ System เพิ่มเติมเข้าไป และประเทศไทยได้นามาตรฐาน ISO/IEC 29110
มาประกาศใช้ในราชกิจจานุเบกษา เป็นมาตรฐานผลิตภัณฑ์อุตสาหกรรม มอก. 29110 โดยกระทรวง
อตุ สาหกรรม (ภาพท่ี 1-3)

ภาพท่ี 1-3 ประกาศกระทรวงอุตสาหกรรม มาตรฐานเลขท่ี มอก. 29110 1-4
บทที่ 1 มาตรฐาน ISO/IEC 29110

คมู่ อื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หน่วยงานภาครฐั

(15) ปี พ.ศ. 2558 มาตรฐาน ISO/IEC 29110 ในการประชุมที่ประเทศบราซิล คณะทางาน
ดาเนินการปรับปรุงมาตรฐานเดิมและแนวทางในการพัฒนาให้มาตรฐานสอดคล้องกับการประเมินต ามความ
ต้องการของตลาด โดยมีกลุ่มประเทศยุโรปและลาตินอเมริกาเป็นผู้นา อีกท้ังได้ตั้งคณะทางานย่อยในการ
ยกร่างและพัฒนามาตรฐาน System และ Service เพ่ิมเติมจากเดิมท่ีได้สาเร็จไปแล้วจากการประชุม
ทปี่ ระเทศเปรู โดยมีประเทศแคนาดาและสหรฐั อเมริกาเป็นผู้นา

1.2 มาตรฐาน ISO/IEC 29110
มาตรฐาน ISO/IEC 29110 ในปัจจุบันมีด้วยกัน 4 ระดับ คือ 1. Entry Profile 2. Basic Profile

3. Intermediate Profile และ 4. Advanced Profile (ภาพท่ี 1-4)

Advanced Profile

Intermediate Profile

Basic Profile

ภาพที่ 1-5 มาตรฐานสากล ISO/IEC 29110 Profile

Entry Profile

ภาพท่ี 1-4 มาตรฐาน ISO/IEC 29110 Profile

มาตรฐาน ISO/IEC 29110 ที่ประกาศใช้ในปัจจุบันคือระดับ Basic Profile เป็นมาตรฐานสากล
ทช่ี ่วยในการปรบั ปรุงกระบวนการทางานอยู่ในระดับของ Basic ซ่ึงเหมาะกับการนาไปใช้ในการบริหารจัดการ
และดาเนินโครงการ สาหรับบรษิ ทั หรือองค์กรท่ีมีขนาดเล็ก (VSEs, Very Small Entities) ในที่น้ีหมายรวมถึง
หนว่ ยงาน หรอื โครงการท่ีมีจานวนคนไม่เกิน 25 คน แต่หลังจากท่ีได้ประกาศใช้กลุ่มประเทศลาตินอเมริกาได้
แจ้งกบั ทางผ้พู ฒั นามาตรฐานวา่ ไม่สามารถท่ีจะนามาตรฐาน ISO/IEC 29110 ในระดับ Basic Profile มาใช้ได้
เนอ่ื งจากยงั มีเน้ือหารายละเอียดท่ีมากอยู่ ดังนั้นทางผู้พัฒนามาตรฐานได้ดาเนินการพัฒนามาตรฐานในระดับ
Entry Profile เพิ่มเติม เพื่อให้ทางกลุ่มประเทศลาตินอเมริกาสามารถนาไปใช้ได้ แต่ยังอยู่ในขั้นตอนการ
พฒั นาไปพรอ้ มๆ กบั มาตรฐานในระดับ Intermediate Profile และ ระดับ Advanced Profile

บทที่ 1 มาตรฐาน ISO/IEC 29110 1-5

คมู่ ือปฏบิ ตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรบั หน่วยงานภาครฐั

มาตรฐาน ISO/IEC 29110 ระดบั Basic Profile จะมุ่งเน้นไปที่ 2 กระบวนการหลักๆ ดังน้ี (ภาพที่ 1-5)
1. Project Management (PM) Process
2. Software Implementation (SI) Process

ภาพที่ 1-5 Basic profile guide processes
(อ้างอิง Basic profile guide processes ของ ISO/IEC 29110)

1.2.1 Project Management (PM) Process เป็นกระบวนการที่ใช้ในการวางแผนการดาเนิน
โครงการ การจัดการทรพั ยากรที่จาเป็นต้องใช้ในโครงการ การควบคุมภาพรวมของโครงการ การติดตามความ
คืบหน้าของโครงการเมอ่ื เปรยี บเทียบกับแผนท่ไี ด้วางไว้ รวมถงึ การปรับเปล่ียนแผนการต่างๆ เพื่อให้เหมาะสม
กับการดาเนินโครงการ โดยต้องคานึงถึงเรื่องการส่งงานตามข้อกาหนดให้ได้ภายในระยะเวลาดาเนินโครงการ
ตามกระบวนการมาตรฐานไดม้ ีการกาหนดวัตถุประสงคใ์ นการดาเนินการ 7 ขอ้ ดังนี้

(1) PM.O1 แผนการดาเนินโครงการ (Project Plan) ท่ีใช้ในการดาเนินโครงการต้องสร้าง
มาจากขอบเขตของโครงการ (Statement of Work) และจะต้องนาไปให้ผู้ใช้งานพิจารณา โดยใน Project
Plan จะตอ้ งกาหนดกจิ กรรมตา่ งๆ ในการดาเนนิ งานพรอ้ มทรัพยากรท่จี าเป็น

(2) PM.O2 ความก้าวหน้าของโครงการ (Project Progress) จะต้องถูกตรวจสอบ
เปรียบเทียบกบั Project Plan โดยจัดทาเปน็ รายงานความก้าวหน้าของโครงการ (Progress Status Record)
เมื่อพบปัญหาระหว่างดาเนินโครงการจะต้องแก้ไขปัญหาเพื่อให้งานสามารถดาเนินต่อไป ในการปิดโครงการ
จะต้องไดร้ บั การยอมรับงานจากผใู้ ช้ โดยการจดั ทาเอกสารการสง่ มอบงาน (Acceptance Record)

(3) PM.O3 การขอเปล่ียนแปลงความต้องการ (Change Requests) ที่ได้จากผู้ใช้จะต้อง
นามาวิเคราะห์หาผลกระทบต่อความต้องการของซอฟท์แวร์ (Software Requirements) เพ่ือประเมินหา
ค่าใช้จา่ ย และระยะเวลาทดี่ าเนินการ

บทที่ 1 มาตรฐาน ISO/IEC 29110 1-6

คู่มอื ปฏิบัตติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครัฐ

(4) PM.O4 การทบทวนการประชุม (Review Meetings) มีการจัดทารายงานการประชุม
ท้ังท่ีเป็นการประชุมภายใน และประชุมรว่ มกับผใู้ ช้งาน

(5) PM.O5 ความเส่ยี ง (Risk) มีการประเมินความเสยี่ งในการทาโครงการ และติดตามความ
เสย่ี งทจ่ี ะเกดิ ระหวา่ งดาเนนิ โครงการ

(6) PM.O6 กลยุทธ์ในการควบคุมเวอร์ช่ันของซอฟต์แวร์ (Software Version Control
Strategy) จะต้องกาหนดวิธีการให้ชัดเจน เมื่อมีการเปล่ียนแปลงเกิดขึ้น จะต้องมีการควบคุมให้พร้อมที่จะ
นาไปใชง้ านต่อได้

(7) PM.O7 การรับประกันคุณภาพของซอฟต์แวร์ (Software Quality Assurance) เพ่ือให้
แน่ใจวา่ Work Products และกระบวนการทางานเป็นไปตาม Project Plan และ Requirements

1.2.2 Software Implementation (SI) Process เป็นกระบวนการที่ใช้ในการดาเนินงานโดย
อา้ งองิ ตามแผนทีไ่ ด้จาก Project Management Process ซงึ่ จะเป็นแนวทางในการดาเนินงาน ท้ังในส่วนของ
การวิเคราะห์ความต้องการของระบบ การออกแบบระบบ การพัฒนาระบบงานตามท่ีได้ออกแบบไว้ รวมถึง
การทดสอบการใช้งาน และการส่งมอบงานให้ลูกค้า ซ่ึงตามกระบวนการมาตรฐานได้กาหนดวัตถุประสงค์ใน
การดาเนินการ 7 ขอ้ ดังนี้

(1) SI.O1 กิจกรรมต่างๆ (Task) ที่ดาเนินการจะต้องดาเนินการตาม Project Plan
ตัวปัจจบุ ัน

(2) SI.O2 ความต้องการของซอฟต์แวร์ (Software Requirements) ที่ถูกกาหนดและผ่าน
การวเิ คราะหเ์ พ่อื ความถูกต้อง และต้องได้รบั การพจิ ารณาเหน็ ชอบจากผใู้ ชง้ าน

(3) SI.O3 การออกแบบสถาปัตยกรรมและรายละเอียดของซอฟต์แวร์ (Software
architecture and detailed design) จะต้องอธิบายถึงรายละเอียดของ Software Components และ
แนวทางในการเชื่อมต่อกับงานอื่นๆ โดยจะต้องสอดคล้องกับ Software Requirements ผ่านความเห็นชอบ
จากผู้ใช้งาน

(4) SI.O4 องค์ประกอบของซอฟต์แวร์ (Software Components) ที่พัฒนาข้ึนจะต้องผ่าน
การทดสอบ (Unit Test) ว่าสอดคลอ้ งกบั Software Requirements และ Software Design

(5) SI.O5 ซอฟต์แวร์ (Software) ที่ได้จากการรวบรวม Software Components
เขา้ ด้วยกนั จะตอ้ งนามาทดสอบโดยใช้ Test Cases and Test Procedures และจะต้องบันทึกผลการทดสอบ
ใน Test Report เม่ือพบข้อผิดพลาดจากการทดสอบจะตอ้ งทาการแก้ไขให้ถกู ตอ้ ง

(6) SI.O6 Software Configuration มีการจัดทาคู่มือสาหรับผู้ใช้ คู่มือสาหรับผู้ดูแล
และค่มู อื การบารงุ รักษา เมื่อมกี ารขอเปลย่ี นแปลงความต้องการจะต้องนา Change Request มาบนั ทกึ

(7) SI.O7 Verification and Validation มีการตรวจสอบกระบวนการทางานและ Work
Products ต่างๆ โดยผลการตรวจสอบจะจัดทาเป็น Verification Result และการยืนยันความต้องการ
กบั ผู้ใชง้ าน โดยจัดทาเปน็ Validation Result เม่อื พบขอ้ บกพร่องกต็ อ้ งดาเนนิ การแกไ้ ขให้ถูกต้อง

บทที่ 1 มาตรฐาน ISO/IEC 29110 1-7

คู่มอื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครัฐ

1.3 ประโยชนข์ องมาตรฐาน ISO/IEC 29110 และการนาไปใช้
การนากระบวนการทางวิศวกรรมซอฟต์แวร์มาประยุกต์ใช้ในการ ดาเนินโครงการตามมาตรฐาน

ISO/IEC 29110 ไม่ว่าจะใช้ภายในองค์กรเอง หรือระหว่างองค์กร จะทาให้มีข้อมูลไปในทิศทางเดียวกัน
ท้งั ทีมงาน และผู้ทีเ่ กี่ยวขอ้ งกบั โครงการท้ังทางตรงและทางอ้อม ทาให้สามารถบริหารโครงการให้เสร็จส้ินตาม
ความตอ้ งการของผู้ใช้งาน โดยอยู่ในกรอบของระยะเวลาทไี่ ด้วางแผนไว้ โดยสามารถแบ่งไดด้ ังน้ี

1.3.1 เพ่อื ใหบ้ ุคลากรทเ่ี ก่ียวขอ้ งกับกระบวนการพัฒนาระบบสารสนเทศ เข้าใจในแนวทางเก่ียวกับ
มาตรฐาน ISO/IEC 29110

1.3.2 เขา้ ใจบทบาทและหน้าที่ความรับผิดชอบของตนเองอย่างชัดเจน สามารถปฏิบัติงานได้อย่าง
มีประสทิ ธภิ าพ

1.3.3 เข้าใจการทางานในแต่ละขั้นตอน ทาให้เกิดประสิทธิภาพในการดาเนินงาน รวมถึงสามารถ
ทดแทนกนั ไดใ้ นบางหนา้ ท่ี

1.3.4 มีรูปแบบของการสรุปความต้องการท่ีชัดเจน ลดข้อขัดแย้งและประเด็นปัญหาระหว่าง
เจ้าของระบบงานและผูพ้ ัฒนาระบบงาน

1.3.5 เพ่อื ใหโ้ ครงการตา่ งๆ ท่ีเกี่ยวข้องกบั กระบวนการพัฒนาระบบสารสนเทศ มีเอกสารท่ีสมบูรณ์
ครบถ้วน เพียงพอที่จะดูแลรักษาระบบให้ใช้งานได้อย่างมีประสิทธิภาพ รวมถึงสามารถพัฒนาระบบงาน
เพ่มิ เตมิ ต่อไปได้

1.3.6 เพื่อกาหนดรูปแบบของเอกสารต่างๆ ที่จาเป็นต้องใช้งาน และนาไปใช้กับทุกโครงการ
ทเ่ี กี่ยวข้องกบั การพฒั นาระบบสารสนเทศ

1.3.7 เพื่อให้สามารถวิเคราะห์และประเมินระยะเวลาในการดาเนินโครงการได้อย่างถูกต้อง
เหมาะสม รวมถึงสามารถตดิ ตามความก้าวหน้าของงานได้

1.3.8 สามารถกาหนดแนวทางหรือนโยบายเกี่ยวกับการพัฒนาระบบสารสนเทศได้อย่างเหมาะสม
กบั องค์กร

1.3.9 ได้ทีมงานทม่ี ีมาตรฐาน ในการดาเนนิ โครงการ มาเป็นผ้รู บั งาน
1.3.10 สามารถติดตามความคืบหน้าของโครงการ และตรวจสอบความถูกต้องเหมาะสมของ
กระบวนการได้อยา่ งมีหลกั การเป็นขั้นเปน็ ตอน

บทท่ี 1 มาตรฐาน ISO/IEC 29110 1-8

คู่มือปฏิบัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหน่วยงานภาครัฐ

บทที่ 2
ขัน้ ตอนการบริหารจัดการโครงการ

(Project Management)

2.1 วตั ถุประสงค์
ข้ันตอนการบริหารจัดการโครงการ เป็นข้ันตอนท่ีใช้เพ่ือกาหนดแนวทางข้ันตอนและผู้รับผิดชอบ

รวมถึงเอกสารอ้างอิงและสิ่งท่ีเกี่ยวข้อง (Artifacts) ในการบริหารจัดการโครงการ เพื่อให้มีรายละเอียดในการ
บริหารจัดการและติดตามความคืบหน้าของโครงการได้อย่างมีประสิทธิภาพ สอดคล้องกับนโยบายและ
วัตถปุ ระสงคห์ ลกั ของโครงการ โดยขน้ั ตอนน้ีจะมีขอบขา่ ยขั้นตอนตา่ ง ๆ

2.2 ขอบเขตกระบวนการ
ขอบเขตของข้ันตอนในกระบวนการบริหารจัดการโครงการ เป็นกระบวนการพัฒนาระบบและ

ซอฟต์แวร์ ซ่งึ ประกอบไปด้วยข้นั ตอนต่างๆ ดงั ต่อไปน้ี
2.2.1 การพิจารณาและกาหนดขอบเขตของโครงการ (Statement of Work - SOW)
ข้ันตอนนี้เป็นการนาสาระสาคัญของข้อกาหนดในสัญญาการจัดซื้อจัดจ้างของโครงการ

(TOR) หรือใบส่ังจ้าง ตามระเบียบราชการหรือระเบียบองค์กร ประกอบกับสาระสาคัญของข้อเสนอของโครงการ
มาใชใ้ นการวางแผนและบริหารจัดการโครงการ

2.2.2 การวางแผนบรหิ ารโครงการ (Project Plan) มรี ายละเอียดตา่ งๆ ดงั ตอ่ ไปน้ี
(1) กาหนดการทางาน และการกาหนดทรัพยากรที่เหมาะสม (Project Scheduling

and Resources Allocation)
(2) แผนการส่งมอบและงวดเงิน (Payment Scheduling)
(3) แผนบริหารจัดการผู้ใหบ้ ริการและทรัพยากร (Resource Plan)
(4) กระบวนการบรกิ าร IT (IT Service Desk)
(5) การจัดเก็บเอกสาร สาระสาคัญของโครงการ และระบบคุณภาพ (Project

Infrastructure, Repository & Quality Management System)
2.2.3 การติดตาม (Tracking) หาทางเลือก (Solution Finding) และการยกระดับความเข้มข้น
(Escalation)
เพ่ือใหโ้ ครงการสามารถตดิ ตามและบรหิ ารจัดการการเปลย่ี นแปลง โดยการหาแนวทางทั้ง

ภายใต้และภายนอกกรอบของโครงการ หรือให้บรรลุวัตถุประสงค์ของโครงการ ซึ่งการบริหารจัดการ
การเปลี่ยนแปลงจะต้องมีกรอบแนวทางความรับผิดชอบของการแก้ไขปัญหาในแต่ละระดับของปัญหา หรือการ
ยกระดับความเข้มข้นของการแก้ไขปัญหา (Escalation) ให้สอดคล้องกับแนวทางในการปฏิบัติของภาครัฐซ่ึง
กาหนดหนา้ ที่ และขอบเขตการรับผดิ ชอบและอานาจการตัดสินใจไวช้ ดั เจน

บทที่ 2 ขนั้ ตอนการบรหิ ารจดั การโครงการ 2-1

ค่มู อื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หน่วยงานภาครฐั

2.2.4 การควบคมุ บันทกึ คุณภาพ (Quality Control)
กระบวนการบรหิ ารจัดการระบบปรับปรงุ กระบวนการ (Process Improvement)

ภายใตก้ รอบระบบคณุ ภาพ (Quality Process) ตามกรอบมาตรฐานสากล Plan-Do-Check-Act (PDCA)
ในระบบคุณภาพโดยทั่วไปในแตล่ ะขน้ั ตอนจะมรี ายละเอยี ดเปน็ ข้อกาหนด

2.3 นยิ าม

คานยิ ามและความหมายที่เกย่ี วขอ้ งมรี ายละเอยี ดตามตารางท่ี 2-1

ตารางที่ 2-1 คานยิ ามและความหมายท่ีเก่ยี วข้อง

คานยิ าม ความหมาย

เอกสารอ้างองิ และส่งิ ทีเ่ กย่ี วข้อง (Artifacts) เอกสารอา้ งอิงและสิ่งเก่ียวข้อง ท่ีจาเป็นสาหรับโครงการ

แบ่งได้หลายประเภทตามมาตรฐาน และข้อกาหนด

คุณภาพของโครงการนี้ เป็นเอกสารอ้างอิงและสิ่ง

เก่ียวข้องมีทั้งที่ต้องส่งมอบภายใต้กรอบของโครงการ

(Deliverable) และเอกสารอ้างอิงและสิ่งท่ีเกี่ยวข้องอื่นๆ

ที่ใช้เฉพาะภายในโครงการท่ีไม่ต้องส่งมอบ (Non-

deliverable)

ขอบเขตโครงการ (Statement of Work - SOW) เป็นเอกสารทางราชการที่สามารถอ้างอิงได้ถูกต้องตาม

และข้อกาหนดของสัญญาการจัดซ้ือจัดจ้างของ กระบวนการจัดซื้อ ผ่านขั้นตอนและกระบวนการจัดซื้อ

โครงการ (TOR) ตามระเบียบราชการ หรือข้อกาหนดองค์กร ซ่ึงควรมี

แผนการส่งมอบและงวดเงนิ (Payment Scheduling)

กระบวนการให้บรกิ าร IT (IT Service Desk) กระบวนการให้บริการ IT ซึ่งมุ่งเน้นการรองรับการ

เปล่ียนแปลง (Changes) ความต้องการ (Requests)

และประเด็น IT (Incident) ทเ่ี กิดขน้ึ

Project Manager (PM) ผู้บรหิ ารโครงการ

System Analyst (SA) นกั วิเคราะห์และออกแบบระบบงาน

Quality Assurance (QA) ผู้ควบคุมคุณภาพของการดาเนินการให้เป็นไปตาม

นโยบายของการพัฒนาระบบสารสนเทศ

Administrator (AM) ผูด้ ูแลระบบ

Work Team (WT) คณะทางานพัฒนาระบบสารสนเทศ

Customer (Cus) ผูใ้ ชร้ ะบบ

บทที่ 2 ขนั้ ตอนการบรหิ ารจดั การโครงการ 2-2

คมู่ ือปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหน่วยงานภาครัฐ

2.4 ขัน้ ตอนการทางาน
กระบวนการบริหารจัดการโครงการ (Project Management) ตามมาตรฐาน ISO/IEC 29110 แบ่ง

ออกเป็นกระบวนการตา่ งๆ ได้ 4 กระบวนการ (ภาพที่ 2-1) ซึง่ มรี ายละเอียดดงั ตอ่ ไปน้ี

ภาพที่ 2-1 Project Management Process 2-3
(อา้ งองิ Project Management Process diagram ของ ISO/IEC 29110)

บทท่ี 2 ข้นั ตอนการบริหารจดั การโครงการ

คู่มอื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหน่วยงานภาครฐั

2.4.1 การวางแผนโครงการ (Project Planning)
เป็นกิจกรรมหลักของการบริหารจัดการ ตามมาตรฐาน ISO/IEC 29110 ได้จัดให้เป็น

ปัจจัยความสาคัญอันดับต้นๆ ในการบริหารจัดการเพ่ือระบบคุณภาพภายใต้กรอบมาตรฐานนี้ กระบวนการ
ดังกล่าวม่งุ เนน้ การบรหิ ารจดั การเพ่ือผลสาเร็จของการบรหิ ารจดั การโครงการ การบรหิ ารจดั การในองค์กรขนาดใด
กต็ าม สามารถนาไปประยกุ ตใ์ ช้ได้ เพอ่ื เป็นประโยชน์ในการวางแผน การดาเนินการ การติดตาม ปรับปรุงและการ
เรยี นรเู้ มอื่ สิน้ สุดโครงการ โดยกระบวนการต่างๆ เป็นไปตามหลักคุณภาพสากล องค์ประกอบหลักของการบริหาร
จัดการโครงการสากล (Project Management Institution - PMI) ประกอบไปด้วย 1. งานที่ต้องดาเนินการ
(Task) 2. ระยะเวลาท่ีต้องใช้ (Time) 3. กาหนดวันเริ่มต้น (Start) 4. เป้าหมายวันสิ้นสุด (End) และ 5. บุคลากร
ทม่ี ีคณุ สมบัตติ รงกบั งานทม่ี อบหมายให้ไปดาเนินการตามแผนที่กาหนดขน้ึ (Resource) เป็นสง่ิ ท่ีสาคญั ที่สดุ แม้ว่า
การพัฒนาซอฟต์แวร์ (Software Implementation) จะมรี ะบบวิศวกรรมซอฟตแ์ วร์อ้างอิง แต่รูปแบบการบริหาร
จดั การ และการติดตาม แต่ละโครงการ ภายใต้กรอบกาหนดของโครงการจะต้องนามาตรฐานสากลไปประยุกต์ใช้
ให้เหมาะสม ซ่งึ ตามมาตรฐาน ISO/IEC 29110 ไดก้ าหนดงานและหนา้ ทที่ ่ีเก่ยี วขอ้ ง อา้ งองิ ได้จากตารางท่ี 2-2

บทท่ี 2 ขัน้ ตอนการบริหารจดั การโครงการ 2-4

คู่มือปฏิบัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครฐั

ตารางท่ี 2-2 แนวทางในการวางแผนโครงการ (Project Planning) ตามมาตรฐาน ISO

บทบาท กจิ กรรมทดี่ าเนินการ

(Role) (Task List)

PM PM.1.1 Review the Statement of Work

SA

PM PM.1.2 Define with the Customer the Delivery Instructions of ea

CUS of the deliverables specified in the Statement of Work.

PM PM.1.3 Identify the specific tasks to be performed in order to p

SA the deliverables and their software components identified

Statement of Work. Include tasks in the SI process alon

verification, validation and reviews with Customer and Work

tasks to assure the quality of work products. Identify the ta

perform the Delivery Instructions. Document the Tasks.

PM PM.1.4 Establish the Estimated Duration to perform each task.

SA

PM PM.1.5 Identify and document the resources: human, m

SA equipment and tools, standards, including the required training

Work Team to perform the project. Include in the schedule the

when resources and training will be needed.

บทท่ี 2 ข้ันตอนการบริหารจดั การโครงการ

ฐ ผลลัพธ์ทีไ่ ด้
(Output Products)
O/IEC 29110 Statement of Work [reviewed]
เอกสารตง้ั ตน้

(Input Products)
Statement of Work

ach one Statement of Work [reviewed] Delivery Instructions

produce Statement of Work [reviewed] Tasks
in the

ng with
k Team
asks to

Tasks Estimated Duration

material, Statement of Work Resources
g of the
e dates

2-5

คมู่ อื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครฐั

บทบาท กจิ กรรมท่ีดาเนินการ

(Role) (Task List)

PM PM.1.6 Establish the Composition of Work Team assigning rol

SA responsibilities according to the Resources.

PM PM.1.7 Assign estimated start and completion dates to each

SA the tasks in order to create the Schedule of the Project Tasks

into account the assigned resources, sequence and depende

the tasks.

PM PM.1.8 Calculate and document the project Estimated Effort and

PM PM.1.9 Identify and document the risks which may affect the pro
SA
PM PM.1.10 Document the Version Control Strategy in the Project P
SA
PM PM.1.11 Generate the Project Plan integrating the elements prev

identified and documented.

บทที่ 2 ขน้ั ตอนการบริหารจดั การโครงการ

ฐ ผลลพั ธท์ ี่ได้
(Output Products)
เอกสารต้งั ตน้ Composition of Work Team
(Input Products)
les and Resources

one of Tasks Schedule of the Project Tasks
s taking Estimated Duration
ency of Composition of Work Team

d Cost. Schedule of the Project Tasks Estimated Effort and Cost
Resources

oject. All elements previously defined Identification of Project Risks

Plan. Version Control Strategy

viously Tasks Project Plan
Estimated Duration
Resources
Composition of Work Team
Schedule of the Project Task
Estimated Effort and Cost

2-6

ค่มู ือปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครัฐ

บทบาท กิจกรรมทด่ี าเนนิ การ
(Role) (Task List)

PM PM.1.12 Include product description, scope, objectives and
SA deliverables in the Project Plan.

PM PM.1.13 Verify and obtain approval of the Project Plan.
QA Verify that all Project Plan elements are viable and consistent. T

results found are documented in a Verification Results and corre
are made until the document is approved by PM.
PM PM.1.14 Review and accept the Project Plan.
CUS Customer reviews and accepts the Project Plan, making sure tha
Project Plan elements match with the Statement of Work.
AM PM.1.15 Establish the project repository using the Version Contro
PM Strategy.

บทที่ 2 ขั้นตอนการบริหารจดั การโครงการ

ฐ

เอกสารตง้ั ต้น ผลลัพธ์ที่ได้
(Input Products) (Output Products)
Identification of Project Risks
Version Control Strategy Project Plan
Delivery Instructions
Statement of Work Verification Results
(Product Description, Scope, Project Plan [verified]
Objectives and Deliverables)
Project Plan
The
ections

Project Plan [verified] Meeting Record
at the Project Plan [accepted]

ol Version Control Strategy Project Repository

2-7

คมู่ อื ปฏิบัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครัฐ

2.4.2 การดาเนนิ การตามแผนของโครงการ (Project Plan Execution)
เป็นกิจกรรมในการบริหารจัดการโครงการเพ่ือให้งานที่ดาเนินการเป็นไปตามแผน

การตดิ ตามการดาเนินการจะเป็นเครื่องมอื สอ่ื สารของโครงการใหท้ ราบอย่างท่วั ถงึ ครบถว้ นในความคืบหน้า ปัญหา
และอุปสรรคในการดาเนินการตามแผนของโครงการ การบันทึกรายละเอียดและสถิติที่ได้จากการดาเนินการจะ
เป็นดัชนีชี้วัดที่สาคัญในกิจกรรมต่างๆ ของโครงการ โดยมีรูปแบบและวิธีการท่ีหลากหลายในแต่ละประเภทของ
โครงการ ซ่ึงตามมาตรฐาน ISO/IEC 29110 ได้กาหนดงานและหนา้ ทที่ ่ีเกยี่ วขอ้ ง อ้างองิ ได้จากตารางท่ี 2-3

บทที่ 2 ข้นั ตอนการบรหิ ารจดั การโครงการ 2-8

คู่มือปฏบิ ัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรบั หน่วยงานภาครฐั

ตารางท่ี 2-3 แนวทางในการดาเนนิ การตามแผนของโครงการ (Project Plan Executio

บทบาท กจิ กรรมท่ีดาเนนิ การ

(Role) (Task List)

PM PM.2.1 Monitor the Project Plan execution and record actual

SA Progress Status Record.

WT

PM PM.2.2 Analyse and evaluate the Change Request for cost, sc

SA and technical impact.

The Change Request can be initiated externally by the Custo

internally by the Work Team. Update the Project Plan, if the ac

change does not affect agreements with Customer.

Change Request, which affects those agreements, needs to be

negotiated by both parties (see PM.2.4).

PM PM.2.3 Conduct revision meetings with the Work Team, i

SA problems, review risk status, record agreements and track th

WT closure

PM PM.2.4 Conduct revision meetings with the Customer,
CUS agreements and track them to closure.
SA Change Request initiated by Customer or initiated by Work
WT which affects the Customer, needs to be negotiated to

บทท่ี 2 ขั้นตอนการบริหารจดั การโครงการ

ฐ ผลลพั ธท์ ี่ได้
(Output Products)
on) ตามมาตรฐาน ISO/IEC 29110 Progress Status Record
เอกสารตง้ั ต้น

(Input Products)
data in Project Plan

chedule Change Request [initiated] Change Request [evaluated]
Project Plan Project Plan [updated]

omer or
ccepted

identify Project Plan Meeting Record [updated]
hem to Progress Status Record
Meeting Record [updated]
Correction Register Change Request [accepted]
Meeting Record Project Plan [updated]
record Project Plan
Progress Status Record 2-9
Team, Change Request [evaluated]
o reach Meeting Record

คู่มอื ปฏิบตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรบั หน่วยงานภาครัฐ

บทบาท กจิ กรรมที่ดาเนนิ การ

(Role) (Task List)

acceptance of both parties.

If necessary, update the Project Plan according to new agreeme

Customer.

AM PM.2.5 Perform backup according to the Version Control Strateg

PM

AM PM.2.6 Perform Project Repository recovery using the Project

PM Repository Backup, if necessary.

บทท่ี 2 ขั้นตอนการบรหิ ารจดั การโครงการ

ฐ ผลลัพธท์ ไี่ ด้
(Output Products)
เอกสารต้ังตน้
(Input Products) Project Repository Backup
Project Repository [recovered]
ent with

gy. Version Control Strategy

Project Repository Backup

2-10

คูม่ อื ปฏิบตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหน่วยงานภาครัฐ

2.4.3 การประเมนิ และควบคมุ โครงการ (Project Assessment and Control)
กิจกรรมนี้เป็นกิจกรรมต่อเนื่องที่สัมพันธ์กับกิจกรรมการดาเนินการตามแผนของ

โครงการ (2.4.2) โดยมแี ผนและผลของงานทแ่ี ล้วเสร็จเป็นดัชนีเปรียบเทียบ เพื่อใช้ประเมินโอกาสความสาเร็จของ
โครงการ ซง่ึ เปา้ หมายโดยทว่ั ไปของโครงการคือ การบรรลุวัตถุประสงค์ ตามความต้องการ ภายในระยะเวลา และ
งบประมาณท่ีกาหนด ซ่ึงเป็นปัญหาหลักของการจัดหาโครงการระบบและซอฟต์แวร์ จากสถิติผลสารวจของ
คณะทางาน WG24 ISO/IEC SC7 พบว่าโครงการระบบและซอฟต์แวร์มีอัตราความล่าช้าสูงถึงร้อยละ 50 ดังน้ัน
การประเมนิ และควบคมุ โครงการ จงึ มคี วามสาคัญต่อปัจจัยความสาเร็จของการบริหารจัดการวางแผน ดาเนินการ
ใหเ้ ป็นไปตามแผน ซึ่งตามมาตรฐาน ISO/IEC 29110 ได้กาหนดงานและหน้าที่ท่ีเก่ียวข้อง อ้างอิงได้จากตารางท่ี
2-4

บทท่ี 2 ขนั้ ตอนการบริหารจดั การโครงการ 2-11

ค่มู ือปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครัฐ

ตารางที่ 2-4 แนวทางในการประเมนิ และควบคมุ โครงการ (Project Assessment and

บทบาท กจิ กรรมทดี่ าเนนิ การ

(Role) (Task List)

PM PM.3.1 Evaluate project progress with respect to the Project Plan

SA comparing:

WT - actual tasks against planned tasks

- actual results against established project objectives

- actual resource allocation against planned resources

- actual cost against budget estimates

- actual time against planned schedule

- actual risk against previously identified

PM PM.3.2 Establish actions to correct deviations or problem

SA identified risks concerning the accomplishment of the pl

WT needed, document them in Correction Register and track th

closure.

PM PM.3.3 Identify changes to requirements and/or Project Plan to

SA address major deviations, potential risks or problems concerning

WT accomplishment of the plan, document them in Change Reques

track them to closure.

บทท่ี 2 ขนั้ ตอนการบริหารจดั การโครงการ

ฐ

d Control) ตามมาตรฐาน ISO/IEC 29110 ผลลัพธ์ท่ไี ด้
เอกสารตัง้ ตน้ (Output Products)
Progress Status Record
(Input Products) [evaluated]
n, Project Plan

Progress Status Record

ms and Progress Status Record Correction Register
lan, as [evaluated] Change Request [initiated]
hem to

Progress Status Record
g the [evaluated]
st and

2-12

คู่มอื ปฏิบัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครฐั

2.4.4 การสิน้ สดุ หรอื ปิดโครงการ (Project Closure)

เป็นกิจกรรมสุดท้ายเพ่ือปิดโครงการอย่างเป็นทางการ ซ่ึงเป็นการสอบทาน ตรวจสอบ

ปรับปรุงเอกสาร สาระสาคัญของผลงานของโครงการ และสรุปการเรียนรู้ที่ได้จากงานที่ทา เพ่ือปรับปรุงให้เกิด

ระบบคณุ ภาพที่ดีต่อองค์กรต่อไป ซึง่ ตามมาตรฐาน ISO/IEC 29110 ไดก้ าหนดงานและหน้าทีท่ ่ีเกีย่ วขอ้ ง อ้างอิงได้

จากตารางที่ 2-5

ตารางที่ 2-5 แนวทางในการสนิ้ สดุ หรอื ปดิ โครงการ (Project Closure) ตามมาตรฐาน ISO/IEC 29110

บทบาท กจิ กรรมทด่ี าเนินการ เอกสารตง้ั ตน้ ผลลัพธ์ทีไ่ ด้

(Role) (Task List) (Input Products) (Output Products)

PM PM.4.1. Formalize the completion of the Project Plan Acceptance Record

CUS project according to the Delivery Software Software

Instructions established in the Project Plan, Configuration[deli Configuration

providing acceptance support and getting vered] [accepted]

the Acceptance Record signed.

AM PM.4.2 Update Project Repository. Software Project Repository

Configuration [updated]

[accepted]

Project Repository

บทที่ 2 ขัน้ ตอนการบรหิ ารจดั การโครการ 2-13

คมู่ อื ปฏบิ ัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครัฐ

จากกระบวนการบริหารจัดการโครงการ (Project Management) ตามมาตรฐาน ISO/IEC
29110 เม่ือนามาประยุกต์ให้เข้ากับการทางานของภาครัฐ จึงได้เพ่ิมข้ันตอนท่ี 5 Service Desk ที่เป็นการจัดตั้ง
คณะทางานร่วมเพ่ือกล่ันกรองความต้องการและปัญหาท่ีเกิดข้ึนอย่างต่อเนื่อง มีการเปล่ียนชื่อเอกสารจาก
Change Request ไปเปน็ Service Desk Request

ภาพท่ี 2-2 Project Management Process (Apply)
การประยกุ ต์กระบวนการบรหิ ารจดั โครงการของภาครัฐ

บทที่ 2 ขนั้ ตอนการบรหิ ารจดั การโครการ 2-14

คมู่ ือปฏิบัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครัฐ

2.5 ผังการไหลของกระบวนการบรหิ ารจดั การโครงการ (Project Management Workflow)
ตารางที่ 2-6 ผงั การไหลของกระบวนการบริหารจัดการโครงการ

ผู้รบั ผิดชอบ ข้ันตอน เอกสารท่ีเกย่ี วขอ้ ง

Project Manager (PM), 2.5.1 Project Planning Proj_Statement_of_Work,
System Analyst (SA), Proj_Project_Plan,
Customer (Cus), Proj_Meeting_Report,
Quality Assurance (QA), Proj_Verification_Result
Administrator (AM)

Project Manager (PM), 2.5.2 Project Plan Proj_Progress_Report,
Work Team (WT), Execution Proj_Meeting_Report,
Customer (Cus) Proj_Project_Plan

Project Manager (PM), 2.5.3 Project Assessment Proj_Service_Desk_Request
Work Team (WT)
and Control

N Change/

Incident

Y

Project Manager (PM), 2.5.4 Proj_Correction_Register
Work Team (WT)
Service Desk

Proj_Acceptance_Record

Project Manager (PM), 2.5.5 Project Closure
Administrator (AM),
Customer (Cus)

บทท่ี 2 ขั้นตอนการบริหารจดั การโครการ 2-15

ค่มู อื ปฏิบัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครัฐ

จากผังการไหลของกระบวนการบริหารจัดการโครงการ (Project Management
Workflow) ในการบริหารจัดการโครงการเทคโนโลยีสารสนเทศน้ัน ผู้ท่ีเก่ียวข้องต้องปฏิบัติตามรายละเอียด
จากคู่มือฉบับนี้ โดยในแต่ละขั้นตอนการดาเนินงานจะเกี่ยวข้องกับการปฏิบัติตามข้ันตอนต่างๆ และเอกสาร
ต้นแบบ (Template) โดยมรี ายละเอียดในแต่ละข้ันตอนดังต่อไปน้ี

2.5.1 การวางแผนโครงการ (Project Planning)
ขัน้ ตอนการวางแผนโครงการเรม่ิ จากการนาขอบเขตของโครงการ (Statement of Work)

มาทบทวนและใช้ในการวางแผนการดาเนินโครงการ (Project Plan) และจัดเตรียมพื้นที่ที่ใช้เก็บงาน (Project
Repository) โดยนาแผนการดาเนินโครงการไปพิจารณาร่วมกับทีมงาน พร้อมนาเสนอแผนที่ผ่านการพิจารณา
ให้กับผู้ใช้ระบบเพ่ืออนุมัติในการดาเนินโครงการ โดยมีการจัดทาเอกสารรายงานการประชุม (Meeting Record)
มีการตรวจสอบคุณภาพในการดาเนินโครงการ (Verification Result)

2.5.2 การดาเนนิ การตามแผนของโครงการ (Project Plan Execution)
ข้ันตอนการดาเนินการตามแผนของโครงการ เป็นการดาเนินโครงการตามแผนท่ีวางไว้

โดยต้องมีการติดตามความก้าวหน้าของโครงการเป็นระยะ (Progress Status Record) มีการจัดทารายงานการ
ประชุม (Meeting Record) มีการสารองข้อมูลที่เก็บในพ้ืนท่ีเก็บงาน (Project Repository Backup) เม่ืองานท่ี
ดาเนินการไมเ่ ปน็ ไปตามแผนทวี่ างไว้ จะตอ้ งปรบั แผนการดาเนนิ โครงการ (Project Plan)

2.5.3 การประเมินและควบคุมโครงการ (Project Assessment and Control)
ข้ันตอนการประเมินและควบคุมโครงการ เป็นการหาดัชนี (Indicator) ในการชี้วัดโอกาส

และปัจจยั ความสาเร็จและความล้มเหลวของโครงการ เพ่ือนามาใช้ในการบริหารจัดการการเปล่ียนแปลงที่ต่อเน่ือง
(Service Desk Request) และเมื่อพบปัญหาระหว่างดาเนินโครงการท่ีส่งผลกระทบให้การดาเนินโครงการ
ไมเ่ ป็นไปตามแผนท่วี างไว้ต้องมีการบนั ทึกใน Correction Register

2.5.4 การบริหารความต้องการและการเปลีย่ นแปลงผา่ นจุดบริการ (Service Desk)
ในหลักการโดยท่ัวไปการบริการจัดการการเปล่ียนแปลงความต้องการ (Requirement

Management) เป็นหน่ึงในปัญหาหลักของการบริหารจัดการโครงการ ซึ่งส่วนใหญ่การหาข้อยุติระหว่าง
ความต้องการใหม่ ซ่ึงเป็นความรับผิดชอบของการให้ข้อมูลกับความครบถ้วนของการออกแบบตามความต้องการ
ซ่ึงเป็นหน้าที่ของฝ่ายจัดทาซอฟต์แวร์ เป็นประเด็นต่อเน่ืองและยังมิได้ถูกกาหนดในมาตรฐานสากล ISO/IEC
29110 ดังนั้นเพื่อให้กระบวนการดังกล่าวเป็นไปอย่างมีระบบ คู่มือน้ีจึงได้นากระบวนการจุดบริการ (Service
Desk) เพ่ิมเติมร่วมกับกระบวนเดิมของกระบวนการบริหารจัดการความต้องการและการเปล่ียนแปลงตาม
มาตรฐานสากลเดมิ โดยกระบวนการดงั กลา่ วยงั คงไว้ซึ่งความสอดคล้องตามมาตรฐานเดิม ซึ่งถือว่าเป็นข้ันพื้นฐาน
ตามมาตรฐาน ISO/IEC 29110

2.5.5 การสิน้ สุดหรอื ปดิ โครงการ (Project Closure)
ข้ันตอนการสนิ้ สดุ หรอื ปดิ โครงการ เป็นจดุ เปลย่ี นแปลงของการส้นิ สดุ ของโครงการพัฒนา

และจุดเร่ิมต้นการใช้งานจริง ซึ่งประเด็นความสาคัญและการบริหารจัดการมีความแตกต่างกัน แต่ท้ังน้ีจะต้องมี
ความตอ่ เนอ่ื งกันและสัมพันธ์กัน โดยจะต้องมีการจดั ทาเอกสารส่งมอบงาน (Acceptance Record)

บทที่ 2 ข้ันตอนการบรหิ ารจดั การโครการ 2-16

คูม่ อื ปฏบิ ัตติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หน่วยงานภาครัฐ

2.6 เอกสารอา้ งอิงและสง่ิ ท่เี ก่ียวขอ้ ง

อ้างองิ จากตารางท่ี 2-6 ผงั การไหลของกระบวนการบริหารจัดการโครงการ ตวั อยา่ งของเอกสารใน

แตล่ ะขอ้ สามารถดทู ภ่ี าคผนวก ก.

2.6.1 Proj_Statement_of_Work ขอบเขตของโครงการ

2.6.2 Proj_Project_Plan แผนการดาเนนิ โครงการ

2.6.3 Proj_Meeting_Report รายงานการประชมุ

2.6.4 Proj_Verification_Result บนั ทกึ การตรวจสอบตามขอ้ กาหนดของมาตรฐาน

2.6.5 Proj_Progress_Report รายงานความก้าวหนา้ ของโครงการ

2.6.6 Proj_ Service_Desk_Request บันทึกขอเปลีย่ นแปลงความตอ้ งการ

2.6.7 Proj_Correction_Register เอกสารสรปุ ปัญหาทพ่ี บระหว่างดาเนินโครงการ

2.6.8 Proj_Acceptance_Record บนั ทึกการสง่ มอบงาน

บทท่ี 2 ข้ันตอนการบริหารจดั การโครการ 2-17

คมู่ ือปฏบิ ตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครฐั

บทที่ 3
ข้ันตอนการพฒั นาระบบและซอฟตแ์ วร์
(System & Software Implementation)

3.1 วตั ถปุ ระสงค์
ข้นั ตอนการพฒั นาระบบและซอฟต์แวร์ เป็นหนึ่งในกระบวนการหลักตามกระบวนการวิศวกรรมระบบ

และซอฟต์แวร์ (System and Software Engineering) โดยมีกระบวนการบริหารโครงการ (Project
Management) และกระบวนการให้บริการสารสนเทศ (IT Service) เป็นกรอบในการควบคุม กระบวนการ
ดังกล่าวใช้เพ่ือกาหนดแนวทาง ขั้นตอนและผู้รับผิดชอบ รวมถึงเอกสารอ้างอิงและส่ิงที่เก่ียวข้อง (Artifacts)
ในการพัฒนา (Implementation) เพ่ือให้การดาเนินการและการติดตามโครงการเป็นไปอย่างมีประสิทธิภาพ
สอดคล้องกับนโยบาย และวัตถุประสงค์หลักของโครงการ โดยขั้นตอนน้จี ะมีขอบขา่ ย ข้นั ตอนตา่ งๆ ดังต่อไปน้ี

3.2 ขอบเขตของกระบวนการ
ขอบเขตของขั้นตอนในกระบวนการพัฒนาระบบและซอฟต์แวร์ประกอบไปด้วยข้ันตอนต่างๆ

ดงั ต่อไปนี้
(1) การบริหารจัดการความต้องการ ของระบบและซอฟต์แวร์ (System and Software

Requirements) เพื่อใหเ้ กิดความเขา้ ใจตรงกนั กบั ผู้ให้ข้อมูล
(2) การออกแบบระบบและซอฟต์แวร์ (System and Software Design) เป็นการออกแบบระบบตาม

ขอ้ สรุปความตอ้ งการ
(3) การพัฒนาระบบและซอฟต์แวร์ (System and Software Implementation) เป็นการพัฒนา

ระบบตามการออกแบบ โดยต้องมกี ารกาหนดแนวทางในการพฒั นาใหไ้ ปในทิศทางเดยี วกัน
(4) การทดสอบระบบและซอฟต์แวร์ (System and Software Testing) เป็นการทดสอบระบบ

เพ่อื ให้ม่นั ใจว่า ระบบท่ีพฒั นาขึน้ เป็นไปตามความตอ้ งการของผ้ใู ชง้ าน และการออกแบบ
(5) การส่งมอบระบบและการนาไปใช้จริง (Product Delivery and Deployment) เป็นการนา

ระบบงานที่ไดไ้ ปสง่ มอบ และเรม่ิ ใช้งาน

บทท่ี 3 ข้นั ตอนการพฒั นาระบบและซอฟต์แวร์ 3-1

คู่มอื ปฏบิ ัตติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครัฐ

3.3 นิยาม

คานิยามและความหมายทเ่ี กี่ยวขอ้ งมรี ายละเอยี ดดงั ตารางท่ี 3-1

ตารางที่ 3-1 คานิยามและความหมายท่เี กี่ยวขอ้ ง

คานิยาม ความหมาย

เอกสารอ้างองิ และส่ิงท่เี กีย่ วข้อง (Artifacts) เอกสารอ้างอิงและส่ิงเกี่ยวข้องท่ีจาเป็นสาหรับโครงการ

แบ่งได้หลายประเภท ตามมาตรฐานและข้อกาหนด

คณุ ภาพของโครงการนี้มีทงั้ ท่ีตอ้ งส่งมอบภายใต้กรอบของ

โครงการ (Deliverable) รวมไปถึงซอฟต์แวร์ และ

Source Code เอกสารอ้างอิงและส่ิงท่ีเกี่ยวข้องอื่นๆ

ท่ีใช้เฉพาะภายในโครงการท่ีไม่ต้องส่งมอบ (Non-

deliverable)

การพัฒนา (Implementation) ครอบคลุมนิยามมิใช่เฉพาะการเขียนโปรแกรม (Software

Coding) เท่าน้ัน และยังรวมไปถึงกิจกรรมต่างๆ เพ่ือให้ได้

ระบบและซอฟต์แวร์ตามความต้องการ (System and

Software Requirements)

การสง่ มอบระบบ (Product Delivery) การส่งมอบระบบ ครอบคลุมระบบซ่ึงโดยทั่วไปหมายถึง

Hardware Software และบริการ (IT Service) ที่ได้

เริ่มต้นไว้แล้ว

Project Manager (PM) ผู้บรหิ ารโครงการ

System Analyst (SA) นกั วเิ คราะหแ์ ละออกแบบระบบงาน

Programmer (PG) นักพัฒนาโปรแกรม

Tester (Test) ผทู้ ดสอบระบบ

Quality Assurance (QA) ผู้ควบคุมคุณภาพของการดาเนินการให้เป็นไปตาม

นโยบายของการพฒั นาระบบสารสนเทศ

Work Team (WT) คณะทางานพัฒนาระบบสารสนเทศ

Customer (Cus) ผ้ใู ชร้ ะบบ

บทท่ี 3 ข้นั ตอนการพฒั นาระบบและซอฟตแ์ วร์ 3-2

คู่มอื ปฏิบตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหน่วยงานภาครัฐ

3.4 ขน้ั ตอนการทางาน
กระบวนการพัฒนาซอฟต์แวร์ (Software Implementation Process) อ้างอิงตามมาตรฐาน ISO/IEC

29110 สามารถแบ่งออกเป็นกระบวนการตา่ งๆ ได้ 6 กระบวนการ (ภาพท่ี 3-1) ซ่งึ มีรายละเอยี ดดังต่อไปนี้

ภาพท่ี 3-1 Software Implementation Process 3-3
(อ้างองิ Software Engineering Process ของ ISO/IEC 29110)

บทที่ 3 ข้นั ตอนการพัฒนาระบบและซอฟตแ์ วร์

คู่มอื ปฏิบัตติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครฐั

3.4.1 การรเิ ริม่ การพฒั นาซอฟตแ์ วร์ (Software Implementation Initiation)

เป็นกิจกรรมหลักเร่ิมต้นที่สาคัญของกระบวนการพัฒนาซอฟต์แวร์ (Software

Implementation) ทาให้เกิดระบบ อาจรวมถึงการเขียนโปรแกรม (Coding) การติดตั้ง และการติดตั้งตัวแปร

(Installation & Configuration) และอื่นๆ เพื่อทาให้ระบบนาไปใช้งาน กิจกรรมน้ีประกอบไปด้วยการทบทวน

แผน และการจัดสภาพแวดล้อมต่างๆ ที่เหมาะสมกับกิจกรรมท่ีกล่าวต่อไป ซ่ึงตามมาตรฐาน ISO/IEC 29110 ได้

กาหนดงาน และหนา้ ทที่ ี่เกยี่ วขอ้ งอ้างองิ ไดจ้ ากตารางท่ี 3-2

ตารางท่ี 3-2 แนวทางในการเร่ิมการพัฒนาซอฟต์แวร์ (Software Implementation Initiation) ตาม

มาตรฐาน ISO/IEC 29110

บทบาท กจิ กรรมทีด่ าเนนิ การ เอกสารต้งั ตน้ ผลลัพธ์ทไี่ ด้

(Role) (Task List) (Input Products) (Output Products)

PM SI.1.1 Revision of the current Project Plan Project Plan Project Plan

SA with the Work Team members in order to [reviewed]

WT achieve a common understanding and get

their engagement with the project.

SA SI.1.2 Set or update the implementation Project Plan

WT environment. [reviewed]

3.4.2 การวเิ คราะหค์ วามต้องการของซอฟตแ์ วร์ (Software Requirement Analysis)
เป็นกิจกรรมสาคัญหลักของการบริหารภายใต้วิศวกรรมซอฟต์แวร์ เพื่อทาให้

กระบวนการพัฒนาซอฟต์แวร์ (Software Implementation) เป็นไปอย่างเป็นระบบ และสามารถบริหารจัดการ
อย่างต่อเนื่องได้ โดยกิจกรรมได้มุ่งเน้นกระบวนการบริหารจัดการความต้องการ (Requirement Management)
ให้ถูกควบคุมภายใต้ระบบคุณภาพ (Quality Assurance) อน่ึงการบริหารจัดการความต้องการซอฟต์แวร์คิดเป็น
ปัญหามากกว่ารอ้ ยละ 50 ของการบริหารจัดการโครงการ ดังน้ันงานของกิจกรรมการบริหารจัดการความต้องการ
ซอฟต์แวรภ์ ายใตร้ ะบบคุณภาพจะประกอบไปด้วย เอกสาร ขั้นตอนท่ีจะต้องระบุที่มา ความสัมพันธ์ กระบวนการ
จัดเก็บเอกสาร การไหลเวียน ข้ันตอนการรับรู้ และยืนยันความต้องการจากผู้ให้ข้อมูล การทบทวน และ
กระบวนการสอบทาน ซ่ึงสอดคล้องกับหลักวิชาการตามวิศวกรรมซอฟต์แวร์ ซึ่งตามมาตรฐาน ISO/IEC 29110
ได้กาหนดงานและหน้าทที่ ี่เกย่ี วขอ้ ง อา้ งอิงได้จากตารางที่ 3-3

บทท่ี 3 ขั้นตอนการพฒั นาระบบและซอฟตแ์ วร์ 3-4

คมู่ อื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวิศวกรรมซอฟต์แวร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครฐั

ตารางท่ี 3-3 แนวทางในการวเิ คราะห์ความตอ้ งการของซอฟตแ์ วร์ (Software Requir

บทบาท กจิ กรรมทีด่ าเนินการ

(Role) (Task List)

SA SI.2.1 Assign tasks to the Work Team members in accordance wi

WT their role, based on the current Project Plan.

SA SI.2.2 Document or update the Requirements Specification.

CUS Identify and consult information sources (customer, users, p

systems, documents, etc.) in order to get new requirements.

Analyse the identified requirements to determinate the scop

feasibility. Generate or update the Requirements Specification.

SA SI.2.3 Verify and obtain approval of the Requirements Specificati

Verify the correctness and testability of the Requirements Speci

and its consistency with the Product Description. Additionally,

that requirements are complete, unambiguous and not contrad

The results found are documented in a Verification Resul

corrections are made until the document is approved by SA.

If significant changes were needed, initiate a Change Request.

CUS SI.2.4 Validate and obtain approval of the Requirements Specific

SA Validate that Requirements Specification satisfies needs and

upon expectations, including the user interface usability.

บทท่ี 3 ขนั้ ตอนการพัฒนาระบบและซอฟตแ์ วร์

ฐ

rement Analysis) ตามมาตรฐาน ISO/IEC 29110 ผลลัพธ์ทไ่ี ด้
เอกสารตั้งตน้ (Output Products)

(Input Products)
ith Project Plan[reviewed]

Project Plan (Product Requirements Specification
previous Description)

pe and

ion. Requirements Specification Verification Results
ification Project Plan (Product Requirements Specification
review Description) [verified]
dictory. Change Request [initiated]
lts and

cation Requirements Specification Validation Results
agreed [verified] Requirements Specification
[validated]

3-5

คู่มอื ปฏิบตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหนว่ ยงานภาครฐั

บทบาท กจิ กรรมทดี่ าเนนิ การ

(Role) (Task List)

The results found are documented in a Validation Resul

corrections are made until the document is approved by the CU

SA SI.2.5 Document the preliminary version of the Software User

Documentation or update the present manual. (optional)

SA SI.2.6 Verify and obtain approval of the Software User Documen

Verify consistency of the Software User Documentation wi

Requirement Specification. The results found are documente

Verification Results and corrections are made until the docum

approved by SA. If significant changes were needed, initiate a

Request. (optional)

SA SI.2.7 Incorporate the Requirements Specification, and *Software

Documentation to the Software Configuration in the baseline.

*(optional)

บทท่ี 3 ขั้นตอนการพัฒนาระบบและซอฟตแ์ วร์

ฐ

เอกสารต้ังตน้ ผลลพั ธท์ ี่ได้
(Input Products) (Output Products)
lts and
US. Software User Documentation
Requirements Specification [preliminary]
[validated] Verification Results
ntation Software User Documentation Software User Documentation
ith the [preliminary] [preliminary, verified]
ed in a Requirement Specification Change Request [initiated]
ment is
Change

e User Requirements Specification Software Configuration

[validated] Requirements Specification

*Software User Documentation [validated, baselined],

[preliminary, verified] *Software User

Documentation [preliminary,

verified, baselined]

3-6

คู่มือปฏบิ ัตติ ามกระบวนการมาตรฐานวิศวกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หนว่ ยงานภาครฐั

3.4.3 สถาปตั ยกรรมและการออกแบบซอฟตแ์ วร์ (Software Architecture Design)
เป็นกิจกรรมสาคัญทางด้านวิศวกรรม เชื่อมโยงกับการพัฒนาซอฟต์แวร์ของ

กระบวนการพัฒนาซอฟต์แวร์ (Software Implementation) ซง่ึ กิจกรรมต่อไป จะต้องผ่านกระบวนการน้ี มุ่งเน้น
การออกแบบและการกาหนดสถาปัตยกรรมท่ีเหมาะสมถูกต้องตามหลักวิชาการ เพ่ือให้สิ่งท่ีต้องการตามการ
วิเคราะห์ความต้องการมีความเป็นไปได้ จะสังเกตได้ว่ากระบวนการวิเคราะห์ความต้องการและการออกแบบ
จะตอ้ งเป็นกจิ กรรมท่ตี ่อเน่ืองและสัมพันธ์กันระหวา่ งการบรหิ ารจัดการและวศิ วกรรมอย่างเป็นระบบ กระบวนการ
และมาตรฐานจึงเป็นองค์ประกอบที่สาคัญของกระบวนการทางานตามมาตรฐานวิศวกรรมซอฟต์แวร์ ซ่ึงตาม
มาตรฐาน ISO/IEC 29110 ได้กาหนดงานและหน้าท่ีทเ่ี กยี่ วขอ้ ง อา้ งองิ ได้จากตารางที่ 3-4

บทท่ี 3 ขนั้ ตอนการพฒั นาระบบและซอฟตแ์ วร์ 3-7

คมู่ อื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรบั หน่วยงานภาครัฐ

ตารางท่ี 3-4 แนวทางในการออกแบบสถาปตั ยกรรมและการออกแบบซอฟตแ์ วร์ (Soft

บทบาท กิจกรรมท่ดี าเนนิ การ

(Role) (Task List)

SA SI.3.1 Assign tasks to the Work Team members related to their ro

according to the current Project Plan.

SA SI.3.2 Understand Requirements Specifications.

SA SI.3.3 Document or update the Software Design:
Analyse the Requirements Specification to generate the architec
design, its arrangement in subsystems and software components
defining the internal and external interfaces. Describe in detail, t
appearance and the behaviour of the interface, based on the
requirements specification in a way that resources for its
implementation can be foreseen.
Provide the detail of software components and their interfa
allow the construction in an evident way. Generate or upda
Traceability Record.

SA SI.3.4 Verify and obtain approval of the Software Design
Verify correctness of Software Design documentation, its feasibil
consistency with their requirement specification. Verify th

บทที่ 3 ขัน้ ตอนการพัฒนาระบบและซอฟตแ์ วร์

ฐ

tware Architecture Design) ตามมาตรฐาน ISO/IEC 29110

เอกสารตั้งต้น ผลลัพธท์ ไี่ ด้

(Input Products) (Output Products)

ole Project Plan

Requirements Specification Software Design
[validated, baselined] Traceability Record
Requirements Specification
ctural [validated, baselined]
s
the

aces to Verification Results
ate the Software Design [verified]
Traceability Record [verified]
Software Design
lity and Traceability Record
hat the Requirement Specification

3-8

คมู่ อื ปฏบิ ตั ติ ามกระบวนการมาตรฐานวศิ วกรรมซอฟตแ์ วร์ ISO/IEC 29110 สาหรับหน่วยงานภาครัฐ

บทบาท กจิ กรรมทดี่ าเนนิ การ

(Role) (Task List)

Traceability Record contains the adequate relationships be

requirements and the Software Design elements. The results fou

documented in a Verification Results and corrections are mad

the document is approved by SA. If significant changes were n

initiate a Change Request.

SA SI.3.5 Establish or update Test Cases and Test Procedures for

integration testing based on Requirements Specification and Sof

Design. Customer provides testing data, if needed.

SA SI.3.6 Verify and obtain approval of the Test Cases and Test
QA Procedures. Verify consistency among Requirements Specificatio

Software Design and Test Cases and Test Procedures. The resul
found are documented in a Verification Results and corrections
made until the document is approved by SA.
SA SI.3.7 Update the Traceability Record incorporating the Test Cas
Test Procedures.

บทท่ี 3 ขน้ั ตอนการพัฒนาระบบและซอฟต์แวร์

ฐ ผลลพั ธท์ ่ไี ด้
(Output Products)
เอกสารต้งั ต้น Change Request [initiated].
(Input Products)
etween [validated, baselined]
und are
de until
needed,

Requirements Specification Test Cases and Test

ftware [validated, baselined] Procedures

Software Design [verified,

baselined]

Test Cases and Test Procedures Verification Results

on, Requirements Specification Test Cases and Test

lts [validated, baselined] Procedures [verified]

are Software Design [verified,

baselined]

ses and Test Cases and Test Procedures Traceability Record [updated]

[verified]

Traceability Record [updated]

3-9