ทบทวนความรู้ SDLC และ SRS
รายละเอียดโจทย์
ทบทวนและสรุปแนวคิดพื้นฐานที่สำคัญของการพัฒนาซอฟต์แวร์ 2 หัวข้อหลัก ได้แก่ วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) และเอกสารข้อกำหนดความต้องการซอฟต์แวร์ (SRS) เพื่อสร้างความเข้าใจพื้นฐานก่อนเริ่มออกแบบและพัฒนาระบบจริง
SDLC
1. ความหมายของ SDLC
วงจรชีวิตการพัฒนาซอฟต์แวร์ คือกระบวนการทำงานที่เป็นระบบและมีขั้นตอนชัดเจนในการสร้าง ปรับปรุง และดูแลรักษาซอฟต์แวร์ เปรียบเสมือนแผนที่นำทางที่ช่วยให้ทีมพัฒนาดำเนินงานได้อย่างมีทิศทาง
2. ขั้นตอนของ SDLC
ประกอบด้วย 6 ขั้นตอนหลัก: การวางแผน (Planning) เพื่อกำหนดขอบเขตและประเมินความเป็นไปได้ → การวิเคราะห์ (Analysis) เพื่อรวบรวมความต้องการจากผู้ใช้ → การออกแบบ (Design) โครงสร้างและหน้าตาระบบ → การพัฒนา (Implementation) หรือการเขียนโค้ด → การทดสอบ (Testing) เพื่อหาและแก้ไขข้อผิดพลาด → การบำรุงรักษา (Maintenance) เพื่อดูแลและอัปเดตระบบหลังใช้งานจริง
3. Waterfall Model
แนวคิดการพัฒนาซอฟต์แวร์แบบดั้งเดิม ทำงานเป็นขั้นบันไดตามลำดับ ต้องทำแต่ละขั้นตอนให้เสร็จสมบูรณ์ 100% ก่อนจึงย้ายไปขั้นถัดไปได้ เหมาะกับโครงการที่ความต้องการนิ่งและชัดเจน แต่ขาดความยืดหยุ่น
4. Agile Model
แนวคิดสมัยใหม่ที่ออกแบบมาลบจุดอ่อนของ Waterfall เน้นความยืดหยุ่นและการทำงานร่วมกันอย่างใกล้ชิด แบ่งโครงการใหญ่เป็นรอบทำงานสั้น ๆ เพื่อส่งมอบฟีเจอร์เล็ก ๆ ที่ใช้งานได้จริง ช่วยรับมือกับความต้องการที่เปลี่ยนแปลงได้ดีและลดความเสี่ยงที่ซอฟต์แวร์จะไม่ตรงใจผู้ใช้
5. ความสำคัญของ SDLC ในการพัฒนาซอฟต์แวร์
ช่วยลดความเสี่ยงที่โครงการจะล้มเหลวหรือทำงานไม่ทัน การมีขั้นตอนมาตรฐานช่วยให้ทีมงานเข้าใจบทบาทหน้าที่ของตนเองดีขึ้น มีการควบคุมคุณภาพในทุกเฟส และช่วยประเมินทรัพยากร งบประมาณ และระยะเวลาได้แม่นยำ หากไม่มี SDLC การพัฒนาซอฟต์แวร์มักสะเปะสะปะ เกิดปัญหาโค้ดบานปลาย และส่งงานไม่ได้ตามที่ตกลง
SRS
6. ความหมายของ SRS
เอกสารข้อกำหนดความต้องการทางซอฟต์แวร์ ทำหน้าที่เป็นพิมพ์เขียวอย่างเป็นทางการในการสร้างระบบ รวบรวมรายละเอียดว่าซอฟต์แวร์ต้องทำอะไร มีคุณสมบัติอย่างไร และมีข้อจำกัดอะไรบ้าง เป็น "ข้อตกลงร่วมกัน" ระหว่างลูกค้าและทีมพัฒนา เพื่อให้เข้าใจตรงกันก่อนเริ่มเขียนโค้ดจริง ลดความผิดพลาดและเวลาที่ต้องแก้งาน
7. โครงสร้างของเอกสาร SRS
อ้างอิงตามมาตรฐาน IEEE 830 แบ่งเป็น 3 ส่วนหลัก: บทนำ (Introduction) อธิบายวัตถุประสงค์และขอบเขต, คำอธิบายภาพรวม (Overall Description) ให้ภาพกว้างของฟังก์ชัน ข้อจำกัด และผู้ใช้งาน, และข้อกำหนดเฉพาะ (Specific Requirements) ซึ่งเป็นเนื้อหาเชิงเทคนิคที่ละเอียดที่สุด
8. Functional Requirements
ข้อกำหนดที่ระบุว่าระบบ "ต้องทำอะไรบ้าง" เป็นฟังก์ชันหรือฟีเจอร์หลักที่ผู้ใช้มองเห็นและสั่งการได้ เช่น ตรวจสอบสิทธิ์การเข้าสู่ระบบด้วยรหัสผ่าน คำนวณภาษีมูลค่าเพิ่มอัตโนมัติ หรือส่งอีเมลยืนยันคำสั่งซื้อภายใน 1 นาที
9. Non-functional Requirements
ข้อกำหนดด้านคุณภาพหรือคุณลักษณะทางเทคนิคที่ระบุว่าระบบ "ต้องทำงานอย่างไร" เพื่อให้มีประสิทธิภาพ ปลอดภัย และน่าเชื่อถือ เช่น รองรับผู้ใช้งานพร้อมกัน 5,000 คน หน้าเว็บโหลดเสร็จภายใน 2 วินาที หรือเข้ารหัสข้อมูลส่วนบุคคลตามมาตรฐานความปลอดภัย
10. ความสำคัญของ SRS ในโครงการซอฟต์แวร์
เป็นหัวใจสำคัญที่กำหนดทิศทางความสำเร็จของโครงการ เปลี่ยนความต้องการที่คลุมเครือของลูกค้าให้เป็นข้อกำหนดทางเทคนิคที่ชัดเจน ช่วยให้โปรแกรมเมอร์เขียนโค้ดและทีมทดสอบสร้าง Test Case ได้ตรงจุด และเป็นเครื่องมือควบคุมขอบเขตงานไม่ให้บานปลาย