01
Business brief
โจทย์และเกณฑ์รับงาน
SOFTWARE DEVELOPMENT
ซอฟต์แวร์ที่ตอบโจทย์ธุรกิจ
ทีมที่ดูแลต่อได้จริง
ตั้งแต่ Requirements ไปจนถึง Production เราช่วยองค์กรออกแบบ พัฒนา และส่งมอบระบบอย่างเป็นขั้นตอน พร้อมทีมที่มีประสบการณ์ดูแลเว็บไซต์ลูกค้ามากกว่า 10 ปี
SDLCISO/IEC 29110ส่งมอบโค้ดและเอกสาร
จากโจทย์ธุรกิจ สู่ระบบที่พร้อมส่งต่อ
ภาพรวมการส่งมอบ · ภาพตัวอย่างกระบวนการ
02
Engineering
ออกแบบ · พัฒนา · ทดสอบ
03
Production
อนุมัติ Release และส่งมอบ
04
Long-term care
ดูแลและปรับปรุงต่อเนื่อง
หลักฐานที่เดินไปพร้อมงานRequirement → Review → Test → Release
10+ ปี
ประสบการณ์ดูแลเว็บไซต์ลูกค้า เข้าใจทั้งวันเปิดตัวและวันที่ระบบต้องปรับตัว
ISO/IEC 29110
ใช้เป็นแนวทางจัดการโครงการและพัฒนาซอฟต์แวร์ ให้การทำงานและสิ่งส่งมอบตรวจสอบได้
Build → Run → Improve
วางแผนส่งต่อและดูแลตั้งแต่ต้น เพื่อให้ระบบมีเจ้าของและมีทางพัฒนาต่อ
BUILT AROUND YOUR BUSINESS
ระบบที่พอดีกับวิธีทำงาน
ขององค์กรคุณ
เริ่มจากงานที่ต้องทำให้ดีขึ้น เลือกขอบเขตและ Technology ให้เหมาะกับผู้ใช้ ข้อมูล และทีมที่จะรับช่วงดูแล
01
Business applications
รวมขั้นตอนที่กระจัดกระจาย
ระบบภายใน Workflow อนุมัติ และข้อมูลที่แต่ละทีมต้องใช้ร่วมกัน ลดงานซ้ำและกำหนดสิทธิ์ตามบทบาท
02
Customer platforms
สร้างประสบการณ์ให้ลูกค้าและคู่ค้า
Customer portal, เว็บไซต์ธุรกิจ และระบบบริการที่เชื่อมข้อมูลหลังบ้าน พร้อมประสบการณ์ใช้งานที่เหมาะกับอุปกรณ์
03
Integration & modernization
ต่อยอดระบบเดิมอย่างมีแผน
เชื่อม API และข้อมูลระหว่างระบบ ประเมิน Legacy code และแบ่งการปรับปรุงเป็นส่วนที่ทดสอบและส่งมอบได้
THE DELIVERY SYSTEM
ทุกขั้นมีเป้าหมาย
ทุกการส่งต่อมีหลักฐาน
กรอบบริการ 6 ขั้นของ Ruk-Com ช่วยให้เห็นงาน ผู้รับผิดชอบ และจุดตัดสินใจ ปรับรอบการทำงานให้เหมาะกับโครงการและทำซ้ำได้
กระบวนการ SDLC · ภาพตัวอย่างกระบวนการ
เลือกขั้นตอนเพื่อดูผู้รับผิดชอบและสิ่งส่งมอบด้านล่าง
ส่งต่องานFeedback กลับไปทบทวนผ่านการอนุมัติ
01
Discover & Plan
เห็นโจทย์เดียวกันก่อนลงมือ
02
Architecture & Design
ออกแบบให้เข้ากับงานและระบบเดิม
03
Build & Review
พัฒนาเป็นรอบ ตรวจสอบย้อนกลับได้
04
QA & UAT
ตรวจคุณภาพและรับงานจากการใช้งานจริง
05
Release & Handover
ขึ้นระบบอย่างมีแผน ส่งมอบอย่างชัดเจน
06
Operate & Improve
ดูแลต่อจากข้อมูลการใช้งานจริง
เส้นทางปกติ: ตกลงโจทย์ → ออกแบบ → พัฒนา → ทดสอบ → ส่งมอบ → ดูแล การขึ้น Production ผ่านการอนุมัติที่ตกลง
01
Discover & Plan
ทำความเข้าใจผู้ใช้ ขั้นตอนธุรกิจ และข้อจำกัด แปลงโจทย์เป็น Requirements และ Backlog ที่มีเกณฑ์รับงาน ประเมินขอบเขต ความเสี่ยง และแผนส่งมอบร่วมกัน
- Owner
- Business owner + PM / BA
- สิ่งส่งมอบ
- Requirements · Scope · Acceptance criteria
- จุดตรวจร่วมกัน
- ลูกค้ายืนยันโจทย์ ลำดับความสำคัญ และขอบเขตเริ่มต้น
02
Architecture & Design
วาง User flow, UX/UI, Data model และ API contract ระบุ Integration, Access control และทางเลือก Architecture ให้ผู้เกี่ยวข้องตรวจและตัดสินใจก่อนเริ่มพัฒนา
- Owner
- Product owner + Designer / Architect
- สิ่งส่งมอบ
- UX flow · Data model · API contract
- จุดตรวจร่วมกัน
- ตรวจ Design และข้อจำกัดการเชื่อมระบบร่วมกัน
03
Build & Review
พัฒนาตาม Backlog ที่จัดลำดับไว้ แยก Branch และ Pull request ให้เพื่อนร่วมทีม Review พร้อม Unit test และบันทึกการเปลี่ยนแปลง เชื่อมงานกลับไปยัง Requirement ต้นทาง
- Owner
- Engineer + Code reviewer
- สิ่งส่งมอบ
- Source code · Pull requests · Unit tests
- จุดตรวจร่วมกัน
- Review โค้ดและผลทดสอบก่อนรวมการเปลี่ยนแปลง
04
QA & UAT
ทดสอบ Integration และ Regression ตามความเสี่ยง ให้ผู้ใช้ทำ UAT ตามเกณฑ์ที่ตกลง บันทึก Defect และส่งกลับทีมพัฒนาเพื่อแก้ไขและทดสอบซ้ำก่อนพิจารณารับงาน
- Owner
- QA + Business users
- สิ่งส่งมอบ
- Test results · Defect log · UAT record
- จุดตรวจร่วมกัน
- ผู้รับผิดชอบพิจารณาผล UAT และประเด็นคงค้าง
05
Release & Handover
เตรียม Release checklist, แผนย้ายข้อมูล และ Rollback ตามลักษณะระบบ ส่งมอบ Repository เอกสาร และความรู้ให้ทีมที่รับช่วง การเปลี่ยน Production ต้องผ่านผู้อนุมัติที่ตกลง
- Owner
- Release owner + Client approver
- สิ่งส่งมอบ
- Release notes · Runbook · Handover record
- จุดตรวจร่วมกัน
- อนุมัติ Release พร้อมแผนตรวจผลและ Rollback
06
Operate & Improve
ติดตามระบบและรับ Feedback ตามขอบเขตดูแล แยก Incident, Defect และ Change request ให้ชัด งานที่เพิ่มหรือเปลี่ยนขอบเขตต้องกลับไปประเมิน Requirement ผลกระทบ และการอนุมัติก่อนเริ่มรอบใหม่
- Owner
- Service owner + Support / Engineering
- สิ่งส่งมอบ
- Service log · Maintenance plan · Change request
- จุดตรวจร่วมกัน
- ตกลงงานปรับปรุงและอนุมัติผลกระทบก่อนทำต่อ
ปรับรอบการทำงานแบบ Agile หรือ Iterative ให้เหมาะกับโปรเจกต์ โดยยังตรวจสอบ Requirements และสิ่งส่งมอบได้ทุกระยะ
PROCESS WITH ACCOUNTABILITY
ISO/IEC 29110
จากแนวทาง สู่การทำงานจริง
นำแนวทาง Basic profile มาเชื่อมการจัดการโครงการกับการพัฒนาซอฟต์แวร์ ให้เรื่องธุรกิจและงานวิศวกรรมเดินไปด้วยกัน
PM
Project Management
รู้ว่ากำลังทำอะไร ใครรับผิดชอบ และต้องตัดสินใจเรื่องไหน
- กำหนด Scope, แผนงาน และความรับผิดชอบร่วมกัน
- Review ความคืบหน้า ความเสี่ยง และประเด็นที่ต้องตัดสินใจ
- ประเมินผลกระทบของ Change request ก่อนอนุมัติ
- ตรวจสิ่งส่งมอบและบันทึกการยอมรับงาน
Project plan · Progress record · Change log
SI
Software Implementation
เปลี่ยน Requirements เป็นซอฟต์แวร์ที่ตรวจและส่งต่อได้
- วิเคราะห์ Requirement และออกแบบส่วนประกอบระบบ
- พัฒนา Review โค้ด และควบคุม Version
- ทดสอบตามเกณฑ์และจัดการ Defect อย่างเป็นระบบ
- เตรียม Software configuration และชุดส่งมอบ
Requirements · Design · Code · Tests · Delivery
เห็นที่มาของทุกการเปลี่ยนแปลง
ตัวอย่างการเชื่อมหลักฐาน ไม่ใช่ข้อมูลจากโปรเจกต์ลูกค้า
- Requirement
- Design
- Pull request
- Test result
- Release
อ่านแนวทางเพิ่มเติมจาก ISO/IEC 29110 series
QUALITY IS PART OF THE WORK
คุณภาพและ Security
อยู่ในกระบวนการตั้งแต่ต้น
ตกลงเกณฑ์ตรวจตามความเสี่ยงของระบบ แล้วเก็บหลักฐานให้ทีมธุรกิจและทีมเทคนิคตรวจร่วมกัน
Clear acceptance
ระบุพฤติกรรมที่คาดหวัง ขอบเขตข้อมูล และกรณีผิดพลาดก่อนพัฒนา เพื่อให้ UAT วัดจากเกณฑ์เดียวกัน
Requirements → Test casesReviewed changes
ใช้ Version control และ Code review แยก Environment และวาง Automated test ให้เหมาะกับส่วนสำคัญของระบบ
Pull request → Review → TestSecurity by scope
พิจารณาสิทธิ์เข้าถึง การจัดเก็บ Secret, Dependency และช่องทางข้อมูล การทดสอบ Security เชิงลึกระบุ Scope และการอนุญาตแยก
Access · Secrets · DependenciesRelease readiness
ตรวจ Release checklist, Backup และ Rollback ตามลักษณะงาน พร้อมผู้อนุมัติและแผนตรวจผลหลัง Deploy
Approve → Deploy → VerifyBUILT TO BE LOOKED AFTER
วันเปิดระบบ
คือจุดเริ่มต้นของการดูแล
ประสบการณ์ดูแลเว็บไซต์ลูกค้ากว่า 10 ปี ทำให้เราวางแผนการส่งต่อและบำรุงรักษาควบคู่ไปกับการพัฒนา ตั้งแต่สิทธิ์เข้าถึงจนถึงคนที่รับผิดชอบเมื่อเกิดปัญหา
การดูแลต่อเนื่อง · ภาพตัวอย่างกระบวนการ
01
Monitor
รับสัญญาณและคำแจ้ง
02
Triage
ประเมินผลกระทบและเจ้าของ
03
Fix
แก้ตาม Scope ที่ตกลง
04
Verify
ทดสอบและตรวจผลกระทบ
05
Approved deploy
อนุมัติ → Deploy → ตรวจผล
↳ หลัง Deploy กลับสู่ Monitoring เพื่อตรวจผลและดูแลต่อ
ดูแลให้ชัดทั้งงานประจำ
และงานเปลี่ยนแปลง
เลือกแผนดูแลให้เหมาะกับระบบของคุณ ระบุ Environment, ช่วงเวลา ช่องทางรับเรื่อง และขอบเขตความรับผิดชอบก่อนเริ่มบริการ
- Monitoring และการรับเรื่อง พร้อมจัดลำดับตามผลกระทบ
- Update, Backup และ Restore ตามแผนที่ตกลงและทดสอบได้
- Runbook, Access inventory และผู้รับผิดชอบที่รับช่วงต่อได้
- แยก Defect warranty ออกจาก Maintenance และงานเพิ่ม Feature
ทีมคนและ Ruk-Com Agent ทำงานร่วมกัน
Ruk-Com Agent Agent ช่วยติดตามและรวบรวมข้อมูลให้ทีมพิจารณา การเข้าถึงระบบและการลงมือแก้ไขอยู่ภายใต้สิทธิ์ ขอบเขต และการอนุมัติที่ตกลง ไม่ใช่การเปลี่ยน Production โดยอัตโนมัติ
A HANDOVER YOU CAN USE
ส่งมอบมากกว่า Feature
ให้ทีมคุณพัฒนาต่อได้
กำหนดสิ่งส่งมอบ สิทธิ์ใน Source code และเงื่อนไขการใช้งานให้ชัดในข้อตกลง รวมถึงข้อจำกัดของ Open source และ Third-party license
Code & configuration
Repository, Version ที่ส่งมอบ และรายการ Dependency พร้อมวิธี Build และจัดการ Configuration โดยแยก Secret
Documentation & evidence
Architecture, API และเอกสารใช้งานตาม Scope พร้อมผลทดสอบ UAT, Release notes และรายการประเด็นคงค้าง
Knowledge & continuity
ถ่ายทอดความรู้ Runbook และรายการ Access ให้ผู้รับผิดชอบ ระบุระยะรับประกันและแผนดูแลต่อก่อนปิดงาน
เริ่มจากจุดที่คุณอยู่
มีทั้งแนวคิดใหม่ โปรเจกต์ที่ต้องการทีมพัฒนา และระบบเดิมที่ต้องการคนรับช่วง เราจะช่วยแยกโจทย์ก่อนเสนอแผนงาน
- Discoverส่งเป้าหมาย ระบบเดิม และข้อจำกัด
- Agreeตกลง Scope, Milestones, งบ และเกณฑ์รับงาน
- DeliverReview เป็นรอบ พร้อมส่งมอบและดูแลตามแผน
BEFORE WE BEGIN
คุยให้ชัด
ก่อนเริ่มสร้าง
ข้อตกลงที่ชัด ช่วยให้ทั้งทีมธุรกิจและทีมเทคนิคตัดสินใจจากข้อมูลเดียวกัน
ISO/IEC 29110 หมายถึงอะไรสำหรับโปรเจกต์ของเรา?
ใช้แนวทาง Project Management และ Software Implementation เพื่อเชื่อม Scope, Requirements, การตรวจงาน และสิ่งส่งมอบให้ตรวจสอบได้ พร้อมปรับ SDLC ให้เหมาะกับขนาดและรูปแบบโปรเจกต์
ต้องมี Requirements ครบก่อนคุยหรือไม่?
ไม่จำเป็น เริ่มจากเป้าหมาย ผู้ใช้ ระบบที่มีอยู่ และปัญหาที่อยากแก้ได้ ทีมช่วยทำ Discovery เพื่อแยกงานสำคัญ ข้อจำกัด และเกณฑ์วัดผลก่อนประเมิน Scope
เปลี่ยนหรือเพิ่มความต้องการระหว่างทางได้อย่างไร?
บันทึกเป็น Change request แล้วประเมินผลกระทบต่อ Design, เวลา งบ และการทดสอบร่วมกัน เมื่อผู้รับผิดชอบอนุมัติจึงปรับ Backlog และแผนงาน ไม่รวมทุก Feature ที่เพิ่มเข้ามาใน Scope เดิมโดยอัตโนมัติ
ใครเป็นเจ้าของ Source code และได้เอกสารอะไร?
ระบุสิทธิ์ในโค้ด Repository และสิ่งส่งมอบในสัญญาก่อนเริ่ม รวมถึงข้อกำหนดของ Open source, Library และบริการ Third-party เอกสารและการถ่ายทอดความรู้กำหนดตาม Scope และทีมที่จะรับช่วง
ถ้า UAT ไม่ผ่าน จะทำอย่างไร?
บันทึก Defect เทียบกับเกณฑ์รับงานที่ตกลง จัดลำดับและส่งกลับทีมพัฒนา จากนั้นทดสอบซ้ำก่อนให้ผู้รับผิดชอบพิจารณารับงาน หากเป็นความต้องการใหม่จะแยกเข้าสู่กระบวนการ Change request
รับช่วงระบบเดิมที่ทีมอื่นพัฒนาได้หรือไม่?
เริ่มจากตรวจ Source code, Stack, Dependency, สิทธิ์เข้าถึง และเอกสารที่มีอยู่ เพื่อประเมินความเสี่ยงและความพร้อมก่อนรับ Scope งาน อาจเริ่มจาก Assessment หรือแก้จุดสำคัญเป็นระยะ
หลังส่งมอบ การรับประกันและการดูแลครอบคลุมแค่ไหน?
ระบุระยะเวลา เงื่อนไข และขอบเขต Defect warranty ให้ชัด ส่วน Monitoring, Update, Backup, Support และ Feature ใหม่ตกลงในแผนบริการที่เกี่ยวข้อง ไม่ถือว่ารวมทุกอย่างตลอดอายุระบบ
LET’S BUILD THE NEXT CHAPTER
เล่าโจทย์ธุรกิจของคุณ
แล้ววางแผนไปด้วยกัน
ส่งภาพรวมระบบ เป้าหมาย และช่วงเวลาที่ต้องการ ทีมช่วยประเมินขอบเขตการพัฒนาและการดูแลที่เหมาะกับคุณ