SA – สรุปเนื้อหาวิชา System Analysis and Design

1 ระบบสารสนเทศ, บทบาทของ SA และระเบียบวิธีการพัฒนา (System Analysis & Methodology)

🎯 ครูบอก: บทที่ 1 เป็นปูพื้นฐานที่สำคัญที่สุดของวิชา SA! อาจารย์เน้นออกสอบ 3 เรื่องหลัก: (1) Five-Component Model & ประเภทของระบบสารสนเทศ (TPS, MIS, DSS, ESS) (2) บทบาทของ SA vs. Programmer และ (3) ขั้นตอน SDLC / Waterfall เปรียบเทียบกับ Agile จำโครงสร้างนี้ให้แม่นนะครับ!

1. พื้นฐานระบบสารสนเทศ (Information System Fundamentals)

1.1 ระบบ (System) คืออะไร?

ระบบ (System) คือ กลุ่มขององค์ประกอบที่ทำงานร่วมกัน มีปฏิสัมพันธ์กัน เพื่อบรรลุเป้าหมายหรือวัตถุประสงค์เดียวกัน โดยมีโครงสร้างการทำงาน 4 ขั้นตอน: Input ➔ Processing ➔ Output ➔ Feedback Control

1.2 ข้อมูล (Data) vs. สารสนเทศ (Information)

หัวข้อ	ข้อมูล (Data)	สารสนเทศ (Information)
ความหมาย	ข้อเท็จจริงดิบ (Raw Facts) ที่ยังไม่ผ่านการจัดหมวดหมู่หรือประมวลผล	ข้อมูลที่ผ่านการประมวลผล มีบริบท และนำไปใช้ตัดสินใจได้จริง
ลักษณะ	ตัวเลข ตัวอักษร สัญลักษณ์ หรือภาพถ่ายดิบๆ	รายงาน สรุปสถิติ กราฟ หรือแนวโน้ม
ตัวอย่างร้านกาแฟ	ตัวเลขยอดขายรายแก้ว: 60, 60, 75, 55, 60	"เมนู อเมริกาโน่เย็น มียอดขายสูงสุด 45% ในช่วงเวลา 08:00 - 10:00 น."

1.3 องค์ประกอบของระบบสารสนเทศ (Five-Component Model)

ระบบสารสนเทศไม่ได้หมายถึงเพียงแค่ซอฟต์แวร์หรือคอมพิวเตอร์ แต่เกิดจากองค์ประกอบ 5 ส่วนที่ต้องทำงานร่วมกันอย่างสมบูรณ์:

1. Hardware
อุปกรณ์กายภาพ เช่น คอมพิวเตอร์, เครื่อง POS, แท็บเล็ตรับออเดอร์, เครื่องพิมพ์ใบเสร็จ, เครื่องสแกนบาร์โค้ด

2. Software
ชุดคำสั่งและโปรแกรม เช่น ระบบปฏิบัติการ (OS), ระบบจัดการฐานข้อมูล (DBMS), แอปพลิเคชัน POS

3. Data
ข้อมูลที่ระบบจัดเก็บ เช่น ตารางสินค้า, ราคากาแฟ, ข้อมูลสมาชิก, ประวัติรายการขาย, ยอดวัตถุดิบคงเหลือ

4. Procedures
ขั้นตอนการปฏิบัติงานและคู่มือ เช่น ขั้นตอนเปิด-ปิดร้านประจำวัน, วิธีบันทึกคืนเงิน, ขั้นตอนตรวจสอบสต็อก

5. People
บุคลากรผู้ใช้งานและเกี่ยวข้อง เช่น ลูกค้า, บาริสต้า, เจ้าของร้าน, SA, โปรแกรมเมอร์, ผู้ดูแลระบบ

1.4 ประเภทของระบบสารสนเทศในองค์กร (Types of Information Systems) — ⭐ ออกสอบบ่อย!

ระบบสารสนเทศแบ่งตามระดับการใช้งานและการบริหารจัดการในองค์กรออกเป็น 4 ระดับหลัก:

ประเภทระบบ	ระดับการใช้งาน	วัตถุประสงค์หลัก	ตัวอย่างการใช้งานจริง
TPS (Transaction Processing System)	ระดับปฏิบัติการ (Operational Level)	บันทึกรายการประจำวัน (Daily Transactions) ให้ถูกต้อง รวดเร็ว และเป็นปัจจุบัน	ระบบบันทึกการขายหน้าร้าน (POS), ระบบฝาก-ถอนเงิน ATM, ระบบสแกนจ่าย PromptPay
MIS (Management Information System)	ระดับบริหารจัดการ (Tactical Level / Mid-Management)	สรุปข้อมูลจาก TPS ออกเป็นรายงานประจำวัน/สัปดาห์/เดือน เพื่อควบคุมและติดตามงาน	รายงานสรุปยอดขายแยกตามสาขา, รายงานวัตถุดิบใกล้หมดอายุ, สถิติมียอดขายประจำเดือน
DSS (Decision Support System)	ระดับผู้ตัดสินใจ (Decision-Making Level)	ช่วยวิเคราะห์ทางเลือกในสถานการณ์กึ่งโครงสร้าง (Semi-structured) ด้วยแบบจำลอง What-if	การวิเคราะห์ "ถ้าปรับขึ้นราคากาแฟ 10% จะกระทบกำไรและยอดขายอย่างไร", ระบบวางแผนการจัดส่งสินค้า
ESS / EIS (Executive Support System)	ระดับบริหารสูงสุด (Strategic Level / Top Executive)	สนับสนุนการวางแผนเชิงกลยุทธ์ระยะยาว สรุปข้อมูลภาพรวมผ่าน Dashboard และข้อมูลภายนอก	Executive Dashboard แสดงส่วนแบ่งตลาด, สรุปผลกำไรขาดทุนรวมทุกสาขาทั่วประเทศ, แนวโน้มคู่แข่ง

🔑 ข้อสังเกตลำดับความเชื่อมโยง (GIGO Principle):

TPS (เก็บบันทึกข้อมูล) ➔ MIS (สรุปรายงาน) ➔ DSS (วิเคราะห์ทางเลือก) ➔ ESS (วางแผนกลยุทธ์)

หากข้อมูลระดับ TPS มีความผิดพลาด (Garbage In) สารสนเทศในระดับ MIS, DSS และ ESS ทั้งหมดก็จะผิดพลาดไปด้วย (Garbage Out)

1.5 เทคโนโลยีสารสนเทศยุคใหม่

Cloud Computing: บริการประมวลผลและจัดเก็บข้อมูลผ่านอินเทอร์เน็ต ทำให้ระบบเข้าถึงได้จากทุกสาขา ลดภาระการดูแล Server ในร้าน
Artificial Intelligence (AI): วิเคราะห์ข้อมูลเพื่อคาดการณ์ เช่น AI แนะนำเมนูกาแฟที่ลูกค้าน่าจะชอบจากประวัติการซื้อ
Big Data Analytics: วิเคราะห์ข้อมูลขนาดใหญ่และหลากหลายแหล่ง เช่น ข้อมูลพฤติกรรมลูกค้าบน Social Media เพื่อวางแผนโปรโมชัน

2. จากปัญหาธุรกิจสู่ระบบสารสนเทศ (Business Problem to IS)

2.1 บทบาทของนักวิเคราะห์ระบบ (Systems Analyst: SA)

นักวิเคราะห์ระบบ (SA) คือ ผู้เชื่อมช่องว่างระหว่าง ผู้ใช้งานทางธุรกิจ (Business Users) และ ทีมพัฒนาเทคนิค (Technical Team) ทำหน้าที่วิเคราะห์ปัญหาและออกแบบระบบแก้ปัญหาที่ตอบโจทย์องค์กร

1. Agent of Change
เป็นผู้นำการเปลี่ยนแปลง ชี้ให้เห็นปัญหาและโอกาสในการปรับปรุงกระบวนการทำงาน

2. Problem Analyst
สืบค้นหาต้นตอของปัญหาที่แท้จริง ไม่ใช่แก้เฉพาะอาการภายนอก

3. Requirements Facilitator
สัมภาษณ์ จัดประชุม สังเกตการณ์ และสรุปความต้องการของผู้ใช้ให้ชัดเจน

4. System Designer
ออกแบบกระบวนการ (DFD), ฐานข้อมูล (ERD), และหน้าจอ (UI Mockup)

5. Communicator
แปลภาษาธุรกิจให้โปรแกรมเมอร์เข้าใจ และอธิบายข้อจำกัดทางเทคนิคให้ผู้ใช้เข้าใจ

ประเด็น	นักวิเคราะห์ระบบ (SA)	โปรแกรมเมอร์ (Programmer)
จุดเน้นหลัก	เน้นปัญหาธุรกิจ, ความต้องการผู้ใช้, และการออกแบบโครงสร้างภาพรวม (WHAT & WHY)	เน้นการเขียนโค้ดภาษาคอมพิวเตอร์, อัลกอริทึม, และการทำให้ระบบทำงานตามแบบ (HOW)
ผลงานหลัก (Deliverables)	เอกสาร SRS, DFD Diagram, ER Diagram, UI Prototype	Source Code, Executable Program, Unit Test Cases

2.2 ทำไมต้องทำ SA&D ก่อนลงมือเขียนโค้ด?

🏗️ เปรียบเสมือนการสร้างบ้าน: การเขียนโปรแกรมโดยไม่วิเคราะห์และออกแบบ เหมือนการก่อสร้างโดยไม่มีพิมพ์เขียว อาคารอาจถล่มหรือใช้งานจริงไม่ได้
🛡️ ลดความเสี่ยงทำระบบผิดโจทย์: ช่วยให้มั่นใจว่าระบบใหม่แก้ปัญหาธุรกิจได้จริง
💰 ประหยัดต้นทุนการแก้ไข: ข้อผิดพลาดที่พบในขั้นตอนการวิเคราะห์มีต้นทุนการแก้ไขต่ำกว่าข้อผิดพลาดที่พบหลังติดตั้งระบบใช้งานจริงหลายสิบเท่า

2.3 กรณีศึกษาจากสไลด์อาจารย์ (Case Studies)

Blend and Blew (ร้านกาแฟ): ใช้การจดออเดอร์ด้วยกระดาษ ทำให้ช่วงเร่งด่วนจดผิด คิดเงินพลาด ไม่รู้สต็อก ➔ แก้ไขโดยการนำระบบ POS (TPS) บันทึกออเดอร์อัตโนมัติ + รายงาน MIS สรุปเมนูขายดี + ระบบ Inventory ตัดสต็อกวัตถุดิบ
Hoosier Burger (ร้านอาหารด่วน): ใช้แรงงานคนจดออเดอร์และคลังสินค้า ➔ ปรับเปลี่ยนจาก Manual System สู่ระบบรับคำสั่งซื้อดิจิทัล
Pine Valley Furniture (ธุรกิจเฟอร์นิเจอร์): ข้อมูลแฟ้มแยกส่วนซ้ำซ้อน ➔ รวมศูนย์ฐานข้อมูลและขยายสู่ WebStore/Mobile App

3. วงจรการพัฒนาระบบ (SDLC - Software Development Life Cycle)

SDLC คือ กรอบแนวคิดที่กำหนดขั้นตอนลำดับการพัฒนาระบบตั้งแต่เริ่มต้นจนบำรุงรักษา ประกอบด้วย 5 ขั้นตอนหลัก:

1. Systems Planning (การวางแผนระบบ): กำหนดขอบเขตโครงการ วิเคราะห์ความเป็นไปได้ (Feasibility Analysis) ทำ Project Charter และขออนุมัติโครงการ
2. Systems Analysis (การวิเคราะห์ระบบ): เก็บรวบรวมความต้องการ (Requirements Gathering), วิเคราะห์กระบวนการปัจจุบัน (As-Is Model) และกำหนดความต้องการระบบใหม่ (To-Be Model / DFD Level 0-1)
3. Systems Design (การออกแบบระบบ): ออกแบบเชิงตรรกะและกายภาพ ได้แก่ ฐานข้อมูล (ERD / Normalization), ส่วนติดต่อผู้ใช้ (UI/UX), และสถาปัตยกรรมระบบ
4. Systems Implementation (การพัฒนาและติดตั้ง): เขียนโค้ดโปรแกรม, ทดสอบระบบ (Unit Test, Integration Test, System Test, UAT), อบรมผู้ใช้ และเปลี่ยนผ่านระบบ (Cutover/Conversion)
5. Systems Security, Support & Maintenance (การดูแลและบำรุงรักษา): แก้ไขข้อผิดพลาด (Bug Fixing), ปรับปรุงประสิทธิภาพ และอัปเดตระบบตามกฎหมายหรือธุรกิจที่เปลี่ยนไป

4. Waterfall Model และระเบียบวิธีพัฒนาทางเลือก (Development Methodologies)

4.1 Waterfall Model (แบบจำลองน้ำตก)

Waterfall เป็นระเบียบวิธีพัฒนาแบบดั้งเดิมที่ดำเนินงานตาม SDLC เรียงลำดับจากบนลงล่างทีละขั้นตอนเหมือนน้ำตก — ต้องทำขั้นตอนก่อนหน้าให้เสร็จและเซ็นรับรองเอกสารก่อนเริ่มขั้นตอนถัดไป

✅ ข้อดี: โครงสร้างชัดเจน เอกสารสมบูรณ์ ติดตามความก้าวหน้าง่าย เหมาะกับทีมขนาดใหญ่
❌ ข้อเสีย: ยืดหยุ่นน้อย ย้อนกลับแก้ไขยาก ผู้ใช้เห็นระบบจริงช้ามาก (ช่วงท้ายของโครงการ)
🎯 ความเหมาะสม: เหมาะกับโครงการที่ Requirement ชัดเจนแน่นอน เทคโนโลยีคุ้นเคย และเปลี่ยนแปลงน้อย (เช่น ระบบบัญชี, ระบบงานราชการ)

4.2 ตารางเปรียบเทียบ Methodology พื้นฐาน 5 รูปแบบ (ออกสอบ!)

Methodology	ลักษณะเด่น	เหมาะกับโครงการลักษณะใด	ข้อควรระวัง / จุดอ่อน
Waterfall	ทำทีละขั้นตอน เอกสารครบถ้วน ควบคุมแผนงานง่าย	Requirement ชัดเจนแน่นอน ไม่ค่อยเปลี่ยนแปลง	ยืดหยุ่นน้อย ผู้ใช้เห็นระบบช้า เสี่ยงไม่ตรงใจตอนท้าย
Prototyping	สร้างต้นแบบหน้าจอ/ระบบให้ผู้ใช้ทดลองและปรับแก้ไข	ผู้ใช้ยังนึกภาพระบบไม่ออก หรือเน้น UI/UX สัมผัสได้	ผู้ใช้อาจเข้าใจผิดว่าต้นแบบคือระบบจริงที่พร้อมใช้
JAD (Joint Application Design)	จัดเวิร์กช็อปประชุมร่วมระหว่าง ผู้ใช้ + ผู้บริหาร + SA	ต้องการสรุปความต้องการอย่างรวดเร็วและลดข้อขัดแย้ง	ต้องเตรียมการดีและใช้เวลาผู้บริหารระดับสูงเข้าร่วม
RAD (Rapid Application Dev)	ผสมผสาน JAD + Prototyping + CASE Tools เพื่อพัฒนาเร็ว	โครงการขนาดเล็ก-กลาง ขอบเขตชัดเจนและต้องการใช้ด่วน	ไม่เหมาะกับระบบใหญ่ที่มีสถาปัตยกรรมซับซ้อนมาก
Agile (Scrum / XP / Kanban)	ทำงานเป็นรอบสั้นๆ (Sprint) ส่งมอบระบบที่ทำงานได้จริงเรื่อยๆ	Requirement เปลี่ยนแปลงบ่อย โครงการนวัตกรรมยุคใหม่	ต้องมีผู้ใช้งานร่วมทำงานใกล้ชิดและทีมมีวินัยสูงมาก

🧠 แบบฝึกหัดทบทวน — บทที่ 1: SA & Methodology

ข้อ 1: จงอธิบายความแตกต่างระหว่าง TPS, MIS, DSS และ ESS พร้อมบอกว่าถ้าข้อมูลใน TPS ผิดพลาดจะส่งผลอย่างไร?

ข้อ 2: องค์ประกอบ 5 ส่วนของ Five-Component Model มีอะไรบ้าง? จงระบุองค์ประกอบของระบบตู้ ATM

ข้อ 3: บทบาทของ Systems Analyst (SA) ต่างจาก Programmer อย่างไร?

ข้อ 4: เหตุใดเราจึงต้องทำ Systems Analysis & Design ก่อนลงมือเขียนโค้ดโปรแกรม?

ข้อ 5: เปรียบเทียบ Waterfall Model และ Agile Methodology ในแง่ความยืดหยุ่นและประเภทโครงการที่เหมาะสม

2 การวิเคราะห์ปัญหาธุรกิจและความเป็นไปได้ของโครงการ

การระบุปัญหาทางธุรกิจ — PIECES Framework

ใช้ PIECES เป็นเครื่องมือช่วยวิเคราะห์ปัญหาของระบบเดิมอย่างเป็นระบบ:

หมวด	คำเต็ม	ตัวอย่างคำถาม/ปัญหา
P	Performance (ประสิทธิภาพ)	ระบบทำงานช้า ประมวลผลไม่ทันเวลา
I	Information (ข้อมูล)	ข้อมูลไม่ถูกต้อง ไม่ครบถ้วน ซ้ำซ้อน
E	Economics (เศรษฐศาสตร์)	ต้นทุนสูงเกินไป ไม่คุ้มค่า
C	Control (การควบคุม)	ขาดการรักษาความปลอดภัยข้อมูล
E	Efficiency (ประสิทธิผล)	ใช้ทรัพยากรมากเกินความจำเป็น
S	Service (บริการ)	ระบบไม่ตอบสนองความต้องการผู้ใช้

เจาะลึกการระบุปัญหาทางธุรกิจ (PIECES Framework)

PIECES Framework เป็นหัวใจสำคัญที่ช่วยให้นักวิเคราะห์ระบบค้นหาปัญหาในระบบเดิม (As-Is System) ได้อย่างครอบคลุมรอบด้านค่ะ ครูสรุปคำจำกัดความอย่างละเอียดมาให้ดังนี้:

Performance (ประสิทธิภาพ): วิเคราะห์ความเร็วของการตอบสนอง (Response Time) และปริมาณงานที่ประมวลผลได้ต่อหน่วยเวลา (Throughput) ของระบบ เช่น ระบบค้นหาข้อมูลสินค้าใช้เวลาเกิน 10 วินาที
Information (ข้อมูลสารสนเทศ): ดูเรื่องคุณภาพข้อมูลดิบและสารสนเทศที่ระบบส่งมอบ เช่น ข้อมูลล่าช้า ข้อมูลผิดพลาดไม่ถูกต้อง รายงานมีโครงสร้างอ่านยาก หรือข้อมูลมีความซ้ำซ้อนกันมาก
Economics (เศรษฐศาสตร์): ประเมินต้นทุนและผลประโยชน์ เช่น ต้นทุนในการจัดเก็บเอกสารสูงเกินไป หรือควบคุมงบการทำงานลำบาก
Control (การควบคุมความปลอดภัย): ตรวจสอบว่าระบบมีระบบป้องกันเพียงพอหรือไม่ ขาดการกำหนดสิทธิ์ในการเข้าถึงข้อมูล ข้อมูลลูกค้ารั่วไหลง่าย หรือมีการควบคุมดูแลที่ไม่รัดกุม
Efficiency (ประสิทธิผลการทำงาน): ดูเรื่องความสิ้นเปลืองของทรัพยากร เช่น พนักงานต้องคีย์ข้อมูลซ้ำๆ บนระบบเดิม เสียเวลาและแรงงานโดยเปล่าประโยชน์
Service (การบริการ): ตรวจสอบว่าระบบตอบสนองความต้องการของผู้ใช้และลูกค้าได้ครบถ้วนหรือไม่ ระบบใช้งานยากและซับซ้อนเกินไป

การประเมินความเป็นไปได้เชิงลึก (Feasibility Studies)

การวิเคราะห์ความเป็นไปได้เพื่อขออนุมัติจัดตั้งโครงการ จะประเมินจากปัจจัยรอบด้านดังนี้ค่ะ:

1. Technical Feasibility (ความเป็นไปได้ทางเทคนิค)

ประเมินความเสี่ยงและขีดความสามารถด้านเทคโนโลยีขององค์กรและทีมพัฒนา โดยเน้นตอบคำถามหลัก:

ทีมพัฒนาซอฟต์แวร์มีความคุ้นเคยหรือเชี่ยวชาญในเทคโนโลยีที่จะนำมาใช้พัฒนาหรือไม่? (เช่น การเลือกใช้ AI หรือภาษาเขียนโปรแกรมใหม่)
ความเสี่ยงด้านขนาดของระบบ: ระบบมีขนาดใหญ่เกินกว่าที่เคยพัฒนามาก่อนหรือไม่?
ฮาร์ดแวร์ ซอฟต์แวร์ และโครงสร้างพื้นฐานเครือข่ายเดิมสามารถรองรับระบบใหม่ได้หรือไม่?

2. Economic Feasibility (ความเป็นไปได้ทางเศรษฐศาสตร์)

เป็นการเปรียบเทียบระหว่างต้นทุน (Costs) และผลตอบแทนเชิงตัวเลข (Benefits) ของระบบใหม่ เพื่อคำนวณความคุ้มค่าของการลงทุน (Cost-Benefit Analysis) โดยใช้เกณฑ์ทางเศรษฐศาสตร์ที่สำคัญ:

Payback Period (ระยะเวลาคืนทุน): ระยะเวลาที่ผลตอบแทนสะสมเท่ากับเงินลงทุนเริ่มต้น (ปี/เดือน) ยิ่งคืนทุนเร็วเท่าไหร่ โครงการก็ยิ่งน่าสนใจและมีความเสี่ยงต่ำลงค่ะ
สูตรเบื้องต้น: เงินลงทุนทั้งหมด / ผลตอบแทนสุทธิเฉลี่ยต่อปี
ROI (Return on Investment - อัตราผลตอบแทนจากการลงทุน): อัตรากำไรสุทธิเทียบกับเงินลงทุนเริ่มต้น คิดเป็นร้อยละ
สูตร: (ผลประโยชน์สุทธิทั้งหมด - ต้นทุนสะสมทั้งหมด) / ต้นทุนสะสมทั้งหมด * 100%
NPV (Net Present Value - มูลค่าปัจจุบันสุทธิ): เนื่องจากเงินมีมูลค่าตามเวลา (Time Value of Money) ค่า NPV จึงเป็นการคำนวณโดยลดมูลค่าผลประโยชน์ในอนาคตกลับมาเป็นมูลค่าปัจจุบันตามอัตราคิดลด (Discount Rate) หาก NPV มีค่าเป็นบวก (NPV > 0) แสดงว่าโครงการนี้น่าลงทุนและคุ้มค่าค่ะ

3. Operational Feasibility (ความเป็นไปได้ทางปฏิบัติการ)

วิเคราะห์ว่าเมื่อระบบสร้างเสร็จแล้ว จะถูกนำไปใช้งานได้จริงและเกิดประโยชน์ตามเป้าหมายขององค์กรหรือไม่ โดยมีหัวข้อการพิจารณา เช่น:

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

4. Legal Feasibility (ความเป็นไปได้ด้านกฎหมายและข้อบังคับ)

เป็นการตรวจสอบว่าโครงการพัฒนาระบบนี้ขัดกับกฎหมาย สัญญาสิทธิบัตร ลิขสิทธิ์ซอฟต์แวร์ หรือข้อกำหนดทางจรรยาบรรณใดๆ หรือไม่ ประเด็นสำคัญในยุคปัจจุบัน ได้แก่:

การละเมิดลิขสิทธิ์ซอฟต์แวร์ หรือเทคโนโลยีที่นำมาพัฒนา
การปฏิบัติตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล (เช่น PDPA ของไทย หรือ GDPR ของต่างประเทศ) ในการเก็บรักษาข้อมูลผู้ใช้และลูกค้า
สัญญากับพาร์ทเนอร์และข้อตกลงระดับบริการ (SLA)

🔑 Schedule Feasibility (ความเป็นไปได้ด้านเวลา) บางครั้งถูกเพิ่มเป็นมิติที่ 5 — เพื่อตรวจสอบว่าโครงการสามารถทำเสร็จตามกรอบเวลาที่กำหนดได้จริงหรือไม่

การทำ Business Case

เอกสารเพื่อนำเสนอผู้บริหาร ประกอบด้วย:

คำอธิบายปัญหาและโอกาสทางธุรกิจ
ทางเลือกที่เป็นไปได้ (Alternatives)
ต้นทุนและผลประโยชน์ของแต่ละทางเลือก
ข้อเสนอแนะ (Recommendation)
แผนการดำเนินงานเบื้องต้น

⚠️ ข้อสอบมักถาม: ให้วิเคราะห์กรณีศึกษาโดยใช้ PIECES, คำนวณ ROI/NPV/Break-even/Payback, และเปรียบเทียบ Feasibility ทั้ง 4 ด้าน (Technical, Economic, Operational, Legal)

🏋️ คำถามทบทวนความรู้ประจำบทที่ 2

มาซ้อมวิเคราะห์โจทย์ทางธุรกิจและศึกษาความเป็นไปได้กันนะคะนักศึกษา (คลิกเพื่อเปิดดูแนวคิดเฉลยได้เลยค่ะ):

โจทย์ข้อที่ 1: วิเคราะห์ปัญหาด้วย PIECES Framework

คำถาม: พนักงานบริการลูกค้าบ่นว่า "ทุกวันนี้ต้องกรอกข้อมูลส่วนตัวลูกค้าคนเดิมซ้ำซ้อนกันในหลายระบบ ทำให้ทำงานล่าช้า และข้อมูลที่อยู่ไม่ตรงกันในบางตาราง" จงระบุว่าประโยคนี้มีปัญหาในหมวดหมู่ใดตามหลัก PIECES และให้แนวทางแก้ไขคร่าวๆ ค่ะ

โจทย์ข้อที่ 2: NPV vs Payback Period

คำถาม: หากคุณต้องเลือกอนุมัติระหว่าง 2 โครงการดังนี้:
- โครงการ A: มีระยะเวลาคืนทุน (Payback Period) เร็วมากเพียง 1 ปี แต่เมื่อคำนวณ NPV ตลอดอายุ 5 ปีแล้วได้ค่า ติดลบ (-50,000 บาท)
- โครงการ B: มีระยะเวลาคืนทุนช้ากว่าคือ 3.5 ปี แต่มีค่า NPV ตลอด 5 ปีเป็น บวก (+200,000 บาท)
ในฐานะนักวิเคราะห์ระบบที่ต้องการเสนอผลประโยชน์สูงสุดแก่องค์กร คุณจะแนะนำให้ลงทุนในโครงการใด เพราะเหตุใด?

โจทย์ข้อที่ 3: ความแตกต่างของ Feasibility ด้านต่างๆ

คำถาม: หากบริษัทของคุณต้องการนำเสนอบริการวิเคราะห์ข้อมูลเครดิตลูกค้าด้วยการเชื่อมโยงระบบเข้ากับฐานข้อมูลสาธารณะของประเทศ SA ทำการวิเคราะห์ว่า "ระบบสามารถเขียนเชื่อมต่อได้ง่ายด้วยภาษา Python" แต่พอลองเสนอกรรมการ ฝ่ายกฎหมายกลับบอกว่า "ไม่สามารถทำได้เนื่องจากติดข้อจำกัดด้านความยินยอมข้อมูลลูกค้าส่วนบุคคล" ปัญหานี้แสดงถึงความล้มเหลวในการศึกษาความเป็นไปได้ในมิติใด?

📝 บันทึกส่วนตัว — บทที่ 2

✓ บันทึกอัตโนมัติแล้ว

3 การวางแผนโครงการ และแบบจำลองกระบวนการ (Project Planning & Process Modeling)

1. แผนภาพกระแสข้อมูล (DFD – Data Flow Diagram)

DFD เป็นเครื่องมือในการวิเคราะห์ระบบที่ใช้แสดงการไหลของข้อมูล (Data Flow) การประมวลผล (Process) แหล่งเก็บข้อมูล (Data Store) และสภาพแวดล้อมภายนอกที่เกี่ยวข้อง (External Entity) ประกอบด้วย 4 สัญลักษณ์หลัก:

สัญลักษณ์ (Element)	หน้าที่หลัก	สัญลักษณ์แบบ Gane & Sarson (นิยมใช้เรียน)	สัญลักษณ์แบบ DeMarco & Yourdon
1. Process (กระบวนการ)	การทำงานแปรรูปข้อมูลดิบ (Input) ให้เป็นสารสนเทศ (Output)	กล่องสี่เหลี่ยมผืนผ้าขอบมน แบ่งเป็น 3 ส่วน (ID, Label, Location)	วงกลม (Bubble) หรือวงรี
2. Data Store (แหล่งเก็บข้อมูล)	ที่จัดเก็บข้อมูลชั่วคราวหรือถาวร เช่น ตารางในฐานข้อมูล ไฟล์ หรือเอกสาร	กล่องสี่เหลี่ยมเปิดข้างขวา (มีแถบใส่รหัสร้านค้าทางซ้าย)	เส้นตรงขนานกันสองเส้น (Open-ended)
3. External Entity (ปัจจัยภายนอก)	คน องค์กร หรือระบบภายนอกที่เป็นแหล่งกำเนิดหรือปลายทางข้อมูล	กล่องสี่เหลี่ยมจัตุรัสมีมิติ (Double-bordered box)	กล่องสี่เหลี่ยมจัตุรัสธรรมดา
4. Data Flow (เส้นไหลข้อมูล)	เส้นแสดงทิศทางการเคลื่อนที่ของข้อมูล	เส้นลูกศรชี้ทิศทางเดียว (ระบุชื่อข้อมูลกำกับชัดเจน)	เส้นลูกศรชี้ทิศทางเดียว

⚠️ กฎเหล็ก DFD ที่ออกข้อสอบวิเคราะห์บ่อยมาก (DFD Rules):

ห้ามเชื่อมตรงระหว่างผู้ใช้นอกกับแหล่งข้อมูล: External Entity ห้ามโยนข้อมูลเข้า Data Store ตรงๆ และ Data Store ห้ามโยนกลับไปหา External Entity โดยไม่มี Process คั่นกลางเด็ดขาด!
ห้ามคลังข้อมูลคุยกันเอง: Data Store ห้ามส่งข้อมูลไปหา Data Store อื่นตรงๆ ต้องผ่าน Process มาทำหน้าที่อ่านและเขียนเสมอ
กฎของ Process:
- Black Hole (หลุมดำ): Process ที่มีแต่กระแสข้อมูลเข้า แต่ไม่มีกระแสข้อมูลออกเลย (ผิดลอจิก)
- Miracle (ปาฏิหาริย์): Process ที่มีแต่กระแสข้อมูลออก แต่ไม่มีข้อมูลเข้าเลย (งอกข้อมูลขึ้นมาเอง ผิดลอจิก)
- Gray Hole (หลุมเทา): Process ที่รับข้อมูลเข้าอย่างหนึ่ง แต่ดันงอกผลลัพธ์ที่ไม่มีความเกี่ยวข้องกับอินพุตนั้นเลย

2. การแบ่งระดับของ DFD (DFD Levelling & Balancing)

ในการวิเคราะห์ระบบขนาดใหญ่ เราไม่สามารถวาดทุกอย่างรวมในหน้าเดียวได้ จึงต้องแบ่งเป็นระดับชั้น (Hierarchy):

Context Diagram (แผนภาพบริบท): แผนภาพระดับสูงสุด (Level 0) แสดงภาพรวมของทั้งระบบ มีโหนด **Process เพียงตัวเดียว (Process ID: 0)** เชื่อมต่อกับ External Entities ทั้งหมดโดยไม่มีการแสดงตารางเก็บข้อมูล (Data Store) ด้านใน
Diagram 0 (DFD Level 0): แตกรายละเอียดจาก Context Diagram ออกมาเป็นระบบย่อย แสดงกระบวนการหลัก (Process 1, 2, 3...) แหล่งเก็บข้อมูล (Data Stores) และเส้นข้อมูลที่เชื่อมถึงกัน
DFD Level 1 / 2 (Child Diagram): แตกรายละเอียดเชิงลึกของแต่ละ Process ในระดับพ่อแม่ออกเป็นขั้นตอนย่อย เช่น Process 1 แตกเป็น 1.1, 1.2, 1.3...
💡 กฎ DFD Balancing: กระแสข้อมูลเข้าและออกของกระบวนการระดับ Parent จะต้องเท่ากันและตรงกันใน Child Diagram เสมอ ห้ามสูญหายหรือเกินมาระหว่างทาง

3. เครื่องมือบริหารเวลาโครงการ: Gantt Chart vs PERT/CPM

เมื่อเข้าสู่เฟสวางแผนโครงการ (Project Planning) นักวิเคราะห์ระบบต้องเลือกเครื่องมือควบคุมเวลา:

Gantt Chart (ผังแกนท์): แผนภาพแท่งแนวนอนตามแกนเวลา เหมาะสำหรับการดูภาพรวม ระยะเวลาเริ่ม-จบของงาน และดูว่ามีงานใดทำควบคู่กันได้บ้าง แต่ **ข้อเสียคือ ดูความเชื่อมโยงของงาน (Dependencies) ได้ยาก และหาเส้นทางวิกฤตลำบาก**
PERT (Program Evaluation Review Technique) / CPM (Critical Path Method): ข่ายงานเชื่อมโหนดเส้นทาง (Network Diagram)
- โหนด (Node): วงกลมระบุเลขโหนดแสดงเหตุการณ์เริ่มต้น/สิ้นสุด
- เส้นลูกศร (Activity): แทนกิจกรรมที่ต้องทำ เขียนกำกับด้วย [ชื่อกิจกรรม], [ระยะเวลา] (เช่น A,7)
- **ข้อดี:** แสดงความสัมพันธ์ก่อนหลังของงานชัดเจน หาเส้นทางวิกฤตและวันยืดหยุ่นง่ายมาก

4. การวิเคราะห์ข่ายงานและเส้นทางวิกฤต (Critical Path Method - CPM)

การไล่เวลาในผัง PERT เพื่อหาเวลารวมโครงการ มีกฎการคำนวณ 2 ฝั่ง:

Forward Pass (บวกไปข้างหน้า): หาเวลาเริ่มเร็วที่สุด (Earliest Start - ES) และเวลาเสร็จเร็วที่สุด (Earliest Finish - EF)
สูตร: EF = ES + Duration
⚠️ กรณีรวมเส้นทาง (Merge): ถ้าโหนดปลายทางรับอินพุตจากโหนดก่อนหน้าหลายตัว ให้เลือกค่า **EF ที่มีค่ามากที่สุด** มาเปรียบเทียบเป็นค่า ES ของโหนดถัดไป
Backward Pass (ลบย้อนกลับ): หาเวลาเสร็จช้าที่สุด (Latest Finish - LF) และเวลาเริ่มช้าที่สุด (Latest Start - LS)
สูตร: LS = LF - Duration
⚠️ กรณีแยกเส้นทาง (Burst): ถ้าโหนดย้อนกลับแยกย้ายไปหลายฝั่ง ให้เลือกค่า **LS ที่มีค่าน้อยที่สุด** มาเปรียบเทียบเป็นค่า LF ของโหนดถัดไป
Slack Time / Float (ระยะเวลายืดหยุ่น): เวลาที่กิจกรรมนั้นสามารถล่าช้าได้โดยไม่ส่งผลกระทบต่อกำหนดเสร็จโครงการ
สูตร: Slack = LS - ES หรือ LF - EF
📌 Critical Path (เส้นทางวิกฤต): เส้นทางเชื่อมกิจกรรมที่มีค่า Slack Time = 0 (ไม่สามารถช้าได้เลยแม้แต่วันเดียว) ซึ่งเป็นเส้นทางที่มี **เวลารวมยาวนานที่สุด** ในโครงการ

5. การวิเคราะห์การเร่งโครงการ (Project Crashing) - จุดวิกฤตในข้อสอบ!

การเร่งวันโครงการ (Crashing): การพยายามลดระยะเวลาของโครงการลงให้ได้ตามเป้าหมาย (เช่น ลดลง 4 วัน) โดยการทุ่มทรัพยากร/เพิ่มเงินจ้างเร่งงานในกิจกรรม **ที่อยู่บนสายงานวิกฤต (Critical Path) เท่านั้น** และเลือกกิจกรรมที่มี **ค่าใช้จ่ายในการเร่งต่อวันต่ำที่สุด** เสมอ

📝 เจาะลึกโจทย์ตัวอย่างมหาโหด (สไลด์บทที่ 3 หน้า 46):

โจทย์กำหนดกิจกรรมและเงื่อนไข: ต้องการเร่งโครงการจากเวลาปกติให้เหลือเสร็จสิ้นใน 28 วัน โดยเสียค่าใช้จ่ายน้อยที่สุด

งาน	งานก่อนหน้า	เวลาปกติ (วัน)	เวลาเร่งได้สุด (วัน)	ค่าใช้จ่ายเร่งต่อ 1 วัน (บาท)
A	-	7	6 (ลดได้ 1 วัน)	150
B	-	8	6 (ลดได้ 2 วัน)	75
C	A	9	7 (ลดได้ 2 วัน)	200
D	A	11	9 (ลดได้ 2 วัน)	125
E	B	8	5 (ลดได้ 3 วัน)	115
F	B	10	7 (ลดได้ 3 วัน)	100
G	C	13	11 (ลดได้ 2 วัน)	200
H	D,E	13	12 (ลดได้ 1 วัน)	100
I	F	14	10 (ลดได้ 4 วัน)	125

วิเคราะห์ข่ายงานมีทิศทางเชื่อมได้ 4 เส้นทาง (Paths) เวลาเริ่มต้นปกติ:

Path 1 (A-C-G): 7 + 9 + 13 = 29 วัน
Path 2 (A-D-H): 7 + 11 + 13 = 31 วัน
Path 3 (B-E-H): 8 + 8 + 13 = 29 วัน
Path 4 (B-F-I): 8 + 10 + 14 = 32 วัน (สายงานวิกฤตเริ่มต้น - ต้องเล็งลดฝั่งนี้ก่อน)

🎯 การวิเคราะห์เชิงลึกเปรียบเทียบ 2 แนวทาง (จุดเฉลยขัดแย้งในสไลด์):

💡 แนวทางที่ 1: เฉลยตามสไลด์ของอาจารย์ (ค่าใช้จ่ายรวม 850 บาท - ใช้ส่งห้องสอบ)

อาจารย์ใช้วิธีเร่งลดทีละขั้นแต่เกิดการ Over-crashing (เร่งเกินความจำเป็น) ของกิจกรรม D:
1. ลด 32 -> 31 วัน: เร่ง B บนสายงานวิกฤต 1 วัน (จ่าย 75 บ.) ➜ สายงานวิกฤตกลายเป็น B-F-I (31) และ A-D-H (31)
2. ลด 31 -> 30 วัน: ต้องเร่งสองฝั่งร่วมกัน เลือกเร่ง B อีก 1 วัน (จ่าย 75 บ.) และ H อีก 1 วัน (จ่าย 100 บ.) รวมจ่าย 175 บ. ➜ B และ H เร่งสุดแล้ว
3. ลด 30 -> 28 วัน (สไลด์รวบยอด): อาจารย์ทำการสั่งลด **D อีก 2 วัน** (จ่าย 250 บ.) และ **F อีก 2 วัน** (จ่าย 200 บ.) พร้อมกับ เร่ง A อีก 1 วัน (จ่าย 150 บ.) เพื่อดึงเส้น A-C-G (29 วัน) ลงมาเหลือ 28 วัน
➜ ผลลัพธ์สุดท้าย: เร่ง A(1 วัน), B(2 วัน), D(2 วัน), F(2 วัน), H(1 วัน) ➜ ค่าใช้จ่ายรวม = 850 บาท
*วิเคราะห์จุดผิดพลาดในสไลด์:* เมื่อเราลดเวลา A ลง 1 วัน (จาก 7 เหลือ 6) จะส่งผลให้เส้น A-D-H ลดลงตามไปด้วยโดยปริยาย ดังนั้นกิจกรรม D จริงๆ แล้วต้องการลดแค่ 1 วัน (ลดเหลือ 10) ก็เพียงพอที่จะทำให้เส้น A-D-H ยาว 28 วันพอดี การที่สไลด์สั่งลด D ไปถึง 2 วัน ทำให้เส้น A-D-H สั้นลงเหลือ 27 วันอย่างไร้ประโยชน์ (Over-crashing)

💡 แนวทางที่ 2: วิธีที่ดีที่สุดตามหลักคณิตศาสตร์จริง (Optimal - จ่ายประหยัดสุด 725 บาท)

หากลดทีละ 1 วันอย่างรอบคอบตามหลักทฤษฎีเชิงระบบจริง:
- รอบ 1 (ลด B): จ่าย 75 บ. (เวลาเหลือ 31)
- รอบ 2 (ลด B + H): จ่าย 175 บ. (เวลาเหลือ 30)
- รอบ 3 (ลด D + F): จ่าย 125 + 100 = 225 บ. เพื่อคุมเส้นวิกฤตทั้งสองให้เหลือ 29 วัน
- รอบ 4 (ลด A + F): จ่าย 150 + 100 = 250 บ. (เพราะ A เป็นจุดร่วมของ Path 1 และ Path 2)
➜ ผลลัพธ์ที่คุ้มที่สุด: เร่ง A(1 วัน), B(2 วัน), **D(1 วัน)**, F(2 วัน), H(1 วัน) ➜ ค่าใช้จ่ายรวม = 725 บาท (ประหยัดกว่าเฉลยสไลด์ไป 125 บาท!)

📌 คำแนะนำของครูในการสอบ: หากข้อสอบอัตนัยวิเคราะห์ ให้เขียนระบุอธิบายทั้ง 2 แนวทางชี้ให้เห็นมุมมองวิจารณญาณที่ถูกต้อง จะได้คะแนนเต็มอย่างแน่นอน!

🏋️ โจทย์ซ้อมแผนภาพและบริหารโครงการระดับข้อสอบ

ลองมาทดลองแก้ปัญหาโจทย์แนวทฤษฎีและคำนวณที่มักออกสอบวิชา SA บทเรียนนี้กันครับ:

โจทย์ข้อที่ 1: ตรวจจับข้อผิดพลาด DFD Rules

คำสั่งโจทย์: ในการตรวจทาน DFD ระบบย่อยหนึ่ง พบว่ามีองค์ประกอบดังนี้:
1) Process 1.1 รับข้อมูลจากตาราง Customers และเขียนข้อมูลใบเสร็จส่งตรงเข้าตาราง Invoices
2) ลูกค้า (External Entity) ทำการหยิบข้อมูลสินค้าจากตาราง Products เพื่อเปรียบเทียบราคาด้วยตนเองก่อนสั่งซื้อ
จงบอกจุดที่ละเมิดกฎ DFD และวิธีแก้ไขที่ถูกต้อง

โจทย์ข้อที่ 2: คำนวณหาสายงานวิกฤตและ Slack Time

คำสั่งโจทย์: โครงการพัฒนาซอฟต์แวร์มีเส้นทางการดำเนินงานดังนี้:
- เส้นทางที่ 1 (A-B-C) ใช้เวลาปกติ: 5, 8, 4 วัน ตามลำดับ
- เส้นทางที่ 2 (D-E-C) ใช้เวลาปกติ: 6, 6, 4 วัน ตามลำดับ
จงวิเคราะห์ว่า:
1) สายงานวิกฤตของโครงการนี้คือเส้นทางใด? โครงการเสร็จสิ้นในกี่วัน?
2) ค่า Slack Time ของกิจกรรม B และ E มีค่าเท่าใด?

โจทย์ข้อที่ 3: ซ้อมวิเคราะห์การเร่งโครงการขนาดเล็ก

คำสั่งโจทย์: โครงการหนึ่งมีสายงานวิกฤต A-B ใช้เวลา 15 วัน (A=9 วัน, B=6 วัน) และสายงานยืดหยุ่น C-D ใช้เวลา 12 วัน (C=7 วัน, D=5 วัน)
- กิจกรรม A เร่งได้สูงสุด 2 วัน (ค่าเร่ง 100 บาท/วัน)
- กิจกรรม B เร่งได้สูงสุด 1 วัน (ค่าเร่ง 50 บาท/วัน)
หากต้องการลดเวลาโครงการลง 2 วัน (เหลือ 13 วัน) ให้ประหยัดที่สุด ต้องเร่งที่กิจกรรมใด และเสียเงินเท่าไร?

📝 บันทึกส่วนตัว — บทที่ 3

✓ บันทึกอัตโนมัติแล้ว

4 การเก็บรวบรวมความต้องการระบบ (Requirements Gathering)

ประเภทของ Requirements

Functional Requirements — ฟังก์ชันการทำงานที่ระบบต้องทำได้ (เช่น ล็อกอิน, ค้นหาสินค้า, ออกรายงาน)
Non-Functional Requirements — คุณสมบัติเชิงคุณภาพ (เช่น ความเร็ว, ความปลอดภัย, Availability 99.9%)

เทคนิคการเก็บรวบรวมความต้องการ

เทคนิค	ข้อดี	ข้อเสีย	เหมาะเมื่อ
Interviews (สัมภาษณ์)	ได้ข้อมูลลึก เจาะประเด็น ถามเพิ่มเติมได้	ใช้เวลาสูง ข้อมูลอาจมีอคติจากผู้ตอบ	ต้องการเข้าใจลึกจากผู้ใช้คนสำคัญ
Questionnaires (แบบสอบถาม)	เก็บจากคนจำนวนมากได้ ประหยัดเวลา	ข้อมูลอาจไม่ละเอียด ถามเพิ่มไม่ได้	ต้องการข้อมูลเชิงปริมาณจากคนจำนวนมาก
Observations (สังเกตการณ์)	เห็นการทำงานจริง ลดการบิดเบือน	ใช้เวลา ผู้ถูกสังเกตอาจเปลี่ยนพฤติกรรม	ต้องการเข้าใจกระบวนการทำงานที่เป็นอยู่จริง
Document Analysis (วิเคราะห์เอกสาร)	ศึกษาได้โดยไม่รบกวนผู้ใช้ ข้อมูลเป็นทางการ	เอกสารอาจล้าสมัย ไม่ตรงกับการปฏิบัติจริง	ทำความเข้าใจระบบเดิมผ่านคู่มือ/ฟอร์ม/รายงาน
JAD (Joint Application Development)	ได้ข้อสรุปเร็ว ทุกฝ่ายมีส่วนร่วม	ต้องประสานงานให้ทุกคนว่างพร้อมกัน	โครงการสำคัญที่ต้องการการตัดสินใจร่วมกัน

เจาะลึกเทคนิคการเก็บรวบรวมความต้องการ (Requirements Gathering Techniques)

การเข้าใจปัญหาที่แท้จริงของผู้ใช้ขึ้นอยู่กับวิธีการที่เราเก็บข้อมูลค่ะ มาศึกษาข้อดี ข้อเสีย และรายละเอียดการทำงานแต่ละวิธีกันนะคะ:

1. Interviews (การสัมภาษณ์)

เป็นการสื่อสารสองทางโดยตรงระหว่าง SA และผู้สัมภาษณ์เพื่อทำความเข้าใจเป้าหมาย ปัญหา และทิศทางระบบที่ต้องการ แบ่งออกเป็น 2 รูปแบบย่อยหลัก:

Structured Interviews (การสัมภาษณ์แบบมีโครงสร้าง): SA จะจัดเตรียมคำถามเฉพาะเจาะจงล่วงหน้า และผู้ตอบคำถามจะตอบในกรอบคำถามที่กำหนดไว้
👍 ข้อดี: คุมเวลาได้ดี เปรียบเทียบข้อมูลคำตอบได้ง่าย รวบรวมข้อมูลอย่างรวดเร็ว
👎 ข้อเสีย: ขาดความยืดหยุ่น อาจพลาดข้อมูลสำคัญที่อยู่นอกเหนือคำถามที่เตรียมไว้
Unstructured Interviews (การสัมภาษณ์แบบไม่มีโครงสร้าง): เป็นการพูดคุยที่มีหัวข้อกว้างๆ และดำเนินคำถามแบบมีอิสระ ยืดหยุ่นไปตามคำตอบของผู้ถูกสัมภาษณ์
👍 ข้อดี: ได้ข้อมูลเชิงลึก ความคิดเห็นและมุมมองใหม่ๆ ที่เราไม่เคยวางแผนถามมาก่อน
👎 ข้อเสีย: ใช้เวลาสัมภาษณ์ค่อนข้างมาก สรุปหัวข้อคำตอบยาก และมีความเสี่ยงสูงที่จะออกนอกลู่นอกทาง

2. Observation (การสังเกตการณ์)

SA จะเข้าไปติดตามดูวิธีการและกระบวนการทำงานจริงของพนักงานในสภาพแวดล้อมจริงโดยไม่แทรกแซงหรือรบกวน

ทำไมต้องใช้: บ่อยครั้งที่ผู้ใช้ตอบสัมภาษณ์อย่างหนึ่ง แต่พอทำงานจริงกลับทำอีกอย่าง (หรือจำขั้นตอนข้อยกเว้นไม่ได้) การสังเกตการณ์ช่วยให้ SA เห็นขั้นตอนจริงและข้อผิดพลาดเชิงปฏิบัติงาน
ข้อควรระวัง: พฤติกรรมของพนักงานอาจเปลี่ยนไปเมื่อพวกเขารู้ตัวว่ากำลังถูกจับตามอง (Hawthorne Effect)

3. Document Analysis (การวิเคราะห์เอกสาร)

การวิเคราะห์คู่มือปฏิบัติงาน ฟอร์มเอกสาร รายงาน แฟ้มประวัติ และบันทึกของระบบเดิมเพื่อเข้าใจประวัติศาสตร์และวิธีการป้อนข้อมูล

ประโยชน์: ช่วยให้เห็นโครงสร้างฟิลด์ข้อมูล ข้อมูลขาเข้าและขาออกที่เป็นทางการ ทำให้ SA เข้าใจข้อเท็จจริงดั้งเดิมขององค์กรโดยไม่ต้องรบกวนผู้ปฏิบัติงานจริง
ความเสี่ยง: เอกสารมักล้าสมัย ไม่ตรงกับการทำงานจริงในปัจจุบัน (เช่น มีการตกลงนอกรอบ หรือใช้ทางลัดที่ไม่มีในคู่มือ)

4. JAD (Joint Application Development)

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

แนวทางปฏิบัติ: ประชุมในห้องแยกเป็นเวลา 1-2 วัน มีการร่างเอกสารและวาดแบบจำลองกระบวนการร่วมกันอย่างเข้มข้นจนเกิดเป็นข้อตกลง SRS เบื้องต้น

5. RAD (Rapid Application Development) ในการเก็บความต้องการ

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

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

การเขียน Use Case

Use Case เป็นเครื่องมืออธิบายปฏิสัมพันธ์ระหว่างผู้ใช้ (Actor) กับระบบ:

Actor — ผู้ใช้หรือระบบภายนอกที่โต้ตอบกับระบบ
Use Case — หน้าที่/ฟังก์ชันที่ระบบต้องทำเพื่อตอบสนอง Actor
Use Case Diagram — แผนภาพรวมแสดง Actor ทั้งหมดและ Use Case ที่เกี่ยวข้อง
Use Case Description — เอกสารรายละเอียดพร้อม Main Flow, Alternative Flow, Exception Flow

SRS Document (Software Requirements Specification)

เอกสาร SRS คือผลลัพธ์สำคัญของขั้นตอน Analysis ประกอบด้วย:

บทนำ (Introduction) — วัตถุประสงค์, ขอบเขต, นิยามศัพท์
คำอธิบายทั่วไป (Overall Description) — มุมมองผลิตภัณฑ์, คุณสมบัติ, ข้อจำกัด
Functional Requirements — รายละเอียดฟังก์ชันทั้งหมด
Non-Functional Requirements — ข้อกำหนดด้านประสิทธิภาพ ความปลอดภัย
Appendix — ข้อมูลเพิ่มเติม

⚠️ ข้อสอบมักถาม: เปรียบเทียบข้อดี/ข้อเสียของแต่ละเทคนิคการเก็บความต้องการ, วิเคราะห์สถานการณ์เพื่อเลือกเทคนิคที่เหมาะสมที่สุด, เขียน Use Case Description จากกรณีศึกษา, และแยกแยะระหว่าง Functional vs Non-Functional Requirements

🏋️ คำถามทบทวนความรู้ประจำบทที่ 4

มาฝึกฝนการเลือกเครื่องมือและเทคนิคการรวบรวมข้อมูลข้อกำหนดความต้องการกันนะคะ (คลิกเพื่อแสดงคำตอบเฉลยค่ะ):

โจทย์ข้อที่ 1: เปรียบเทียบเทคนิคการสัมภาษณ์

คำถาม: หากคุณต้องสัมภาษณ์ ผู้บริหารระดับสูง (CEO) เพื่อขอวิสัยทัศน์โครงการระบบใหม่ และสัมภาษณ์ พนักงานหน้าเคาน์เตอร์ เพื่อถามรายละเอียดรหัสการคีย์ข้อมูล คุณควรเลือกใช้ Structured หรือ Unstructured Interview กับใคร เพราะเหตุใด?

โจทย์ข้อที่ 2: วิเคราะห์ปัญหาของ Document Analysis

คำถาม: "ในการทำระบบงาน SA ค้นพบว่าคู่มือ SOP บันทึกระบบจองห้องพักระบุให้ทำตามขั้นตอน 1➔2➔3 แต่เมื่อ SA ไปสังเกตการณ์จริง (Observation) กลับพบว่าพนักงานทำขั้นตอน 1➔3 ข้ามขั้นตอน 2 ไปโดยอ้างว่าขั้นตอน 2 เสียเวลาและไม่จำเป็น" ปัญหานี้บอกความท้าทายของการใช้วิธี Document Analysis อย่างไร?

โจทย์ข้อที่ 3: บทบาทและประโยชน์ของ JAD

คำถาม: โครงการระบบสวัสดิการพนักงานมีการโต้เถียงกันระหว่างฝ่ายบุคคล (HR) และฝ่ายการเงิน (Finance) โดยฝ่ายแรกต้องการความยืดหยุ่น ส่วนฝ่ายหลังกลัวงบประมาณบานปลาย หากคุณสัมภาษณ์ทีละคนแล้วข้อมูลไม่ลงตัว คุณจะใช้แนวทาง JAD แก้ไขปัญหานี้ได้อย่างไร?

📝 บันทึกส่วนตัว — บทที่ 4

✓ บันทึกอัตโนมัติแล้ว

P โครงงานรายวิชา System Analysis and Design

ขั้นตอนการทำโครงงาน

โครงงานรายวิชานี้ต้องการให้นักศึกษาประยุกต์ใช้ทุกบทเรียนที่เรียนมา ในการวิเคราะห์และออกแบบระบบจริง:

เลือกหัวข้อ — ระบุปัญหาจากธุรกิจหรือองค์กรจริง
ทำ Feasibility Study — ประเมินความเป็นไปได้ (Technical, Economic, Operational)
เก็บรวบรวมความต้องการ — ใช้เทคนิคที่เรียน (สัมภาษณ์, แบบสอบถาม, สังเกต)
สร้างแบบจำลอง — จัดทำ DFD (Context, Level 0, Level 1), Use Case Diagram
ออกแบบระบบ — ER Diagram, UI Mockup, System Architecture
เขียนเอกสาร SRS — รวบรวมทั้งหมดเป็นเอกสารสมบูรณ์

เอกสารที่ต้องส่ง (Deliverables)

📋 Project Proposal / Business Case
📊 Context Diagram + DFD Level 0, 1
👤 Use Case Diagram + Use Case Descriptions
🗃️ ER Diagram (Entity-Relationship Diagram)
🖥️ UI/UX Mockup หรือ Prototype
📄 SRS Document ฉบับสมบูรณ์

คู่มือนำทางและแนวทางการทำโครงงานอย่างเป็นขั้นตอน (Comprehensive Walkthrough & Guidelines)

โครงงานวิชา SA เป็นการจำลองบทบาทการทำงานจริงของ System Analyst ค่ะ เพื่อไม่ให้นักศึกษาเกิดความสับสนและสามารถจัดทำเอกสารได้อย่างสมบูรณ์สอดคล้องกันทุกบท ครูขอสรุปขั้นตอนการเดินทางของโครงงานและคำแนะนำในแต่ละสเต็ปมาดังนี้นะคะ:

🎯 เฟสที่ 1: การระบุขอบเขตโครงการและการศึกษาความเป็นไปได้ (Scope & Feasibility Study)

เริ่มต้นจากการหาองค์กรหรือธุรกิจขนาดย่อม (เช่น ร้านขายของชำ ร้านกาแฟ หรือระบบงานเฉพาะฝ่ายในสถาบัน) มาเป็นกรณีศึกษา:

เก็บปัญหาด้วย PIECES: ลิสต์ปัญหาของระบบเดิมเป็นข้อๆ เช่น ค้นหาสินค้าล่าช้า (P), เอกสารใบสั่งซื้อสูญหายบ่อย (I), สต็อกไม่สอดคล้องกับชั้นวางจริง (E)
วิเคราะห์ Feasibility: ประเมินความเป็นไปได้เชิงเทคนิค (ใช้เทคโนโลยีใด พัฒนาเองหรือคลาวด์), ความเป็นไปได้ทางเศรษฐศาสตร์ (เงินทุน, คำนวณหาจุดคุ้มทุน ROI), ความเป็นไปได้ทางปฏิบัติการ (ผู้ใช้ยอมรับและพร้อมใช้ไหม)
ผลลัพธ์เฟสนี้: เอกสาร Project Proposal หรือ Business Case ที่มีขอบเขตเป้าหมายชัดเจน

📊 เฟสที่ 2: การวิเคราะห์กระบวนการและสร้างแบบจำลอง (Process Modeling)

เฟสนี้เป็นการแปลงคำพูดของผู้ใช้ที่ได้จากแบบสอบถามหรือสัมภาษณ์ให้เป็นแผนภาพกระบวนการ:

Context Diagram: วาดภาพรวมระบบยักษ์ 1 กล่อง (Process ID 0) ระบุสิ่งแวดล้อมภายนอก (External Entities) เช่น ลูกค้า, พนักงาน, ระบบธนาคาร ขีดทิศทางไหลเข้าออกของข้อมูล
DFD Level 0: แตก Process ID 0 ออกมาเป็น 4-6 กระบวนการหลัก (เช่น 1. จัดการสมาชิก, 2. บันทึกคำสั่งซื้อ, 3. ตัดสต็อกสินค้า, 4. ออกรายงานการเงิน) และเริ่มจัดวางแหล่งข้อมูล (Data Stores) ลงในระดับนี้
DFD Level 1 / 2: กระบวนการใดมีความซับซ้อน เช่น การตรวจสอบชำระเงิน ให้แตกย่อยลงเป็นขั้นตอนย่อย 2.1, 2.2 เพื่อความชัดเจน
⚠️ กฎเหล็กของกลุ่ม DFD: ให้เช็ค Balancing ระหว่างแผนภาพระดับบนและระดับล่าง ลูกศรข้อมูลเข้า-ออกต้องสอดคล้องเท่ากัน และห้ามวาดเส้นเชื่อมระหว่าง External Entity ➔ Data Store หรือ Data Store ➔ Data Store โดยเด็ดขาดค่ะ

👤 เฟสที่ 3: แบบจำลองปฏิสัมพันธ์ของผู้ใช้ (Use Case Analysis)

แปลงฟังก์ชันการทำงานในมุมมองของผู้ใช้งาน:

Use Case Diagram: วาดแผนภาพที่ระบุ Actor (ผู้ใช้ระบบ) และกิจกรรมที่ต้องการทำในรูปของวงรี Use Case เช่น (สมัครสมาชิก), (สั่งซื้อสินค้า), (ชำระเงิน)
Use Case Description: เขียนอธิบายกระบวนการใน Use Case ทีละอันโดยมีรายละเอียด: Actor, Preconditions, Postconditions, และขั้นตอนการโต้ตอบปกติ (Normal Flow) รวมถึงกรณีเกิดข้อผิดพลาด (Exception Flow เช่น ชำระเงินไม่ผ่าน)
💡 ความสอดคล้องกับ DFD: Use Cases ที่เกิดขึ้นควรตรงกันหรือแมปได้กับกระบวนการ (Processes) ต่างๆ ที่วาดไว้ใน DFD ค่ะ

🗃️ เฟสที่ 4: การออกแบบฐานข้อมูลและสถาปัตยกรรม (Database & Architecture Design)

เปลี่ยนผ่านจากข้อมูลเชิงลอจิกเป็นโครงร่างทางกายภาพของฐานข้อมูลเพื่อเตรียมเก็บไฟล์ข้อมูล:

Entity-Relationship Diagram (ER Diagram): ระบุโหนดเอนทิตีที่จำเป็น (เช่น Entity: Customers, Orders, Products) วาดความสัมพันธ์ (1:1, 1:M, M:N) และใส่คุณสมบัติคีย์หลัก คีย์ร่วม (PK/FK) ให้ชัดเจน
การทำ Normalization: แปลงตารางให้อยู่ในระดับ 1NF, 2NF และ 3NF เพื่อลดความซ้ำซ้อนของข้อมูลและหลีกเลี่ยงข้อผิดพลาดในการเพิ่ม ลบ และอัปเดตข้อมูล (Anomaly)
💡 ความสอดคล้อง: เอนทิตีต่างๆ ใน ER Diagram และชื่อตาราง จะต้องสอดคล้องสัมพันธ์กับโหนด Data Stores ที่นักศึกษาเขียนไว้ในแผนภาพ DFD Level 0/1 เสมอค่ะ

🖥️ เฟสที่ 5: การออกแบบหน้าตาแอปและเขียนรายงาน (UI Design & SRS Document)

ขั้นตอนสรุปชิ้นงานก่อนนำเสนอส่งโครงการ:

UI Mockups / Prototype: วาดหน้ากากหน้าจอ UI (ใช้ Figma, Adobe XD หรือเครื่องมือลากวาง) ในหน้าจอสำคัญ เช่น หน้าลงชื่อเข้าใช้, หน้าตะกร้าสินค้า และแสดงขั้นตอนระบบจำลองการกด
จัดทำเอกสาร SRS (Software Requirements Specification): นำเนื้อหาและแผนภาพทั้งหมดมารวบรวมเรียบเรียงให้อยู่ในรูปแบบที่เป็นระบบตามเทมเพลตมาตรฐานสากล

🔑 Tips: เน้นความสอดคล้องระหว่าง Requirements → DFD → Use Case → ER Diagram ทุกส่วนต้องเชื่อมโยงกัน ข้อมูลจาก DFD ต้องปรากฏใน Data Store ซึ่งต้องสัมพันธ์กับ ER Diagram

📌 คำแนะนำสำคัญในการพรีเซนต์ของครู:
กรรมการผู้ตรวจโครงงานมักจะมองหา "ความสอดคล้องอย่างเป็นเนื้อเดียวกัน (Traceability)" ของเอกสารค่ะ นักศึกษาต้องตรวจเช็คให้แน่ใจว่า ความต้องการในระบบ (Requirements) ➔ นำไปสู่วงรีใน Use Case ➔ นำไปสู่โพรเซสใน DFD ➔ นำไปสู่การจัดเก็บตารางใน ER Diagram ทั้งหมดต้องสะท้อนข้อมูลกลุ่มเดียวกันเสมอ หากความต้องการระบบระบุฟังก์ชันชำระเงิน แต่ใน DFD ไม่มีระบบนี้ และใน ER ไม่มีตารางบันทึกใบเสร็จ โครงงานจะถูกหักคะแนนความถูกต้องเชิงระบบทันทีค่ะ!

🏋️ คำถามทบทวนสำหรับการเตรียมตัวทำโครงงาน

มาซ้อมตอบคำถามเตรียมความพร้อมก่อนพรีเซนต์และพัฒนาโครงงานกับคณะกรรมการกันนะคะ (คลิกเพื่อดูเฉลยได้เลยค่ะ):

โจทย์ข้อที่ 1: ปัญหาขอบเขตโครงงานล้นหลาม (Scope Creep)

คำถาม: "กลุ่มของนักศึกษาวางแผนจะทำระบบบริหารจัดการธุรกิจโรงพยาบาลครบวงจร โดยมีทั้งส่วนงานทะเบียนผู้ป่วย, ระบบจัดการคิวแพทย์, ระบบคลังจ่ายยา, ระบบวิเคราะห์ภาพเอกซเรย์ด้วย AI, และระบบชำระเงินออนไลน์" ในฐานะที่ปรึกษาโครงงาน คุณคิดว่าขอบเขตนี้เหมาะสมหรือไม่ และเพราะเหตุใด?

โจทย์ข้อที่ 2: ความสอดคล้องระหว่าง DFD และ ER Diagram

คำถาม: ในการวิจารณ์ผลงานโครงงาน กรรมการถามว่า "คุณวาดตารางเก็บข้อมูลใน ER Diagram ทั้งสิ้น 12 เอนทิตี แต่ในภาพ DFD Level 0 ของคุณมี Data Store เพียงแค่ 2 กล่องเท่านั้น แบบนี้ถือว่าเอกสารสอดคล้องกันหรือไม่ และจุดผิดปกติเกิดจากอะไรได้บ้าง?"

คำแนะนำและเฉลยจากครู:

ถือว่าเอกสาร "ไม่สอดคล้องกันอย่างรุนแรง (Inconsistency)" ค่ะ

จุดผิดปกติและสาเหตุที่เป็นไปได้:

วิเคราะห์ DFD ตกหล่น: นักศึกษาอาจไม่ได้วาด Data Stores ใน DFD ให้ครบถ้วนตามความจริงของกิจกรรมที่มีการเข้าถึงข้อมูล เช่น ลืมวาดกล่องเก็บข้อมูลประวัติการชำระเงิน หรือข้อมูลใบสั่งซื้อ
วิเคราะห์ ER เกินขอบเขต: มีการวาดเอนทิตีใน ER Diagram เกินกว่ากิจกรรมที่มีในกระบวนการระบบ (Processes) ส่งผลให้ตารางข้อมูลที่เขียนขึ้นในฐานข้อมูลไม่มีกระบวนการของโปรแกรมใดๆ เข้าไปเรียกอ่านหรือบันทึกเขียนข้อมูลเลย (กลายเป็นโคลนฐานข้อมูลเปล่า)

แนวทางแก้ไข: ให้นักศึกษาสรุปรายการตารางข้อมูลใน ER Diagram แล้วกลับไปตรวจสอบที่แผนภาพ DFD เพื่อเพิ่มกล่อง Data Store และขีดลูกศรเชื่อมความสัมพันธ์ในการอ่าน/เขียนของโพรเซสให้ตรงกันแบบ 1 ต่อ 1 กับตารางหลักใน ER Diagram ค่ะ

โจทย์ข้อที่ 3: การระบุ Exception Flow ใน Use Case

คำถาม: ในขั้นตอนการออกแบบ Use Case Description ของฟังก์ชัน "ชำระเงินค่าสินค้าออนไลน์" หากลูกค้ากดทำรายการแต่พบว่า "ระบบสแกนตรวจสอบสลิปไม่สำเร็จเนื่องจาก QR Code ชำรุด" เหตุการณ์นี้จัดเป็น Flow รูปแบบใด และเขียนรายละเอียดอย่างไร?

📝 บันทึกส่วนตัว — โครงงาน

✓ บันทึกอัตโนมัติแล้ว

📝 ข้อสอบจำลองวิชา System Analysis and Design

แบบทดสอบทบทวนความรู้เพื่อเตรียมสอบวิชาการวิเคราะห์และออกแบบระบบงาน เน้นหัวข้อ SDLC, PIECES Framework, การวาด DFD, Requirements และโครงงาน

เลือกบทเรียนที่ต้องการทดสอบ

จำนวนข้อสอบที่ต้องการทำ

บทที่ 1

ข้อที่ 1 จากทั้งหมด 10 ข้อ

เวลาที่ใช้: 00:00

คำถามกำลังโหลด...

8/10 คะแนนที่ได้

เก่งมาก! ผ่านเกณฑ์ฉลุย

คุณทำข้อสอบเสร็จเรียบร้อยแล้ว ลองทบทวนข้อที่ทำผิด หรือทดลองทำซ้ำอีกครั้งเพื่อสร้างความคุ้นเคย

📂 ไฟล์สไลด์ต้นฉบับ (PDF)

1 ระบบสารสนเทศ, บทบาทของ SA และระเบียบวิธีการพัฒนา (System Analysis & Methodology)

1. พื้นฐานระบบสารสนเทศ (Information System Fundamentals)

1.1 ระบบ (System) คืออะไร?

1.2 ข้อมูล (Data) vs. สารสนเทศ (Information)

1.3 องค์ประกอบของระบบสารสนเทศ (Five-Component Model)

1.4 ประเภทของระบบสารสนเทศในองค์กร (Types of Information Systems) — ⭐ ออกสอบบ่อย!

1.5 เทคโนโลยีสารสนเทศยุคใหม่

2. จากปัญหาธุรกิจสู่ระบบสารสนเทศ (Business Problem to IS)

2.1 บทบาทของนักวิเคราะห์ระบบ (Systems Analyst: SA)

2.2 ทำไมต้องทำ SA&D ก่อนลงมือเขียนโค้ด?

2.3 กรณีศึกษาจากสไลด์อาจารย์ (Case Studies)

3. วงจรการพัฒนาระบบ (SDLC - Software Development Life Cycle)

4. Waterfall Model และระเบียบวิธีพัฒนาทางเลือก (Development Methodologies)

4.1 Waterfall Model (แบบจำลองน้ำตก)

4.2 ตารางเปรียบเทียบ Methodology พื้นฐาน 5 รูปแบบ (ออกสอบ!)

🧠 แบบฝึกหัดทบทวน — บทที่ 1: SA & Methodology

2 การวิเคราะห์ปัญหาธุรกิจและความเป็นไปได้ของโครงการ

การระบุปัญหาทางธุรกิจ — PIECES Framework

เจาะลึกการระบุปัญหาทางธุรกิจ (PIECES Framework)

การประเมินความเป็นไปได้เชิงลึก (Feasibility Studies)

1. Technical Feasibility (ความเป็นไปได้ทางเทคนิค)

2. Economic Feasibility (ความเป็นไปได้ทางเศรษฐศาสตร์)

3. Operational Feasibility (ความเป็นไปได้ทางปฏิบัติการ)

4. Legal Feasibility (ความเป็นไปได้ด้านกฎหมายและข้อบังคับ)

การทำ Business Case

🏋️ คำถามทบทวนความรู้ประจำบทที่ 2

โจทย์ข้อที่ 1: วิเคราะห์ปัญหาด้วย PIECES Framework

โจทย์ข้อที่ 2: NPV vs Payback Period

โจทย์ข้อที่ 3: ความแตกต่างของ Feasibility ด้านต่างๆ

📝 บันทึกส่วนตัว — บทที่ 2

3 การวางแผนโครงการ และแบบจำลองกระบวนการ (Project Planning & Process Modeling)

1. แผนภาพกระแสข้อมูล (DFD – Data Flow Diagram)

2. การแบ่งระดับของ DFD (DFD Levelling & Balancing)

3. เครื่องมือบริหารเวลาโครงการ: Gantt Chart vs PERT/CPM

4. การวิเคราะห์ข่ายงานและเส้นทางวิกฤต (Critical Path Method - CPM)

5. การวิเคราะห์การเร่งโครงการ (Project Crashing) - จุดวิกฤตในข้อสอบ!

📝 เจาะลึกโจทย์ตัวอย่างมหาโหด (สไลด์บทที่ 3 หน้า 46):

🏋️ โจทย์ซ้อมแผนภาพและบริหารโครงการระดับข้อสอบ

โจทย์ข้อที่ 1: ตรวจจับข้อผิดพลาด DFD Rules

โจทย์ข้อที่ 2: คำนวณหาสายงานวิกฤตและ Slack Time

โจทย์ข้อที่ 3: ซ้อมวิเคราะห์การเร่งโครงการขนาดเล็ก

📝 บันทึกส่วนตัว — บทที่ 3

4 การเก็บรวบรวมความต้องการระบบ (Requirements Gathering)

ประเภทของ Requirements

เทคนิคการเก็บรวบรวมความต้องการ

เจาะลึกเทคนิคการเก็บรวบรวมความต้องการ (Requirements Gathering Techniques)

1. Interviews (การสัมภาษณ์)

2. Observation (การสังเกตการณ์)

3. Document Analysis (การวิเคราะห์เอกสาร)

4. JAD (Joint Application Development)

5. RAD (Rapid Application Development) ในการเก็บความต้องการ

การเขียน Use Case

SRS Document (Software Requirements Specification)

🏋️ คำถามทบทวนความรู้ประจำบทที่ 4

โจทย์ข้อที่ 1: เปรียบเทียบเทคนิคการสัมภาษณ์

โจทย์ข้อที่ 2: วิเคราะห์ปัญหาของ Document Analysis

โจทย์ข้อที่ 3: บทบาทและประโยชน์ของ JAD

📝 บันทึกส่วนตัว — บทที่ 4

P โครงงานรายวิชา System Analysis and Design

ขั้นตอนการทำโครงงาน

เอกสารที่ต้องส่ง (Deliverables)

คู่มือนำทางและแนวทางการทำโครงงานอย่างเป็นขั้นตอน (Comprehensive Walkthrough & Guidelines)

🎯 เฟสที่ 1: การระบุขอบเขตโครงการและการศึกษาความเป็นไปได้ (Scope & Feasibility Study)

📊 เฟสที่ 2: การวิเคราะห์กระบวนการและสร้างแบบจำลอง (Process Modeling)

👤 เฟสที่ 3: แบบจำลองปฏิสัมพันธ์ของผู้ใช้ (Use Case Analysis)

🗃️ เฟสที่ 4: การออกแบบฐานข้อมูลและสถาปัตยกรรม (Database & Architecture Design)

🖥️ เฟสที่ 5: การออกแบบหน้าตาแอปและเขียนรายงาน (UI Design & SRS Document)

🏋️ คำถามทบทวนสำหรับการเตรียมตัวทำโครงงาน

โจทย์ข้อที่ 1: ปัญหาขอบเขตโครงงานล้นหลาม (Scope Creep)

โจทย์ข้อที่ 2: ความสอดคล้องระหว่าง DFD และ ER Diagram

โจทย์ข้อที่ 3: การระบุ Exception Flow ใน Use Case

📝 บันทึกส่วนตัว — โครงงาน

📝 ข้อสอบจำลองวิชา System Analysis and Design

ข้อที่ 1 จากทั้งหมด 10 ข้อ

เก่งมาก! ผ่านเกณฑ์ฉลุย