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

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

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

(Role) (Task List)

SA SI.3.8 Incorporate the Software Design, and Traceability Record t

Software Configuration as part of the baseline.

Incorporate the Test Cases, and Test Procedures to the Project

Repository.

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

ฐ

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

(Input Products) (Output Products)

to the Software Design[verified] Software Configuration

Test Cases and Test Procedures Software Design [verified,

[verified] baselined]

Traceability Record [verified] Test Cases and Test

Procedures [verified]

Traceability Record [verified,

baselined]

3-10

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

3.4.4 การพฒั นาซอฟตแ์ วร์ (Software Construction)
เปน็ กิจกรรมทางด้านวิศวกรรมเพ่อื ทาให้เกิดซอฟตแ์ วร์ โดยมีขอบเขตความต้องการและ

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

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

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

ตารางที่ 3-5 แนวทางในการพฒั นาซอฟตแ์ วร์ (Software Construction) ตามมาตรฐ

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

(Role) (Task List)

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

PG according to the current Project Plan.

PG SI.4.2 Understand Software Design.

PR SI.4.3 Construct or update Software Components based on the
detailed part of the Software Design.

PG SI.4.4 Design or update unit test cases and apply them to verify
the Software Components implements the detailed part of the
Software Design.

PG SI.4.5 Correct the defects found until successful unit test (reach
criteria) is achieved.

PG SI.4.6 Update the Traceability Record incorporating Software
Components constructed or modified.

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

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

(Input Products)
ole, Project Plan

Software Design [verified, Software Components
baselined]
Software Design [verified, Software Components [unit
baselined], tested]
Traceability Record [verified,
baselined]
that Software Components

hing exit Software Components [unit Software Components
tested] [corrected]
Software Components Traceability Record [updated]
[corrected]
Traceability Record [verified,
baselined].

3-12

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

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

(Role) (Task List)

SA SI.4.7 Incorporate Software Components and Traceability Rec

the Software Configuration as part of the baseline.

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

ฐ

เอกสารต้งั ตน้ ผลลัพธท์ ีไ่ ด้
(Input Products) (Output Products)
cord to Software Components Software Configuration
[corrected] Software Components
Traceability Record [updated] [corrected, baselined]
Traceability Record [updated,
baselined]

3-13

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

3.4.5 การทดสอบการเชอื่ มโยงซอฟต์แวร์ (Software Integration and Test)
เป็นกิจกรรมทางด้านวิศวกรรมในการทดสอบซอฟต์แวร์โดยมีข้อกาหนดของความ

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

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

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

ตารางที่ 3-6 แนวทางในการทดสอบการเชอ่ื มโยงระบบและซอฟต์แวร์ (System & Sof

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

(Role) (Task List)

SA SI.5.1 Assign tasks to the work team members related to their ro

PG according to the current Project Plan.

PG SI.5.2 Understand Test Cases and Test Procedures.

Set or update the testing environment.

PG SI.5.3 Integrates the Software using Software Components and u

Test Cases and Test Procedures for integration testing, as neede

Tester SI.5.4 Perform Software tests using Test Cases and Test Procedu
CUS integration and document results in Test Report.
PG SI.5.5 Correct the defects found and perform regression test un
Tester criteria is achieved.

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

ฐ

ftware Integration Test) ตามมาตรฐาน ISO/IEC 29110

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

(Input Products) (Output Products)

ole, Project Plan

Test Cases and Test Procedures

[verified, baselined]

updates Software Components Software Test Cases and Test

ed. [corrected, baselined] Procedures

Test Cases and Test Procedures

[verified]

Traceability Record [updated,

baselined]

ures for Software Test Cases and Test Software [tested]

Procedures Test Report

ntil exit Software [tested], Test Report. Software [corrected]

Test Cases and Test Procedures Test Report [defects

Traceability Record [updated, eliminated]

baselined]

3-15

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

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

(Role) (Task List)

PG SI.5.6 Updates the Traceability Record if appropriate.

AM SI.5.7 Document the Product Operation Guide or update the
guide, if appropriate.

QA SI.5.8 Verify and obtain approval of the Product Operation G
AM appropriate (see SI.5.7) Verify consistency of the Product Op
SA Guide with the Software. The results found are documente

Verification Results and corrections are made until the docum
approved by SA.
SA SI.5.9 Document the Software User Documentation or upda
current one, if appropriate.

SA SI.5.10 Verify and obtain approval of the Software User
CUS Documentation, if appropriate (see SI.5.9) Verify consistency of

Software User Documentation with the Software. The results fou
are documented in a Verification Results and corrections are ma
until the document is approved by CUS.

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

ฐ

เอกสารตั้งต้น ผลลัพธ์ที่ได้
(Input Products) (Output Products)
Software [corrected] Traceability Record [updated]
Traceability Record [updated,
baselined]. Product Operation Guide
current Software [tested]

Guide, if Product Operation Guide Verification Results
peration Software [tested] Product Operation Guide
ed in a [verified]
ment is

ate the Software [tested] Software User Documentation
Software User Documentation
[preliminary] (optional) Verification Results
Software User Documentation Software User Documentation
[verified]
the Software [tested]
und
ade

3-16

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

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

(Role) (Task List)

SA SI.5.11 Incorporate the Test Cases and Test Procedures, So

Traceability Record, Test Report, Product Operation Guid

Software User Documentation to the Software Configuration as

the baseline.

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

ฐ

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

(Input Products) (Output Products)

oftware, Test Cases and Test Procedures Software Configuration

de and Software [tested] Test Cases and

part of Test Report Test Procedures [baselined]

Traceability Record [updated] Software [tested, baselined]

Product Operation Guide Traceability Record

[verified] [updated,baselined]

Software User Documentation Test Report [baselined]

[verified] Product Operation Guide

[verified, baselined]

Software User Documentation

[verified, baselined]

3-17

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

3.4.6 การส่งมอบซอฟต์แวร์ (Product Delivery)
เป็นกิจกรรมส้ินสุดของกระบวนการทาให้เกิดซอฟต์แวร์ เป็นการส้ินสุดกระบวนการ

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

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

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

ตารางที่ 3-7 แนวทางในการสง่ มอบซอฟตแ์ วร์ (Product Delivery) ตามมาตรฐาน IS

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

(Role) (Task List)

SA SI.6.1 Assign tasks to the work team members related to their ro

WT according to the current Project Plan.

SA SI.6.2 Understand Software Configuration.

SA SI.6.3 Document the Maintenance Documentation or update the

current one.

QA SI.6.4 Verify and obtain approval of the Maintenance Documen

SA Verify consistency of Maintenance Documentation with So

Configuration. The results found are documented in a Veri

Results and corrections are made until the document is appro

SA.

SA SI.6.5 Incorporate the Maintenance Documentation as baseline f

Software Configuration.

SA SI.6.6 Perform delivery according to Delivery Instructions.

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

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

(Input Products)
ole, Project Plan

Software Configuration Maintenance Documentation
e Software Configuration

ntation. Maintenance Documentation Verification Results
oftware Software Configuration Maintenance Documentation
ification [verified]
oved by

for the Software Configuration Software Configuration
Maintenance Documentation Maintenance Documentation
[verified] [verified, baselined]
Delivery Instructions Software Configuration
Software Configuration [delivered]

3-19

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

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

ภาพท่ี 3-2 System and Software Implementation Process 3-20
กระบวนการพัฒนาระบบและซอฟตแ์ วร์

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

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

3.5 ผงั การไหลของกระบวนการพัฒนาระบบและซอฟตแ์ วร์ (System & Software Implementation
Workflow)
ตารางท่ี 3-8 ผงั การไหลของกระบวนการพฒั นาระบบและซอฟตแ์ วร์

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

Project Manager (PM), 3.5.1 System & Software Proj_Project_Plan
Work Team (WT) Implementation Initiation

System Analyst (SA), 3.5.2 System & Software Proj_Validation_Result,
Customer (Cus), Requirement Analysis Proj_Requirement_Spec,
Quality Assurance (QA) Proj_Verification_Result

System Analyst (SA), 3.5.3 System & Software Proj_SystemSoftware_Design,
Tester (Test), Architecture Design Proj_Traceability_Record,
Quality Assurance (QA), Proj_Test_Cases,
Customer (Cus) Proj_Service_Desk_Request,
Proj_Verification_Result

System Analyst (SA), 3.5.4 System & Software Proj_Software_Component,
Programmer (PG) Construction Proj_Traceability_Record,

Programmer (PG), 3.5.5 System & Software Proj_Test_Report,
Tester (Test), Integration Test Proj_Admin_Manual,
Customer (Cus), Proj_User_Manual,
Administrator (AM), Proj_Verification_Result
Quality Assurance (QA)

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

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

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

System Analyst, 3.5.6 Product Delivery Proj_Maintenance_Document
Quality Assurance Proj_Verification_Result

จากตารางผังการไหลของกระบวนการพัฒนาระบบและซอฟต์แวร์ (System & Software
Implementation Workflow) ผู้ท่ีเกี่ยวข้องจะต้องปฏิบัติตามรายละเอียดจากคู่มือฉบับน้ี โดยใน
แต่ละขั้นตอนการดาเนินงานจะเกยี่ วขอ้ งกบั การปฏิบัติตามข้ันตอนและเอกสารต้นแบบต่างๆ ตามที่ได้จัดเก็บ
ไว้ตามวิธีการปฏิบัติการของคู่มือ ซึ่งครอบคลุมกระบวนการต่างๆ ดังกล่าวข้างต้น และการควบคุมบันทึก
คุณภาพภายใต้การจดั เกบ็ เอกสารและสาระสาคัญของโครงการ

3.5.1 การริเร่ิมการพัฒนาระบบและซอฟตแ์ วร์ (System & Software Implementation
Initiation)
ขนั้ ตอนการริเร่ิมการพัฒนาระบบและซอฟต์แวร์ ข้ันตอนนี้เร่ิมจากการทบทวนแผนการ

ดาเนนิ โครงการ จัดเตรยี มสภาพแวดล้อมในการพฒั นาระบบและซอฟต์แวร์ และเรมิ่ ดาเนนิ การตามแผนท่วี างไว้
3.5.2 การวเิ คราะห์ความตอ้ งการของระบบและซอฟต์แวร์ (System & Software
Requirement Analysis)
ข้ันตอนการวิเคราะห์ความต้องการของระบบและซอฟต์แวร์ เป็นข้ันตอนการรวบรวม

ความต้องการของระบบและซอฟต์แวร์ นาความต้องการท่ีสรุปได้ไปยืนยันกับผู้ใช้งาน (Validation Result)
การจัดทาเอกสารสรุปความต้องการ (Requirement Specification) และการตรวจสอบคุณภาพในการดาเนิน
โครงการ (Verification Result)

3.5.3 สถาปตั ยกรรม และการออกแบบระบบและซอฟตแ์ วร์ (System & Software
Architecture Design)
ขั้นตอนสถาปัตยกรรมและการออกแบบระบบและซอฟต์แวร์ เป็นการนาความต้องการ

ทสี่ รุปไดม้ าออกแบบระบบและซอฟตแ์ วร์ (System & Software Design) โดยจะตอ้ งออกแบบเชิงสถาปัตยกรรม
ของระบบ (Architectural high level software design) การออกแบบเชิงรายละเอียดของระบบ (Detail low
level software design) พร้อมกับออกแบบกรณีทดสอบ (Test Cases) เพื่อใช้สาหรับทดสอบการใช้งาน และ
การตรวจสอบคุณภาพในการดาเนินโครงการ (Verification Result)

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

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

3.5.4 การพัฒนาระบบ (System & Software Construction)
ข้ันตอนการพัฒนาระบบ เป็นการพัฒนาโปรแกรมต่างๆ (Software Components)

ตามเอกสารการออกแบบระบบและซอฟต์แวร์ (System & Software Design)
3.5.5 การทดสอบการเชอ่ื มโยงระบบและซอฟต์แวร์ (System & Software Integration Test)
ข้ันตอนการทดสอบการเช่ือมโยงระบบและซอฟต์แวร์ เป็นการนาเอาโปรแกรมต่างๆ

ทพี่ ัฒนา (Software Components) มารวมเขา้ ด้วยกนั ทดสอบการใช้งานโดยใชก้ รณีทดสอบ (Test Cases) โดย
บันทึกผลการทดสอบในเอกสารบันทึกผลการทดสอบ (Test Report) จัดทาคู่มือสาหรับผู้ใช้งาน (Software
User Documentation) คู่มือสาหรับผดู้ แู ลระบบงาน (Product Operation Guide) และการตรวจสอบคุณภาพ
ในการดาเนินโครงการ (Verification Result)

3.5.6 การส่งมอบระบบและซอฟต์แวร์ (Product Delivery)
ข้ันตอนการส่งมอบระบบและซอฟต์แวร์ เป็นการนาซอฟต์แวร์ท่ีผ่านการทดสอบเสร็จ

เรียบร้อยแล้วไปติดต้ังและจัดทาคู่มือ Maintenance Document และการตรวจสอบคุณภาพในการดาเนิน
โครงการ (Verification Result)

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

อ้างองิ จากตารางที่ 3-8 ผังการไหลของกระบวนการพฒั นาระบบและซอฟตแ์ วร์ ตวั อย่างของ

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

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

3.6.2 Proj_Validation_Result บันทึกการยนื ยนั ความต้องการกบั ผูใ้ ช้งาน

3.6.3 Proj_Requirement_Spec เอกสารสรปุ ความต้องการของระบบงาน

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

3.6.5 Proj_SystemSoftware_Design เอกสารการออกแบบระบบ

3.6.6 Proj_Traceability_Record เอกสารบันทึกการตรวจสอบย้อนกลบั ของระบบ

3.6.7 Proj_Test_Cases เอกสารแสดงตัวอยา่ งชดุ ขอ้ มลู ที่ใช้ทดสอบ

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

3.6.9 Proj_Software_Component เอกสารแสดงสว่ นประกอบตา่ ง ๆ ของโปรแกรม

3.6.10 Proj_Test_Report บันทกึ ผลการทดสอบระบบ

3.6.11 Proj_Admin_Manual เอกสารค่มู ือปฏบิ ตั งิ านสาหรับผูด้ ูแลระบบ

3.6.12 Proj_User_Manual เอกสารค่มู ือการใชง้ านสาหรับผู้ใช้

3.6.13 Proj_Maintenance_Document เอกสารค่มู ือการบารงุ รกั ษาระบบ

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

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

บทที่ 4
การนามาตรฐาน ISO/IEC 29110 มาประยุกต์ใช้ในหน่วยงาน

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

4.1 สาหรบั หนว่ ยงานท่ีพัฒนาเอง
หน่วยงานภาครัฐและรัฐวิสาหกิจหลายๆ แห่งมีความพร้อมด้านบุคลากรที่มีความสามารถในการ

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

บทท่ี 4 การนามาตรฐาน ISO/IEC 29110 มาประยุกตใ์ ชใ้ นหน่วยงาน 4-1

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

ภาพท่ี 4-1 แสดงขนั้ ตอนการนาไปใชส้ าหรบั หน่วยงานทพี่ ัฒนาเอง 4-2
บทท่ี 4 การนามาตรฐาน ISO/IEC 29110 มาประยกุ ต์ใช้ในหนว่ ยงาน

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

รายละเอยี ดขั้นตอนการนาไปใช้สาหรับหน่วยงานท่ีพฒั นาเอง

(1) ศกึ ษาและจดั ทาขอบเขตของโครงการ (Statement of Work)
ขั้นตอนนี้เป็นการที่หน่วยงานต้องทาการศึกษาความต้องการของหน่วยงานหรือผู้ใช้ท่ี

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

(2) จัดทาแผนการดาเนินโครงการ (Project Plan)
ขัน้ ตอนน้ีผบู้ ริหารโครงการตอ้ งดาเนินการวางแผนในการดาเนนิ โครงการ โดยอ้างอิงจาก

ขอบเขตของโครงการ (Statement of Work) มีการกาหนดบุคลากรในโครงการ กาหนดพื้นที่จัดเก็บของ
โครงการ มีการประเมินความเสี่ยงในการดาเนินโครงการ และนาเสนอแผนในการดาเนินโครงการให้ผู้ท่ี
เกยี่ วขอ้ งไดร้ บั ทราบ

(3) จัดเตรยี มพ้นื ทีส่ าหรับโครงการ (Project Repository)
ขนั้ ตอนนี้ผู้บริหารโครงการต้องประสานกับผู้ดูแลเคร่ือง Server เพ่ือขอพ้ืนท่ีที่ใช้ในการ

จัดเก็บเอกสารและโปรแกรมทพ่ี ัฒนา
(4) รวบรวมและวิเคราะห์ความตอ้ งการ (Requirement Gathering)
ขั้นตอนนี้นักวิเคราะห์และออกแบบระบบงานจะดาเนินการรวบรวมความต้องการจาก

ผู้ใช้งาน แล้วนาความต้องการท่ีได้มาศึกษาทาความเข้าใจและวิเคราะห์เพ่ือสรุปเป็นความต้องการของระบบ
และซอฟต์แวร์

(5) ยืนยนั ความต้องการกับผ้ใู ช้ (Validation Results)
ข้ันตอนนี้นักวิเคราะห์และออกแบบระบบงานจะนาเอาความต้องการที่สรุปได้กลับไป

ยนื ยันความตอ้ งการกับผู้ใช้ เพอ่ื ให้เกดิ ความเขา้ ใจทีต่ รงกนั
(6) จัดทาเอกสารสรปุ ความต้องการของระบบ (Requirements Specification)
ขั้นตอนนี้นักวิเคราะห์และออกแบบระบบงานจะนาเอาความต้องการท่ีผ่านการยืนยัน

มาจัดทาเปน็ เอกสารสรุปความตอ้ งการของระบบ และนาไปใหผ้ ู้ใช้งานพิจารณาเห็นชอบ
(7) ออกแบบระบบและซอฟตแ์ วร์ (System & Software Design)
ข้ันตอนนี้นักวิเคราะห์และออกแบบระบบงานจะดาเนินการออกแบบระบบและ

ซอฟตแ์ วรต์ ามเอกสารสรุปความตอ้ งการของระบบ เช่น การออกแบบสถาปัตยกรรมของระบบและซอฟต์แวร์
(System & Software Architecture) การออกแบบรายละเอียดของหน้าจอ (Screens Design) การ
ออกแบบรายละเอียดของรายงาน (Reports Design) การออกแบบโครงสร้างฐานข้อมูล (E-R Diagram and
Data Dictionary) ขั้นตอนการทางาน (Work Flow Diagram) ฯลฯ โดยให้สอดคล้องตามความต้องการของ
เอกสารสรุปความต้องการของระบบ

บทที่ 4 การนามาตรฐาน ISO/IEC 29110 มาประยกุ ตใ์ ช้ในหนว่ ยงาน 4-3

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

(8) ออกแบบเอกสารแสดงตวั อย่างขอ้ มลู ทีใ่ ช้ทดสอบ (Test Cases and Test Procedures)
ข้ันตอนนี้นักวิเคราะห์และออกแบบระบบงานจะดาเนินการออกแบบตัวอย่างข้อมูล

ทจ่ี ะใช้ในการทดสอบการใช้งานซอฟต์แวร์ เพื่อให้ครอบคลุมตามความต้องการของเอกสารสรุปความต้องการ
ของระบบ และถูกต้องตามเอกสารการออกแบบระบบและซอฟต์แวร์

(9) เอกสารบันทกึ การตรวจสอบย้อนกลับของระบบ (Traceability Record)
ข้ันตอนน้ีนักวิเคราะห์และออกแบบระบบงานจะทาการบันทึกข้อมูลลงในเอกสารเพื่อดู

ความสัมพันธ์จากความต้องการ (Requirements) เช่ือมไปยังการออกแบบ (Design) เช่ือมไปยังโปรแกรม
(Components) และเช่อื มไปยังชุดข้อมูลทีใ่ ช้ทดสอบ (Test Cases)

(10) พฒั นาระบบงาน (Software Components)
ขั้นตอนนี้นักพัฒนาโปรแกรมดาเนินการพัฒนาตามเอกสารการออกแบบระบบและ

ซอฟต์แวร์ (Software Design) และการทดสอบการใช้งานเบือ้ งต้น (Unit Test)
(11) ทดสอบระบบงาน (Test Report)
ข้นั ตอนน้ีผูท้ ดสอบระบบจะดาเนนิ การทดสอบการใช้งานโดยใช้ข้อมูลที่ใช้ทดสอบ (Test

Cases) และบันทึกผลลัพธ์ของการทดสอบในเอกสารการทดสอบระบบงาน (Test Report) หากพบปัญหา
ในการใช้งานก็จะรายงานผลไปยังผ้ทู เ่ี กย่ี วขอ้ ง เพอื่ ดาเนนิ การแกไ้ ขให้ระบบใชง้ านได้สมบูรณ์

(12) จัดทาค่มู ือการใช้งานสาหรบั ผ้ใู ช้ (Software User Document)
ข้ันตอนนี้นักวิเคราะห์และออกแบบระบบงานจะเร่ิมจัดทาคู่มือการใช้งานสาหรับผู้ใช้

(Software User Document) หลังจากท่ผี า่ นการทดสอบการใช้งานเป็นที่เรยี บรอ้ ย
(13) จดั ทาคู่มอื ปฏบิ ตั ิงานสาหรับผ้ดู ูแลระบบ (Product Operation Guide)
ขั้นตอนนี้ผู้ดูแลระบบงานจะเริ่มจัดทาคู่มือปฏิบัติงานสาหรับผู้ดูแลระบบ (Product

Operation Guide) เพือ่ อธบิ ายถึงวิธกี ารในการดูแลรักษาระบบงานให้สามารถใช้งานได้อย่างต่อเนื่อง รวมถึง
การสารองข้อมลู (Database Backup)

(14) จัดทาคู่มือการบารุงรกั ษาระบบงาน (Maintenance Document)
ข้ันตอนนี้ผู้ดูแลระบบงานจะเร่ิมจัดทาคู่มือการบารุงรักษาระบบงาน (Maintenance

Document) ซึ่งเปน็ การอธิบายถึงการเตรียมสภาพแวดลอ้ มในการพัฒนาระบบ และการทดสอบระบบ รวมถึง
การสรปุ เวอร์ช่ันสุดท้ายของเอกสารต่างๆ ณ วนั สง่ มอบงาน

(15) สง่ มอบงาน (Acceptance Record)
ขั้นตอนนี้ผู้บริหารโครงการจัดทาเอกสารประกอบการส่งมอบงาน (Acceptance

Record) ให้กับผใู้ ชง้ านได้ลงนามรับมอบระบบงานท่พี ัฒนาขึน้
(16) รายงานการประชมุ (Meeting Record)
ในการบริหารโครงการจาเป็นต้องมีการบันทึกรายงานการประชุม (Meeting Record)

ทกุ ครั้ง ไม่วา่ จะเปน็ การประชมุ ภายในทมี งาน และประชมุ รว่ มกับผู้ใชง้ าน

บทท่ี 4 การนามาตรฐาน ISO/IEC 29110 มาประยุกต์ใชใ้ นหนว่ ยงาน 4-4

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

(17) รายงานความกา้ วหน้าของโครงการ (Progress Status Record)
ในการบริหารโครงการ ผู้บริหารโครงการจะต้องจัดทารายงานความก้าวหน้าของ

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

(18) สรปุ ปญั หาที่พบระหว่างดาเนนิ โครงการ (Correction Register)
ในการบริหารโครงการ ผู้บริหารโครงการจะต้องบันทึกปัญหาที่พบระหว่างดาเนิน

โครงการ (Correction Register) โดยเฉพาะปัญหาท่ีส่งผลกระทบกับแผนการดาเนินโครงการ ทาให้
จาเป็นต้องมีการปรับเปล่ียนแผนการดาเนินโครงการ (Project Plan) และผู้บริหารโครงการจะต้องติดตาม
ปญั หาให้มกี ารดาเนินการแก้ไขปญั หาใหเ้ รียบรอ้ ย

(19) การตรวจสอบตามข้อกาหนดของมาตรฐาน (Verification Result)
ในการบริหารโครงการ ผู้ควบคุมคุณภาพจะดาเนินการตรวจสอบผลการดาเนินการของ

บุคลากรของโครงการตลอดระยะเวลาของโครงการ ว่าได้มีการจัดทาเอกสารตามข้อกาหนดของมาตรฐาน
ISO/IEC 29110 และเป็นไปตามท่แี ผนการดาเนนิ โครงการ (Project Plan) ไดก้ าหนดไว้

(20) การขอเปลีย่ นแปลงความต้องการ (Change Request)
ในการบริหารโครงการ จะต้องบันทึกการขอเปลี่ยนแปลงความต้องการ (Change

Request) ของผู้ใช้งาน หลังจากที่ผู้ใช้งานได้พิจารณาเห็นชอบเอกสารสรุปความต้องการของระบบ
(Requirement Specification) ซง่ึ นักวเิ คราะหแ์ ละออกแบบระบบงานจะต้องวิเคราะห์หาผลกระทบที่ได้จาก
การขอเปลีย่ นแปลง และประเมินระยะเวลาทใี่ ช้ในการดาเนนิ การ

4.2 สาหรับหน่วยงานทใ่ี ช้ตรวจรับการจัดซอ้ื จดั จ้าง
หน่วยงานภาครัฐและรัฐวิสาหกิจจะมีการจัดซ้ือจัดการโครงการในการพัฒนาระบบงาน

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

บทท่ี 4 การนามาตรฐาน ISO/IEC 29110 มาประยุกต์ใชใ้ นหนว่ ยงาน 4-5

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

ภาพที่ 4-2 ข้นั ตอนการนาไปใช้สาหรบั หนว่ ยงานทใี่ ช้ตรวจรบั การจดั ซอ้ื จัดจ้าง 4-6
บทที่ 4 การนามาตรฐาน ISO/IEC 29110 มาประยุกต์ใชใ้ นหน่วยงาน

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

รายละเอยี ดข้นั ตอนการนาไปใชส้ าหรบั หน่วยงานที่ใช้ตรวจรับการจัดซือ้ จดั จา้ ง
(1) ศกึ ษาและจดั ทา TOR

ขั้นตอนน้ีหน่วยงานดาเนินการศึกษารายละเอียดความต้องการระบบและซอฟต์แวร์
เพื่อจัดทาเอกสารข้อกาหนดขอบเขต (Terms of Reference : TOR) ซึ่งควรระบุรายการเอกสารที่ต้องส่ง
มอบตามเอกสาร Work Product ของมาตรฐาน ISO/IEC 29110 เพ่ือใช้ในการจัดซ้ือจัดจ้าง (สามารถดู
ตวั อยา่ งเอกสารขอ้ กาหนดขอบเขตที่ภาคผนวก ค.)

(2) ดาเนินการจัดหาผู้รับจ้างตามระเบียบพัสดุฯ
ข้ันตอนน้ีหน่วยงานดาเนนิ การจดั หาผู้รับจ้างตามระเบียบพัสดุฯ

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

ข้อกาหนดขอบเขตและรายละเอยี ดของการจัดซ้ือจัดจ้าง (TOR)
(4) ตรวจสอบแผนการดาเนนิ โครงการ (Project Plan)
ขั้นตอนน้ีคณะกรรมการตรวจรับการจ้างต้องตรวจสอบแผนในการดาเนินโครงการ

(Project Plan) ว่ามีความเหมาะสมและสอดคล้องกับขอบเขตของระบบงาน (TOR) และมีหัวข้อเป็นไปตาม
ข้อกาหนดของมาตรฐาน ISO/IEC 29110

(5) ตรวจสอบเอกสารยนื ยนั ความต้องการกับผใู้ ช้งาน (Validation Results)
ข้ันตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบเอกสารยืนยันความต้องการกับ

ผใู้ ช้งาน (Validation Result) ว่ามีการยืนยนั ความตอ้ งการครบถ้วนตามเอกสารข้อกาหนดขอบเขต (TOR) ให้
เป็นไปตามขอ้ กาหนดของมาตรฐาน ISO/IEC 29110

(6) ตรวจสอบเอกสารสรปุ ความตอ้ งการของระบบ (Requirements Specification)
ขั้นตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบเอกสารสรุปความต้องการของ

ระบบ (Requirements Specification) ว่าเอกสารได้ผ่านการพิจารณาเห็นชอบ และเป็นไปตามข้อกาหนด
ของมาตรฐาน ISO/IEC 29110

(7) ตรวจสอบเอกสารการออกแบบระบบและซอฟต์แวร์ (System & Software Design)
ข้ันตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบเอกสารการออกแบบระบบและ

ซอฟต์แวร์ (System & Software Design) ที่สอดคล้องกับเอกสารสรุปความต้องการของระบบ
(Requirements Specification) และเปน็ ไปตามข้อกาหนดของมาตรฐาน ISO/IEC 29110

(8) ตรวจสอบเอกสารแสดงตวั อย่างขอ้ มูลทีใ่ ช้ทดสอบ (Test Cases and Test Procedures)
ขั้นตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบเอกสารแสดงตัวอย่างข้อมูลท่ีใช้

ทดสอบ (Test Cases and Test Procedures) ท่ีสอดคล้องกับเอกสารการออกแบบระบบและซอฟต์แวร์
(System & Software Design) และเป็นไปตามขอ้ กาหนดของมาตรฐาน ISO/IEC 29110

บทที่ 4 การนามาตรฐาน ISO/IEC 29110 มาประยุกต์ใช้ในหนว่ ยงาน 4-7

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

(9) ตรวจสอบเอกสารบนั ทึกการตรวจสอบย้อนกลับของระบบ (Traceability Record)
ข้ันตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบเอกสารบันทึกการตรวจสอบ

ย้อนกลับของระบบ (Traceability Record) เพื่อดูว่ามีความสัมพันธ์จากความต้องการ (Requirements)
เชื่อมไปยังการออกแบบ (Design) เชื่อมไปยังโปรแกรม (Components) และเชื่อมไปยังข้อมูลที่ใช้ทดสอบ
(Test Cases) ครบถ้วน และเปน็ ไปตามขอ้ กาหนดของมาตรฐาน ISO/IEC 29110

(10) ตรวจสอบผลการทดสอบระบบงาน (Test Report)
ข้ันตอนน้ีคณะกรรมการตรวจรบั การจ้างต้องตรวจสอบเอกสารผลการทดสอบระบบงาน

(Test Report) เพ่ือดูว่าระบบงานท้ังหมดได้ผ่านการทดสอบมาครบถ้วนพร้อมท่ีจะนาไปใช้งาน และเป็นไป
ตามขอ้ กาหนดของมาตรฐาน ISO/IEC 29110

(11) ทดสอบระบบงานโดยผู้ใช้ (User Acceptance Test)
ขั้ น ต อ น นี้ ค ณ ะ ก ร ร ม ก า ร ต ร ว จ รั บ ก า ร จ้ า ง ด า เ นิ น ก า ร จั ด ห า ตั ว แ ท น ข อ ง ผู้ ใ ช้ ง า น

ดาเนนิ การทดสอบการใช้งานเพอ่ื ใหแ้ นใ่ จว่าระบบงานทสี่ ่งมอบมีความพร้อมท่จี ะนาไปใช้จรงิ
(12) อบรมการใช้งาน (Training)
ข้ันตอนนี้ผู้รับจ้างดาเนินการจัดฝึกอบรมการใช้งานให้กับตัวแทนของหน่วยงาน เพื่อให้

เกดิ ทกั ษะและพร้อมในการใช้งานจริง
(13) ตรวจสอบคู่มือการใชง้ านสาหรบั ผ้ใู ช้งาน (Software User Document)
ข้ันตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบคู่มือการใช้งานสาหรับผู้ใช้งาน

(Software User Document) ว่ามีเนื้อหาที่เหมาะสมเพียงพอที่ผู้ใช้งานนาไปศึกษาการใช้ระบบงาน และ
เปน็ ไปตามข้อกาหนดของมาตรฐาน ISO/IEC 29110

(14) ตรวจสอบคู่มอื ปฏบิ ัตงิ านสาหรบั ผดู้ ูแลระบบ (Product Operation Guide)
ข้ันตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบคู่มือปฏิบัติงานสาหรับผู้ดูแล

ระบบ (Product Operation Guide) ว่ามีเนื้อหาท่ีเหมาะสมเพียงพอที่ผู้ดูแลระบบงานของหน่วยงาน
สามารถนาไปปฏิบตั ใิ นการดูแลการใชง้ าน และเป็นไปตามข้อกาหนดของมาตรฐาน ISO/IEC 29110

(15) ตรวจสอบคู่มอื การบารงุ รกั ษาระบบงาน (Maintenance Document)
ขั้นตอนนี้คณะกรรมการตรวจรับการจ้างต้องตรวจสอบคู่มือการบารุงรักษาระบบงาน

(Maintenance Document) วา่ มีรายละเอียดท่เี พียงพอต่อการเตรียมสภาพแวดลอ้ มในการพัฒนาระบบ และ
การทดสอบระบบ และเปน็ ไปตามข้อกาหนดของมาตรฐาน ISO/IEC 29110

(16) รายงานการประชุม (Meeting Record)
ข้ันตอนน้ีคณะกรรมการตรวจรับการจ้างต้องตรวจสอบรายงานการประชุมว่ามีความ

ถูกต้อง และเป็นไปตามขอ้ กาหนดของมาตรฐาน ISO/IEC 29110

บทที่ 4 การนามาตรฐาน ISO/IEC 29110 มาประยกุ ตใ์ ชใ้ นหน่วยงาน 4-8

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

(17) รายงานความก้าวหน้าของโครงการ (Progress Status Record)
ข้ันต อน น้ี คณะกร รมกา รต รว จรั บการ จ้า งต้องต รว จส อบ รา ยง าน คว ามก้า วห น้า ของ

โครงการ (Progress Status Record) เพ่ือติดตามความก้าวหน้าของโครงการ หากพบปัญหาระหว่างดาเนิน
โครงการที่เก่ียวข้องกับทางหน่วยงาน จะได้ประสานไปยังผู้ท่ีเก่ียวข้องในการแก้ไขปัญหาเพื่อท่ีจะได้ไม่ส่งผล
กระทบการการดาเนนิ โครงการ และเปน็ ไปตามข้อกาหนดของมาตรฐาน ISO/IEC 29110

(18) การตรวจสอบตามข้อกาหนดของมาตรฐาน (Verification Results)
ข้ัน ต อ น นี้ ค ณะกร ร มก า ร ต ร ว จ รั บ กา ร จ้ า ง ต้ อง จั ด ทา ร า ย ง า น ผ ล กา ร ต ร ว จ ส อ บ ต า ม

ข้อกาหนดของมาตรฐาน (Verification Results) เพ่ือแจ้งให้กับทางผู้รับจ้างว่าได้จัดทาเอกสารเป็นไปตาม
ขอ้ กาหนดของมาตรฐาน ISO/IEC 29110

(19) ตรวจรบั ระบบงาน
ขน้ั ตอนนี้คณะกรรมการตรวจรบั การจา้ งดาเนินการตรวจรับงานทผ่ี รู้ ับจา้ งสง่ มอบ

บทที่ 4 การนามาตรฐาน ISO/IEC 29110 มาประยุกตใ์ ชใ้ นหน่วยงาน 4-9

ภาคผนวก ก.

เอกสารอา้ งอิงและส่ิงทเ่ี กีย่ วขอ้ งในสว่ นของ
Project Management

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

Statement of Work

[ชอื่ ระบบงาน]

เวอร์ชนั : 1.0
จัดทาโดย : ชื่อผู้จดั ทา
วันทีจ่ ดั ทาเอกสาร : วันที่

[ชอ่ื ระบบงาน]

ประวตั ิการจัดทาเอกสาร

ลาดับ เวอรช์ ่ัน รายละเอยี ดการดาเนนิ การ ผดู้ าเนินการ ผู้อนุมัติ
(วนั ทด่ี าเนินการ) (วนั ที่อนมุ ตั ิ)
1 0.1 จัดทาขอบเขตการดาเนนิ งาน
(Statement Of Work) ผดู้ าเนินการ AAACCC
(18/03/2559) (21/03/2559)
2 1.0 อนุมตั ขิ อบเขตการดาเนนิ งาน

Proj_Statement_of_Work ก

[ชือ่ ระบบงาน]

สารบัญ

1. วตั ถุประสงค์ของการจัดทา Statement of Work ........................................................................................1
2. วัตถุประสงค์ของโครงการ..............................................................................................................................1
3. ขอบเขตของโครงการ.....................................................................................................................................2

3.1 ขอบเขตของการดาเนินงาน ประกอบด้วย.............................................................................................2
3.2 ระยะเวลาในการดาเนินโครงการ...........................................................................................................2
3.3 งวดงานและงวดเงนิ (ถ้ามี) ....................................................................................................................2
3.4 การรายงานความคบื หน้าของโครงการ..................................................................................................2
3.5 ปจั จัยท่มี ีผลกระทบต่อโครงการ (และงานนอกขอบเขตโครงการ)..........................................................2
4. ข้อตกลงร่วมกัน .............................................................................................................................................3
5. การบรหิ ารการเปลย่ี นแปลง...........................................................................................................................3
6. รายการเอกสารทเี่ ก่ยี วขอ้ ง.............................................................................................................................3

Proj_Statement_of_Work ข

[ช่ือระบบงาน]

ขอบเขตการทางาน

[ช่อื ระบบงานภาษาไทย]
[ช่อื ระบบงานภาษาอังกฤษ (ตัวย่อ)]

1. วัตถปุ ระสงค์ของการจัดทา Statement of Work

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

1.1 ศึกษา วเิ คราะห์ ความต้องการ ให้สอดคล้องกบั วตั ถปุ ระสงค์ของโครงการ
1.2 ปรบั ปรุงขอบเขตของโครงการ ระยะเวลาดาเนินการ สิ่งท่ตี ้องนาสง่ และรายละเอียดตา่ งๆ ทจ่ี าเปน็ ใน

การดาเนนิ โครงการ เพื่อใหม้ ีความเข้าใจที่ถูกต้องตรงกัน ก่อนการเรมิ่ ดาเนนิ โครงการ
1.3 กาหนดขอบเขตของโครงการ ขอ้ ตกลงร่วมกัน แนวทางในการบริหารจัดการ และการแก้ไขปัญหา

ร่วมกันของโครงการ

2. วตั ถุประสงคข์ องโครงการ

2.1 เพ่อื พัฒนาระบบ xxxx ใชภ้ ายในองค์กร เพื่ออานวยความสะดวกในการปฏิบัตงิ านของเจา้ หน้าท่ี และ
เกบ็ ประวัติการดาเนนิ การตา่ งๆ

2.2 Xxxxx

Proj_Statement_of_Work 1/3

[ช่ือระบบงาน]

3. ขอบเขตของโครงการ

ขอบเขตของการพฒั นาระบบ xxxx มรี ายละเอยี ด ดงั ต่อไปนี้
3.1 ขอบเขตของการดาเนินงาน ประกอบด้วย

3.1.1 Xxxxxx
3.1.2 Xxxxxx
3.1.3 Xxxxxx
3.1.4 Xxxxxx

3.2 ระยะเวลาในการดาเนนิ โครงการ
[Work Schedule Overview]

3.3 งวดงานและงวดเงิน (ถา้ มี) งวดเงิน (ถา้ มี)
ลาดับ รายละเอียดของงาน
3.3.1 ส่งมอบเอกสารสรปุ ความตอ้ งการของระบบงาน
3.3.2 ส่งมอบเอกสารการวิเคราะห์และออกแบบระบบงาน
3.3.3 ติดตงั้ ระบบงาน
3.3.4 ทดสอบการใชง้ าน
3.3.5 สง่ มอบระบบงาน และเอกสารของการพฒั นาระบบงาน

3.4 การรายงานความคบื หน้าของโครงการ
ผู้บรหิ ารโครงการ (Project Manager) จะจดั สง่ รายงานการทางาน (Progress Report) ใหก้ บั เจา้ ของ
ระบบงานอยา่ งสม่าเสมอ [เดอื นละ 1 ครั้ง] นับตงั้ แตเ่ รม่ิ โครงการ (Project Kick off)

3.5 ปัจจยั ทีม่ ผี ลกระทบตอ่ โครงการ (และงานนอกขอบเขตโครงการ)
ประกอบดว้ ย
3.5.1 xxxx
3.5.2 xxxx
3.5.3 xxxx

Proj_Statement_of_Work 2/3

[ชอื่ ระบบงาน]

4. ขอ้ ตกลงรว่ มกัน
4.1 ความต้องการจะถูกบริหารจัดการผา่ นกจิ กรรมการบริหารจัดการความต้องการ (System and Software
Requirement Management) ซึ่งเปน็ หน่ึงกระบวนการพัฒนาระบบ (System and Software
Implementation)
4.2 การปรับปรงุ และเปล่ียนแปลงขอบเขตของานจะถูกบรหิ ารจัดการอย่างเปน็ ระบบภายใตก้ รอบของกิจกรรม
ของการบรกิ าร (IT Service Desk) เพ่อื ให้โครงการดาเนนิ การได้อย่างมีประสทิ ธภิ าพ และ แกไ้ ขปัญหาท่ี
อาจเกดิ ขึ้นในการบรหิ ารจดั การ และพัฒนาให้เกดิ การตัดสินใจอย่างเปน็ ระบบซงึ่ เปน็ ส่วนหนึ่งในการ
บริหารจดั การความต้องการเปล่ยี นแปลงหรือเพ่ิมเติม ตามขอ้ 5

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

6. รายการเอกสารที่เกยี่ วขอ้ ง

ลาดับ รายการ
6.1 แผนการดาเนนิ โครงการ (Project Plan)
6.2 เอกสารสรุปความต้องการของระบบงาน (SRS)
6.3 คู่มือสาหรับผใู้ ชง้ าน (User Documentation)
6.4 คูม่ อื สาหรับ Super User (Super User Documentation)

Proj_Statement_of_Work 3/3

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

Project Plan

[ชื่อระบบงาน]

เวอรช์ นั : 1.0
จัดทาโดย : ช่อื ผจู้ ดั ทา
วันที่จัดทาเอกสาร : วนั ท่ี

[ช่ือระบบงาน]

ประวัตกิ ารจัดทาเอกสาร

ลาดบั เวอรช์ ่ัน รายละเอียดการดาเนนิ การ ผูด้ าเนนิ การ ผู้อนมุ ตั ิ
(วันทดี่ าเนินการ) (วันท่ีอนุมัติ)
1 0.1 จดั ทาแผนการดาเนินงาน (Project Plan)
ผู้ดาเนินการ AAACCC
(18/03/2559) (21/03/2559)

2 1.0 อนมุ ัติแผนการดาเนนิ งาน

Proj_Project_Plan ก

[ชื่อระบบงาน]

สารบญั

1. วตั ถุประสงค์ในการจดั ทาแผนบรหิ ารจดั การโครงการ....................................................................................1
2. แนวทางในการบริหารจัดการโครงการ...........................................................................................................1
3. สรุปรายละเอยี ดของความต้องการ ( Detail Requirements) ของระบบ .....................................................1
4. รายการทีต่ ้องส่งมอบตามข้อกาหนดของโครงการ..........................................................................................2
5. โครงสรา้ งคณะทางานในโครงการและความรบั ผิดชอบ

(Project Structure, Role and Responsibility).........................................................................................3
6. ตารางเวลาโครงการ (Project Schedule Details).......................................................................................3
7. อุปกรณ์และเครอื่ งใช้ที่จาเป็นสาหรับโครงการ...............................................................................................4
8. การบริหารจดั การความเสีย่ ง (Risk Factors).................................................................................................4
9. โครงสร้างพนื้ ฐานโครงการ และ คลังสาระสาคญั ของโครงการ และ ระบบคณุ ภาพ

(Project Infrastructure, Repository & Quality Management System)....................................................5
9.1 Project Repository.................................................................................................................................5
9.2 การต้ังชอ่ื ไฟล์ในโครงการ ..........................................................................................................................6
9.3 การควบคมุ Version ของไฟล์ในโครงการ จะแบ่งเปน็ 2 ประเภท คือ Source_Code และ
Document......................................................................................................................................................6
9.4 การ Backup และ Recovery...................................................................................................................7

Proj_Project_Plan ข

[ชอ่ื ระบบงาน]

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

[ชอ่ื ระบบงานภาษาไทย]
[ช่ือระบบงานภาษาอังกฤษ (ตวั ย่อ)]

1. วตั ถุประสงคใ์ นการจัดทาแผนบรหิ ารจัดการโครงการ
1.1 เพอื่ กาหนดแนวทางในการบริหารจัดการ การดาเนนิ การ และตดิ ตามโครงการ
1.2 สรปุ ความตอ้ งการของระบบ (Detail Requirements)
1.3 กาหนดงานท่ีสง่ มอบ ทรัพยากรท่ใี ช้ และตารางการทางาน (Resources Allocation and Project
Scheduling) และการติดตามผลการบรหิ ารจัดการโครงการตามเป้าหมายหลกั (Milestone)
1.4 โครงสรา้ งพ้ืนฐานโครงการและคลงั สาระสาคัญของโครงการ และระบบคุณภาพ (Project Infrastructure,
Repository & Quality Management System)

2. แนวทางในการบริหารจดั การโครงการ
การบริหารจดั การโครงการนีเ้ ปน็ ไปตามแนวทางมาตรฐานสากล วิศวกรรมซอฟต์แวร์และระบบ (International
System & Software Engineering) ภายใต้ ISO/IEC 29110 ซึ่งได้กาหนดกรอบปฏิบัติไว้เป็นแนวปฏิบัติตาม
ภาค 5 (Part 5) ซ่ึงแนวทางในการปฏิบัติตามรายละเอียดของเอกสารน้ี สอดคล้องตามคู่มือปฏิบัติขั้นพื้นฐาน
(Basic) ของกระทรวงเทคโนโลยีสารสนเทศและการสอ่ื สาร ดงั ต่อไปนี้

3. สรปุ รายละเอียดของความต้องการ ( Detail Requirements) ของระบบ
3.1 ความต้องการระบบ (System Requirements)
ลาดบั รายละเอยี ด
1 ระบบต้องสามารถ xxxxx
2 สามารถ …..
3.2 ความตอ้ งการซอฟต์แวร์ (Software Requirements)
ลาดบั รายละเอยี ด
1 ลิขสทิ ธก์ิ ารใชง้ านฐานข้อมูล xxxxx

Proj_Project_Plan 1/7

[ชื่อระบบงาน]

4. รายการท่ีตอ้ งส่งมอบตามข้อกาหนดของโครงการ ประเภท จานวน กาหนดการ
ลาดบั รายละเอียด เอกสาร 1 11/05/2559
เอกสาร 5 31/08/2559
1 แผนดาเนนิ โครงการ DVD 1 31/08/2559
2 สรปุ ความต้องการ SRS เอกสาร 5 31/10/2559
DVD 1 31/10/2559
3 เอกสารการออกแบบระบบ ใบ License 1 15/11/2559

4 ลขิ สิทธ์ิการใชง้ านฐานข้อมูล xxxx

Proj_Project_Plan 2/7

[ช่อื ระบบงาน]

5. โครงสรา้ งคณะทางานในโครงการและความรับผดิ ชอบ (Project Structure, Role and Responsibility)

ชื่อ หน้าที่ (Role) ความรับผิดชอบ จานวนวนั
(Resource) ในโครงการ

นาย ก Project Manager - บริหารจัดการโครงการ

(PM) - ตดิ ตามความก้าวหน้าของโครงการ

นางสาว ข Project Coordinator - ประสานงานระหว่างทมี งานโครงการ

and IT Service Desk - บริหารจัดการความต้องการการเปล่ยี นแปลง

(PCo) - ติดตามและรายงานความคบื หน้าของโครงการ

System Analysis - รวมรวบและสรปุ ความต้องการ

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

- นาเสนอโปรแกรมตน้ แบบ

- ออกแบบ Test Cases และ Test Procedures

Developer - พฒั นาโปรแกรม

(Dev) - ทดสอบโปรแกรมเบอ้ื งต้น

Technical Support - ติดตั้งและดูแลระบบงาน

(Tech) - ตดิ ตง้ั ระบบทใี่ ชใ้ นการพัฒนา (Set up Development

Environment)

Implementer - รวมรวบและสรปุ ความต้องการ

(Imp) - นาเสนอโปรแกรมตน้ แบบ

- ทดสอบโปรแกรม

- ประสานงานการติดตงั้

- จัดทาคู่มือระบบงาน

- อบรมผู้ใชง้ าน

6. ตารางเวลาโครงการ (Project Schedule Details)

ตารางการทางานของโครงการ กาหนดไว้ท่ี Proj_Project_GanttChart_25590318.xlsx

Proj_Project_Plan 3/7

[ชื่อระบบงาน]

7. อปุ กรณแ์ ละเครอ่ื งใช้ทีจ่ าเป็นสาหรบั โครงการ รายละเอียด
ลาดับ

1 เครอ่ื ง Server xxxx
2 Software zzzz

8. การบริหารจัดการความเสยี่ ง (Risk Factors)

ลาดบั ความเส่ียง แนวทางแกป้ ัญหา โอกาสเกดิ ผลกระทบ
24
1 เป็น Tools ทท่ี ีมงานไมค่ นุ้ เคย ส่งไปฝึกอบรม 44

2 Requirement เปลย่ี นตลอด นา Change Request Form มาใช้

โอกาสเกดิ และผลกระทบตอ่ การดาเนนิ งาน : ระบุคา่ 5, 4, 3, 2, 1 (มากไปนอ้ ย)

Proj_Project_Plan 4/7

[ชอื่ ระบบงาน]

9. โครงสรา้ งพนื้ ฐานโครงการ และ คลังสาระสาคัญของโครงการ และ ระบบคณุ ภาพ
(Project Infrastructure, Repository & Quality Management System)
การจัดเก็บองค์ประกอบทีส่ าคัญของโครงการ (Configuration Items) มีความจาเป็นและสาคัญเป็นอย่างย่ิง

ในการบริหารจัดการโครงการ เพ่ือให้โครงการส่งมอบและบารุงรักษาได้อย่างต่อเน่ือง ดังนั้นโครงการนี้จึงได้กาหนด
แนวทางและวิธีการจัดเก็บองค์ประกอบต่างๆ ท่ีจาเป็นในคลังโครงการ (Project Repository) กฎเกณฑ์การต้ังช่ือ
ไฟล์ (Naming Convention) การควบคุม Version การ Backup และ Recovery ดังนี้

9.1 Project Repository
9.1.1 โปรแกรมที่พฒั นา เกบ็ ไว้ท่ี [ServerName\ShareNameDev]

9.1.2 ไฟลท์ เี่ กยี่ วข้องในโครงการน้ี เกบ็ ไวท้ ่ี [ServerName\ShareNameWorkProducts]
โดยมโี ครงสร้างภายใน และสิทธิการเขา้ ถึงข้อมลู ดงั น้ี

Repository Owner

Statement_Of_Work PM
ProjectPlan PM
MeetingRecord PCo
ProgressStatusRecord PCo
ChangeRequest SA
CorrectionRegister PM
AcceptanceRecord PM
VerificationResults SQA
SoftwareConfiguration SA
ValidationResults SA
SoftwareRequirementSpecification SA
SoftwareDesign SA

TraceabilityMatrix SA
SoftwareComponents SA

TestCasesAndTestProcedures SA

TestReport Imp

เจา้ ของเอกสาร (Owner) จะได้สทิ ธิแบบ Full สว่ นคณะทางานในโครงการ สามารถเขา้ ถึงไดแ้ บบ Read Only

Proj_Project_Plan 5/7

[ชื่อระบบงาน]

9.2 การต้งั ช่อื ไฟลใ์ นโครงการ
ไฟล์ต่างๆ ทใ่ี ช้ในโครงการน้ี จะขน้ึ ต้นดว้ ยช่ือย่อของโครงการ [PROJ] ตามดว้ ย _ แลว้ ตามด้วยประเภท
เอกสาร เชน่ โครงการ Government Handbook (ชอื่ ยอ่ GHB) จะตง้ั ชอ่ื ไฟลเ์ ปน็
GHB_Project_Plan.doc, GHB_SRS.doc

9.3 การควบคมุ Version ของไฟล์ในโครงการ จะแบ่งเปน็ 2 ประเภท คอื Source_Code และ Document
9.3.1 Source Code และ Parameter Setup ต่างๆ ของระบบ
- ทกุ ครง้ั ที่มกี ารเปล่ยี นแปลงแก้ไข จะมีการ Update อตั โนมตั ิ ด้วยเครอื่ งมอื ในการบริหารจัดการ
Version Control เชน่ SVN Tools และเม่ือส่งมอบงาน จะกาหนดใหเ้ ป็นท้ังหมดเป็น Version 1.0
จากนนั้ เม่อื จบโครงการ (จบช่วงบารุงรกั ษา) จะกาหนดให้ทงั้ หมดเป็น Version 2.0
9.3.2 Document
- แผนโครงการ (Project Plan) จะถูกกาหนดเป็น Version ตามกระบวนการ Base Line และจะกาหนด
เป็น Version 1.0 เมื่อได้เป็นท่ียอมรับตรงกันในคร้ังแรก หากมีการปรับปรุง Project Plan ในครั้ง
ต่อไป จะปรับ Version ย่อย เช่น 1.1 และดาเนินการในลักษณะน้ีในทุกคร้ังที่มีการปรับปรุง Project
Plan
- สรุปความต้องการที่เกิดข้ึนในโครงการจะถูกรวบรวมมาเป็นข้อกาหนดความต้องการ (System and
Software Requirement Specification : SRS) โดยใชก้ ระบวนการเดยี วกบั การบริหารจัดการเอกสาร
โครงการ ตามกระบวนการ Base Line และการกาหนด Version โดยกาหนดให้ความต้องการใน
Version แรกคือความต้องการที่ได้รับการยอมรับและอนุมัติจากโครงการคร้ังแรก ก่อนนาไปเป็นข้อมูล
ในการวิเคราะห์และออกแบบระบบ เม่ือมีการปรับปรุงรายละเอียดของ Requirement Specification
เม่ือใด Version ย่อย จะถูกปรับ Version ไปอย่างตอ่ เน่อื ง
- กระบวนการบริหารจัดการเพ่ือคุณภาพ สาหรับเอกสารอ่ืนท่ีต้องควบคุม Version เช่น เอกสาร
ออกแบบระบบ (System & Software Design) ใหเ้ ป็นไปในทิศทางเดยี วกนั

Proj_Project_Plan 6/7

[ช่อื ระบบงาน]

9.4 การ Backup และ Recovery
การ Backup จะทาใน 2 ลกั ษณะคอื
1. Daily Backup จะทาการ Backup ทุกวนั เวลา [Time] โดยนาข้อมูลทงั้ หมดจาก Repository ทง้ั หมด
ไปจดั เกบ็ ไว้ท่ี [DailyBackup] ภายใต้ [YYYY-MM-DD] เปน็ ชอ่ื Directory
2. Weekly Backup จะทาการ Backup ทกุ วัน [Date] ของสัปดาห์ เวลา [Time] โดยนาข้อมูลท้งั หมด
จาก Repository ทง้ั หมดไปจัดเก็บไว้ท่ี [WeeklyBackup]

การกู้ข้อมูลคืน (Recovery) สามารถทาได้โดยการนาข้อมูลที่ Backup ไว้มาแทนท่ี โดยการดาเนินการ
ดังกล่าวควรทาด้วยความระมัดระวัง มีการตรวจสอบ และทาการสารองข้อมูลชั่วคราว (Temporary
Backup) ทกุ คร้งั เพือ่ มใิ ห้เกิดความผดิ พลาดของการดาเนินการ

Proj_Project_Plan 7/7