مقياس برمجي

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

المقاييس الشائعة للبرمجيات

تضمن المقاييس الشائعة للبرمجيّات:

  • وثيقة التقييم المتوازنة
  • الآفات في كل سطر من الرمز
  • طريقة كوكومى
  • تغطية الكود
  • التماسك
  • كثافة التعليق [1]
  • مكونات برمجيات كوناسينت
  • الازدواج
  • تركيب سيكلوماتيكى(تركيب ماكابى)
  • تحليل مستوى الدالة
  • تركيب هولستيد
  • طول مسار التعليمات
  • عدد ألأنواع والواجهات
  • عدد سطور الكود
  • عدد سطور متطلبات العميل
  • زمن تنفيذ البرنامج
  • زمن تحميل البرنامج
  • حجم البرنامج (مزدوج)
  • مقاييس حزمة البرمجيات لـ روبرت سيسل مارتين
  • مستويات الدالة الدقيقة الترجيحيّة

التحديدات

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

قد يستهدف الغرض العام للمقياس أحد هذه المجالات بأعلى أو أكثر، أو يستهدف التوازن بينها كمؤشّر لدوافع فريق العمل أو أداء المشروع.

القبول والرأي العام

يشير بعض الممارسين لتطوير البرمجيات إلى أن المقاييس التبسيطيّة قد تضرّ أكثر من أن تنفع.[4] ويلاحظ البعض الآخر أن المقاييس أصبحت جزٌء لا يتجزأ في عمليّة تطوير البرمجيّات.[2] أثارت هذه المقاييس في نفسيّة المبرمجين المخاوف من الآثار السلبيّة على الأداء بسبب الإجهاد وتوتر الأداء ومحاولات الغش في المقاييس، بينما برى الآخرون أنها تحمل تأثير إيجابي على تقييّم المبرمجين لأعمالهم أنفسهم، وتحول دون الاستهانة بهم.[5] ويجادل البعض بأن تعريفات العديد من منهجيّات المقاييس ليست دقيقة، ومن ثمّ لا تتضح أحيانًا طريقة الأدوات في الحساب وتوصّلها لنتائجها المحددة,[6] بينما يجادل البعض الآخر بأن وجود قياس غير دقيق أفضل من لا شيء ("لا يمكنك التحكم في ما لا يمكنك قياسه.”).[7] ويُظهر الدليل أن الهيئات الحكوميّة والجيش ألأمريكي و وكالة ناسا[8] ومستشارين تكنولوجيا المعلومات والمؤسسات ألأكاديمية[9] وبرمجيات تقييم التنمية الأكاديمية والتجاريّة تستخدم جميعها مقاييس البرمجيّات على نطاق واسع.

انظر أيضا


المراجع
  1. "Descriptive Information (DI) Metric Thresholds"، Land Software Engineering Centre، مؤرشف من الأصل في 6 يوليو 2011، اطلع عليه بتاريخ 19 أكتوبر 2010.
  2. Binstock, Andrew، "Integration Watch: Using metrics effectively"، SD Times، BZ Media، مؤرشف من الأصل في 13 سبتمبر 2012، اطلع عليه بتاريخ 19 أكتوبر 2010.
  3. Kolawa, Adam، "When, Why, and How: Code Analysis"، The Code Project، مؤرشف من الأصل في 14 نوفمبر 2011، اطلع عليه بتاريخ 19 أكتوبر 2010.
  4. Kaner, Dr. Cem، Software Engineer Metrics: What do they measure and how do we know?، مؤرشف من الأصل في 26 أبريل 2020
  5. ProjectCodeMeter (2010) "ProjectCodeMeter Users Manual" page 65 نسخة محفوظة 24 مارس 2017 على موقع واي باك مشين.
  6. Lincke, Rüdiger؛ Lundberg, Jonas؛ Löwe, Welf (2008)، "Comparing software metrics tools" (PDF)، International Symposium on Software Testing and Analysis 2008، ص. 131–142، مؤرشف من الأصل (PDF) في 17 أبريل 2018
  7. DeMarco, Tom، Controlling Software Projects: Management, Measurement and Estimation، ISBN 0-13-171711-1.
  8. NASA Metrics Planning and Reporting Working Group (MPARWG) نسخة محفوظة 15 أغسطس 2011 على موقع واي باك مشين.
  9. USC Center for Systems and Software Engineering نسخة محفوظة 11 ديسمبر 2017 على موقع واي باك مشين.

وصلات خارجية

Covers a minimal set of essential metrics for a successful product delivery.

  • بوابة إدارة أعمال
  • بوابة تقنية المعلومات
  • بوابة علم الحاسوب

ويكيبيديا:وصلات خارجية

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.