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

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

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

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

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

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

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

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

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

E = I´C / S

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

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

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

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

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

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

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

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

สาเหตุของวิกฤตการเงินกรีซ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ห่อ

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

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

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

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

ทำความเข้าใจพื้นฐาน

ความหมายของเอนโทรปีคืออะไร

การวัดความสับสนวุ่นวายในระบบสารสนเทศที่ยังคงเหมือนเดิมหรือเพิ่มขึ้นเมื่อเวลาผ่านไป

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

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

ฉันจะคำนวณเอนโทรปีได้อย่างไร

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