การตรวจสอบย้อนกลับความหมาย

การตรวจสอบย้อนกลับความหมาย (Reverse Semantic TraceabilityหรือRST ) เป็น วิธี การควบคุมคุณภาพเพื่อปรับปรุงการตรวจสอบ ช่วยให้มั่นใจได้ว่าชิ้นงาน มีคุณภาพสูง โดยการแปลความหมายย้อนกลับในแต่ละขั้นตอนของกระบวนการพัฒนาซอฟต์แวร์

แต่ละขั้นตอนของกระบวนการพัฒนาสามารถมองได้ว่าเป็นชุดของการ “แปล” จากภาษาหนึ่งไปอีกภาษาหนึ่ง ในช่วงเริ่มต้น ทีม งานโครงการจะจัดการกับความต้องการและความคาดหวังของลูกค้าที่แสดงออกมาในภาษาธรรมชาติ ความต้องการของลูกค้าเหล่านี้บางครั้งอาจไม่สมบูรณ์ คลุมเครือ หรือแม้กระทั่งขัดแย้งกันเอง ขั้นตอนแรกคือการกำหนดและทำให้ความคาดหวังของลูกค้าเป็นทางการ การเปลี่ยนผ่าน (“การแปล”) ความคาดหวังเหล่านั้นให้เป็นเอกสารความต้องการที่เป็นทางการสำหรับระบบในอนาคต จากนั้นความต้องการจะถูกแปลเป็นสถาปัตยกรรมของระบบและทีละขั้นตอนทีมงานโครงการจะสร้างโค้ดที่เขียนด้วยภาษาโปรแกรมที่เป็นทางการมาก การแปลนั้นมีความเสี่ยงที่จะเกิดข้อผิดพลาด การตีความผิด หรือการสูญหายของบางสิ่งบางอย่างอยู่เสมอ แม้แต่ข้อผิดพลาดเล็กน้อยในความต้องการหรือข้อกำหนดการออกแบบ ก็อาจทำให้เกิดข้อผิดพลาดจำนวนมากในขั้นตอนสุดท้ายของโครงการ บางครั้งความเข้าใจผิดดังกล่าวอาจนำไปสู่ความล้มเหลวของโครงการหรือความไม่พอใจของลูกค้าอย่างสิ้นเชิง

สถานการณ์การใช้งานสูงสุดของวิธีการตรวจสอบย้อนกลับความหมาย (Reverse Semantic Traceability) ได้แก่:

• การตรวจสอบความถูกต้อง ของแบบจำลอง UML : วิศวกรคุณภาพจะกู้คืนคำอธิบายที่เป็นข้อความของโดเมนจากนั้นจะเปรียบเทียบคำอธิบายต้นฉบับและคำอธิบายที่กู้คืนแล้ว
• การตรวจสอบความถูกต้องของการเปลี่ยนแปลงแบบจำลองสำหรับข้อกำหนดใหม่: เมื่อมีแบบจำลองฉบับดั้งเดิมและฉบับที่เปลี่ยนแปลงแล้ว วิศวกรคุณภาพจะกู้คืนคำอธิบายข้อความของข้อกำหนด จากนั้นจึงเปรียบเทียบคำอธิบายฉบับดั้งเดิมและฉบับที่กู้คืนแล้ว
• การตรวจสอบความถูกต้องของ การแก้ไข ข้อผิดพลาด : เมื่อได้รับ ซอร์สโค้ดต้นฉบับและซอร์สโค้ดที่แก้ไขแล้ววิศวกรคุณภาพจะสร้างคำอธิบายข้อความของข้อผิดพลาดที่ได้รับการแก้ไขขึ้นมาใหม่ จากนั้นจึงเปรียบเทียบคำอธิบายต้นฉบับกับคำอธิบายที่สร้างขึ้นใหม่
• การรวม วิศวกรซอฟต์แวร์คนใหม่เข้าสู่ทีม: สมาชิกทีมใหม่ได้รับมอบหมายให้ทำการตรวจสอบความเชื่อมโยงเชิงความหมายย้อนกลับ (Reverse Semantic Traceability) สำหรับส่วนประกอบสำคัญจากโครงการปัจจุบัน

บทบาทหลักที่เกี่ยวข้องในเซสชั่น RST ได้แก่:

• ผู้เขียนผลงานโครงการ (ทั้งข้อมูลนำเข้าและผลลัพธ์)
• วิศวกรย้อนกลับ
• กลุ่มผู้เชี่ยวชาญ
• ผู้จัดการโครงการ

การตรวจสอบความเชื่อมโยงเชิงความหมายย้อนกลับ (Reverse Semantic Traceability: RST) สามารถนำไปใช้กับสิ่งประดิษฐ์ใดๆ ในโครงการ ส่วนใดส่วนหนึ่งของสิ่งประดิษฐ์นั้น หรือแม้แต่เอกสารหรือโค้ดชิ้นเล็กๆ ก็ได้ อย่างไรก็ตาม เป็นที่ชัดเจนว่าการดำเนินการ RST กับสิ่งประดิษฐ์ทั้งหมดจะทำให้เกิดภาระงานเพิ่มขึ้นและควรได้รับการพิจารณาอย่างรอบคอบ (ตัวอย่างเช่น สำหรับซอฟต์แวร์ทางการแพทย์ที่การสูญเสียข้อมูลที่อาจเกิดขึ้นเป็นเรื่องสำคัญมาก)

เป็นความรับผิดชอบของบริษัทและผู้จัดการโครงการที่จะต้องตัดสินใจว่าควร " วิเคราะห์ย้อนกลับ" ( reverse engineering ) ชิ้นส่วนหรือองค์ประกอบต่างๆ ของโครงการมากน้อยเพียงใด จำนวนนี้ขึ้นอยู่กับรายละเอียดเฉพาะของโครงการ เช่น เมทริกซ์ การแลกเปลี่ยนผลประโยชน์นโยบายการประกันคุณภาพ ของโครงการและบริษัทนอกจากนี้ยังขึ้นอยู่กับความสำคัญของชิ้นส่วนหรือองค์ประกอบนั้นๆ ต่อความสำเร็จของโครงการ และระดับการควบคุมคุณภาพที่ใช้กับชิ้นส่วนหรือองค์ประกอบนั้นๆ ด้วย

จำนวนครั้งของการประชุม RST สำหรับโครงการจะถูกกำหนดไว้ในขั้นตอนการวางแผนโครงการ

อันดับแรก ผู้จัดการโครงการควรสร้างรายการสิ่งประดิษฐ์ทั้งหมดที่ทีมงานโครงการจะมีตลอดโครงการ อาจนำเสนอในรูปแบบแผนผังต้นไม้ที่มีความสัมพันธ์และการพึ่งพาอาศัยกัน สิ่งประดิษฐ์อาจปรากฏเพียงครั้งเดียว (เช่นเอกสารวิสัยทัศน์ ) หรือหลายครั้ง (เช่น ความเสี่ยงหรือข้อบกพร่อง) รายการนี้สามารถเปลี่ยนแปลงได้ในภายหลังระหว่างโครงการ แต่แนวคิดเบื้องหลังการตัดสินใจเกี่ยวกับกิจกรรม RST จะยังคงเหมือนเดิม

ขั้นตอนที่สองคือการวิเคราะห์ ความสำคัญของผลลัพธ์ ที่ต้องการสำหรับโครงการ และระดับการควบคุมคุณภาพสำหรับแต่ละส่วนประกอบของโครงการ

ความสำคัญของเอกสาร คือ ระดับผลกระทบของเอกสารต่อความสำเร็จของโครงการและคุณภาพของผลิตภัณฑ์ขั้นสุดท้าย โดยวัดจากมาตราส่วน:

• สำคัญ (1): คุณภาพของผลลัพธ์มีความสำคัญมากต่อคุณภาพโดยรวมของโครงการและแม้กระทั่งความสำเร็จของโครงการ ตัวอย่างเช่นข้อกำหนดด้านฟังก์ชันสถาปัตยกรรมระบบการแก้ไขข้อบกพร่องที่สำคัญ (ปัญหาที่ทำให้โครงการหยุดชะงัก) ความเสี่ยงที่มีความน่าจะเป็นสูงและมีผลกระทบที่สำคัญ
• สูง (2): ผลลัพธ์ที่ได้มีผลกระทบต่อคุณภาพของผลิตภัณฑ์ขั้นสุดท้าย ตัวอย่าง: กรณีทดสอบ ข้อกำหนด อินเทอร์เฟซผู้ใช้การแก้ไขข้อผิดพลาดที่มีความรุนแรงสูง ความเสี่ยงที่มีความเสี่ยงสูง
• ปานกลาง (3): สิ่งประดิษฐ์มีผลกระทบปานกลางหรือทางอ้อมต่อคุณภาพของผลิตภัณฑ์ขั้นสุดท้าย ตัวอย่าง: แผนโครงการการแก้ไขข้อผิดพลาดที่มีความรุนแรงปานกลาง ความเสี่ยงที่มีการเปิดเผยปานกลาง
• ต่ำ (4): สิ่งประดิษฐ์มีผลกระทบต่อคุณภาพของผลิตภัณฑ์ขั้นสุดท้ายน้อยมาก ตัวอย่างเช่น งานของพนักงาน ข้อบกพร่องด้านความสวยงาม ความเสี่ยงที่มีโอกาสเกิดขึ้นต่ำ

ระดับการควบคุมคุณภาพเป็นมาตรวัดที่บ่งชี้ปริมาณกิจกรรมการตรวจสอบและการรับรองที่ใช้กับชิ้นงาน และโอกาสที่จะเกิดการสื่อสารผิดพลาดในระหว่างการสร้างชิ้นงาน

• ต่ำ (1): ไม่ควรมีการตรวจสอบสิ่งประดิษฐ์ การสื่อสารผิดพลาดและการสูญเสียข้อมูลมีโอกาสสูง ช่องทางข้อมูลกระจายตัว มีอุปสรรคทางภาษา เป็นต้น
• ระดับปานกลาง (2): ไม่จำเป็นต้องมีการตรวจสอบสิ่งประดิษฐ์ ช่องทางข้อมูลไม่ได้ถูกกระจาย (เช่น ผู้สร้างสิ่งประดิษฐ์และผู้ให้ข้อมูลเป็นสมาชิกของทีมเดียวกัน)
• เพียงพอ (3): การพัฒนาแบบคู่หรือการตรวจสอบโดยเพื่อนร่วมงานเสร็จสิ้นแล้ว ช่องทางข้อมูลไม่ได้ถูกแจกจ่าย
• ยอดเยี่ยม (4): มีการพัฒนาร่วมกันเป็นคู่ การตรวจสอบโดยเพื่อนร่วมงาน และ/หรือการทดสอบ มีการทำระบบอัตโนมัติหรือการทดสอบหน่วย หรือมีเครื่องมือบางอย่างสำหรับการพัฒนาและการตรวจสอบสิ่งประดิษฐ์

ความสำเร็จของการประชุม RST ขึ้นอยู่กับการมอบหมายผู้รับผิดชอบอย่างถูกต้องเป็นอย่างมาก

การตรวจสอบความเชื่อมโยงเชิงความหมายย้อนกลับ (Reverse Semantic Traceability: RST) เริ่มต้นเมื่อมีการตัดสินใจว่าควรดำเนินการ RST และมีทรัพยากรพร้อมใช้งาน

ผู้จัดการโครงการจะกำหนดเอกสารที่จะใช้เป็นข้อมูลป้อนเข้าสำหรับเซสชัน RST ตัวอย่างเช่น อาจไม่ใช่แค่สิ่งประดิษฐ์ที่จะกู้คืนเท่านั้น แต่ยังรวมถึงข้อมูลเบื้องหลังโครงการด้วย ขอแนะนำให้ระบุจำนวนคำในข้อความต้นฉบับให้กับวิศวกรย้อนกลับ เพื่อให้พวกเขามีแนวคิดเกี่ยวกับปริมาณข้อความที่พวกเขาจะได้รับเป็นผลลัพธ์: อาจเป็นประโยคเดียวหรือหลายหน้าก็ได้ แม้ว่าข้อความที่กู้คืนอาจไม่ได้มีจำนวนคำเท่ากับข้อความต้นฉบับ แต่ค่าต่างๆ ควรเทียบเคียงกันได้

หลังจากนั้น วิศวกรย้อนกลับจะนำสิ่งประดิษฐ์นั้นมาและกู้คืนข้อความต้นฉบับกลับมา กระบวนการ RST เองใช้เวลาประมาณ 1 ชั่วโมงสำหรับข้อความหนึ่งหน้า (750 คำ)

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

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

เกณฑ์การประเมิน RST:

1. ข้อความที่ได้รับการบูรณะและข้อความต้นฉบับมีความแตกต่างกันค่อนข้างมากในด้านความหมายและมีการสูญเสียข้อมูลที่สำคัญไป
2. ข้อความที่ได้รับการบูรณะและข้อความต้นฉบับมีความแตกต่างกันในด้านความหมาย และมีการสูญเสียข้อมูลสำคัญบางส่วน
3. ข้อความที่ได้รับการบูรณะและข้อความต้นฉบับมีความแตกต่างกันในด้านความหมายบ้าง และมีการสูญเสียข้อมูลบางส่วนเล็กน้อยซึ่งไม่มีนัยสำคัญ
4. ข้อความที่ได้รับการบูรณะและข้อความต้นฉบับมีความใกล้เคียงกันมาก มีการสูญเสียข้อมูลเพียงเล็กน้อยเท่านั้น
5. ข้อความที่ได้รับการบูรณะและข้อความต้นฉบับมีความใกล้เคียงกันมาก ไม่มีข้อมูลใดสูญหาย

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

หากคะแนนคุณภาพ RST เฉลี่ยอยู่ในช่วง 1 ถึง 2 แสดงว่าคุณภาพของชิ้นงานอยู่ในระดับต่ำ และแนะนำให้ทำการแก้ไขชิ้นงานที่ผ่านการตรวจสอบแล้วเพื่อกำจัดข้อบกพร่อง รวมถึงแก้ไขชิ้นงานต้นฉบับเพื่อขจัดความเข้าใจผิด ในกรณีนี้ จำเป็นต้องมีการประชุม RST เพิ่มอีกหนึ่งครั้งหลังจากการแก้ไขชิ้นงาน สำหรับชิ้นงานที่มีคะแนนมากกว่า 2 แต่ไม่ถึง 3 จำเป็นต้องแก้ไขชิ้นงานที่ผ่านการตรวจสอบแล้วเพื่อแก้ไขข้อบกพร่องและกำจัดข้อมูลที่สูญหาย อย่างไรก็ตาม แนะนำให้ตรวจสอบชิ้นงานต้นฉบับอีกครั้งเพื่อหาว่ามีข้อมูลใดที่คลุมเครือซึ่งก่อให้เกิดความเข้าใจผิดหรือไม่ ไม่จำเป็นต้องมีการประชุม RST เพิ่มเติม หากคะแนนเฉลี่ยมากกว่า 3 แต่ไม่ถึง 4 ควรแก้ไขชิ้นงานที่ผ่านการตรวจสอบแล้วเพื่อกำจัดข้อบกพร่องและข้อมูลที่สูญหายเล็กน้อย หากคะแนนมากกว่า 4 แสดงว่าชิ้นงานมีคุณภาพดีและไม่จำเป็นต้องมีการแก้ไขหรือแก้ไขเพิ่มเติมใดๆ

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

• กรอบงานการสร้างแบบจำลอง P

• เว็บไซต์ของวลาดิมีร์ แอล. ปาฟลอฟ
• เอกสารไวท์เปเปอร์เกี่ยวกับกรอบงานการสร้างแบบจำลอง P
• กรอบงานการสร้างแบบจำลอง P