شرح إنتروبيا البرمجيات: الأسباب والتأثيرات والعلاجات

تستهدف هذه المقالة مطور البرامج أو مدير المشروع الذي لديه فضول لمعرفة ماهية إنتروبيا البرمجيات ، والآثار العملية على عملهم ، والعوامل الأساسية التي تسهم في نموها.

الهدف الأساسي هو خلق وعي بالانتروبيا البرمجية لأنها عامل في جميع أشكال تطوير البرمجيات. علاوة على ذلك ، نستكشف وسيلة يمكن من خلالها تخصيص إنتروبيا البرمجيات قيمة ملموسة. فقط من خلال قياس إنتروبيا البرمجيات ومراقبة نموها على الإصدارات المتتالية يمكننا أن نفهم حقًا المخاطر التي تشكلها على أهدافنا الحالية وخططنا المستقبلية.

ما هو إنتروبيا البرمجيات؟

تكتسب إنتروبيا البرمجيات اسمها من السمة الرئيسية للإنتروبيا في العالم الحقيقي: إنها مقياس للفوضى التي إما تظل كما هي أو تزداد بمرور الوقت . بطريقة أخرى ، إنه مقياس لعدم الاستقرار المتأصل المضمن في نظام برمجي فيما يتعلق بتعديله.

لسوء الحظ ، نادرًا ما تُمنح إنتروبيا البرمجيات الأهمية التي تستحقها.

لا يتم أخذ ذلك في الاعتبار عند سحب شخص ما من فريق التطوير ، أو بدء دورة التطوير قبل الأوان ، أو تنفيذ "إصلاحات سريعة" - لحظات عندما يكون ، في الواقع ، من المرجح أن ينمو.

تطوير البرمجيات هو فن وتجارة حيث اللبنات الأساسية للبناء غير محددة بشكل جيد. بينما يعمل البناة مع الأسمنت والمسامير ، يعمل مطور البرامج بتأكيدات منطقية ومجموعة من الافتراضات. لا يمكن إمساكها في اليد وفحصها ، ولا يمكن طلبها بثمن البوصة. على الرغم من أن المراقب العرضي قد يميل إلى مقارنة تطوير البرامج بالبناء ، إلا أنه بخلاف بعض أوجه التشابه السطحية ، فإن القيام بذلك يأتي بنتائج عكسية.

على الرغم من هذه الصعوبات ، يمكننا مع ذلك وضع المبادئ التوجيهية التي ستمكننا من فهم مصادر إنتروبيا البرمجيات ، وقياس مدى المخاطر التي تشكلها على أهدافنا ، و (إذا لزم الأمر) ما هي الخطوات التي يمكن اتخاذها للحد من نموها.

التعريف المقترح للإنتروبيا البرمجية هو كما يلي:

حيث يتم اشتقاق I من عدد المشكلات غير المتوقعة التي تم تقديمها أثناء التكرار الأخير للتطوير ، C هو الاحتمال الملحوظ بأن تنفيذ التغييرات على النظام يؤدي الآن إلى I > 0 جديد ، و S هو نطاق تكرار التطوير التالي. بشكل عام ، تعتبر قيم E أقل من 0.1 جيدة. يعتبر E البالغ 0.5 مرتفعًا ، والقيم أعلى من 1.0 ساحقة.

يعد مفهوم تكرار التطوير جزءًا لا يتجزأ من فهمنا للإنتروبيا البرمجية. هذه دورات من النشاط تؤدي من سلوك في النظام إلى سلوك آخر. تسمى الأهداف التي وضعناها لأنفسنا أثناء تكرار البرنامج نطاقها . في تطوير البرمجيات ، تتضمن هذه الدورات تعديل أو توسيع الكود الأساسي للبرنامج.

تحدث جميع التعديلات على التعليمات البرمجية في تكرار التطوير حتى لو لم يفكر القائمون بتنفيذها بهذه الطريقة. وهذا يعني أن المنظمات الأصغر التي تفتخر ببناء أنظمتها باستخدام منهجية "سريعة وقذرة" - مع القليل من جمع المتطلبات أو التحليل أو بدونها - لا تزال تستخدم التكرارات التطويرية لتحقيق أهدافها. إنهم ببساطة لا يخططون لها. وبالمثل ، حتى لو انحرف سلوك النظام المعدل بطريقة ما عن نوايانا ، فإنه لا يزال يتحقق عن طريق التكرار التنموي.

في الواقع ، فإن خطر حدوث هذا هو بالضبط ما يهدف وعينا من إنتروبيا البرمجيات إلى تفسيره ورغبتنا في قياسه تهدف إلى الحد منه. من الناحية العملية ، إذن ، يمكننا تعريف إنتروبيا البرمجيات على النحو التالي.

يحتوي أي نظام على مجموعة محدودة من المشكلات المفتوحة والمعروفة I ₀ . في نهاية التكرار التالي للتطوير ، ستكون هناك مجموعة محدودة من المشكلات المفتوحة والمعروفة ₁ . تحدد الانتروبيا المتأصلة في النظام مدى اختلاف توقعاتنا لـ I ₁ عن قيمتها الفعلية ومقدار الاختلاف المحتمل أن ينمو في التكرارات اللاحقة.

تأثيرات إنتروبيا البرمجيات

تعتمد خبرتنا العملية لتأثيرات إنتروبيا البرمجيات على كيفية تفاعلنا مع النظام المعني.

يتمتع المستخدمون بنظرة ثابتة للبرامج ؛ إنهم مهتمون بكيفية تصرفه الآن ولا يهتمون بالأجزاء الداخلية للنظام. من خلال تنفيذ إجراء محدد مسبقًا ، يفترض المستخدمون أن البرنامج سيستجيب بسلوك مماثل محدد مسبقًا. ومع ذلك ، فإن المستخدمين هم الأقل استعدادًا لاستنتاج مستوى الانتروبيا في البرنامج الذي يستخدمونه.

ترتبط إنتروبيا البرمجيات بمفهوم التغيير وليس لها معنى في نظام ثابت. إذا لم تكن هناك نية لتغيير النظام ، فلا يمكننا التحدث عن الكون الخاص به. وبالمثل ، فإن النظام الذي لم يكن موجودًا بعد (أي ، التكرار التالي هو في الواقع الأول من وجوده) ليس له إنتروبيا.

قد يُنظر إلى البرامج على أنها "عربات التي تجرها الدواب" من وجهة نظر المستخدم ، ولكن إذا حقق مطورو ومديرو البرامج خلال التكرارات اللاحقة أهدافهم كما هو مخطط لها ، يجب أن نستنتج أن الانتروبيا في النظام منخفضة جدًا في الواقع! لذلك ، فإن تجربة المستخدمين تخبرنا القليل جدًا ، إن وجدت ، عن إنتروبيا البرامج:

• يتمتع مطورو البرامج برؤية سلسة للبرامج. إنهم مهتمون بكيفية عمل النظام حاليًا فقط بقدر ما يجب تغييره ، وهم مهتمون بتفاصيل كيفية عمله لوضع استراتيجية مناسبة.

• ربما يكون لدى المديرين أكثر وجهات النظر تعقيدًا للبرامج ، سواء كانت ثابتة أو مائعة. يجب أن يوازنوا بين مقتضيات المدى القصير ومتطلبات خطة العمل التي تمتد إلى المستقبل.

الناس في كلا هذين الدورين لديهم توقعات. تتجلى إنتروبيا البرمجيات نفسها كلما أفسدت هذه التوقعات. أي أن مطوري البرامج والمديرين يبذلون قصارى جهدهم لتقييم المخاطر والتخطيط لها ، ولكن - باستثناء الاضطرابات الخارجية - إذا كانت توقعاتهم مع ذلك مخيبة للآمال ، عندها فقط يمكننا التحدث عن إنتروبيا البرمجيات. إنها اليد الخفية التي تكسر تفاعلات المكونات التي لم تكن في النطاق ، وتتسبب في تعطل خوادم الإنتاج لسبب غير مفهوم ، وتحجب إصلاحًا عاجلاً في الوقت المناسب وفعالاً من حيث التكلفة.

تعتمد العديد من الأنظمة ذات المستويات العالية من الإنتروبيا على أفراد محددين ، خاصةً إذا كان هناك أعضاء صغار في فريق التطوير. يمتلك هذا الشخص معرفة بحيث لا يستطيع الآخرون أداء مهامهم دون مدخلاته "القيمة". لا يمكن التقاطها في مخططات UML القياسية أو المواصفات الفنية لأنها تتكون من مزيج من الاستثناءات ، والحدس ، والنصائح. لا تعتمد هذه المعرفة على إطار عمل متسق منطقيًا وبالتالي من الصعب - إن لم يكن من المستحيل - نقلها إلى أي شخص آخر.

لنفترض أنه بفضل التصميم والجهد الكبيرين ، تستطيع هذه المنظمة تغيير نفسها وتحقيق الاستقرار في قسم تكنولوجيا المعلومات لديها. يبدو أن الوضع قد تحسن لأنه عندما يتوقف تطوير البرمجيات ، فإن أي تقدم مهما كان مشجعًا. ومع ذلك ، في الواقع ، فإن التوقعات التي تم تحقيقها منخفضة والإنجازات غير مثيرة للاهتمام مقارنة بالأهداف السامية التي كانت في متناول اليد بينما كانت الإنتروبيا لا تزال منخفضة.

عندما تطغى إنتروبيا البرمجيات على مشروع ما ، يتجمد المشروع.

لا يمكن أن يكون هناك المزيد من عمليات التطوير. لحسن الحظ ، لا تنشأ هذه الحالة على الفور. إن المسيرة البطيئة ولكن المتهورة نحو حافة الجرف هي أمر يمر به كل نظام. بغض النظر عن مدى جودة التنظيم والفعالية التي قد تكون عليها النسخة الأولى ، ستزداد الإنتروبيا الخاصة بها - وبالتالي خطر حدوث أخطاء غير متوقعة - ما لم يتم اتخاذ خطوات محددة لمنع ذلك.

لا يمكن تقليل إنتروبيا البرامج. تمامًا مثل الانتروبيا في العالم الحقيقي ، فهي تنمو أو تظل كما هي. في البداية ، آثاره لا تذكر. عندما تبدأ في الظهور ، تكون الأعراض خفيفة ويمكن إخفاءها أو تجاهلها. ولكن إذا حاولت منظمة مكافحة إنتروبيا البرامج فقط بمجرد أن تصبح الخطر المهيمن في المشروع ، فسوف تجد للأسف أن جهودها تذهب سدى. لذلك يكون الوعي بالانتروبيا البرمجية أكثر فائدة عندما يكون مداها منخفضًا وتكون التأثيرات الضائرة في حدها الأدنى.

لا يتبع ذلك أن كل منظمة يجب أن تخصص الموارد للحد من نمو الانتروبيا في منتجاتها. الكثير من البرامج التي يتم تطويرها اليوم - البرامج الموجهة نحو المستهلك على وجه الخصوص - لها عمر متوقع قصير نسبيًا ، ربما بضع سنوات. في هذه الحالة ، لا يحتاج أصحاب المصلحة إلى النظر في تأثيرات إنتروبيا البرامج ، حيث نادرًا ما تصبح عقبة خطيرة قبل التخلص من النظام بأكمله. ومع ذلك ، هناك أسباب أقل وضوحًا للنظر في تأثيرات إنتروبيا البرامج.

ضع في اعتبارك البرنامج الذي يدير البنية التحتية لتوجيه الإنترنت أو يحول الأموال من حساب مصرفي إلى آخر. في أي وقت ، هناك إصدار واحد أو أكثر من هذا البرنامج قيد الإنتاج ، ويمكن توثيق سلوكياتهم الجماعية بدقة عالية معقولة.

يعتبر تحمل المخاطر في النظام مقياسًا لمقدار ونوع السلوك غير المتوقع الذي يمكننا السماح به بشكل مريح من عملية تطوير إلى أخرى. بالنسبة لأنواع الأنظمة التي ذكرناها للتو ، فإن تحمل المخاطر أقل بكثير ، على سبيل المثال ، من البرنامج الذي يوجه المكالمات الهاتفية. هذا البرنامج ، بدوره ، لديه تحمل مخاطر أقل من البرنامج الذي يقود عربة التسوق للعديد من المواقع التجارية.

يرتبط تحمل المخاطر وانتروبيا البرامج في أن إنتروبيا البرامج يجب أن تكون في حدها الأدنى للتأكد من أننا سنبقى ضمن نطاق تحمل مخاطر النظام أثناء التكرار التالي للتطوير.

مصادر إنتروبيا البرمجيات

تنشأ إنتروبيا البرمجيات من نقص المعرفة . إنه ناتج عن الاختلاف بين افتراضاتنا الجماعية والسلوك الفعلي لنظام قائم. تشرح هذه الحقيقة سبب كون إنتروبيا البرمجيات لها معنى فقط في سياق تعديل نظام موجود ؛ هذه هي المرة الوحيدة التي سيكون لعدم فهمنا أي تأثير عملي. تجد إنتروبيا البرمجيات الأرض الأكثر خصوبة في نظام لا يمكن لشخص واحد أن يفهم تفاصيله ، ولكنها بدلاً من ذلك تنتشر حول فريق التطوير. الوقت أيضًا ممحاة قوية للمعرفة.

الكود هو تعبير عن سلسلة من التأكيدات المنطقية. عندما لا يتوافق سلوك البرنامج (وبالتالي رمزه) مع المنطق المقصود التعبير عنه ، يمكننا التحدث عن الكون المتأصل فيه. يمكن أن ينشأ هذا الموقف من خلال ثلاث طرق: المنطق معروف جيدًا ويختلف عن تعبيره ، أو أن هناك تفاهمات متعددة للمنطق الذي تهدف الشفرة إلى التعبير عنه ، أو أن المنطق غير معروف جيدًا.

• الموقف الأول - المنطق معروف جيدًا ويختلف عن تعبيره الحالي - هو الأسهل في المعالجة ولكنه أيضًا الأقل شيوعًا. فقط الأنظمة الصغيرة جدًا التي يحتفظ بها ربما اثنان من المشاركين ، مطور وشخص مسؤول عن خطة العمل ، ستندرج ضمن هذه الفئة.

• الحالة الثانية - المنطق غير معروف - نادرة. لجميع المقاصد والأغراض ، لا يمكن حتى أن يبدأ تكرار التطوير. إذا اتفق جميع أصحاب المصلحة في وقت ما ، فمن المحتمل أن يواجهوا الموقف الأول.

يفسر العقل البشري تجاربه ، ويقوم بترشيحها وتعديلها بشكل فعال في محاولة لتلائمها في إطار شخصي. في غياب عادات التنمية الفعالة - القائمة على التبادل الحر للأفكار والاحترام المتبادل والتوقعات الواضحة - قد يكون هناك العديد من التفسيرات لكيفية عمل النظام في الوقت الحاضر كما هو الحال بالنسبة لأعضاء الفريق. قد تكون أهداف الفريق لتكرار التطوير الحالي محل نزاع.

يحمي العديد من المطورين أنفسهم من هذا الموقف من خلال تعزيز فهمهم الفريد لما هو مطلوب منهم وكيف "يجب" تنظيم النظام. من ناحية أخرى ، قد يسعى المدراء وأصحاب المصلحة الآخرون عن غير قصد إلى تغيير افتراضات أعضاء الفريق الآخرين في محاولة مضللة لتسهيل حياتهم.

لقد وصلنا الآن إلى المصدر الأكثر شيوعًا للإنتروبيا البرمجية: هناك العديد من التفسيرات غير الكاملة للمنطق الذي يهدف النظام إلى التعبير عنه. نظرًا لوجود مظهر واحد فقط من أي وقت مضى لهذا المنطق ، فإن الوضع بحكم التعريف يمثل مشكلة.

كيف ينشأ هذا النقص في المعرفة؟ عدم الكفاءة طريقة واحدة. وكما رأينا بالفعل ، فإن عدم وجود اتفاق حول أهداف التكرار التنموي التالي هو شيء آخر. لكن هناك عوامل أخرى يجب مراعاتها. قد تزعم المنظمة أنها تستخدم منهجية تطوير ولكن بعد ذلك تتخلى بشكل عشوائي عن بعض أو كل جوانبها على الأرض. يتم بعد ذلك تكليف مطوري البرامج بإكمال مهام غامضة ، وغالبًا ما تكون مفتوحة للتفسير. المنظمات التي تطبق تغييرات على منهجيتها التنموية معرضة بشكل خاص لهذه الظاهرة ، على الرغم من أنها ليست الوحيدة بأي حال من الأحوال. يمكن أن تؤدي النزاعات الشخصية التي تجهل الإدارة أو لا تستطيع حلها بطريقة أخرى إلى اختلاف خطير بين التوقعات والنتائج.

هناك طريقة ثانية أكثر أهمية نفقد فيها المعرفة التقنية حول المنتج: في النقل. يمثل اكتساب المعرفة التقنية على الورق تحديًا حتى بالنسبة للكُتَّاب الأكثر كفاءة. والسبب هو أن ما يجب نسخه لا يقل أهمية عن الطريقة . بدون الانضباط المناسب ، قد يسجل الكاتب الفني الكثير من المعلومات. بدلاً من ذلك ، قد يضعون افتراضات تجعلهم يتجاهلون النقاط الأساسية. بعد إنتاجها ، يجب بعد ذلك تحديث الوثائق الفنية بدقة ، وهو اقتراح صعب للعديد من المنظمات التي تفقد مسار المستندات بمجرد كتابتها. بسبب هذه الصعوبات ، نادرًا ما يتم نقل المعرفة التقنية في المستندات وحدها ولكن أيضًا في الاقتران أو غيره من أشكال التفاعل الوثيق بين البشر.

تحقق إنتروبيا البرمجيات قفزات كبيرة عندما يغادر أحد المشاركين النشطين فريق التطوير. إنهم يأخذون معهم قدرًا كبيرًا من المعرفة. إن تكرار هذه المعرفة أمر مستحيل ، وتقريبها يتطلب جهدًا كبيرًا. ومع ذلك ، مع الاهتمام والموارد الكافية ، يمكن الحفاظ على المعرفة الكافية لتقليل نمو إنتروبيا النظام.

هناك مصادر أخرى للإنتروبيا ، لكنها ثانوية نسبيًا. على سبيل المثال ، تعفن البرامج هو العملية التي يتأثر بها النظام بشكل غير متوقع بالتغييرات التي تطرأ على بيئته. يمكننا التفكير في برامج الطرف الثالث التي يعتمد عليها (مثل المكتبات) ، ولكن هناك أسباب أخرى أكثر خداعًا لتعفن البرامج ، والتي تنتج عادة عن التغييرات في الافتراضات التي كان يقوم عليها النظام. على سبيل المثال ، إذا تم تصميم نظام بافتراضات معينة حول توفر الذاكرة ، فقد يبدأ في التعطل في لحظات غير متوقعة إذا تم تقليل الذاكرة المتاحة له.

كيفية احتساب الانتروبيا: تعيين القيم لـ C و S و I

أنا هو عدد المشكلات السلوكية التي لم يتم حلها في نظام برمجي ، بما في ذلك عدم وجود الميزات الموعودة. هذه كمية معروفة غالبًا ما يتم تتبعها في نظام مثل JIRA. قيمة أنا مشتق منها مباشرة. أنا هو عدد "وحدات العمل" التي تم التخلي عنها أو تركها غير مكتملة أثناء تكرار التطوير الأخير بالإضافة إلى عدد وحدات العمل الناتجة عن مشاكل سلوكية حديثة وغير متوقعة. نظرًا لأنني محسوب على أنه عدد من وحدات العمل ، فيمكننا ربطها بقيمة S ، وهو نطاق تكرار التطوير التالي في نفس وحدات العمل. ما يشتمل بالضبط على "وحدة العمل" يعتمد على منهجية التطوير.

C هو الاحتمال المتصور أنه ، عند تنفيذ وحدات العمل في النطاق ، سيكون عدد المشكلات المفتوحة الفعلية I1 في التكرار التالي أكبر من تقديره الآن. تعيش هذه القيمة في المجال 0 <= C <= 1.

قد يجادل المرء في أن احتمال C هو بالضبط ما تهدف إنتروبيا البرمجيات إلى قياسه. ومع ذلك ، هناك اختلافات جوهرية بين هذه القيمة وقياسنا للإنتروبيا البرمجية. الاحتمال المتصور لحدوث خطأ ما هو بالضبط: إنها ليست قيمة حقيقية. ومع ذلك ، من المفيد أن تكون مشاعر الأشخاص المشاركين في مشروع ما مصدرًا قيمًا للمعلومات حول مدى استقراره.

يأخذ النطاق S في الاعتبار حجم التغييرات المقترحة ويجب التعبير عنه في نفس الوحدات مثل I. تقلل القيمة الأكبر لـ S الانتروبيا لأننا نقوم بزيادة نطاق التغييرات المقترحة. على الرغم من أن هذا قد يبدو غير بديهي ، يجب أن نضع في اعتبارنا أن الانتروبيا هي مقياس لكيفية تطوير النظام قد لا يلبي توقعاتنا. لا يكفي أن نقول إن الإنتروبيا هي مقياس لفرصة إدخال المشاكل. نحن بشكل طبيعي نحاول ونتوقع المخاطر ونأخذها في الاعتبار في تخطيطنا (وبالتالي في تقديرنا لـ I1 ، والذي قد يزيد عن ₀ ). من الواضح ، أنه كلما زادت ثقتنا بشأن اتخاذ نطاق تغيير كبير ، يمكن القول إن الانتروبيا أقل في النظام - ما لم يكن أولئك الذين يخططون للتغييرات و / أو ينفذونها غير أكفاء. هذا الاحتمال ، مع ذلك ، ربما ينعكس في القيمة الحالية لـ I.

لاحظ أننا لا نحتاج إلى محاولة تحديد حجم الاختلاف بين القيمة الفعلية لـ I ₁ وقيمتها المتوقعة. إذا افترضنا أن خططنا صحيحة عند وضعها ، فليس من المعقول أيضًا افتراض أنه يمكننا التنبؤ بالدرجة التي لن تلبي بها النتيجة توقعاتنا ؛ يمكننا فقط تحديد فرصة متصورة C لن تكون كذلك. ومع ذلك ، فإن الدرجة التي تختلف بها القيمة الفعلية I ₁ عن قيمتها المتوقعة هي مدخلات مهمة في حساب الانتروبيا في التكرار التالي في شكل القيمة المشتقة I.

من الناحية النظرية ، من الممكن أن يكون لدي قيمة سالبة. لكن في الممارسة العملية ، لن يحدث هذا الموقف أبدًا ؛ نحن لا نحل المشاكل عادة عن طريق الخطأ. القيم السلبية بالنسبة لي ليست علامة مطمئنة. إنها تشير إلى أن الوسيلة التي يتم من خلالها حساب الإنتروبيا معيبة. يمكن بالطبع الحد من نمو إنتروبيا البرمجيات من خلال اتخاذ تدابير محددة ، كما هو موضح أدناه. ومع ذلك ، في مثل هذه الحالات ، لا يجب أن أفترض قيمًا سلبية ، لأننا دائمًا ندمج توقعاتنا في تصميماتنا.

C هي قيمة ذاتية. إنه موجود في أذهان المشاركين في تكرار التطوير ويمكن استنتاجه من خلال استطلاع رأيهم واحتساب متوسط ​​النتائج. يجب طرح السؤال بطريقة إيجابية. على سبيل المثال: "على مقياس من 0 إلى 10 مع احتمال 10 ، كيف يمكنك تقدير فرص الفريق في تحقيق جميع أهدافه في هذا التكرار التطويري؟"

لاحظ أنه يتم طرح السؤال حول أهداف الفريق ككل ، وليس مجموعة فرعية. تشير استجابة 10 إلى قيمة 0 لـ C ، بينما تشير استجابة 7 إلى قيمة 0.3. في الفرق الكبيرة ، قد يتم ترجيح كل استجابة اعتمادًا على العوامل ذات الصلة ، مثل المدة التي قضاها الفرد في المشروع ومقدار الوقت الذي يقضيه بالفعل في المشروع. ومع ذلك ، لا ينبغي أن تكون الكفاءة عاملاً في ترجيح الردود. قبل مضي وقت طويل ، حتى العضو المبتدئ في الفريق سيكون لديه إحساس بمدى فعاليته في تحقيق أهدافه. قد ترغب الفرق الكبيرة بما فيه الكفاية في تجاهل القيم الأعلى والأدنى التي تم الإبلاغ عنها قبل حساب متوسط ​​الباقي.

سؤال المهنيين عن احتمالية فشل فريقهم هو اقتراح حساس ومثير. ومع ذلك ، هذا هو بالضبط السؤال الذي يجب على أي منظمة ترغب في تحديد الانتروبيا أن تطرحه. لضمان إجابات صادقة ، يجب على المشاركين تقديم تقديرهم لـ C بشكل مجهول ودون خوف من العواقب ، حتى لو أبلغوا عن قيمة عالية للغاية.

يجب تعيين قيمة S في نفس "وحدات العمل" مثل أنا وبالتالي فهي تعتمد بشكل كبير على منهجية التطوير. بالنسبة للفرق التي تستخدم جوانب منهجية Agile ، تبدو القصص "وحدة العمل" الأكثر وضوحًا لكل من S و I. في هذه الحالة ، يمتد مدى تكرار التطوير لكل إصدار مجدول بانتظام في الإنتاج ، سواء كان ثانويًا أو رئيسيًا. يجب أن أكون كميًا كمجموع لعدد القصص التي لم تكتمل بنجاح خلال كل سباق قبل الإصدار وعدد القصص التي تم إنشاؤها لإدراجها في سباقات السرعة المستقبلية كنتيجة لمشاكل غير متوقعة تظهر بعد الإصدار.

لاحظ أننا لا نعتبر الإصلاحات العاجلة أو الإصدارات الأخرى غير المجدولة للإنتاج على أنها تحدد مدى تكرار التطوير ، ولا ينبغي أن نطرح أي قصص مرتبطة بها.

تكمن الصعوبة في هذا النهج في أن فترة الاكتشاف والتحليل يجب أن تحدث قبل أن يتم تقسيم الأخطاء لاحقًا إلى قصص. لذلك لا يمكن تحديد القيمة الحقيقية لـ I إلا بعد تأخير. بالإضافة إلى ذلك ، يتم إجراء الاستقصاء لـ C بشكل طبيعي في بداية كل سباق. لذلك يجب حساب متوسط ​​النتائج التي تم الحصول عليها مرة أخرى على مدى فترة الإصدار بالكامل. على الرغم من هذه الصعوبات ، فإن أي فريق يستخدم جوانب منهجية Agile من المرجح أن يجد أن القصص هي الوحدة الأكثر دقة لقياس S (وبالتالي أنا ).

هناك منهجيات تطوير أخرى قيد الاستخدام اليوم. مهما كانت المنهجية المستخدمة ، تظل مبادئ قياس إنتروبيا البرمجيات كما هي: يجب قياس إنتروبيا البرامج بين الإصدارات إلى الإنتاج ، ويجب قياس S و I في نفس "وحدات العمل" ، ويجب أخذ تقديرات C من المشاركين المباشرين في بطريقة غير مهددة ويفضل أن تكون مجهولة الهوية.

الحد من نمو E.

بمجرد فقدان المعرفة حول النظام ، لا يمكن استعادتها أبدًا. لهذا السبب ، لا يمكن تقليل إنتروبيا البرامج. كل ما يمكننا القيام به هو كبح جماح نموه.

يمكن الحد من نمو الانتروبيا من خلال اعتماد التدابير المناسبة أثناء تطوير البرمجيات. يعد جانب البرمجة الزوجية في تطوير Agile مفيدًا بشكل خاص في هذا الصدد. نظرًا لأن أكثر من مطور واحد مشترك في وقت كتابة الكود ، يتم توزيع المعرفة بالتفاصيل الأساسية وتخفيف آثار أعضاء الفريق المغادرين.

ممارسة مفيدة أخرى هي إنتاج وثائق جيدة التنظيم وسهلة الاستهلاك ، لا سيما داخل المنظمات التي تستخدم منهجية الشلال. يجب أن يكون هذا التوثيق مدعومًا بمبادئ صارمة ومحددة جيدًا ومفهومة من قبل الجميع. المنظمات التي تعتمد على التوثيق كوسيلة أساسية للاتصال وحماية المعرفة التقنية مناسبة تمامًا لهذا النهج. فقط عندما لا توجد إرشادات أو تدريب حول كيفية كتابة واستهلاك المستندات المكتوبة داخليًا - كما هو الحال غالبًا في المنظمات الأصغر التي تستخدم منهجيات RAD أو Agile - تصبح قيمتها مشكوكًا فيها.

هناك طريقتان لتقليل نمو الانتروبيا في النظام: تنفيذ التغييرات التي تهدف إلى تقليل I أو تنفيذ التغييرات التي تهدف إلى تقليل C.

الأول ينطوي على إعادة بناء ديون. تميل الإجراءات التي تهدف إلى التقليل إلى أن تكون ذات طبيعة تقنية وربما تكون مألوفة بالفعل للقارئ. تطوير التكرار يجب أن يحدث. الجزء من هذا التكرار الذي يهدف إلى تقليل نمو الانتروبيا لن يقدم أي فوائد تجارية ملموسة بينما سيستهلك الوقت والموارد. غالبًا ما تجعل هذه الحقيقة تقليل نمو الانتروبيا أمرًا صعبًا داخل أي مؤسسة.

يعد تقليل قيمة C استراتيجية أكثر قوة لأن التأثير طويل المدى. بالإضافة إلى ذلك ، تعمل لغة C كتحقق مهم على نمو نسبة I إلى S. تميل الإجراءات لتقليل C إلى التركيز على السلوك البشري والتفكير. على الرغم من أن هذه الإجراءات قد لا تتطلب تطويرًا متكررًا في حد ذاته ، إلا أنها ستبطئ التكرارات اللاحقة حيث يقبل المشاركون الإجراءات الجديدة ويتكيفون معها. إن الفعل الذي يبدو بسيطًا والمتمثل في الاتفاق على التحسينات التي يجب إجراؤها هو مسار محفوف بالمخاطر في حد ذاته ، حيث تظهر الأهداف المتباينة للمشاركين وأصحاب المصلحة في المشروع فجأة.

تغليف

إنتروبيا البرمجيات هي خطر أن يؤدي تغيير البرامج الحالية إلى مشاكل غير متوقعة أو أهداف غير محققة أو كليهما.

على الرغم من أنه لا يكاد يُذكر عند إنشاء البرنامج لأول مرة ، إلا أن إنتروبيا البرامج تنمو مع كل تكرار للتطوير. إذا سمح للمضي قدمًا دون رادع ، فإن إنتروبيا البرمجيات ستؤدي في النهاية إلى توقف المزيد من التطوير.

ومع ذلك ، ليس كل مشروع يجب أن يحسب حساب تأثيرات إنتروبيا البرمجيات. سيتم إخراج العديد من الأنظمة من الإنتاج قبل أن يكون للإنتروبيا تأثيرات ملحوظة وضارة. بالنسبة لأولئك الذين تكون أعمارهم طويلة بما يكفي بحيث تشكل الإنتروبيا خطرًا موثوقًا به ، فإن خلق الوعي بها وقياس مداه ، رغم أنه لا يزال منخفضًا ، يوفر وسيلة لضمان عدم قطع التنمية قبل الأوان.

بمجرد أن تغمر تأثيرات إنتروبيا البرامج على النظام تمامًا ، لا يمكن إجراء المزيد من التغييرات وقد انتهى التطوير بشكل أساسي.