หลักการ#

Prototyping = สร้าง “ต้นแบบ” ของระบบที่ทำงานได้บางส่วน ให้ user ลองใช้แล้วให้ feedback แล้วปรับ — ทำซ้ำจน user พอใจ

มี 2 แบบ:

• Iterative prototype — สร้าง prototype ใช้เป็น blueprint ของ requirement แล้วทิ้ง สร้างระบบจริงตาม blueprint นั้น
• Evolutionary prototype — prototype ค่อยๆ พัฒนาเป็นระบบจริงทีละรอบ จนกลายเป็น production system

Risk profile#

ฟังดูดี — แต่มี risk pattern ที่ออกข้อสอบบ่อยมาก

กับดัก ⚠️: Prototype ที่ user “อนุมัติ” แล้ว = ระบบ production ที่พร้อมใช้

ผิดครับ — Prototype มักถูกสร้างโดย skip:

• Backup / recovery
• Security controls
• Audit trails
• Performance optimization
• Error handling สำหรับ edge cases
• Data validation ระดับ enterprise

User ที่บอก “โอเค ใช้ตัวนี้แหละ” — กำลังอนุมัติ functionality ไม่ใช่ production readiness

มุม IS Auditor#

ต้องตรวจว่า prototype ที่ผ่าน user approval ไป ผ่าน full SDLC review ก่อนขึ้น production หรือไม่ ถ้า prototype = production โดยตรง = major control gap

ถ้า evolutionary prototype — ต้องมี checkpoint ที่บอกว่า prototype พร้อม “graduate” เป็น production เมื่อใด และ checkpoint นั้นใครเป็นคน sign-off

หลักการ#

RAD = methodology ที่ใช้ prototyping เป็นเครื่องมือหลัก แต่มีโครงสร้างเป็น 4 stages:

1. Concept / requirements planning — ตกลง scope แบบกว้าง
2. User design — workshop กับ user, สร้าง prototype, refine
3. Development / construction — สร้าง production version จาก prototype
4. Cutover / deployment — testing, training, go-live

RAD มี timeboxing เข้มงวด — แต่ละ phase มี deadline ที่ห้ามเลื่อน ถ้าทำไม่เสร็จ → ลด scope ไม่ใช่ขยายเวลา

Risk profile#

กับดัก: RAD = waterfall ที่เร็วกว่า

ไม่ใช่ครับ — RAD เป็น methodology แยก มี 4 stages ที่ใช้ prototyping เป็น tool หลัก ไม่ใช่ waterfall ที่กดทุก phase ให้สั้น

Risk หลักของ RAD:

• Documentation อาจบาง — เพราะ timeboxing บีบให้ deliver functionality ก่อน docs
• Control design อาจ skip — control ไม่ใช่ “feature” ที่ user ขอ จึงมักถูก deprioritize
• Scope creep ที่ disguised — เพราะ user เห็น prototype แล้วขอเพิ่ม “นิดเดียว”

มุม IS Auditor#

ตรวจว่า:

• มี documented control requirement ที่ฝังใน user design phase ตั้งแต่แรก ไม่ได้รอจนจบ
• Audit trail ของ scope changes — เปลี่ยนอะไรเพิ่มอะไรเมื่อไหร่

หลักการ#

Agile = ปรัชญาในการพัฒนา ไม่ใช่ methodology เป๊ะๆ — เน้น:

• ส่ง working software บ่อยๆ ใน iteration สั้น (1-4 สัปดาห์)
• ทำงานใกล้ชิดกับ business / user ตลอด
• ตอบสนองต่อการเปลี่ยนแปลงดีกว่าทำตามแผน
• เอกสารที่จำเป็น ไม่ใช่เอกสารทั้งหมด

Scrum = framework ที่ implement Agile — มี:

• Sprint — iteration 1-4 สัปดาห์ ที่จบด้วย shippable increment
• Product backlog — list of features ที่ priority แล้ว
• Sprint backlog — features ที่เลือกมาทำใน sprint นี้
• Daily standup — meeting สั้น 15 นาที ทุกวัน
• Sprint review + retrospective — ตอนจบ sprint review work + ปรับปรุง process
• Roles — Product Owner, Scrum Master, Development Team

Risk profile#

นี่คือจุดที่ misconception เยอะที่สุด

กับดัก ⚠️: Agile = ไม่ต้องมีเอกสาร

ผิดครับ — Agile บอกว่า “working software OVER comprehensive documentation” — คำว่า “over” หมายถึง value มากกว่า ไม่ได้แปลว่า “ไม่ต้องมี”

Agile ลด documentation ที่ ไม่จำเป็น — เช่น 200-page requirement spec ที่ outdated ก่อน sprint แรกจะจบ แต่ documentation ที่จำเป็นยังต้องมี:

• User stories ที่ชัดเจนพอจะทดสอบ
• Acceptance criteria ต่อ story
• Architecture decisions
• Security / compliance requirements
• Audit trails ของ decision

กับดัก: Agile ไม่มี control เพราะมัน “ยืดหยุ่น”

ผิดครับ — Agile แค่ implement control คนละแบบ:

• Code review (peer review หรือ automated) ในทุก commit
• Continuous integration ทดสอบ automated
• Definition of Done ที่รวม security checks, code quality, regression test
• Sprint review = formal sign-off ของ feature

มุม IS Auditor#

Audit Agile ต่างจาก audit waterfall มาก — ถ้าใช้ checklist ของ waterfall จะพลาด

ใน waterfall: ขอดู phase documentation ครบทุก phase

ใน Agile / Scrum: ตรวจ:

• Sprint review records — feature นี้ approved แล้วโดยใคร เมื่อไหร่
• Definition of Done ที่ครอบคลุม security + control review หรือไม่
• Sprint retrospective — เห็น lessons learned + improvements ไหม
• Burn-down chart, velocity — โปรเจ็คอยู่ที่ไหนของแผน
• Backlog grooming — ทุก feature มี business justification ไหม
• Code review evidence ใน version control system

มุมที่ผู้บริหารควรเข้าใจ: Agile ไม่ได้ทำให้ control “หายไป” — แค่ control ถูกฝังใน process แทนที่จะเป็น phase แยก auditor ที่ดีต้องรู้จักหา control ในที่ใหม่

หลักการ#

DevOps = ทำลายกำแพงระหว่างทีม Development กับทีม Operations — รวม pipeline ตั้งแต่เขียนโค้ดถึง deploy ให้เป็นกระบวนการเดียวที่ automated มากที่สุด

หลักการสำคัญ:

• CI/CD — Continuous Integration / Continuous Deployment โค้ดที่ commit ถูก build, test, deploy automated
• Infrastructure as Code — server/network config เป็นโค้ดที่ version control
• Automated testing — unit test, integration test รัน automated ในทุก commit
• Monitoring + observability — ดู production แบบ real-time

DevSecOps = DevOps ที่ฝัง security เข้าไปใน pipeline — security ไม่ใช่ “ด่านสุดท้ายก่อน prod” แต่เป็นทุกขั้นตอน:

• Static application security testing (SAST) ใน CI pipeline
• Dynamic application security testing (DAST) ใน staging
• Dependency scanning — library ที่ใช้มี vulnerability ไหม
• Secrets scanning — code ที่ commit มี API key, password หลุดไหม
• Container security scanning ก่อน deploy

Risk profile#

กับดัก: DevOps = ไม่ต้องมี change control เพราะ deploy automated

ผิดมาก — DevOps ไม่ได้ ทำให้ change control หาย แค่ เปลี่ยนรูปแบบของ change control

ใน traditional environment: change request → CAB approval → manual deploy

ใน DevOps environment: change request เป็น Pull Request → automated tests + peer review = approval → automated deploy

control ทั้งคู่ต้องมี audit trail — ใน DevOps audit trail อยู่ใน Git history + CI/CD logs

กับดัก: Automated test = ทดสอบครบทุกอย่าง

ผิด — automated test ทดสอบในสิ่งที่คน design test สำหรับ Edge case ที่ไม่ได้คิดถึงตอนเขียน test → ทดสอบไม่ได้

มุม IS Auditor#

DevOps environment ตรวจ:

• CI/CD pipeline configuration — เหมือน config ของ system อื่น ต้อง version control + change control
• Pipeline gates — มี mandatory check ก่อน deploy production ไหม (security scan, code review approval, test pass)
• SoD ใน pipeline — developer commit ได้ แต่ approve PR ไม่ได้เอง deploy production ไม่ได้เองโดยตรง
• Audit trail completeness — ทุก deploy มี traceability กลับไปยัง commit + PR + approver
• Secrets management — production credentials ไม่อยู่ใน code, ใช้ secrets manager
• Rollback automation — deploy fail → rollback automated หรือต้อง manual

เรื่อง change management ในบริบท operations ลึกๆ — เดี๋ยว Domain 4 จะลง change/release management ในมุมการ run system

หลักการ#

OOSD = วิธีการ design + program ที่มอง entity ในระบบเป็น object มี attribute (data) และ method (behavior)

แนวคิดหลัก:

• Class + Object — class คือ template, object คือ instance ของ class
• Inheritance — class ใหม่สืบทอด attribute + method จาก class แม่
• Polymorphism — object ต่าง class ตอบ method เดียวกันคนละแบบ
• Encapsulation — ซ่อนรายละเอียดภายใน เปิดให้ใช้ผ่าน interface เท่านั้น
• UML (Unified Modeling Language) — ภาษากลางในการ document object design

Risk profile#

กับดักสำคัญ: OOSD = methodology ของโปรเจ็ค

ไม่ใช่ครับ — OOSD เป็น programming paradigm ใช้กับ methodology ไหนก็ได้:

• Build ระบบด้วย waterfall + เขียนโค้ดเป็น OOSD = ได้
• Build ระบบด้วย Agile + เขียนโค้ดเป็น OOSD = ได้
• Build ระบบด้วย RAD + เขียนโค้ดเป็น OOSD = ได้

OOSD ตอบคำถามว่า “เขียนโค้ดยังไง” ไม่ใช่ “บริหารโปรเจ็คยังไง”

Risk ของ OOSD:

• Complexity ของ inheritance chain — class ที่สืบทอดลึกหลายชั้น = bug ที่หา root cause ยาก
• Hidden dependencies ผ่าน polymorphism — หาบ debug ลำบาก
• Reusable component ที่ reuse ผิดบริบท = bug ที่กระจายไปหลายระบบ

มุม IS Auditor#

ในระบบที่ใช้ OOSD ตรวจ:

• Code documentation ของ class hierarchy + UML diagrams
• Test coverage ที่รวม inherited behaviors
• Component reuse policy — มีการ review ก่อน reuse component ระบบอื่นไหม

Risk profile#

• Supply chain risk — component ที่ซื้อมามี vulnerability ที่ผู้สร้างไม่รู้ → ระบบเรามี vulnerability ตามมา
• Version compatibility — component หนึ่ง update อาจทำให้ component อื่นพัง
• License compliance — บาง open source library มี license เงื่อนไขที่ business ต้อง comply

มุม IS Auditor#

• มี inventory ของ components ที่ใช้ในระบบไหม (Software Bill of Materials — SBOM)
• มี vulnerability scanning ของ components เป็นระยะไหม
• มี process update component เมื่อมี security patch ออก

BPR — Business Process Reengineering#

หลักการของ BPR คือ “ออกแบบ process ใหม่จาก scratch” ไม่ใช่ปรับปรุง process เดิม — เพื่อ optimize เต็มที่ตามเทคโนโลยีปัจจุบัน

ผลลัพธ์มักได้ process ที่:

• ขั้นตอนน้อยลง
• ลายเซ็นอนุมัติน้อยลง
• ใช้ระบบ automate แทนคน
• เร็วและถูกกว่าเดิม

ฟังดูดีมาก — แต่มี risk pattern สำคัญที่ออกข้อสอบบ่อย

กับดัก ⚠️: BPR = ลด risk เพราะ process ใหม่ดีกว่าเก่า

ผิดครับ — BPR อาจจะ ลบ control เดิมออกโดยไม่รู้ตัว

ตัวอย่างที่เห็นบ่อย:

• ลายเซ็นอนุมัติ 2 ชั้นถูกตัดเพราะ “ช้า” — แต่ลายเซ็นนั้นเคยเป็น preventive control ของ fraud
• Step การ verify วงเงินถูก automate — แต่ logic ใน automation ไม่ครอบคลุมเงื่อนไขทั้งหมดที่คนเคย verify
• Step การ reconcile ระหว่างระบบถูกข้าม — เพราะ “ระบบ integrate กันแล้ว” — แต่จริงๆ integration ไม่ได้ครอบคลุมทุก case

มุมที่ผู้บริหารต้องเข้าใจ: BPR ที่ดีต้องทำ control assessment ก่อน reengineer — ระบุ control เดิมที่อยู่ใน process, ตัดสินว่าอันไหนยังจำเป็น, design control ใหม่ทดแทนถ้าจะตัดของเดิม การ reengineer ที่เน้นแค่ “ลด step” โดยไม่ดู control = recipe for disaster

ในมุม IS auditor — เวลาบริษัททำ BPR auditor ต้องถาม:

• Process เดิมมี control อะไรบ้าง — และมี control assessment เป็นทางการก่อน reengineer ไหม
• Process ใหม่ implement control อะไรทดแทน
• Risk ที่เคยถูก mitigate ด้วย control เดิม — ถูก re-evaluated ในบริบทใหม่ไหม

Risk profile#

• โค้ดที่ generate ยังต้อง review — ไม่ใช่เชื่อ tool 100%
• Methodology ของ tool อาจ obsolete — tool ที่ใช้กันเมื่อ 10 ปีที่แล้วอาจไม่มี support แล้ว
• Vendor lock-in — โค้ดที่ generate ใช้กับ tool นั้นเท่านั้น

มุม IS Auditor#

• โค้ดที่ generate ผ่าน code review เหมือนโค้ดที่เขียนมือไหม
• Tool ที่ใช้มี vendor support ปัจจุบันไหม
• Skill ของทีมในการ maintain เมื่อ tool obsolete