إنتاجية برمجية

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

• كم الكود الذي يستطيع المبرمج إنتاجه أو صيانته (عادة يقاس بعدد أسطر الكود في اليوم)
• اكتشاف الأخطاء وتجنبها (من خلال أساليب مثل إدارة ستة سيجما، كتابة الكود بطريقة العيوب صفر zero defects، وإدارة الجودة الشاملة)
• تقدير تكلفة البرمجيات (حيث أن الإنتاجية تنعكس بشكل مباشر على التكلفة)

تفاوتت أهمية الإنتاجية وبعض العوامل أخرى المؤثرة في هذا المجال مثل:

• تكلفة الاستعانة بالعمالة البشرية مقارنة بالآلة
• القوى العاملة المتاحة من مختلف أنحاء العالم عبر الإنترنت بأجور أقل كثيرا من المعتاد
  • أمثلة:
    • http://www.wired.com/wired/archive/12.02/india.html?pg=7
    • http://www.wired.com/wired/archive/12.02/india.html
• حجم وتعقيد الأنظمة المراد بناؤها
• المشاريع الشهيرة التي واجهت مشاكل في الجودة أو الالتزام بالجدول الزمني
• ظهور أساليب ووسائل تكنولوجية جديدة لمعالجة مشاكل الإنتاجية
• تقنيات ومقاييس عملية إدارة الجودة
• المبالاة قد تكون سبب (يجب أن تصبح الإنتاجية هدف)

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

علاقة عتاد الحاسب بإنتاجية المبرمج

ليس من العدل تقييم إنتاجية المبرمج بدون النظر إلى الأدوات المقدمة له من عتاد وبرمجيات، فمثلا: المبرمج الذي يتعامل مع شاشتين من المحتمل أن تكون إنتاجيته أعلى ممن يتعامل مع شاشة واحدة. مع انخفاض تكلفة سواقة الحالة الصلبة solid-state drive يمكن أن يعد المبرمج عتاده ليتمكن من ترجمة الكود compilation بشكل أسرع، وهو ما تحتاجه الأساليب الجديدة في عالم تطويرالبرمجيات مثل TDD (التطوير المرتكز على الاختبار test driven development).

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

في هذه الأيام كان المسؤولون عن المشاريع الضخمة لتطوير أنظمة بأكملها - ومعها غالبا المكونات التابعة للنظام (مثل محركات إدارة البيانات data management engines وأنظمة التحكم الطرفية terminal control systems) - ينفذون هذه المشاريع بدون تسجيل الأخطاء والمشاكل التي تحدث في عملية التطوير، مما أدى إلى وجود عدد ضخم من المسئولين عن معالجة البيانات في المؤسسات الكبيرة قد يصل إلى المئات أو الآلاف من مبرمجي لغة التجميع وكوبول وجوفيال وأيدا أو أي أدوات مستخدمة وقتها.

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

أدت الحاجة إلى رفع إنتاجية المبرمج إلى نقلات نوعية في أساليب البرمجة، تأتي من:

• سرعة إنتاج الكود
• أسلوب الصيانة
• التكنولوجيا الجديدة
• منحنى التعلم (التدريب مطلوب)
• أسلوب الاختبار

المراجع

• Software Cost Estimation with Cocomo II, باري بوهم et al., Prentice Hall, 2000. ISBN 978-0130266927.
• Developing Products in Half the Time: New Rules, New Tools, Preston G. Smith and Donald G. Reinertsen, Wiley, 1997. ISBN 978-0471292524
• Programming Productivity, Capers Jones, Mcgraw-Hill, 1986. ISBN 978-0070328112
• Estimating Software Costs, Capers Jones, McGraw-Hill, 2007. ISBN 978-0071483001

Internet articles

• "Coding Horror: Joining The Prestigious Three Monitor Club" (December 2006) http://www.codinghorror.com/blog/2006/12/joining-the-prestigious-three-monitor-club.html
• "Coding Horror: The Programmer's Bill of Rights" (August 2006) http://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html
• "Dual Monitors", Bob Rankin http://askbobrankin.com/dual_monitors.html

"... studies I've read come to the same conclusion: having a dual monitor in a workplace setting can increase productivity by 20 to 50 percent. If you're a computer programmer, it should be obvious that having your source code on one side and your program on the other side of a dual monitor display would be very helpful. Other areas where a dual monitor setup are helpful include customer service reps, web design, and creation of newsletters or PowerPoint presentations."