كيف تتوزع التكاليف في هندسة البرمجيات ؟

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

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

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

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

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

توزع التكاليف في نشاطات هندسة البرمجيات

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

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

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

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

الشكل التالي يوجز الكلام السابق.

تكاليف تطوير منتج برمجي عام

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

م. زاهر الحاج حسين (بتصرف عن  Ian Sommerville)