جودة البرمجيات

تشير جودة البرمجيات (بالإنجليزية: Software quality)‏ في سياق هندسة البرمجيات إلى مفهومين مرتبطين ولكنهما مخلتفان:

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

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

عادةً ما تقيّم الجودة الوظيفية ديناميكيًا، لكن من الممكن أيضًا استخدام الاختبارات الثابتة (مثل مراجعات البرمجيات).

من الناحية التاريخية، اشتُقت أو استُخرجت البنية والتصنيف ومصطلحات السمات والمقاييس المطبقة على إدارة جودة البرمجيات من معيار أيزو 9126-3 ونموذج الجودة التالي أيزو 25000:2005،[3] المعروف أيضًا باسم «سكويرSQuaRE ».[4] واستنادًا إلى هذه النماذج، حدد اتحاد جودة برمجيات تكنولوجيا المعلومات خمس خصائص هيكلية رئيسية مرغوبة وضرورية لجزء من البرمجيات لتوفير قيمة الأعمال: المصداقية، والكفاءة، والأمان، وإمكانية الصيانة، والحجم المناسب.

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

لعرض، واستكشاف، وتحليل ونقل قياسات جودة البرمجيات، توفر مفاهيم وتقنيات تصور المعلومات وسائل مرئية وتفاعلية مفيدة، خاصة إذا كان يجب أن ترتبط عدة إجراءات لجودة البرامج بعضها ببعض أو بمكونات برمجية أو نظام. مثلًا، تمثل الخرائط البرمجية نهجًا متخصصًا «يمكنه التعبير عن المعلومات المتعلقة بتطوير البرمجيات وجودة البرمجيات وديناميكيات النظام وجمعها»[5]

الدافع

«ينضج العلم بنضج أدوات قياسه» (لويس باستور في إيبرت ودومك، ص 91). يحفّز قياس جودة البرامج بسببين على الأقل:

  • إدارة المخاطر: يسبب فشل البرمجيات أكثر من مجرد إزعاج. تسببت الأخطاء البرمجية في حدوث وفيات بشرية. وتراوحت الأسباب من واجهات المستخدم سيئة التصميم إلى أخطاء البرمجة المباشرة. ونوقش أحد الأمثلة على الخطأ البرمجي الذي أدى إلى عدة وفيات في بحث الدكتور ليفيسون.[6] نتج عن ذلك متطلبات لتطوير بعض أنواع البرمجيات، بشكل خاص وتاريخي بالنسبة للبرمجيات المضمنة في الأجهزة الطبية وغيرها من الأجهزة التي تنظم البنى التحتية الهامة:» لاحظ [المهندسون الذين يكتبون البرمجيات المضمنة [أن برامج جافا تتعطل لمدة ثلث ثانية لإجراء تجميع النفايات «البيانات عديمة النفع»[7] وتحديث واجهة المستخدم، ويتصورون سقوط الطائرات من السماء بسببها». في الولايات المتحدة، ضمن إدارة الطيران الفيدرالية، توفر خدمة ترخيص الطائرات برامج وسياسات وإرشادات وتدريبات برمجية، تركز على البرمجيات والأجهزة الإلكترونية المعقدة التي لها تأثير على المنتج المحمول جوًا («المنتج» هو الطائرة أو المحرك أو المروحة).[8]
  • إدارة التكاليف: كما هو الحال في أي مجال هندسي آخر، فإن التطبيق الذي يتميز بجودة برمجية هيكلية جيدة تكون تكلفة صيانته أقل، ويكون أسهل للفهم والتغيير استجابة لاحتياجات الأعمال الملحة. توضح البيانات الصناعية أن الجودة الهيكلية السيئة للتطبيقات في تطبيقات الأعمال الأساسية (مثل تخطيط موارد المؤسسة «إي آر بّي» أو إدارة علاقات العملاء «سي إر إم» أو نظم معالجة المعاملات الكبيرة في الخدمات المالية) تؤدي إلى زيادة التكلفة والجدول الزمني، وتتسبب هدرًا في شكل إعادة العمل (ما يصل إلى 45% من وقت التطوير في بعض المؤسسات).[9] ترتبط أيضًا الجودة الهيكلية السيئة ارتباطًا قويًا باضطرابات العمل شديدة التأثير الناجمة عن البيانات الفاسدة، وانقطاع التطبيقات، والانتهاكات الأمنية، ومشاكل الأداء.

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

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

التعاريف

هناك العديد من التعريفات المختلفة للجودة. بالنسبة للبعض، هي «قدرة منتج البرنامج على الامتثال للمتطلبات» (أيزو/ آي إي سي 9001).[10] بينما بالنسبة للآخرين، يمكن أن تكون مرادفة لـ«قيمة العميل» (هايسمث، 2002) أو حتى مستوى العيب.

يُنسب أول تعريف مسجل تاريخيًا للجودة لشيوارت في بداية القرن العشرين: هناك جانبان شائعان للجودة: يتعلق أحدهما بجودة شيء ما باعتباره واقع موضوعي مستقل عن وجود الإنسان. أما الآخر فيتعلق بما نفكر فيه أو نحس أو نشعر به نتيجة للواقع الموضوعي. وبعبارة أخرى، هناك جانب ذاتي من الجودة. (شيوارت)[11]

كيتشنهام وفليغر وغارفين خمس وجهات نظر حول الجودة

قدّم كيتشنهام وفليغر تقارير أخرى عن تعاليم ديفيد غارفين، وحددوا خمسة وجهات نظر مختلفة حول الجودة:[12]

  • يتعامل المنظور الغيبي مع الجانب الميتافيزيقي للجودة. وفي هذا الرأي تُعتبر الجودة «شيء نسعى لأن يكون مثاليًا، ولكن لا يمكن تنفيذه بالكامل». ولا يمكن تعريفه إلا كما علق القاضي الفيدرالي سابقًا عن الفحش: «أعرفه عندما أراه».
  • يهتم منظور المستخدم بمدى ملاءمة المنتج لسياق معين من الاستخدام. في حين أن طريقة العرض الغيبية غير محددة، فإن طريقة عرض المستخدم أكثر واقعية، وهي تستند إلى خصائص المنتج التي تلبي احتياجات المستخدم.
  • يمثل منظور التصنيع الجودة كمطابقة للمتطلبات. هذا الجانب من الجودة تشدد عليه عدة معايير مثل معيار أيزو 9001، الذي يعرّف الجودة أنها «الدرجة التي تلبي بها مجموعة من الخصائص الأساسية المتطلبات» (أيزو/ آي إي سي 9001).[13]
  • يتضمن منظور المنتج أنه يمكن تقدير الجودة بقياس الخصائص الأساسية للمنتج.
  • أما المنظور النهائي للجودة فهو يعتمد على القيمة. يدرك هذا المنظور أن المنظورات المختلفة للجودة قد يكون لها أهمية أو قيمة مختلفة بالنسبة لمختلف أصحاب المصلحة.

مراجع
  1. Pressman, Roger S. (2005). Software Engineering: A Practitioner's Approach (الطبعة Sixth International). McGraw-Hill Education. صفحة 388. ISBN 0071267824. الوسيط |CitationClass= تم تجاهله (مساعدة)
  2. "How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations". مؤرشف (PDF) من الأصل في 28 ديسمبر 2013. اطلع عليه بتاريخ 18 أكتوبر 2013. الوسيط |CitationClass= تم تجاهله (مساعدة)
  3. "ISO 25000:2005" (PDF). مؤرشف (PDF) من الأصل في 14 أبريل 2013. اطلع عليه بتاريخ 18 أكتوبر 2013. الوسيط |CitationClass= تم تجاهله (مساعدة)
  4. "ISO/IEC 25010:2011". ISO. مؤرشف من الأصل في 14 مارس 2016. اطلع عليه بتاريخ 14 مارس 2016. الوسيط |CitationClass= تم تجاهله (مساعدة)
  5. J. Bohnet, J. Döllner نسخة محفوظة 2014-04-27 على موقع واي باك مشين., "Monitoring Code Quality and Development Activity by Software Maps". Proceedings of the IEEE ACM ICSE Workshop on Managing Technical Debt, pp. 9-16, 2011.
  6. Medical Devices: The Therac-25* نسخة محفوظة 2008-02-16 على موقع واي باك مشين., Nancy Leveson, University of Washington
  7. Embedded Software نسخة محفوظة 2010-07-05 على موقع واي باك مشين., Edward A. Lee, To appear in Advances in Computers (M. Zelkowitz, editor), Vol. 56, Academic Press, London, 2002, Revised from UCB ERL Memorandum M01/26 University of California, Berkeley, CA 94720, USA, November 1, 2001
  8. "Aircraft Certification Software and Airborne Electronic Hardware". مؤرشف من الأصل في 04 أكتوبر 2014. اطلع عليه بتاريخ 28 سبتمبر 2014. الوسيط |CitationClass= تم تجاهله (مساعدة)
  9. Improving Quality Through Better Requirements (Slideshow) نسخة محفوظة 2012-03-26 على موقع واي باك مشين., Dr. Ralph R. Young, 24/01/2004, Northrop Grumman Information Technology [وصلة مكسورة]
  10. International Organization for Standardization, "ISO/IEC 9001: Quality management systems -- Requirements," 1999.
  11. W. A. Shewhart, Economic control of quality of manufactured product. Van Nostrand, 1931.
  12. B. Kitchenham and S. Pfleeger, "Software quality: the elusive target", IEEE Software, vol. 13, no. 1, pp. 12–21, 1996.
  13. S. H. Kan, "Metrics and Models in Software Quality Engineering", 2nd ed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002.
    • بوابة برمجيات
    • بوابة برمجة الحاسوب
    في كومنز صور وملفات عن: جودة البرمجيات
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.