تقدير وتخطيط البرمجيات

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

Definition

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

Scope

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

Core questions

• كيف يتم قياس حجم البرمجيات لدفع التقديرات؟
• كيف تقارن الأساليب الخوارزمية، والمماثلة، وحكم الخبراء؟
• كيف يتم تمثيل وتقليل عدم اليقين مع تقدم المشروع؟
• كيف يختلف التخطيط المرن بالسرعة عن الجدولة المسبقة؟

Key theories

نماذج التكلفة الخوارزمية

تعبر النماذج مثل COCOMO عن الجهد والجدول الزمني كدوال معايرة للحجم المقدر ومحركات تكلفة المشروع، مما يوفر تقديرات قابلة للتكرار يمكن تعديلها باستخدام البيانات التاريخية.

تحديد حجم نقاط الوظائف

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

Clinical relevance

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

Evidence & guidelines

توفر الأبحاث التجريبية حول دقة التقدير والنماذج مثل COCOMO II إرشادات قائمة على الأدلة، ويخضع عد نقاط الوظائف لمعايير IFPUG و ISO/IEC لقياس الحجم الوظيفي.

History

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

Debates

التقدير مقابل حركة عدم التقدير

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

Key figures

• Barry Boehm
• Allan Albrecht
• Steve McConnell

Seminal works

• boehm1981
• albrecht1983
• mcconnell2006

Frequently asked questions

لماذا غالبًا ما تكون تقديرات البرمجيات خاطئة؟

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

هل نقاط القصة مجرد ساعات مقنعة؟

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