أزمة البرامجيات (Software Crisis):

المـحـاضـرة الأولــــــــى

                                                   

مـقـدمـة:

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

أزمة البرامجيات (Software Crisis):

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

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

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

        فمن الناحية الأولى، يجب أن يكون المبرمج شخصا علمياً. بمعنى انه يعمل على أساس مؤلف من نظريات (Theory) واضحة أكيدة، ومجموعة مبادئ مطبقة ( Principles ). فعلى سبيل المثال يمكن للمبرمج إن يستخدم تقنيات البرمجة مثل تحليل البنى(Structural Analysis  )، والتصميم غرضي التوجه      (Object Oriented Design) أو المفاهيم الرياضية لنظرية التحليل العددي، وبحوث العمليات. أما من الناحية الأخرى، يجب أن يكون المبرمج أيضا شخصاً فناناً، ينحت ويركب مكونات النظام من المواد الخام لبنى المعطيات (Data Structure) والخوارزميات (Algorithms)، ومن ثم يجمع الأجزاء ليشكل هذا النظام. ومن المحتمل أن هذه الثنائية هي التي تجعل المعلوماتية علماً أخاذاً، وتتسبب بالمقابل بالكثير من المشاكل.

طبيعة الأزمة (The Nature of The Crisis):

إن القول بوجود أزمة برامجيات (Software Crisis)، يعتبر صيغة سطحية، ففي واقع الحال هنالك اختلاف بسيط عما يمكن تسميته "أزمة".

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

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

  وبمعنى آخر، يتمثل جوهر أزمة أو مرض البرامجيات، بأن بناء نظم برمجية أصعب بكثير مما نشعر أو نحس به.

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

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

الأسباب الرئيسية للأزمة (Underlying Causes of The Crisis):

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

وقد اقترح Devlin عدة أسباب للأزمة، منها:

©   إخفاق في تنظيم وفهم دورة الحياة التي تؤدي لتطور البرنامج.

©   نقص في عدد الأشخاص المؤهلين في هندسة البرامجيات.

©   إن أسس Van Neumann لمعظم آلاتنا، لا تشجع استخدام أساليب البرمجة العصرية.

©   الاتجاه للاعتصام باستخدام لغات برمجة قديمة وغير عملية.

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

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