نموذج الفوضى هو بناء في تطوير البرمجيات يستخدم في عمليات الحوسبة. لاحظ مبتكر النموذج أل بي أس راكون أن النماذج المستخدمة في إدارة المشاريع مثل النموذج الحلزوني ونموذج الشلال قد أثبتت فاعليتها في إدارة التقاويم وغيرها من الأمور إلا أنها لا توفر وسائل لإصلاح الأخطاء البرمجية أو لحل المشاكل التقنية. في الوقت ذاته؛ فإنه على الرغم من فعالية منهجيات البرمجة في إصلاح الأخطاء وحل المشاكل التقنية فإنها لا توفر مساعدة تذكر بخصوص معالجة المواعيد النهائية أو الاستجابة لرغبات العميل ولذا جاء هذا التركيب بغرض ردم هذه الفجوة حيث استُخدم نموذج الفوضى كأداة تساعد في فهم هذه المسائل.[1]
دورة حياة تطوير البرمجيات
ينبه نموذج الفوضى إلى أن مراحل دورة حياة تطوير البرمجيات تنطبق على كافة المستويات الخاصة بالمشاريع ابتداء من المشروع كاملا وحتى سطور الشيفرة البرمجية المفردة.
- يجب تعريف المشروع كاملا وتطبيقه ودمجه معا.
- يجب تعريف الأنظمة وتطبيقها ودمجها معا.
- يجب تعريف الوحدات وتطبيقها ودمجها معا.
- يجب تعريف الدوال البرمجية وتطبيقها ودمجها معا.
- يجب تعريف سطور الشيفرة البرمجية وتطبيقها ودمجها معا.
تتعلق إحدى التغييرات الملحوظة في منظور النموذج بوجوب النظر إلى المشروع كوحدات كاملة أو كفكرة مكونة من عدة أجزاء. لا يوجد شخص قادر على كتابة آلاف السطور البرمجية في جلسة واحدة بل تكتب أجزاء صغيرة من البرنامج بشكل سطر واحد في كل مرة وذلك للتأكد من أن الأجزاء الصغيرة تعمل بشكل صحيح ومن ثم يتابع المبرمج عمله انطلاقا من هذه النقطة. تنبثق الطريقة التي يتصرف بها النظام المعقد من التصرف الجمعي للقوالب الصغيرة التي تكوّن البرنامج.
إستراتيجية الفوضى
إستراتيجية الفوضى هي إستراتيجية خاصة بتطوير البرمجيات ترتكز على نظام الفوضى وتعتمد دائما حل المسائل الأكثر أهمية في البداية كقاعدة أساسية لها بحيث:
- تُعرَّف المسألة بأنها مهمة برمجية غير مكتملة.
- تُعتبر المسألة الأكثر أهمية هي تلك التي تجمع بين كونها كبيرة وملّحة وثابتة.
- تقدم المسائل الكبيرة قيمة للمستخدمين كعمل وظيفي.
- تعتبر المسائل الملحة حساسة للتوقيت وذلك لأن عدم تنفيذها في الوقت المناسب يؤدي إلى تأخير الأعمال الأخرى المتعلقة بها.
- أما المسائل الثابتة؛ فهي موثوق بها وقد تم اختبارها بحيث يمكن للمطورين أن يوجهوا تركيزهم إلى أماكن أخرى وبكل ثقة.
- ويعني حل المسألة الوصول بها إلى نقطة استقرار.
تشبه إستراتيجية الفوضى الطريقة التي يعمل بها المبرمجون للوصول إلى نهاية المشروع في حال وجود سلسلة من الأخطاء التي تستوجب التصحيح ومجموعة من الخصائص التي من الواجب ابتكارها وغالبا ما يقوم شخص ما بتحديد أولوية المهام المتبقية بحيث يقوم المبرمجون بإصلاحها في وقت واحد. تنص إستراتيجية الفوضى على كون هذه الطريقة هي الطريقة الوحيدة الصالحة لأداء العمل وقد استوحيت من استراتيجية غو.
علاقات النموذج بنظرية الشواش
توجد العديد من الروابط التي تربط النموذج بنظرية الشواش وهي:
- قد يساعد نموذج الفوضى في تحديد السبب الذي يتسبب في ميل البرنامج لأن يكون غير متوقعا.
- قد يفسر السبب الذي لا يمكن بواسطته معاملة المبادئ عالية المستوى مثل معمارية الحاسوب بشكل مستقل عن أسطر الشيفرة البرمجية الأقل مستوى.
- يوفر مشجبا يمكن عليه تعليق شرح ما سيحصل لاحقا من حيث استراتيجية الفوضى.
مراجع
قراءات إضافية
- Roger Pressman (1997) Software Engineering: A Practitioner's Approach 4th edition, pages 29–30, McGraw Hill.
- Raccoon (1995) The Chaos Model and the Chaos Life Cycle, in ACM Software Engineering Notes, Volume 20, Number 1, Pages 55 to 66, January 1995, ACM Press.