อะไรจะเป็นคำอธิบายสำหรับการสังเกตนี้?
- ระบบจองโรงเรียนที่เสนอมาดูมีประสิทธิภาพ แต่คำแนะนำขึ้นอยู่กับผู้ใช้ ข้อจำกัด และหลักฐาน คำศัพท์ทางเทคนิคที่สมเหตุสมผลเพียงอย่างเดียวไม่ใช่การตัดสินใจที่มีเหตุผลรองรับ
- เริ่มต้นด้วยการทำนาย ระบุปริมาณหรือลักษณะที่คุณจะเปรียบเทียบ แล้วตัดสินใจว่าหลักฐานอะไรที่จะแยกแยะคำอธิบายสองแบบได้
สร้างโมเดล
- กรณีศึกษาตั้งทางเลือกทางคอมพิวเตอร์ไว้ในสถานการณ์ที่กำหนด ระบุผู้มีส่วนได้ส่วนเสีย ความต้องการ หลักฐานที่มีอยู่ และข้อจำกัดก่อนแนะนำสถาปัตยกรรมหรืออัลกอริทึม แยกแยะข้อเท็จจริงของสถานการณ์ออกจากสมมติฐานและการคาดการณ์ การแลกเปลี่ยนอาจเกี่ยวข้องกับประสิทธิภาพ ความน่าเชื่อถือ การเข้าถึง ความเป็นส่วนตัว การบำรุงรักษา และค่าใช้จ่าย
- throughput: งานที่เสร็จสิ้นต่อหน่วยเวลาภายใต้ภาระงานที่กำหนด; acceptance test: การทดสอบว่าความต้องการของผู้ใช้ที่กำหนดไว้ได้รับการตอบสนองหรือไม่
เลือกหลักฐานที่นำมาทดสอบได้
- คำแนะนำควรเชื่อมโยงความต้องการกับกลไกและการทดสอบที่สังเกตได้ ตัวอย่างเช่น ปัญหาความพร้อมใช้งานต้องการกลยุทธ์ที่ป้องกันการอัปเดตที่ขัดแย้งกัน plus การทดสอบที่แสดง invariant ข้ออ้างเกี่ยวกับความเร็วที่เพิ่มขึ้นต้องการการวัดภาระงานที่เทียบเคียงกันได้แทนที่จะใช้ฉลากความซับซ้อนเท่านั้น ประเมินทางเลือกภายใต้เงื่อนไขที่กำหนดเดียวกัน
- ใช้สถานการณ์ที่รับรองโดยโรงเรียนและข้อมูลสังเคราะห์ สร้างเมทริกซ์ของข้ออ้าง หลักฐานสถานการณ์สนับสนุน คำอธิบายทางเทคนิค ข้อจำกัด และการทดสอบที่ยอมรับ ระบุข้อเท็จจริงที่ขาดหายไปอย่างชัดเจนและแสดงว่าคำแนะนำจะเปลี่ยนไปอย่างไรหากสมมติฐานล้มเหลว สิ่งนี้เตรียมความพร้อมสำหรับการให้เหตุผลจากกรณีโดยไม่คัดลอกกรณีศึกษาการประเมิน IB ที่ไม่สามารถเข้าถึงได้หรือสร้างเกณฑ์การสอบขึ้นมาเอง
เริ่มจากปริมาณที่ทราบแล้ว
- ระบุค่าที่ทราบและหน่วยของมัน เลือกความสัมพันธ์โดยพิจารณาว่าข้อสมมติฐานสอดคล้องกับเคสนี้ แล้วจัดรูปสมการก่อนแทนค่า
- Known: โปรโตไทป์สมมติประมวลผล 120 คำขอสำเร็จในช่วงสังเกต 30 วินาที Throughput คือ 120/30=4 คำขอสำเร็จ/วินาที โปรโตไทป์ที่สองประมวลผล 150 ในช่วง 30 วินาที หรือ 5/วินาที โปรโตไทป์ที่สองมี recorded throughput สูงขึ้น 25% แต่ไม่สามารถสรุปเรื่อง latency, อัตราความล้มเหลว หรือประสิทธิภาพภายใต้ภาระงานที่ใหญ่กว่านี้ได้หากไม่มีข้อมูลวัดเหล่านั้น
ตัวอย่าง:
ระบบสมมติประมวลผลสำเร็จ 210 คำขอใน 30 วินาที. คำนวณ throughput. ใช้ลำดับเดียวกัน: ปริมาณที่ทราบ → โมเดล → ความสัมพันธ์ → แทนค่า → หน่วยและการตีความ
ตรวจสอบข้อสรุปและขอบเขต
- Throughput ไม่ใช่เวลาตอบสนอง คำแนะนำที่แข็งแกร่งต้องระบุเงื่อนไขที่คาดว่าจะทำงานได้และหลักฐานที่อาจปฏิเสธได้ ตรวจสอบข้อกำหนดกรณีศึกษา CS ของทางการปัจจุบันเทียบกับเวอร์ชันการประเมินที่เกี่ยวข้อง
- กลับไปที่การสังเกตเดิม อธิบายว่าผลลัพธ์นี้สนับสนุนสิ่งใด มีเงื่อนไขใดบ้าง และเป็นอย่างไรในการทดสอบคำอธิบายอื่นที่ขัดแย้งกัน
เตือน:
การที่พบปริมาณงานผ่านสูงโดยอัตโนมัติไม่พิสูจน์ได้ว่าเวลาตอบสนองจะต่ำกว่าสำหรับทุกคำขอ ข้อความนี้ผิด: ปริมาณงานผ่านไม่ใช่เวลาตอบสนอง คำแนะนำที่เข้มงวดควรระบุเงื่อนไขที่คาดว่าจะทำงานได้และหลักฐานที่อาจ反驳ได้ (disconfirm) ความต้องการกรณีศึกษา CS แบบทางการปัจจุบันต้องตรวจสอบกับเวอร์ชันการประเมินที่เกี่ยวข้อง
จุดสำคัญ:
การวิเคราะห์กรณีของคอมพิวเตอร์: ประเมินระบบที่เสนอ: คำแนะนำควรเชื่อมโยงความต้องการกับกลไกและการทดสอบที่สังเกตได้ ตัวอย่างเช่น ปัญหาความพร้อมใช้งาน (concurrency) ต้องใช้กลยุทธ์ที่ป้องกันการอัปเดตที่ขัดแย้งกัน plus การทดสอบที่แสดงถึง invariant ข้อกล่าวอ้างว่ามีความเร็วในการตอบสนองมากขึ้นต้องใช้การวัดภาระงานที่เทียบกันได้แทนที่จะเป็นเพียงฉลากความซับซ้อน ประเมินทางเลือกภายใต้เงื่อนไขที่ระบุไว้เดียวกัน
ลายเส้นที่ดำเนินการได้และขอบเขต
for successful, attempted, seconds in [(240, 300, 30), (270, 300, 30)]:
if seconds <= 0 or attempted <= 0:
raise ValueError("Positive exposure required")
throughput = successful / seconds
failure_fraction = (attempted - successful) / attempted
print(throughput, failure_fraction)
ผลลัพธ์ที่คาดหวัง:
8.0 0.2
9.0 0.1
อัตราการสำเร็จและอัตราความล้มเหลวใช้ตัวส่วนที่แตกต่างกัน เวลาเป็นศูนย์หรือจำนวนครั้งเป็นศูนย์ไม่สามารถรองรับอัตราเหล่านี้ได้ สรุปผลสมมติเหล่านี้ไม่ได้ให้หลักฐานเกี่ยวกับเวลาตอบสนอง ค่าใช้จ่าย หรือภาระงานที่เป็นตัวแทน