อธิบายซอฟต์แวร์เอนโทรปี: สาเหตุ ผลกระทบ และการเยียวยา

บทความนี้มุ่งเป้าไปที่ผู้พัฒนาซอฟต์แวร์หรือผู้จัดการโครงการที่สงสัยว่าซอฟต์แวร์เอนโทรปีคืออะไร ผลกระทบในทางปฏิบัติต่องานของพวกเขา และปัจจัยพื้นฐานที่เอื้อต่อการเติบโต

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

ซอฟต์แวร์เอนโทรปีคืออะไร?

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

น่าเสียดายที่ซอฟต์แวร์เอนโทรปีไม่ค่อยให้ความสำคัญเท่าที่ควร

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

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

แม้จะมีปัญหาเหล่านี้ แต่เรายังสามารถวางแนวทางปฏิบัติที่จะช่วยให้เราเข้าใจแหล่งที่มาของเอนโทรปีของซอฟต์แวร์ วัดระดับความเสี่ยงที่เกิดจากวัตถุประสงค์ของเรา และ (หากจำเป็น) ว่าควรดำเนินขั้นตอนใดบ้างเพื่อจำกัดการเติบโต

คำจำกัดความที่เสนอของซอฟต์แวร์เอนโทรปีมีดังนี้:

โดยที่ I ได้มาจากจำนวนของปัญหาที่ไม่คาดคิดซึ่งนำมาใช้ในระหว่างการทำซ้ำการพัฒนาครั้งล่าสุด C คือความน่าจะเป็นที่รับรู้ได้ว่าการนำการเปลี่ยนแปลงไปใช้กับระบบในขณะนี้ส่งผลให้เกิด I ​​> 0 ใหม่ และ S คือขอบเขตของการทำซ้ำการพัฒนาครั้งต่อไป โดยทั่วไป ค่า E ต่ำกว่า 0.1 ถือว่าดี E ที่ 0.5 ถือว่าสูงและค่าที่สูงกว่า 1.0 นั้นล้นหลาม

แนวคิดของ การทำซ้ำการพัฒนา เป็นส่วนสำคัญต่อความเข้าใจของเราเกี่ยวกับซอฟต์แวร์เอนโทรปี เหล่านี้เป็นวัฏจักรของกิจกรรมที่นำไปสู่พฤติกรรมของระบบหนึ่งไปสู่อีกพฤติกรรมหนึ่ง เป้าหมายที่เราตั้งไว้สำหรับตัวเราเองในระหว่างการทำซ้ำซอฟต์แวร์เรียกว่า ขอบเขต ในการพัฒนาซอฟต์แวร์ วงจรดังกล่าวเกี่ยวข้องกับการแก้ไขหรือขยายรหัสพื้นฐานของซอฟต์แวร์

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

อันที่จริง ความเสี่ยงที่สิ่งนี้จะเกิดขึ้นคือสิ่งที่ความตระหนักรู้ของเราเกี่ยวกับซอฟต์แวร์เอนโทรปีมีจุดประสงค์เพื่ออธิบายและความปรารถนาของเราที่จะวัดค่าเอนโทรปีของเรา ในทางปฏิบัติ เราสามารถกำหนดซอฟต์แวร์เอนโทรปีได้ดังนี้

ระบบใดก็ตามที่มีชุดปัญหาที่ทราบและเปิดอยู่จำนวนจำกัด I ₀ ในตอนท้ายของการพัฒนาซ้ำครั้งถัดไป จะมีชุดปัญหาที่ทราบและเปิดอยู่จำนวนจำกัด I ₁ เอนโทรปีโดยธรรมชาติของระบบระบุว่าความคาดหวังของเราเกี่ยวกับ I ₁ มีแนวโน้มที่จะแตกต่างไปจากมูลค่าที่แท้จริงของมันมากน้อยเพียงใด และความแตกต่างมีแนวโน้มที่จะเพิ่มขึ้นในการทำซ้ำครั้งต่อๆ ไปมากเพียงใด

ผลกระทบของซอฟต์แวร์เอนโทรปี

ประสบการณ์เชิงปฏิบัติของเราเกี่ยวกับผลกระทบของซอฟต์แวร์เอนโทรปีขึ้นอยู่กับวิธีที่เราโต้ตอบกับระบบที่เป็นปัญหา

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

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

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

• นักพัฒนาซอฟต์แวร์มีมุมมองที่ลื่นไหลของซอฟต์แวร์ พวกเขากังวลเกี่ยวกับการทำงานของระบบในปัจจุบันตราบเท่าที่ต้องมีการเปลี่ยนแปลงและพวกเขาเกี่ยวข้องกับรายละเอียดเกี่ยวกับวิธีการทำงานเพื่อกำหนดกลยุทธ์ที่เหมาะสม

• ผู้จัดการอาจมีมุมมองที่ซับซ้อนที่สุดของซอฟต์แวร์ ทั้งแบบคงที่และแบบไหล พวกเขาต้องสร้างสมดุลระหว่างความเร่งด่วนในระยะสั้นกับความต้องการของแผนธุรกิจที่จะขยายต่อไปในอนาคต

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

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

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

เมื่อซอฟต์แวร์เอนโทรปีท่วมท้นโปรเจ็กต์ โปรเจ็กต์จะหยุดทำงาน

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

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

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

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

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

ความทนทานต่อความเสี่ยงและเอนโทรปีของซอฟต์แวร์นั้นสัมพันธ์กันโดยที่เอนโทรปีของซอฟต์แวร์นั้นต้องน้อยที่สุดเพื่อให้แน่ใจว่าเราจะอยู่ในระดับที่ยอมรับได้ของระบบในระหว่างการพัฒนาซ้ำครั้งต่อไป

แหล่งที่มาของซอฟต์แวร์เอนโทรปี

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

รหัสคือการแสดงออกของชุดของการยืนยันเชิงตรรกะ เมื่อพฤติกรรมของซอฟต์แวร์ (และด้วยเหตุนี้โค้ดของซอฟต์แวร์) ไม่สอดคล้องกับตรรกะที่ตั้งใจจะแสดง เราสามารถพูดถึงเอนโทรปีที่มีอยู่จริงได้ สถานการณ์นี้สามารถเกิดขึ้นได้สามวิธี: ตรรกะเป็นที่รู้จักดีและแตกต่างจากนิพจน์ มีการเข้าใจตรรกะหลายอย่างที่โค้ดตั้งใจแสดง หรือตรรกะไม่เป็นที่ทราบกันดี

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

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

จิตใจของมนุษย์ตีความประสบการณ์ของตน กรองและปรับเปลี่ยนอย่างมีประสิทธิภาพเพื่อพยายามปรับให้เข้ากับกรอบการทำงานส่วนบุคคล ในกรณีที่ไม่มีนิสัยการพัฒนาที่มีประสิทธิภาพ—โดยอาศัยการแลกเปลี่ยนความคิดอย่างเสรี การเคารพซึ่งกันและกัน และความคาดหวังที่ชัดเจน—อาจมีการตีความหลายอย่างว่าระบบทำงานอย่างไรในปัจจุบันเมื่อมีสมาชิกในทีม เป้าหมายของทีมสำหรับการพัฒนาซ้ำในปัจจุบันอาจมีข้อโต้แย้ง

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

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

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

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

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

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

วิธีการคำนวณเอนโทรปี: การกำหนดค่าให้กับ C, S และ I

I คือจำนวนปัญหาด้านพฤติกรรมที่ยังไม่ได้รับการแก้ไขในระบบซอฟต์แวร์ รวมถึงการไม่มีคุณสมบัติที่สัญญาไว้ นี่คือปริมาณที่ทราบซึ่งมักถูกติดตามในระบบเช่น JIRA ค่าของ I ได้มาจากมันโดยตรง I คือจำนวน “หน่วยงาน” ที่ถูกละทิ้งหรือไม่สมบูรณ์ในระหว่างการพัฒนาซ้ำครั้งล่าสุด นอกเหนือไปจากจำนวนหน่วยงานที่เกิดจากปัญหาพฤติกรรมที่ไม่คาดคิดเข้ามาใหม่ เนื่องจาก I ถูกนับเป็นจำนวนหน่วยงาน เราจึงสามารถเชื่อมโยงกับค่าของ S ซึ่งเป็นขอบเขตของการวนซ้ำของการพัฒนาครั้งต่อไปในหน่วยงานเดียวกัน สิ่งที่ประกอบเป็น "หน่วยงาน" อย่างแท้จริงนั้นขึ้นอยู่กับวิธีการพัฒนา

C คือความน่าจะเป็นที่รับรู้ได้ว่า เมื่อหน่วยงานในขอบเขตถูกนำไปใช้ จำนวนปัญหาที่เปิดอยู่จริง I1 ในการทำซ้ำครั้งต่อไปจะมากกว่าที่ประมาณไว้ในขณะนี้ ค่านี้อยู่ในโดเมน 0 <= C <= 1

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

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

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

ในทางทฤษฎี เป็นไปได้ที่ฉันมีค่าติดลบ อย่างไรก็ตาม ในทางปฏิบัติ สถานการณ์นี้จะไม่เกิดขึ้น เรามักจะไม่แก้ปัญหาโดยบังเอิญ ค่าลบสำหรับ ฉัน ไม่ใช่สัญญาณที่ปลอบโยน พวกเขาบอกเป็นนัยว่าวิธีการคำนวณเอนโทรปีนั้นมีข้อบกพร่อง แน่นอนว่าการเติบโตของเอนโทรปีของซอฟต์แวร์สามารถลดลงได้โดยใช้มาตรการเฉพาะดังที่อธิบายไว้ด้านล่าง อย่างไรก็ตาม ในกรณีเช่นนี้ ฉัน ไม่ควรถือเอาค่าเชิงลบ เนื่องจากเรารวมความคาดหวังของเราเข้ากับการออกแบบของเราเสมอ

C เป็นค่าอัตนัย มันมีอยู่ในความคิดของผู้เข้าร่วมการพัฒนาซ้ำและสามารถอนุมานได้โดยการสำรวจพวกเขาและหาค่าเฉลี่ยผลลัพธ์ ควรถามคำถามในทางบวก ตัวอย่างเช่น: “ในระดับ 0 ถึง 10 โดย 10 มีแนวโน้มมากที่สุด คุณจะประเมินโอกาสของทีมในการบรรลุเป้าหมายทั้งหมดที่ทำซ้ำการพัฒนานี้อย่างไร”

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

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

S ต้องได้รับการกำหนดค่าใน “หน่วยงาน” เดียวกันกับ I ดังนั้นจึงขึ้นอยู่กับวิธีการพัฒนาอย่างมาก สำหรับทีมที่ใช้แง่มุมต่างๆ ของวิธีการแบบ Agile เรื่องราวดูเหมือนจะเป็น “หน่วยงาน” ที่ชัดเจนที่สุดสำหรับทั้ง S และ I ในกรณีนี้ ขอบเขตของการทำซ้ำการพัฒนาจะครอบคลุมแต่ละรุ่นที่มีกำหนดการเป็นประจำในการผลิต ไม่ว่าจะรุ่นย่อยหรือรุ่นหลัก ฉันควรหาปริมาณเป็นผลรวมของจำนวนเรื่องราวที่ไม่เสร็จสมบูรณ์ในระหว่างการวิ่งแต่ละครั้งที่นำไปสู่การปล่อยตัวและจำนวนเรื่องราวที่สร้างขึ้นเพื่อรวมในการวิ่งในอนาคตอันเป็นผลมาจากปัญหาที่ไม่คาดคิดซึ่งปรากฏหลังจากปล่อย

โปรดทราบว่าเราไม่ถือว่าโปรแกรมแก้ไขด่วนหรือการเผยแพร่ที่ไม่ได้กำหนดไว้สำหรับการผลิตเป็นการกำหนดขอบเขตของการทำซ้ำการพัฒนา และไม่ควรลบเรื่องราวที่เกี่ยวข้องออกจาก I

ความยากลำบากของแนวทางนี้คือต้องมีช่วงเวลาของการค้นพบและวิเคราะห์ก่อนที่จะแยกย่อยเป็นเรื่องราวได้ ค่าที่แท้จริงของ I สามารถกำหนดได้หลังจากล่าช้าเท่านั้น นอกจากนี้ การหยั่งเสียงสำหรับ C จะเกิดขึ้นในช่วงเริ่มต้นของการวิ่งแต่ละครั้ง ผลลัพธ์ที่ได้จึงต้องนำมาเฉลี่ยอีกครั้งตลอดช่วงการปล่อยทั้งหมด แม้จะมีปัญหาเหล่านี้ ทีมใดก็ตามที่ใช้แง่มุมต่างๆ ของวิธีการแบบ Agile มักจะพบว่าเรื่องราวเป็นหน่วยที่แม่นยำที่สุดสำหรับการหาปริมาณ S (และด้วยเหตุนี้ I )

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

ลดการเจริญเติบโตของ E

เมื่อความรู้เกี่ยวกับระบบหายไป จะไม่สามารถเรียกคืนได้อีก ด้วยเหตุผลนี้ ซอฟต์แวร์เอนโทรปีไม่สามารถลดลงได้ สิ่งที่เราทำได้คือจำกัดการเติบโตของมัน

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

แนวทางปฏิบัติที่เป็นประโยชน์อีกประการหนึ่งคือการผลิตเอกสารที่มีโครงสร้างดีและใช้ง่าย โดยเฉพาะอย่างยิ่งภายในองค์กรที่ใช้วิธีน้ำตก เอกสารดังกล่าวต้องได้รับการสนับสนุนโดยหลักการที่เข้มงวดและชัดเจนซึ่งทุกคนเข้าใจ องค์กรที่ใช้เอกสารเป็นสื่อกลางในการสื่อสารและปกป้องความรู้ด้านเทคนิคนั้นเหมาะสมอย่างยิ่งสำหรับแนวทางนี้ เฉพาะเมื่อ ไม่มี แนวทางหรือการฝึกอบรมเกี่ยวกับวิธีการเขียนและใช้เอกสารที่เป็นลายลักษณ์อักษรภายใน—ซึ่งมักจะเป็นกรณีในองค์กรที่อายุน้อยกว่าที่ใช้วิธี RAD หรือ Agile— คุณค่าของพวกเขาจะกลายเป็นที่น่าสงสัย

มีสองวิธีในการลดการเติบโตของเอนโทรปีในระบบ: ดำเนินการเปลี่ยนแปลงเพื่อลด I หรือดำเนินการเปลี่ยนแปลงเพื่อลด C

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

การลดค่าของ C เป็นกลยุทธ์ที่มีประสิทธิภาพมากขึ้นเนื่องจากผลกระทบในระยะยาว นอกจากนี้ C ยังทำหน้าที่เป็นตัวตรวจสอบที่สำคัญในการเติบโตของอัตราส่วน I ต่อ S การดำเนินการเพื่อลด C มักจะเน้นที่พฤติกรรมและการคิดของมนุษย์ แม้ว่าการกระทำเหล่านี้อาจไม่ต้องการการทำซ้ำการพัฒนา แต่จะทำให้การทำซ้ำในภายหลังช้าลงเมื่อผู้เข้าร่วมยอมรับและปรับให้เข้ากับขั้นตอนใหม่ การกระทำที่ดูเหมือนง่ายในการตกลงร่วมกันว่าควรปรับปรุงอะไรเป็นเส้นทางที่เต็มไปด้วยอันตรายของตัวเอง เมื่อเป้าหมายที่แตกต่างกันของผู้เข้าร่วมโครงการและผู้มีส่วนได้ส่วนเสียปรากฏขึ้นในทันใด

ห่อ

เอนโทรปีของซอฟต์แวร์เป็นความเสี่ยงที่การเปลี่ยนแปลงซอฟต์แวร์ที่มีอยู่จะส่งผลให้เกิดปัญหาที่ไม่คาดคิด วัตถุประสงค์ที่ไม่เป็นไปตามวัตถุประสงค์ หรือทั้งสองอย่าง

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

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

เมื่อระบบได้รับผลกระทบจากเอนโทรปีของซอฟต์แวร์อย่างท่วมท้น จะไม่สามารถทำการเปลี่ยนแปลงได้อีกและการพัฒนาก็สิ้นสุดลงโดยพื้นฐานแล้ว