ข้ามไปที่เนื้อหาหลัก

ขั้นตอนการเก็บรวบรวมความต้องการ Waterfall step 2



Waterfall Model ขั้นตอนที่ 2 การเก็บรวบรวมความต้องการระบบ

หัวข้อก็บอกต้องอธิบายกันดีรึเปล่าครับ คือ ก่อนที่เราจะสร้างระบบหรือซอฟต์แวร์ เราก็ต้องการรู้ก่อนว่าความต้องการที่จะได้ซอฟต์แวร์แบบไหนออกมาให้ตรงความต้องการลูกค้าหรือผู้ใช้งาน
งานหลักๆ ของ System Analyst (SA) ในขั้นตอนนี้ คือ หาความต้องการของระบบ โดยจะมีวิธีอยู่หลายๆอย่าง เบื้องต้น
  • การทำแบบสอบถาม
  • การสัมภาษณ์ 
  • การขอเอกสารของระบบงาน กรณีต้องการเอาระบบงานเดิมที่ทำงานโดยใช้เอกสารเปลี่ยนมาเป็นระบบงานโดยใช้ไอที

โดยข้อมูลเบื้องต้นที่ผมได้กล่าวถึงนี้ ซึ่งก็เพียงพอต่อการทราบถึงข้อมูลความต้องการของระบบ ซึ่งในส่วนนี้เป็นอะไรที่สำคัญมากๆ เพราะการที่ SA มีประสบการณ์งานเยอะจะได้เปรียบในการรวบรวมข้อมูลต่างๆ รวมถึงการตั้งคำถาม การหาข้อมูลเชิงลึกสำคัญที่เกี่ยวกับระบบที่พัฒนา

ผมลืมพูดถึงไปนิดเกี่ยวกับของการจัดทำในส่วนของแบบสอบถาม หรือการสัมภาษณ์นั้น ซึ่ง SA ที่ชำนาญและมีประสบการณ์ระบบงานมากๆ นั้น จะมีการใช้คำถามปิด และคำถามเปิด เพื่อให้ได้มาของความต้องการของระบบ

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

เพิ่มเติมให้อีกนิด จากการเก็บรวบรวมความต้องการระบบ เมื่อได้ข้อสรุปเบื้องต้นจากผู้ใช้ระบบ ซึ่งในส่วนนี้ถ้าจำไม่ผิดไม่มีตอนผู้เขียนเรียนมหาลัย (อาจลืมเอง) แต่ผู้เขียนได้ไปเรียน Software Architecture ที่ SIPA ก็ทำให้รู้จักศัพท์ 2 คำ ได้แก่

  • Functional  คือ รายละเอียดของระบบงานหลักว่ามีอะไรบ้าง เช่น ระบบสมาชิก, ระบบโพสต์บทความ ฯลฯ (มีตอนเรียนมหาลัย)
  • Non Functional คือ ความต้องการนอกเหนือระบบงาน หรือความสามารถเสริม เช่น ในส่วนหน้าสมัครสมาชิกตรงของเลขบัตรประชาชนต้องมีการตรวจสอบความถูกต้อง, ในหน้าล็อคอินเข้าระบบสมาชิกต้องมีการตรวจสอบด้านความปลอดภัยของข้อมูล ฯลฯ (ตอนเรียนที่ SIPA หมายถึงคำศัพท์ Non Functional)

ปิดท้ายสิ่งที่ไม่มีในห้องเรียน ซึ่งทางผู้เขียนอยากเพิ่มเติมให้กับทางผู้อ่าน โดยการเก็บรวมรวบความต้องการระบบนั้นเกี่ยวข้องกับบุคคล ไม่ว่าจะเป็นผู้ว่าจ้าง ผู้ใช้งาน ฯลฯ ซึ่งที่ SA ต้องรีบศึกษาโครงสร้างของบุคลากรของบริษัท หรือหน่วยงานที่เกี่ยวข้อง การที่ SA สามารถหาผู้ที่มีอำนาจในการตัดสินใจ (MAN Power) และผู้ใช้งานระบบจริงได้เร็วนั้น ระบบที่พัฒนาจะตรงตามความลูกค้าและได้ข้อสรุปรวดเร็ว และถูกใจของผู้ที่เซ็นต์รับงานจ่ายเงินให้เรา ซึ่งในส่วนนี้ไม่ใช่แค่หน้าที่ของ SA อย่างเดียว ซึ่งอาจต้องมี Sale , Project Manager มาช่วยดำเนินการ และท้ายสุดการทำงานกับคน SA ควรเป็นบุคคลที่ใจเย็น สุขุม รอบคอบ ทัศนะคติด้านบวก จะช่วยให้การทำงานรวมกับลูกค้าได้ด้วยดี

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



อ่านตอน 1 ได้ที่ https://thaidevnote.blogspot.com/2018/04/waterfall-step-1.html

ความคิดเห็น

โพสต์ยอดนิยมจากบล็อกนี้

System Analyst สำคัญฉะไหน

ถ้าคุณเจอปัญหาเหล่านี้ มาลองให้ความสำคัญกับ System Analyst แล้วจะรู้ว่าคุณเข้าใจผิดเกี่ยวกับหน้าที่ของ SA โปรเจคที่พัฒนาล้มเหลว โปรเจคที่พัฒนาออกแบบไม่ตรงตามความต้องลูกค้า โปรเจคที่พัฒนาไม่เสร็จตามกำหนดเวลา โปรเจคที่พัฒนาต้นทุนบานปลาย โปรเจคที่พัฒนาเลือกใช้เทคโนโลยีผิด และอื่นๆ อีกมากมายที่ซอฟต์แวร์หรือระบบที่พัฒนาไม่ประสบความสำเร็จ สิ่งที่ System Analyst ต้องมี ประสบการณ์ (เจ้าข้อนี้และที่เข้าใจผิดกันเยอะ) SA ที่ดีต้องเคยเขียนหรือพัฒนาโปรแกรมมาก่อนหรือก็คือ เป็นโปรแกรมเมอร์มาก่อน SA ที่ดีต้องเคยต้องเคยออกแบบฐานข้อมูล SA ที่ดีต้องเคยวิเคราะห์และออกแบบระบบงานเกี่ยวกับธุรกิจมาเยอะพอสมควร SA ที่ดีต้องเขียนและอธิบายเอกสารได้ ตามหลักสากลนะ รอบรู้  มีความรู้เกี่ยวกับเทคโนโลยีต่างๆ แค่รู้ไม่จำเป็นต้องชำนาญ มีความเข้าใจเกี่ยวกับระบบงานของธุรกิจต่างๆ เป็นอย่างดี เข้าใจขั้นตอนการพัฒนาซอฟต์แวร์ตามหลักการพัฒนา System development Life Cycle (SDLC) เข้าใจขั้นตอนการพัฒนาซอฟต์แวร์แบบอื่นๆ เช่น Agile เป็นต้น รอบคอบและเฉลียวฉลาด ข้อนี้จะเกิดได้ ก็จากสองอันแรก ...

Dynamic Kernel Module Support (DKMS) ภาค 3

Dynamic Kernel Module Support เกริ่นมา 2 บทความแล้ว หวังว่าผู้อ่านจะเข้าใจนะครับ สรุปง่ายๆ คือ เจ้าพระเอกของเรา DKMS คำสั่งนี้จะช่วยให้เราจะทำการไฟล์ติดตั้งไดว์เวอร์ให้เราอัตโนมัติ เมื่อมีการอัพเดต kernel ให้เรา ทำให้เราไม่เจอปัญหาเวลาอัพเดตระบบปฏิบัติการแล้วใช้งานไดว์เวอร์การ์ดแลนได้ ปล. มันไม่ใช้แค่ช่วยเรื่องไดว์เวอร์ ยังช่วยทำให้เราเพิ่มความสามารถให้กับ kernel อีกด้วย ขั้นตอนการทำดังนี้ ก่อนทำ เราจะเช็คดูก่อนเพื่อสำรองไฟล์เดิมหรือทำการเช็คเวอร์ชั่นที่ใช้อยู่ได้ เช่น modinfo e1000e (เช็คตำแหน่งที่เก็บไฟล์ไดว์เวอร์) ethtool eth0 (ดูเวอร์ชั่นของไดว์เวอร์) ฯลฯ สามารถใช้ผู้ใช้งาน root ในการทำได้  และก่อนทำบนเครื่องต้องมีคำสั่งและ kernel header ด้วยในที่นี้ผู้เขียนทำตัวอย่างบนระบบปฏิบัติการ Debian ก็ได้ทำการติดตั้งดังนี้  apt-get install dkms deb-helper build-essential linux-headers-$(uname -r) make  cd /usr/src/ sudo wget https://downloadmirror.intel.com/15817/eng/e1000e-3.4.0.2.tar.gz sudo tar xvfz e1000e-3.4.0.2.tar.gz cd e1000e-3.4.0.2 sudo ...

Predictable Network Interface Names #2

Predictable Network Interface Names มาต่อกันจากประเด็นตอนที่แล้วทำให้ผู้เขียนต้องหาวิธีให้ระบบปฏิบัติการที่ผู้เขียนใช้เปลี่ยนกลับเป็นแบบเดิม เช่น eno1 เป็น eth0 ฯลฯ  และเหตุผลหลักที่ผมต้องการเปลี่ยนเป็นแบบเดิม ผมทำอุปกรณ์ network appliance ของ lanner ลิงค์รุ่น FW-7525 ตามรูปด้านล่าง ซึ่งจริงดูเหมือนว่าจะเป็น onboard ทั้งหมดนิ ไม่ยากอะไร แต่จริงแล้วตัวอุปกรณ์มี chipset การ์ดแลนคนละแบบกัน  ตัวอย่างชื่ออินเตอร์เฟส ens3,  ens4,  eno1,  eno2,  eno3,  eno4 ปัญหาที่เกิดขึ้น คือ มันจะแสดงแบบด้านบน แล้วผมจะเขียนโปรแกรมยังไงว่าพอร์ตซ้าย คือ พอร์ต manage พอเปลี่ยน hardware อีกชื่อก็เปลี่ยนอีก ผู้เขียนเลยต้องการเปลี่ยนให้เขียนโปรแกรมง่าย และเรียงลำดับพอร์ตเองได้อย่างถูกต้อง ไม่ต้องเหนื่อยคนเขียนโปรแกรม ขั้นตอนแก้ไขเปลี่ยนกลับแบบเดิม OS: Debian 9.0 - 9.4 (Stretch) nano /etc/default/grub หาบรรทัด GRUB_CMDLINE_LINUX ทำการเพิ่ม net.ifnames=0 biosdevname=0 บันทึกไฟล์ และทำการ update-grub OS: Ubuntu 14.04.X แก้เป็น...