สรุป Paper “Toward a More Reliable Theory of Software Reliability”

จาก Paper เรื่อง “Toward a More Reliable Theory of Software Reliability

จุดมุ่งหมายของ Paper นี้เพื่อรวบรวมกรรมวิธี “Software Reliability Theory” ที่ใช้กันทั่วไป ตลอดจนที่มีใช้ใน Field .. Telecommunication และ Aerospace
รวมทั้งได้เสนอกรรมวิธีใหม่ในงานวิจัย Software Reliability, “ปัจจัยที่เป็นผลร้าย ที่ส่งผลต่อ พฤติกรรมของ Software”

  • “Software Testing” เกิดขึ้นหลังจากการพัฒนา (ก่อนส่งมอบ) เพื่อรับรองว่า Software ดังกล่าวใช้งานได้จริง …แต่สำหรับ “Software Reliability Theory” จะมุ่งประเด็นไว้ที่ เมื่อนำ Software ไปใช้งานจริง จะสามารถเชื่อถือได้หรือไม่ อย่างไร
  • Reliability Model สามารถวัดค่าได้เป็นปริมาณ .. แต่กระบวนการ Software Testing นำค่าดังกล่าวเพื่อระบุว่า Software ผ่านเกณฑ์บททดสอบหรือไม่เท่านั้น แต่ไม่ได้นำปริมาณ มาทำนายผลการทำงานใน Field จริง
  • สอง Field ที่นำ Reliability Theory ไปใช้ได้ผลคือ Telecommunication & Aerospace เนื่องจากสองเหตุผลคือ
    1. เป็นงานที่ต้องการคุณภาพ มีรัฐควบคุม ส่งมอบครั้งเดียว แต่สำหรับ Commercial Software แล้วอาจจำเป็นต้องเพิ่มเติม Feature อีก .. ส่งผลถึง bug ??
    2. เนื่องจากงานทั้งสอง (tele & aero) ผนึกเข้ากับ Embedded System – Hardware อย่างไม่สามารถแยกแยะได้ .. จึงไม่อาจจำแนกว่าความผิดพลาดที่เกิดขึ้นนั้น มาจาก S/W หรือ H/W
  • เหมือนจะค่อยๆเล่าจากอดีตมาสู่ปัจจุบัน .. ซึ่งกล่าวว่า Community ที่ทำวิจัยเรื่องนี้ยังคงไม่ให้ความเชื่อถือกับกรรมวิธีทั้งหมดที่คิดขึ้นได้ในปัจจุบันจะรับประกันได้ว่า Softwares ที่สร้างขึ้นจะมี Reliability ตามที่มุ่งหวัง 100%

Software Reliability Defined
คืออะไร ?

เชื่อว่ามีที่มาจาก Field ด้าน Hardware โดยที่เรื่องหลักที่ถกเถียงกันคือ Time และ Operating Condition ดังนั้น “Software Reliability” = โอกาสที่ Software จะทำงานโดยปราศจากความผิดพลาดภายใต้ระยะเวลา และสภาพแวดล้อมที่กำหนด

Rethinking the notion of time

“เมื่อใด H/W ที่ออกแบบไว้จะเกิดความผิดพลาด ?” .. H/W ที่ถึงแม้จะถูกสร้างอย่างดีแต่ก็สามารถเสื่อมสภาพตามระยะเวลา หรือวิธีการใช้งานที่แตกต่างกัน ต่างกับ S/W ที่ความผิดพลาดเกิดต่อเมื่อ ความผิดพลาดที่ไม่ได้ตรวจพบขณะพัฒนา กลับปรากฏออกมาขณะกำลังใช้งาน ซึ่งคำถามจะเฉพาะเจาะจงไปว่า “เมื่อใดความผิดพลาดที่ไม่สามารถตรวจพบได้ขณะพัฒนา S/W จะปรากฏ ?” .. นำไปสู่ข้อกำหนดว่า Tester ต้องทำการทดสอบด้วยระยะเวลานานเท่าใด ภายใต้คุณสมบัติเสมือนใช้งานจริง

Alternative criteria

กฏเกณฑ์ใดที่เราสามารถใช้ยืนยันได้ว่า S/W มีความน่าเชื่อถือได้ ? .. แค่เพียงระยะเวลาในการทดสอบพอเพียงหรือไม่นั้นขึ้นอยู่กับ ความซับซ้อนของ S/W เอง และวิธีการทดสอบที่ทำได้ครบถ้วนตาม Function การใช้งานของ S/W หรือไม่

จาก Graph จะเห็นว่ายิ่งเวลาของการทดสอบผ่านไปมากขึ้นเท่าใด Reliability ก็ยิ่งเพิ่มมากขึ้นเท่านั้น เพราะเหตุผลว่าตรวจพบ Bug ใน S/W ลดลงจึงอนุมาณว่าความน่าเชื่อถือเพิ่มขึ้น อธิบายได้ตามสมการต่อไปนี้ (Function ของ Lamda คือ Failure Rate)

อย่างไรก็ดี สมการดังกล่าวไม่ได้ประกอบด้วยตัวแปรที่สามารถนำความ Complexity ของ S/W เข้ามาคิด ดังนั้นจึงต้องเป็นหน้าที่ของ Tester เองที่จะต้องปรับให้เหมาะสมที่สุดกับสิ่งที่ต้องการทดสอบ

Rethinking the operational profile

สำหรับ H/W การใช้งานผิดประเภทไม่ได้รับการประกัน .. เหมือนกับการใช้งานเตาปิ้งขนมปังในสระน้ำ

วิธีการใช้งาน S/W ก็เป็นส่วนหนึ่งที่ต้องกำหนดในกระบวนการทดสอบ เรียกว่าOperational Profile .. จากสอง paper ที่อ้างอิง [5][6] นิยามว่าคือ กระบวนการทำงานของ S/W ทั้งหมดที่โอกาสว่าจะถูกเรียกใช้งาน .. อย่างไรก็ดี Operational Profile ควรระบุถึงกระบวนการทำงานที่ทดสอบ และสภาพแวดล้อมขณะทดสอบด้วย

การทำสอบ S/W อาจไม่ได้ทำการทดสอบทั้งหมด ได้แต่เพียงทำการทดสอบบางส่วนที่ใช้งานตามปรกติ ทำให้ Operational Profile ก็ยังแบ่งออกเป็นสองกลุ่ม คือกลุ่มที่ทดสอบแล้วว่าสามารถใช้งานได้ตามปรกติ (มักเป็น Function ที่ใช้งานทั่วไป) และอีกส่วนยังไม่ได้รับการทดสอบ (อาจเนื่องจากทาง Tester นึกไม่ถึง) ดังนั้นหากใช้งาน S/W ดังกล่าวนอกเหนือ Operational Profile ที่ทดสอบ จึงไม่สามารถรับประกันความน่าเชื่อถือได้

ความซับซ้อนของ Operational Profile ที่ถูกกำหนดให้ทดสอบ ยิ่งมีมากขึ้นเมื่อคำนึงถึง Condition ของสภาพแวดล้อมที่ไม่คาดคิดมาก่อน และยังไม่มี Profiling Technique (งานวิจัย) นำเสนอในปัจจุบัน

  • Word Processing หากกำลัง Save file แล้ว Disk เสีย ?
  • ถ้ามีการ Set จากระบบ OS ให้ File ที่ทำงานอยู่ใน S/W, เปลี่ยนเป็น Read-only ?
  • ในระบบ Multi-user จะมีปัญหาเรื่อง Access Privilege หรือไม่ ?

Revisiting Software Reliability Fundamentals
หลักการพื้นฐาน

หาก Operational Profile รวมทุกความเป็นไปได้ของวิถีทางการใช้งาน กรณีที่ต้องทดสอบย่อมต้องมีจำนวนมหาศาล ซึ่งทางหนึ่งที่ช่วยได้คืออาศัยสังคมของผู้ที่ใช้ S/W ประเภทนี้เป็นประจำ ช่วยกำหนด Operational Profile

อีกประเด็นที่น่าสนใจคือ หาก S/W เกิดจากการ Repair และ Modification ล่ะ ? ..

  • ความเกี่ยวเนื่องของ S/W เก่า กับที่ถูกแก้ไข, มี Reliability, ตรวจวัดเชิงสถิติได้หรือไม่ ?
  • ดูแลเรื่องความผิดพลาดซ้ำจาก Version ก่อนได้อย่างไร ?
  • Profile ของการทดสอบ S/W ที่ได้ทำการแก้ไข จำเป็นต้องรวมสิ่งที่เคยทดสอบไปแล้วหรือไม่ ?
  • หากว่า Failure ที่เคยเกิดมากก่อน เกิดขึ้นล่ะ ?

ทั้งหมดนี้เพื่อบอกว่า จำเพาะ “ระยะเวลาของการทดสอบ” กับ “Operational Profile ที่เป็นเพียง Math” ยังไม่พอเพียงที่จะรับรอง Reliability .. สิ่งที่ควรมองให้ลึกลงไปอีกคือประเด็นที่ทำให้เกิดข้อผิดพลาด

Application Complexity

เนื่องจาก S/W มี Complexity แตกต่างกัน จำเป็นต้องแจกแจงกระบวนการทำงาน แค่การทดสอบจำนวนครั้งของการเกิด Fault ใน S/W ตามระยะเวลาทดสอบไม่เพียงพอ ควรมีเปรียบเทียบร่วมกับความซับซ้อนในการทดสอบด้วย (ทดสอบได้ครบถ้วนหรือไม่ ? .. การทดสอบ Function ปัจจุบันทำเป็นครั้งแรกตั้งแต่ต้น S/W เริ่มทำงาน หรือทำต่อจากการทดสอบ Function อื่นก่อนหน้า ? .. Error สะสม ?)

Test Effectiveness

เพียงแค่ช่วงระยะเวลทดสอบนานขึ้น ไม่มีประโยชน์ ประสิทธิผลขึ้นอยู่กับจำนวน Test Input และวิธีการทดสอบที่หลากหลาย (ครอบคลุม)

Complete Operating Environment

Operational Profile ที่อ้างอิงในการทดสอบ มีสมมติฐานบนสภาวะแวดล้อมที่ทดสอบเท่านั้น ดังนั้นการใช้งานนอกเหนือสภาวะแวดล้อมดังกล่าว จะไม่สามารถรับรอง Reliability ของ S/W ได้ .. ซึ่งคำถามต่อมาก็คือ “ต้องระบุ อะไร เท่าไร จึงพอเพียงแก่การเป็น สภาวะแวดล้อมของ Operational Profile ?” .. Hardware Configuration ที่ใช้กับ S/W .. ระบบที่ใช้ Run ตัว S/W .. พอเพียงหรือยัง ? .. ถ้าคำตอบคือยิ่งมากยิ่งดี แน่นอนว่าคงต้องบันทึกทุกรายละเอียดระหว่างการทดสอบ .. และสิ่งสำคัญที่สามารถเพิ่มเติมลงใน Operational Profile ได้อีกคือ Third-Party Software, Runtime Library และ Data File ที่ใช้ทดสอบ

ตัวอย่าง การทดสอบ S/W ตัวหนึ่งสามารถยืนยันได้ว่ามี Reliability 99.99% หากใช้งานกับ OS “X” ร่วมกับ Database Engine “Y” ทั้งยังแนบฉลากกำกับ (เหมือน อย. ) ว่าควรระวังหากใช้งานนอกเหนือจากสภาวะแวดล้อมที่กำหนดก็จะดียิ่งขึ้น .. อย่างไรก็ดี ในอีกมุมหนึ่ง หากระบุจำกัดสภาวะแวดล้อมจำกัดมากเกินไป (ต้องเป็น Computer ที่ตั้งอยู่ที่ดาวอังคารเท่านั้น) ค่า Reliability ดังกล่าวจะไม่สามารถนำไปใช้ประโยชน์ได้เช่นกัน

Research Agenda Software Reliability
ประเด็นข้อวิจัย

ใน Field ของ S/W Reliability เราทำการ Model ตัว S/W ให้อยู่ในรูป Math เพื่อสามารถคำนวณได้ หรืออีกวิธีคืออาศัยกระบวนการทางสถิติทดสอบเก็บค่า เพื่อนำมาคำนวณหา Reliability .. ยิ่งกว่านั้น ได้อาศัยงานวิจัยนอกเหนือจาก Field ของ S/W Reliability อาทิเช่น “กรรมวิธีหา Complexity ของ S/W”, “การวัดทดสอบประสิทธิผล”, และ “วิธีกำหนด ตรวจสอบ สภาวะแวดล้อมของ S/W” .. เพื่อทำให้ค่า Reliability ที่ได้น่าเชื่อถือ แม่นยำที่สุด

Measuring Application Complexity

หลายปัจจจัยที่ทำให้ S/W ซับซ้อน

  • มี Input และ Output จำนวนมากที่ต้องตรวจสอบความถูกต้อง
  • ยากที่จะจำลองสถานการณ์ที่ต้องการทดสอบขึ้นมา เช่นจะดูว่าหากเกิด Fault ของ H/W ขึ้นมา S/W ยังสามารถทำงานต่อได้หรือไม่ .. ต้องมีการทดสอบพัง H/W ?
  • ต้องทดสอบกับสภาวะแวดล้อมหลากหลาย โดยควบคุม Input ที่ป้อนให้เหมือนกัน
  • หาก S/W ที่ถูกทดสอบต้องทำงานร่วมกับระบบ หรือ S/W อื่น จำเป็นต้องควบคุมให้ทั้งสอง (ซึ่ง Share ข้อมูล หรือมีการส่ง Signal หากัน) ทำงานอย่างสอดคล้องกับแนวทางทดสอบให้ได้ .. และจะยากขึ้นไปอีกหาก S/W ที่ทดสอบ ต้องเชื่อมต่อร่วมกับ S/W อื่นจำนวนมาก
  • Fault บางกรณีเกิดขึ้นเนื่องจากการป้อน Input ในลำดับที่ถูกต้อง .. ถึงแม้เป็น Input เดียวกัน แต่หากลำดับไม่เหมือนกันก็หาไม่พบ

หากคาดหวังว่าการค้นหา Fault ของ S/W จาก Source Code จะแก้ปัญหาได้ .. ผิดถนัด .. เพราะ Fault บางอย่างเป็นผลภายหลังจากการ Compile .. ซับซ้อน

*** มีตัวอย่างงานวิจัยหรือไม่ ***

Code Complexity Metrics

ความสัมพันธ์ที่วัดได้ระหว่าง Quality กับ Code นั้น เป็นผลมาจาก “คุณสมบัติของพฤติกรรม” ไม่ใช่ “โครงสร้างของ Source Code” .. ยิ่ง S/W มี Logic ซับซ้อนเท่าไร โอกาสเกิด Bug ก็จะมีมากยิ่งขึ้น .. จึงเป็นการยากที่จะออกแบบ Code Metric หนึ่งเดียวสำหรับ S/W ทุกประเภท

กรณีศึกษาเรื่อง จรวด Centaur ณ. ฐานยิง Ariane-5 คือความผิดพลาดเนื่องจากการ Reuse Code ที่ใช้ค่าเดิมไม่ได้เปลี่ยนค่า Constant ใหม่ ทำให้เกิดระเบิด ..เห็นได้ชัดว่าเป็นอะไรที่ไม่เกี่ยวกับโครงสร้างของ Source Code เลย

ดังนั้นค่าคุณภาพ S/W จาก Metric ดังกล่าว จึงเกี่ยวข้องโดยตรงกับการจัดการ Source Code เช่นสามารถทำความเข้าใจได้ง่าย หรือบำรุงรักษาได้สะดวก .. PIE (Propagation, Infection, and Execution) จะพูดถึงพฤติกรรม สภาพแวดล้อมในการดูแลรักษา Source Code

PIE Model :

  • Propagation Analysis คือ
  • Infection Analysis คือ
  • Execution Analysis คือ

Measuring Test Effectiveness

จะทราบได้อย่างไรว่า Generated Test Case ที่ทำขึ้น มีประสิทธิผลจริง ? .. สามารถวัดผลได้หรือไม่ ? .. แนวทางวิจัยนี้ต้องตอบโจทย์จากปัจจัยทั้งสามคือ ความซับซ้อนของ Source Code, สภาวะแวดล้อมที่ S/W ทำงาน, และความสามารถของ S/W ที่จะสามารถหลบซ่อน Bug ได้

นับจำนวน Bug ที่พบต่อจำนวนของบันทัด ? .. งานอัปรีย์มาก เพราะไม่ได้ระบุประเภทของ Fault, เกิดขึ้นบ่อยแค่ไหน, และไม่สามารถทำนายต่อได้ว่าจะเกิดขึ้นอีกเท่าไร

Software Fault Injection

@article{ hsueh97fault,
author = “Mei-Chen Hsueh and Timothy K. Tsai and Ravishankar K. Iyer”,
title = “Fault Injection Techniques and Tools”,
journal = “IEEE Computer”,
volume = “30”,
number = “4”,
pages = “75-82”,
year = “1997”,
url = “http://citeseer.ist.psu.edu/hsueh97fault.html” }

Modeling Complete Operating conditions

The Road Ahead
ทิศทางในอนาคต

ยังดีที่ปัญหาดังที่ได้กล่าวมา ไม่กระทบต่อ S/W ที่ใช้กันอยู่มากนัก, วิธีการวัด Reliability ยังไม่นับว่าต้องใช้งานอย่างแพร่หลาย .. การวัดผลที่ไม่แม่นยำ เนื่องมาจาก Model ที่นำมาวิเคราะห์มีพื้นฐานจากวิธีการทำงานที่ยังไม่ครบถ้วนดี ทั้งสภาวะแวดล้อมที่ยังไม่สามารถรวบรวมได้ทั้งหมด .. ที่ควรทำคือ ต้องคำนึงถึงเหตุการณ์ที่อาจทำใหเกิด Bug ทั้งหมด

หัวข้อที่จะทำให้สมการที่บอกได้ถึง Reliability ของ S/W ได้อย่างแม่นยำควรประกอบไปด้วย

  • Application Complexity (ความซับซ้อนวัดออกมาได้หรือเปล่า ?)
  • Test Effectiveness (ระบุค่าของประสิทธิผล,Output ของสมการ, ได้หรือไม่ ?)
  • Test Suite ที่หลากหลาย (Input, สถานะการณ์ ที่หลากหลาย ?)
  • Operational Profile ที่ครบถ้วน (วิธีการใช้งานทั้งหลาย ?)

ซึ่งน่าจะเป็นหัวข้อที่น่าสนใจ และส่งผลดีต่ออุตสาหกรรมพัฒนา S/W ต่อไปในอนาคต

Note

  • ยังไม่เข้าใจคำว่า notions of time และคำว่า operational profile

    The notions of time and the operational profile incorporated into software reliability are incomplete.
    Reliability shoulf be redefined as a function of application complexity, test effectiveness, and operating environment.

  • Reliability = Function ( Complexity, Test effectiveness, Operating environment )
  • Shrink-wrap Software ???
Advertisements

ใส่ความเห็น

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