สารบัญ7 หัวข้อหลัก
- 1.ระบบงานประยุกต์ SDLC ความต้องการ และแบบจำลองวิเคราะห์
- 2.การออกแบบซอฟต์แวร์ โครงสร้างข้อมูล และฐานข้อมูล
- 3.สถาปัตยกรรม การติดตั้ง API ตัวตน และการคุ้มครองข้อมูล
- 4.Secure SDLC มาตรฐานความปลอดภัย และช่องโหว่เว็บ
- 5.การเข้าถึงและกลยุทธ์การทดสอบ
- 6.การส่งมอบ ปฏิบัติการ เหตุการณ์ผิดปกติ และการบำรุงรักษา
- 7.Pseudocode ภาษาโปรแกรม และการใช้มาตรฐานเป็นหลักฐาน
ระบบงานประยุกต์ SDLC ความต้องการ และแบบจำลองวิเคราะห์
ความหมาย ขอบเขต และองค์ประกอบของระบบงานประยุกต์ — ระบบงานประยุกต์เป็นระบบซอฟต์แวร์ที่สนับสนุนภารกิจหรือกระบวนงานเฉพาะ การพัฒนาจึงต้องพิจารณาคน กระบวนการ ข้อมูล ซอฟต์แวร์ โครงสร้างพื้นฐาน การควบคุม และผลลัพธ์ทางธุรกิจร่วมกัน มิใช่พิจารณาเฉพาะการเขียนโปรแกรม Outcome มีสาระสําคัญดังนี้ ปัญหา/ภารกิจอะไรดีขึ้น วัดอย่างไร และใครรับผิดผล People/roles มีสาระสําคัญดังนี้ actor, owner, approver, operator, support, data/security owner และผู้ได้รับผลกระทบ วงจรชีวิตซอฟต์แวร์และผลส่งมอบของแต่ละระยะ — ISO/IEC/IEEE 12207:2026 กําหนดกรอบร่วมของกระบวนการตลอดวงจรชีวิตซอฟต์แวร์ ตั้งแต่แนวคิด การจัดหา การพัฒนา การดําเนินงาน การสนับสนุน จนถึงการเลิกใช้ โดยสามารถประยุกต์กระบวนการแบบวนซ้ําและเพิ่มส่วนได้ และไม่ได้บังคับให้ใช้แบบจําลองวงจรชีวิตแบบใดแบบหนึ่ง Initiation/discovery มีรายละเอียดดังนี้ กิจกรรม/คําถาม ได้แก่ problem, stakeholder, scope, feasibility, risk; หลักฐาน/ทางออก ได้แก่ vision, context, outcome metric, option/feasibility,
initial risk แบบจําลองกระบวนการพัฒนาและแนวทางแบบ Agile — แบบจําลอง Waterfall, V-Model, Iterative, Incremental, Spiral, Prototyping และ Agile จัดลําดับการเรียนรู้ การตัดสินใจ และการควบคุมความเสี่ยงต่างกัน การเลือกต้องอาศัยความชัดเจนของความต้องการ ความเสี่ยง ต้นทุนของการเปลี่ยนแปลง ข้อกํากับ และความถี่ที่ต้องส่งมอบคุณค่า Waterfall/sequential มีรายละเอียดดังนี้ เหมาะเมื่อ ได้แก่ scope/technology/acceptance ค่อนข้างนิ่งและ gate/document สําคัญ; ข้อจํากัด ได้แก่ feedback ผู้ใช้/technical risk มาช้าถ้ารอท้าย บทบาท ความรับผิดชอบ และธรรมาภิบาลของทีมพัฒนา — การพัฒนาระบบเป็นงานหลายสาขา บทบาทของเจ้าของผลิตภัณฑ์ ผู้ใช้ นักวิเคราะห์ สถาปนิก นักพัฒนา ผู้ทดสอบ ผู้ดูแลความปลอดภัย ผู้ปฏิบัติการ และผู้อนุมัติต้องมีขอบเขตอํานาจ ผลส่งมอบ และจุดส่งต่องานที่ชัดเจน การพัฒนาระบบสารสนเทศต้องอาศัยทีมงานที่มีทักษะหลากหลาย แต่ละบทบาทมีหน้าที่เฉพาะที่ส่งเสริมกันและกัน การเข้าใจบทบาทเหล่านี้ช่วยให้สามารถวางแผนทรัพยากรและจัดการโครงการได้อย่างมีประสิทธิภาพ
การศึกษาความเป็นไปได้และการกําหนดขอบเขตโครงการ — การศึกษาความเป็นไปได้ต้องประเมินด้านเทคนิค เศรษฐกิจ การปฏิบัติงาน กฎหมาย กําหนดเวลา และความพร้อมขององค์การ โดยเชื่อมสมมติฐาน ต้นทุน ประโยชน์ ความเสี่ยง และเงื่อนไขยุติโครงการเข้ากับหลักฐานที่ตรวจสอบได้ ก่อนที่องค์กรจะลงทุนพัฒนาระบบสารสนเทศใด ๆ จําเป็นต้องทําการศึกษาความเป็นไปได้เสียก่อน เพื่อประเมินว่าโครงการนั้นควรดําเนินการหรือไม่ การวิเคราะห์ความเป็นไปได้แบ่งออกเป็น 5 ด้าน การค้นหา วิเคราะห์ และจัดประเภทความต้องการ — วิศวกรรมความต้องการครอบคลุมการค้นหา วิเคราะห์ ระบุ ตรวจสอบ รับรอง จัดลําดับ และควบคุมการเปลี่ยนแปลง ความต้องการที่ดีต้องจําเป็น ไม่กํากวม สอดคล้อง เป็นไปได้ ตรวจสอบย้อนกลับได้ และทดสอบหรือประเมินการยอมรับได้ Business มีสาระสําคัญดังนี้ ลดเวลารอ/ข้อผิดพลาด/ต้นทุนหรือเพิ่ม compliance—not ชื่อ feature Stakeholder/user มีสาระสําคัญดังนี้ actor ต้องบรรลุ goal/งานใดในบริบทใด Functional มีสาระสําคัญดังนี้ system behavior, rule, workflow, state transition, exception
Use Case, User Story และเกณฑ์การยอมรับ — Use Case อธิบายปฏิสัมพันธ์ระหว่างผู้กระทํากับระบบเพื่อบรรลุเป้าหมาย ส่วน User Story สื่อความต้องการขนาดเล็กจากมุมมองผู้ใช้ ทั้งสองรูปแบบต้องมีบริบท เงื่อนไข และเกณฑ์การยอมรับที่ชัดเจนจึงจะใช้พัฒนาและทดสอบได้ Use case diagram มีรายละเอียดดังนี้ ใช้ทําอะไร ได้แก่ เห็น actor–system goals/boundary ระดับภาพรวม; สิ่งที่ต้องมี ได้แก่ actor, use cases, system boundary และ relation ที่มีความหมาย การตรวจสอบย้อนกลับและการควบคุมการเปลี่ยนแปลง — การตรวจสอบย้อนกลับเชื่อมความต้องการกับแหล่งที่มา การออกแบบ โค้ด การทดสอบ การอนุมัติ และรุ่นที่เผยแพร่ เมื่อมีการเปลี่ยนแปลงต้องวิเคราะห์ผลกระทบ ต้นทุน ความเสี่ยง ลําดับความสําคัญ และหลักฐานการตัดสินใจก่อนปรับเส้นฐาน ลําดับการดําเนินงานประกอบด้วย ระบุ source/owner และเหตุผล → ให้ ID/version กับ requirement/decision → เชื่อม model/ADR/design → เชื่อม code/config/migration → เชื่อม test/evidence → เชื่อม
release/operation metric → เมื่อเปลี่ยนทํา impact analysis และอนุมัติตาม risk แบบจําลองการวิเคราะห์และความสัมพันธ์ระหว่างแผนภาพ — แบบจําลองแต่ละชนิดตอบคําถามต่างกัน ได้แก่ ขอบเขตและผู้เกี่ยวข้อง การไหลของข้อมูล โครงสร้างข้อมูล พฤติกรรม ลําดับข้อความ สถานะ และการติดตั้ง จึงต้องเลือกแผนภาพตามประเด็นที่ต้องสื่อและรักษาความสอดคล้องระหว่างแบบจําลอง Context diagram/DFD มีรายละเอียดดังนี้ ตอบคําถาม ได้แก่ ข้อมูลไหลระหว่างระบบกับใคร/กระบวนการ/data store อย่างไร; องค์ประกอบเด่น ได้แก่ external entity, process, data flow, data store; ต้อง balance ข้ามระดับ แผนภาพกระแสข้อมูล — Data Flow Diagram แสดงแหล่งกําเนิดและปลายทางข้อมูล กระบวนการ แหล่งเก็บข้อมูล และกระแสข้อมูล โดยเน้นการแปลงข้อมูลมากกว่าลําดับเวลา การแตกระดับต้องรักษาสมดุลของกระแสข้อมูลระหว่างระดับแม่กับระดับลูก Data Flow Diagram หรือ DFD คือแผนภาพที่แสดงให้เห็นถึงการไหลของข้อมูลภายในระบบ ว่าข้อมูลมาจากไหน ผ่านกระบวนการอะไรบ้าง และเก็บไว้ที่ใด DFD
เป็นเครื่องมือที่ใช้กันอย่างแพร่หลายในการวิเคราะห์ระบบแบบ Structured Analysis และมีสาระสําคัญมาก แบบจําลองข้อมูล พจนานุกรมข้อมูล และข้อกําหนดกระบวนการ — Entity-Relationship Diagram ใช้อธิบายเอนทิตี แอตทริบิวต์ ความสัมพันธ์ และคาร์ดินัลลิตี พจนานุกรมข้อมูลกําหนดความหมาย รูปแบบ แหล่งที่มา และกฎของข้อมูล ส่วนข้อกําหนดกระบวนการอธิบายตรรกะที่แผนภาพระดับสูงไม่แสดง ERD คือแผนภาพที่ใช้แสดงโครงสร้างข้อมูลของระบบ โดยแสดงให้เห็นว่าระบบมีข้อมูลอะไรบ้าง และข้อมูลแต่ละชนิดมีความสัมพันธ์กันอย่างไร ERD เป็นพื้นฐานของการออกแบบฐานข้อมูล องค์ประกอบหลักของ ERD ได้แก่ Entity คือสิ่งที่เราสนใจเก็บข้อมูล เช่น นักเรียน วิชา ครู สัญลักษณ์คือสี่เหลี่ยม, Attribute คือคุณสมบัติหรือรายละเอียดของ Entity เช่น Entity นักเรียนมี Attribute ได้แก่ รหัสนักเรียน ชื่อ นามสกุล วันเกิด สัญลักษณ์คือวงรี, และ Relationship คือความสัมพันธ์ระหว่าง Entity เช่น นักเรียน "ลงทะเบียน" วิชา สัญลักษณ์คือสี่เหลี่ยมข้าวหลามตัด
- 1กำหนดผลลัพธ์ ผู้ใช้ กระบวนงาน ข้อมูล และข้อจำกัด
- 2ค้นหา วิเคราะห์ จัดลำดับ และรับรองความต้องการ
- 3สร้างแบบจำลองข้อมูล พฤติกรรม ขอบเขต และเกณฑ์ยอมรับ
- 4เลือกสถาปัตยกรรมพร้อมบันทึกเหตุผลและผลแลกเปลี่ยน
- 5พัฒนา ทดสอบ เผยแพร่ และตรวจหลักฐานย้อนกลับ
- 6ติดตามการใช้งาน เหตุการณ์ ความเสี่ยง และปรับระบบรอบต่อไป
การออกแบบซอฟต์แวร์ โครงสร้างข้อมูล และฐานข้อมูล
สถาปัตยกรรมและสถานการณ์คุณลักษณะคุณภาพ — สถาปัตยกรรมกําหนดองค์ประกอบ ความรับผิดชอบ อินเทอร์เฟซ การพึ่งพา และข้อจํากัดสําคัญ คุณลักษณะคุณภาพควรถูกเขียนเป็นสถานการณ์ที่มีแหล่งกระตุ้น สิ่งกระตุ้น สภาพแวดล้อม องค์ประกอบที่ได้รับผล การตอบสนอง และค่าที่วัดได้ ตามกรอบคุณภาพที่เป็นปัจจุบัน เช่น ISO/IEC 25010:2023 Performance มีสาระสําคัญดังนี้ เมื่อ X users ส่ง Y workload ในสภาพ Z, p95 latency/throughput/resource เท่าใด Availability มีสาระสําคัญดังนี้ failure ใดเกิด ระบบตรวจ/กู้/ให้บริการลดรูปภายในเวลาใด บันทึกการตัดสินใจทางสถาปัตยกรรมและการทบทวน — Architecture Decision Record บันทึกบริบท ทางเลือก การตัดสินใจ เหตุผล ผลกระทบ และสถานะ ช่วยให้ทีมทบทวนข้อแลกเปลี่ยนและย้อนกลับไปตรวจเหตุผลเดิมได้โดยไม่พึ่งความทรงจําของบุคคล Context/problem มีสาระสําคัญดังนี้ แรงผลัก constraint, quality scenario, current state Decision มีสาระสําคัญดังนี้ เลือกอะไร ขอบเขตและวันที่/status Options มีสาระสําคัญดังนี้ ทางเลือกที่พิจารณารวม do nothing การออกแบบเชิงโครงสร้าง Cohesion และ Coupling — การออกแบบเชิงโครงสร้างแบ่งระบบเป็นโมดูลที่มีหน้าที่ชัด โดยมุ่งให้ความสัมพันธ์ภายในโมดูลแน่นและการพึ่งพาระหว่างโมดูลต่ํา การพิจารณา Cohesion และ
Coupling ต้องดูชนิดของข้อมูล การควบคุม อินเทอร์เฟซ และผลของการเปลี่ยนแปลงร่วมกัน การออกแบบระบบเป็นขั้นตอนที่แปลงความต้องการของผู้ใช้ที่วิเคราะห์ได้จากขั้นตอนก่อนหน้า ให้กลายเป็นแบบแผนที่นักพัฒนาสามารถนําไปสร้างระบบจริงได้ ขั้นตอนนี้ครอบคลุมตั้งแต่การกําหนดโครงสร้างของโปรแกรม การจัดเก็บข้อมูล ไปจนถึงการออกแบบส่วนที่ผู้ใช้จะมองเห็นและโต้ตอบด้วย การออกแบบที่ดีจะส่งผลโดยตรงต่อความง่ายในการบํารุงรักษา ประสิทธิภาพการทํางาน และความปลอดภัยของระบบในระยะยาว การออกแบบเชิงวัตถุและแผนภาพ UML — UML 2.5.1 เป็นภาษาสําหรับสร้างแบบจําลองโครงสร้างและพฤติกรรม Class Diagram แสดงชนิดและความสัมพันธ์ Sequence Diagram แสดงข้อความตามเวลา Activity Diagram แสดงการไหลของกิจกรรม และ State Machine Diagram แสดงสถานะกับเหตุการณ์เปลี่ยนสถานะ การออกแบบเชิงวัตถุ (Object-Oriented Design: OOD) เป็นแนวทางที่มองระบบในรูปของ "วัตถุ" ที่มีข้อมูล (Attribute) และพฤติกรรม (Method) ในตัวเอง วัตถุต่างๆ โต้ตอบกันผ่านการส่งข้อความ (Message Passing) แนวคิดหลักของ OOD ประกอบด้วย Encapsulation ที่ซ่อนรายละเอียดภายในวัตถุ, Inheritance ที่ให้คลาสลูกรับคุณสมบัติจากคลาสแม่, Polymorphism
ที่ให้วัตถุต่างชนิดตอบสนองต่อข้อความเดียวกันได้ต่างกัน และ Abstraction ที่แสดงเฉพาะสิ่งจําเป็น หลักการเขียนโปรแกรมเชิงวัตถุ — การเขียนโปรแกรมเชิงวัตถุจัดข้อมูลและพฤติกรรมไว้ในวัตถุ หลักสําคัญประกอบด้วยการห่อหุ้ม การทําให้อยู่ในรูปนามธรรม การสืบทอด และพหุสัณฐาน โดยควรใช้ composition เมื่อความสัมพันธ์เป็นการประกอบและไม่จําเป็นต้องผูกกับลําดับชั้นการสืบทอด Encapsulation มีรายละเอียดดังนี้ ความหมาย ได้แก่ ซ่อน representation และรักษา invariant ผ่าน interface; ข้อจํากัดหรือความเสี่ยง ได้แก่ getter/setter ทุก field โดยไม่ปกป้องกฎไม่ใช่ encapsulation ที่มีคุณค่า รูปแบบการออกแบบ หลักการออกแบบ และคุณภาพโค้ด — Design Pattern เป็นรูปแบบแนวทางแก้ปัญหาการออกแบบที่เกิดซ้ํา มิใช่โค้ดสําเร็จรูป การเลือกต้องเริ่มจากเจตนา บริบท แรงที่ขัดกัน และผลแลกเปลี่ยน พร้อมรักษาความเรียบง่าย ความชัดเจน การทดสอบได้ และขอบเขตความรับผิดชอบของหน่วยโปรแกรม Factory Method/Abstract Factory มีรายละเอียดดังนี้ Intent ได้แก่ แยกการสร้างและ family ของ object; ข้อควรระวัง ได้แก่ ไม่ควรสร้าง factory เมื่อ constructor ธรรมดาพอ Builder
มีรายละเอียดดังนี้ Intent ได้แก่ สร้าง object ซับซ้อนทีละขั้น/immutable; ข้อควรระวัง ได้แก่ อาจซ้ํากับ named parameters/validation โครงสร้างข้อมูล ความซับซ้อน และอัลกอริทึม — การเลือกโครงสร้างข้อมูลและอัลกอริทึมต้องพิจารณารูปแบบการเข้าถึง ปริมาณข้อมูล หน่วยความจํา ลําดับข้อมูล และกรณีเลวร้าย Big-O อธิบายอัตราการเติบโตเชิงประมาณ แต่ไม่แทนการวัดจริงหรือต้นทุนคงที่ของระบบเป้าหมาย Array/vector มีรายละเอียดดังนี้ จุดเด่น ได้แก่ random access และ locality ดี; Complexity โดยทั่วไป/เงื่อนไข ได้แก่ index O(1); insert/delete กลาง O(n); dynamic resize amortized ฐานข้อมูลเชิงสัมพันธ์ ERD และการทํา Normalization — การออกแบบฐานข้อมูลเชิงสัมพันธ์เริ่มจากความหมายของข้อมูล คีย์ ข้อจํากัด และความสัมพันธ์ Normalization ลดความซ้ําและความผิดปกติของการเพิ่ม แก้ไข และลบข้อมูล โดยต้องรักษาความถูกต้องและพิจารณารูปแบบการใช้งานจริงก่อนตัดสินใจทํา denormalization ฐานข้อมูลเชิงสัมพันธ์ (Relational Database) จัดเก็บข้อมูลในรูปแบบตาราง (Table หรือ Relation) แต่ละตารางประกอบด้วยคอลัมน์ (Attribute) และแถว (Tuple หรือ Record) ฐานข้อมูลประเภทนี้เป็นที่นิยมที่สุดในระบบราชการและองค์กรทั่วไป เพราะมีมาตรฐาน รองรับ SQL และมีความน่าเชื่อถือสูง
ภาษา SQL และการเข้าถึงข้อมูล — SQL ใช้กําหนดโครงสร้าง จัดการข้อมูล สอบถาม ควบคุมสิทธิ และควบคุมธุรกรรม การเขียนคําสั่งต้องเข้าใจลําดับเชิงตรรกะของการประมวลผล การเชื่อมตาราง การรวมกลุ่ม ค่า NULL ข้อจํากัด และแผนการทํางานของฐานข้อมูล SQL เป็นภาษามาตรฐานสําหรับจัดการฐานข้อมูลเชิงสัมพันธ์ แบ่งออกเป็นกลุ่มคําสั่งหลักได้แก่ DDL (Data Definition Language) สําหรับสร้าง/แก้ไขโครงสร้างตาราง, DML (Data Manipulation Language) สําหรับจัดการข้อมูล และ DCL (Data Control Language) สําหรับจัดการสิทธิ์ ธุรกรรม ACID, MVCC, Isolation และ CAP — ธุรกรรมรักษาคุณสมบัติ Atomicity, Consistency, Isolation และ Durability ส่วน MVCC ช่วยจัดการเวอร์ชันข้อมูลเพื่อรองรับงานพร้อมกัน ระดับ isolation กําหนดปรากฏการณ์ที่ยอมรับได้ ขณะที่ CAP ใช้อธิบายข้อจํากัดของระบบกระจายเมื่อเกิด network partition มิได้หมายความว่าระบบเลือกคุณสมบัติเพียงสองข้ออย่างตายตัวในทุกเวลา Atomicity มีรายละเอียดดังนี้ ความหมาย ได้แก่ ทั้ง Transaction สําเร็จหรือผลเขียนถูก Undo ทั้งหน่วย; กลไกตัวอย่าง ได้แก่ log/rollback Consistency มีรายละเอียดดังนี้ ความหมาย ได้แก่
Transaction พาฐานจาก State ที่ Constraints จริงไปอีก State ที่จริง หาก Logic ถูก; กลไกตัวอย่าง ได้แก่ constraints/application/transaction การสํารองข้อมูล RPO, RTO และการกู้คืน — แผนสํารองข้อมูลต้องเชื่อมชนิดการสํารอง ความถี่ การเก็บนอกระบบ การเข้ารหัส การตรวจสอบความสมบูรณ์ และการทดสอบกู้คืนกับ Recovery Point Objective และ Recovery Time Objective การมีไฟล์สํารองโดยไม่เคยทดสอบกู้คืนยังไม่ถือว่าเป็นความพร้อม Full backup มีรายละเอียดดังนี้ ความหมาย ได้แก่ สําเนาข้อมูลทั้งหมดในขอบเขต; ข้อควรระวัง ได้แก่ — Incremental มีรายละเอียดดังนี้ ความหมาย ได้แก่ การเปลี่ยนตั้งแต่ Backup ก่อนตามรูปแบบ; ข้อควรระวัง ได้แก่ — การเปลี่ยนแปลงสคีมา การย้ายข้อมูล และการกระทบยอด — การเปลี่ยนแปลงฐานข้อมูลต้องออกแบบให้เข้ากันได้ระหว่างรุ่น แยกขั้นขยาย เติมข้อมูล สลับการใช้งาน และขั้นเก็บกวาด พร้อมตรวจนับ แฮช ยอดรวม ตัวอย่างข้อมูล ข้อผิดพลาด และแนวทางย้อนกลับก่อนปิดงาน Design มีสาระสําคัญดังนี้ compatibility หลาย app version, lock/space/time, constraint/index, privacy และ recovery Test data มีสาระสําคัญดังนี้ ใช้ข้อมูลขนาด/shape/edge case ใกล้จริงโดย mask/synthetic ตามนโยบาย
เนื้อหาสรุปนี้จัดทำขึ้นเพื่อการศึกษาส่วนบุคคล ห้ามคัดลอก ทำซ้ำ หรือนำไปใช้เพื่อวัตถุประสงค์ทางการค้าโดยไม่ได้รับอนุญาต