NFR Checklist: Performance, Scalability, Interoperability & Integrability

Checklist สำหรับใช้จับประเด็น เพื่อช่วยตั้งคำถามด้าน non-functional requirement ในงาน requirement, ช่วยออกแบบ non-functional test case, ช่วยออกแบบโซลูชั่น

 

NFR Checklist ด้าน Performance

ความต้องการ (Requirement)

สมมติฐาน (Assumption)

Incoming Event

  • การเกิดขึ้นของ event เนื่องจากการเข้ามาใช้ระบบโดยผู้ใช้ หรือ client เป็นแบบใด? เช่น periodic event, sporadic event, stochastic event
  • จำแนกตามอะไร? เช่น หน้าจอ, ฟังก์ชั่น, เซอร์วิส
  • จำนวนผู้ใช้ หรือ client ต่อวัน/ชั่วโมง/วินาทีคือเท่าไร?
  • จำนวน concurrent ของผู้ใช้ หรือ client เป็นเท่าไร? ณ ช่วงเวลาใดบ้าง?

Resource

  • ทรัพยากรที่จะใช้มีกี่ประเภท? เช่น หน่วยความจำ, I/O, ซีพียู, database server, ERP, network, directory server
  • Resource system มีอะไรบ้าง? ยี่ห้ออะไร? เวอร์ชั่นอะไร?
  • Network bandwidth ที่เหลือโดยเฉลี่ย(เช่น ต่อชั่วโมง) ที่เชื่อมต่อไปยัง resource system เหล่านั้นคือเท่าไร?
  • เครื่องที่ระบบนี้จะไป deploy มีทรัพยากรเหลือโดยเฉลี่ยเท่าไร? เช่น ต่อชั่วโมง ต่อวัน
  • มีทรัพยากรใดที่ถูกเข้าถึงพร้อมกันบ้าง (simultaneous access)? เกี่ยวข้องกับฟังก์ชั่นหรือกลไกใด?

Client Behavior

  • แบ่งผู้ใช้ หรือ client เป็นกี่ประเภท?
  • พฤติกรรมของผู้ใช้ หรือ client แต่ละประเภทเป็นอย่างไร?

Deadline

  • Deadline ของ process/transaction จะกำหนดที่เท่าไร? ในช่วงนี้อาจยังไม่ทราบชัดเจน เอาคำตอบแบบคร่าวๆ ก่อน เป็นช่วงเวลาหรือค่าประมาณ

Throughput

  • ปริมาณงานที่จะเสร็จต่อช่วงเวลาเป็นเท่าไร? เช่น ภายใน 1 ช.ม.ต้องประมวลผลคำสั่งสั่งซื้อให้เสร็จอย่างน้อย 100 คำสั่ง

Latency

  • ระยะเวลาหน่วงหรือดีเลย์ในการเข้าถึงทรัพยากรคือเท่าไรที่ยอมรับได้? เข้าถึงทรัพยากรใด? เช่น หาก request  เข้าไปถึง database แล้ว database จะใช้เวลาประมวลผล request นี้ไม่เกิน 1,000 มิลลิวินาที แต่พอ request ไปถึง database แต่ดันไม่ว่าง เข้าไม่ได้ request เลยต้องรอ เสียเวลารอไป 850 มิลลิวินาที พอเข้าได้แล้ว database ประมวลผล request ไป 1,000 มิลลิวินาที สรุปแล้วระยะเวลาเข้าใช้ database โดยรวมคือ 1,850 มิลลิวินาที คิดเป็นเวลา latency (หรือเวลาหน่วง/ดีเลย์) 850 มิลลิวินาที ดังนั้นระบบที่ต้องการความเร็วมากๆ จึงต้องหาทางลด latency ลง เพื่อให้ response time สั้นลง ซึ่ง latency สามารถเกิดได้ทุกจุดที่เป็น resource โดยเฉพาะ shared resource ที่ต้องใส่ใจมากๆ

Business Process

  • มี business process ให้วิเคราะห์หรือไม่?
  • Business process มีความละเอียดพอนำมาวิเคราะห์ประเด็นต่างๆ ในคำถามก่อนหน้าหรือไม่? (ในหลายงานจำเป็นต้องจูนทั้ง business (คนทำ) และ system (ระบบทำ))

Cost & Budget

  • มีงบประมาณสำหรับทรัพยากร/ฮาร์ดแวร์เท่าไร?
  • โดยประมาณเท่าไร?
  • ที่สามารถจ่ายได้สูงสุดไม่เกินเท่าไร?

NFR Checklist ด้าน Scalability

ความต้องการ (Requirement)

สมมติฐาน (Assumption)

Increased Users

  • อัตราการเพิ่มขึ้นของจำนวนผู้ใช้, client และ concurrent มีหรือไม่ เท่าไร?
  • พฤติกรรมของผู้ใช้/client เป็นอย่างไร?

Increased Features

  • ระบบจะมีฟีจเจอร์หรือเซอร์วิสเพิ่มในอนาคตหรือไม่? ถ้ามีมีเมื่อไร เท่าไร? ฟีจเจอร์หรือเซอร์วิสอะไร?

Reduced Resources

  • เครื่องที่ระบบนี้จะ deploy มีระบบอื่นทำงานอยู่ด้วยหรือไม่? ถ้ามีให้ตั้งคำถามเกี่ยวกับ Scalability ทุกข้อกับระบบเหล่านั้นด้วย เพราะต้องวิเคราะห์อัตราการเปลี่ยนแปลงของระบบเหล่านั้นด้วย
  • เครื่องที่ระบบนี้จะ deploy จะมีระบบอื่นมา deploy บนเครื่องนี้ในอนาคตหรือไม่?

Budgeting

  • มีการเตรียมด้านงบประมาณหรือวางแผนด้านงบประมาณประกอบหรือไม่ ในกรณีต้อง scale-up หรือ scale-out ในอนาคต?

*โดยทั่วไปนิยม scale ไปเพื่อสนับสนุน performance ให้ดีขึ้น จริงๆ แล้วสามารถ scale ได้หลายแบบ แบ่งเป็น 2 ประเภทใหญ่ๆ คือ scale up (vertical scale) กับ scale out (horizontal scale) ซึ่งวัตถุประสงค์การ scale ก็มีหลายประการ อาทิ scale เพื่อสนับสนุน performance, เพื่อสนับสนุน availability (เช่นการทำ HA (high availability) cluster), เพื่อสนับสนุนเสถียรภาพระบบ เป็นต้น แต่ไม่ว่าจะ scale แบบใดล้วนใช้เงินทั้งนั้น หลายคนชอบวิตกเรื่อง performance แต่กับ scalability นี่น่ากลัวกว่าเยอะ เพราะองค์ประกอบต่างๆ ต้องวางอย่างดี สอดคล้องกัน ไม่ว่าจะเป็น ภาษาโปรแกรม, เฟรมเวิร์ก, สถาปัตยกรรมระบบ, แอพพลิเคชั่นเซิร์ฟเวอร์, database, การเลือกรูปแบบ cluster ที่จะใช้, ฮาร์ดแวร์ เป็นต้น

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

ยิ่งถ้าเป็นระบบซับซ้อนประเภท composite system ที่มีหลายระบบในหลายโซนเน็ตเวิร์กมาทำงานร่วมกันยิ่งไปกันใหญ่ เพราะมี quality attribute ด้าน interoperability & integrability เข้ามาเกี่ยวข้องด้วย และยิ่งหากสถาปัตยกรรมโดยรวมออกแบบจัดการ quality attribute ด้าน modifiability มาไม่ได้ และการจัดการ quality attribute ด้าน testabiltiy ในแง่การเตรียม test data, test environment, test scenario, test case มาไม่สะท้อนความเป็นจริง และทำ regression test ไม่ดีพอ… มีโอกาสเจอสถานการณ์ ‘ฟลุ้ก test ผ่าน’ ได้ง่ายๆ เพราะคิด test case กันง่ายๆ มั่วๆ เลยทดสอบผ่าน แต่พอเริ่มใช้งานระบบจริงๆ ปัญหาเกิด… ดังนั้น scalability ไม่ง่ายครับ ผมลิสต์ความต้องการและสมมติฐานเอาไว้นิดเดียว จริงๆ มีเยอะมาก เอาไว้จะเขียนอธิบายแยกเป็นบทความต่างหาก

 

NFR Checklist ด้าน Interoperability  & Integrability

ความต้องการ (Requirement)

สมมติฐาน (Assumption)

Legacy System Integration

  • มี legacy system ที่ต้องไปเชื่อมต่อ (interface) หรือไม่?
  • ถ้ามี เป็นระบบอะไร? ยี่ห้ออะไร? เวอร์ชั่นอะไร? ใช้ภาษาหรือเทคโนโลยีหรือโปรโตคอลอะไร? สถานที่ตั้งอยู่ที่ไหน?
  • เกี่ยวข้องกับฟังก์ชั่นหรือกลไกใด?
  • มีความถี่ในการไปติดต่อหรือเรียกใช้เท่าไร? เช่น 2,000 ครั้งต่อวัน
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อการเชื่อมต่อ?

External System Interoperation

  • มี external system หรือไม่ ที่ต้องไปเรียกใช้หรือถูกเรียกใช้?
  • ถ้ามี เป็นระบบอะไร? ยี่ห้ออะไร? เวอร์ชั่นอะไร? ใช้ภาษาหรือเทคโนโลยีหรือโปรโตคอลอะไร? สถานที่ตั้งอยู่ที่ไหน?
  • เกี่ยวข้องกับฟังก์ชั่นหรือกลไกใด?
  • มีความถี่ในการไปเรียกใช้หรือถูกเรียกใช้เท่าไร? เช่น 2,000 ครั้งต่อวัน
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อการทำงานร่วมกัน?

Boundary

  • ขอบเขตระบุชัดเจนแล้วหรือไม่?
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อการกำหนดขอบเขต? จะมีการเปลี่ยนแปลงหรือแปรผันอย่างไรได้หรือไม่ เกิดจากปัจจัยใด?

Data Exchange

  • ต้องมีการแลกเปลี่ยนข้อมูลหรือไม่?
  • หากมีการแลกเปลี่ยนข้อมูล ต้องมีการ convert ฟอร์แมตข้อมูลหรือไม่ ระหว่างฟอร์แมตอะไรกับฟอร์แมตอะไร?
  • ต้องมีฟอร์แมตข้อมูลกลางหรือไม่? ถ้ามีมีมาตรฐานหรือไม่?

Granularity

  • ปริมาณการติดต่อกันเท่าไร? เช่น ต่อชั่วโมง, ต่อนาที, ต่อวัน
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อปริมาณข้อมูลที่รับ-ส่งกัน?

Security

  • มี constraint ด้าน security หรือไม่?

Reliability

  • มีการเชื่อมต่อหรือการทำงานร่วมกันในส่วนใดบ้างที่ต้องการความน่าเชื่อถือสูงๆ?
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อความน่าเชื่อถือ?
  • มีเกณฑ์การควบคุมเสถียรภาพการทำงานระหว่างระบบอะไรบ้าง?

Performance

  • มีการเชื่อมต่อหรือการทำงานร่วมกันในส่วนใดบ้างที่ต้องการประสิทธิภาพสูงๆ?
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อประสิทธิภาพ?

Modifiability

  • หากระบบปลายทางมีการเปลี่ยนแปลงใดๆ เกิดขึ้น (เช่น เทคโนโลยี ฟอร์แมตข้อมูล business logic) สามารถส่งผลกระทบต่อระบบที่ไปเรียกได้หรือไม่? แค่ไหน?
  • มีการเปลี่ยนแปลงอะไรบ้างที่ระบบต่างๆ ที่เชื่อมต่อและทำงานร่วมกัน ต้องร่วมกันกำหนดและแก้ไขให้เป็นมาตรฐาน?

Availability

  • มีการกำหนด SLA ระหว่างกันหรือไม่ อย่างไร?
  • มี constraint ใดบ้างที่ส่งผลกระทบต่อความพร้อมในการให้บริการ?
  • หากระบบปลายทางล่ม หรือไม่ตอบสนอง จนไม่สามารถเชื่อมต่อได้ จะทำอย่างไร?

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s